noob_臭代码-Java Noob的自白

noob

The topic of "code smell" is rather fascinating, as well as rather "geeky". Is it better to learn from one's own mistakes while developing in a new programming language, or, seeing the coding mishaps of someone else?

“代码气味”的主题既令人着迷，又令人讨厌。 在使用新的编程语言进行开发时从自己的错误中学习，还是看到别人的编码事故，是更好的选择吗？

Here are some interesting points of "code smells" that most OOP (Object-Oriented Programming) "noob" developers could probably use to get better at Java / OOP PHP.

以下是一些“代码味道”的有趣之处，大多数OOP（面向对象编程）“菜鸟”开发人员可能会使用它们来提高Java / OOP PHP的水平。

Great examples of code smells are realized when a developer is tasked with having to go back and rework multiple developers' code for a maintenance and upgrade project for an employer. A common example might be a Web Portal that POUNDS on a SQL database by taking field level values of a result set of a SQL query, and creates new queries from that result set, and sends NEW queries on different JOINed tables/views to produce reporting. The database servers capacity and internet pipe might be PATHETIC for what the company is trying to accomplish, so imagine optimization is rather critical in this case. The "too many cooks in one kitchen" code was thrown together to make an impossible deadline, and with little to no business requirements. It is a disaster to unravel... BUT... it somehow work! Even though, it is still slow during peak usage times, but fully functional for the most part. Does it have a bunch of bugs? No... not really. It likely just lacks design, structure and consistency and n serious need of some "code deodorant".

当开发人员被要求回去为雇主进行维护和升级项目而不得不返工并重做多个开发人员的代码时，就会意识到代码气味的绝佳示例。 一个常见的示例可能是Web门户网站，该门户网站通过获取SQL查询结果集的字段级值在SQL数据库上进行充值，并从该结果集中创建新查询，并在不同的JOINed表/视图上发送新查询以生成报告。 数据库服务器的容量和Internet管道可能对于公司要实现的目标而言是不切实际的，因此可以想象在这种情况下优化至关重要。 “一个厨房里厨师太多”的代码被拼凑成一个不可能的截止日期，几乎没有业务需求。 要解散真是一场灾难...但是...以某种方式起作用！ 即使在高峰使用时间它仍然很慢，但是在大多数情况下都可以正常运行。 它有很多错误吗？ 不，不是。 它可能只是缺乏设计，结构和一致性，并且根本不需要某些“代码除臭剂”。

From: http://www.codinghorror.com/blog/2006/05/code-smells.html We get three great definitions for "Lazy Class", "Feature Envy" and "Indecent Exposure".

来自： http : //www.codinghorror.co m /博客/ 200 6/05 / code- 气味.htm l对于“懒惰类”，“特征嫉妒”和“不雅暴露”，我们得到了三个很好的定义。

懒人班 (Lazy Class)

Classes should pull their weight. Every additional class increases the complexity of a project. If you have a class that isn't doing enough to pay for itself, can it be collapsed or combined into another class?

班级应尽力而为。 每增加一个类，都会增加项目的复杂性。 如果您的一门课程做得还不够，可以将其折叠或合并为另一门课程吗？

OOP "noobs" tend to make a class with the anticipation of needing if for a number of reasons in the future during the planning phase, but then end up only using it as a sort of "stepping stone" and have other classes do the heavy lifting. Perhaps one could get rid of some of the getters/setters they (or a sophisticated IDE like NetBeans or Eclipse) create for example. Since many attributes can be present in a class, getters/setters are usually a benefit to data encapsulation so a developer new to OOP may feel reluctant to hit the delete key because of thoughts such as "Just leave it in there. It may be needed for some reason eventually...", when it often does not.

OOP的“新手”倾向于在将来有计划的情况下上课，如果出于某些原因，将来在计划阶段，则最终将其用作“垫脚石”，而让其他班级承担重担起重。 例如，也许可以摆脱他们（或诸如NetBeans或Eclipse这样的复杂IDE）创建的一些getter / setter。 由于一个类中可以存在许多属性，因此getter / setter方法通常对数据封装是有好处的，因此，刚接触OOP的开发人员可能会因为诸如“只需将其留在那儿”之类的想法而不太愿意按Delete键。出于某种原因最终……”，但通常情况并非如此。

功能羡慕 (Feature Envy)

Methods that make extensive use of another class may belong in another class. Consider moving this method to the class it is so envious of.

广泛使用另一个类的方法可能属于另一个类。 考虑将这种方法移到令人羡慕的类上。

During the initial design of the application, procedural developers tend to compartmentalize what tasks need to happen by creating multiple methods to do each "thing" individually. By the time the developer is over halfway finished, the often realize that some of the methods are doing very much the same thing. If they were to just add an if/else statement to one method, I could potentially eliminate another completely.

在应用程序的初始设计过程中，过程开发人员倾向于通过创建多种方法来分别执行每个“操作”来区分需要执行的任务。 当开发人员完成一半时，通常会意识到某些方法在做的事情非常相似。 如果他们只是将if / else语句添加到一个方法中，则可能完全消除另一个方法。

不雅暴露 (Indecent Exposure)

Beware of classes that unnecessarily expose their internals. Aggressively refactor classes to minimize their public surface. You should have a compelling reason for every item you make public. If you don't, hide it.

当心那些不必要地暴露其内部的类。 积极重构类，以最大程度地减少其公开露面。 每个公开的项目都应该有令人信服的理由。 如果不这样做，请将其隐藏。

Object-Oriented Design (OOD) is often a completely new idea to a developer that has experience with procedure style coding, so the idea of "data hiding" seems unnatural. In fact, many time a developer with go out of the way to create function libraries into a single "include file" in PHP, and add the include statement to each of my web page "header" templates so the can access code such as function libraries on the all the pages of the site, "just in case". Solid OOD principles push a developer to start seeing the benefits of the "private" methods/classes as a means of controlling the "flow" of a Java / OOP PHP applications so that they can quickly say "oh, that's a private method, so other methods cannot be changing the value there... where else could it be happening?" It provides an experienced procedural developer with an entirely new way of thinking when develop applications. It is a bit more cumbersome in the design process, but the end result is quite a bit more "fluid" and elegant.

面向对象设计（OOD）对于具有过程样式编码经验的开发人员来说通常是一个全新的想法，因此“数据隐藏”的想法似乎不自然。 实际上，很多时候，开发人员会竭尽全力在PHP中将函数库创建到单个“ include文件”中，并将include语句添加到我的每个网页“ header”模板中，以便可以访问诸如函数之类的代码。网站所有页面上的库，以防万一。 可靠的OOD原则促使开发人员开始将“私有”方法/类的好处视为控制Java / OOP PHP应用程序“流”的一种方式，以便他们可以快速说“哦，这是私有方法，因此其他方法不能在那改变值...那又会发生什么呢？” 它为经验丰富的过程开发人员提供了开发应用程序时的全新思维方式。 它在设计过程中比较麻烦，但是最终结果却更加“流畅”且优雅。

From: http://en.wikipedia.org/wiki/Code_smell

来自： http : //en.wikipedia.org/wi ki / Code_sm ell

In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don't currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.

在计算机编程中，代码气味是程序源代码中的任何症状，可能表明存在更深层的问题。 代码气味通常不是错误-从技术上讲它们不是错误的，并且当前不阻止程序运行。 相反，它们表明设计中的弱点可能会减慢开发速度，或增加将来出现错误或故障的风险。

And lastly, From: http://c2.com/xp/CodeSmell.html

最后，来自： http : //c2.com/xp/CodeSmell .html

代码不足（最好将半熟的代码放回烤箱中一会儿） (Not enough code (better put the half-baked code back in the oven a while))

Explicitly setting variables to null. Can indicate that either there are references to things that this code has no business referencing, or the structure is so complex that the programmer doesn't really understand it and feels the need to do this to be safe.

将变量显式设置为null。 可以表明存在对代码没有业务引用的事物的引用，或者结构太复杂以致程序员无法真正理解它，并认为这样做很安全。

An ounce of prevention is worth a pound of cure. Sometimes developers will expect to need some variable or method for some lesser purpose, but later forget what it was created it for after lunch with the VP, or perhaps feel the need to assign it a value so that they do not try to calculate or concatenate with a NULL value with the legendary PHP check:

一盎司的预防值得一磅的治疗。 有时，开发人员会期望出于某些次要目的而需要一些变量或方法，但后来却忘记了与VP共进午餐后为变量或方法创建的内容，或者感到有必要为其分配值，以便他们不尝试计算或连接带有传奇PHP检查的NULL值：

<?php
if (is_null($some_junk) == false) {
echo "Do you want to go play pool or ".$some_junk."?";
} else {
echo "I don't have a thing to wear tonight.";
}
?>

The more a new OOP developer can find a useful implementation to practice Java / OOP PHP, the better they will get at it. Hopefully reading this article and some more practice, much like with these developers' beginnings with Perl or PHP, they can get better at the planning and design process and prevent such smelly code they may have laid thus far as an OOP noob.

新的OOP开发人员可以找到更多有用的实现来实践Java / OOP PHP的实现，他们将越能从中受益。 希望阅读本文和更多实践，就像这些开发人员从Perl或PHP入手时一样，他们可以在规划和设计过程中变得更好，并防止他们可能编写的直到OOP入门的臭代码。

翻译自: https://www.experts-exchange.com/articles/10738/Smelly-Code-Confessions-of-a-Java-Noob.html

noob