22种代码味道（Martin Fowler与Kent Beck）
Martin Fowler在Refactoring: Improving the Design of Existing Code（中譯名：《重構——改善既有代碼的設計》）一書中與Kent Beck一起總結了22種代碼壞味(Bad Smells in Code)，因為Sunny這段時間正在做一些與代碼味道自動識別與自動重構有關的研究工作，對這些內容進行了重新的深入理解與分析。后續將在博客中轉載和原創一些相關的文章，希望對廣大從事軟件開發的朋友們能夠帶來些許幫助。你在編程過程中面臨哪些代碼味道？哪些代碼味道你覺得最應該消除？對于消除這些代碼味道你有何意見和建議？歡迎大家與我一起交流討論。
?????? 注：本文中，代碼壞味道的中文名稱源于侯捷和熊節的中譯本《重構——改善既有代碼的設計》。
?
????? 類內味道
????? 1、Measured Smells（可度量的味道）
?????? (1) Long Method（過長方法）
?????? A method is too long.（方法太長。）
??????? (2) Large Class（過大類）
?????? A class is trying to do too much, it often shows up as too many instance variables.（一個類試圖做太多的事情，通常會出現太多的實例變量。）
?????? (3) Long Parameter List（過長參數列）
?????? A method needs passing too many parameters.（一個方法需要傳遞太多的參數。）
?????? (4)?Comments（過多的注釋）
?????? Do not write comments when it is unnecessary. When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.（在非必要的情況下不要寫注釋。當你覺得需要去寫一段注釋時，你首先應該嘗試去重構代碼，這將使任何注釋都變得是多余的。）
?
????? 2、Unneccessary Complexity（不必要的復雜性）
?????? (5) Speculative Generality（夸夸其談的未來性）
?????? If a machinery was being used, it would be worth it. But if it is not, it is not. The machinery just gets in the way, so get rid of it.（如果一個裝置【一個設計或實現方案】會被用到，那就值得去做；如果用不到，就不值得。用不到的裝置會成為攔路石，因此需要將它搬移。）
?
????? 3、Duplication（重復）
?????? (6) Duplicated Code（重復代碼）
?????? Same code structure happens in more than one place.（在一個以上的地方發現相似的代碼結構。）
?????? (7) Alternative Classes with Different? Interfaces（異曲同工的類）
?????? Classes are doing similar things but with different signatures. （不同的類做相同的事情，卻擁有不同的簽名，主要是指方法簽名不同。）
?
????? 4、Conditional Logic（條件邏輯）
?????? (8) Switch Statements（Switch驚悚現身）
?????? Switch statements often lead to duplication. Most times you see a switch statement which you should consider as polymorphism.（Switch語句通常會導致代碼重復。大多數時候，一看到Switch語句你應該考慮使用多態來替換。）
?
?
???? 類間味道
???? 1、Data（數據）
?????? (9) Primitive Obsession（基本類型偏執）
?????? Primitive types are overused in software. Small classes should be used in place of primitive types in some situations.（在軟件中，基本類型被過度使用。在某些場合下，應該使用一些小的類來代替這些基本類型。）
?????? (10) Data Class（純稚的數據類）
????? These are classes that have fields, getting and setting methods for the fields, and nothing else. Such classes are dumb data holders and are almost certainly being manipulated in far too much detail by other classes.（這些類擁有一些字段【成員變量】，并提供了對應的Getter和Setter方法，除此以外一無所有。這些類只是一些不會說話的數據容器， 而且它們必定會被其他類過分瑣細地操作。）
?????? (11) Data Clumps（數據泥團）
?????? Some data items together in lots of places: fields in a couple of classes, parameters in many method signatures.（一些數據項同時出現在多個地方：例如一對類中的值域【成員變量】，多個方法簽名中的參數等。）
?????? (12) Temporary Field（令人迷惑的暫時值域）
?????? Sometimes you see an object in which an instance variable is set only in certain circumstances. Such code is difficult to understand, because you expect an object to need all of its variables.（有時候你會看到一個對象的實例變量僅為某些特定的場合而設。這樣的代碼將導致難以理解，因為你期望一個對象需要它所有的變量。）
?
???? 2、Inheritance（繼承）
?????? (13) Refused Bequest（被拒絕的遺贈）
?????? Subclasses get to inherit the methods and data of their parents, but they just use a few of them.（子類繼承父類的方法和數據，但是它們只需要使用其中的一部分。）
?????? (14) Inappropriate Intimacy（狎昵關系）
?????? Sometimes classes become far too intimate and spend too much time delving in each others’ private parts.（有時候，類之間的關系變得非常親密，并且需要花費大量時間來探究彼此之間的私有成分。）
?????? (15) Lazy Class（冗贅類）
?????? Each class you create costs money to maintain and understand. A class that is not doing enough to pay for itself should be eliminated.（你所創建的每個類都需要花錢去維護和理解。一個類如果不值其身價，它就應該消失。）
?
????? 3、Responsibility（職責）
?????? (16) Feature Envy（依戀情節）
?????? The whole point of objects is that they are a technique to package data with the processes used on that data. A Feature Envy is a method that seems more interested in a class other than the one it actually is in.（對象的全部要點在于它是一種封裝數據以及施加于這些數據的處理過程的技術。依戀情節是指一個方法對別的類的興趣高過它本身所在的類。）
?????? (17) Message Chains（過度耦合的消息鏈）
?????? You see message chains when a client asks one object for another object, which the client then asks for yet another object, which the client then asks for yet another object, and so on. Navigating in this way means that the client is coupled to the structure of the navigation. Any change to the intermediate relationships causes the client to have to change.（你看到的消息鏈是這樣的：當一個客戶端向一個對象請求另一個對象，然后再向后者請求另一個對象，然后再請求另一個對象，如此反復。這種方式的導航意味著客戶端將與整個導航結構緊密耦合在一起。一旦對象之間的聯系發生任何改變，將導致客戶端也不得不做出相應的修改。）
?????? (18) Middle Man（中間轉手人）
?????? You look at a class’s interface and find that half the methods are delegating to this other class. It may mean problems.（當你審查一個類的接口時發現其中有一半的方法都委托給了其他類，這也許就意味著存在問題了。）
?
?????4、Accommodating Change（協調變化）
?????? (19) Divergent Change（發散式變化）
?????? Divergent change occurs when one class is commonly changed in different ways for different reasons.（如果某個類經常因為不同的原因在不同的方向上發生變化就會產生發散式變化。也就是說，一個類擁有多個引起它發生變化的原因。）
?????? (20) Shotgun Surgery（霰彈式修改）
?????? Shotgun surgery is similar to divergent change but is the opposite. Every time you make a kind of change, you have to make a lot of little changes to a lot of different classes.（霰彈式修改與發散式變化類似，卻又存在相反的一面。每次進行某種修改時，你都必須對多個不同的類進行很多對應的小修改。）
?????? (21) Parallel Inheritance Hierarchies（平行繼承體系）
?????? Parallel inheritance hierarchies is really a special case of shotgun surgery. In this case, every time you make a subclass of one class, you also have to make a subclass of another. You can recognize this smell because the prefixes of the class names in one hierarchy are the same as the prefixes in another hierarchy.（平行繼承體系是霰彈式修改的一個特例。在這種情況下，當你為某個類增加一個子類時，你不得不為另一個類也相應增加一個子類。你也許能夠識別到這種味道，因為一個繼承體系中類的類名前綴與另一個體系中的類名前綴一樣。）
?
???? 5、Library Classes（庫類）
?????? (22) Incomplete Library Class（不完善的程序庫類）
?????? Library classes should be used carefully, especially we do not know whether a library is completed.（庫類在使用時一定要小心，特別是在我們不知道一個庫是否完整時。）
?
?
【作者：劉偉?http://blog.csdn.net/lovelion】?
from:?http://blog.csdn.net/lovelion/article/details/9301691
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的22种代码味道（Martin Fowler与Kent Beck）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件重构过程中的思维转换: 遗留代码如何
- 下一篇： JVM字节码