12、Lazy Class – 冗贅類
對於幾乎沒有用的類，運用inline class 將其功能移動。去除這些不值得維護的類。
13、Speculative Generality – 誇誇其談未來性
對於你現在用不到，覺得總有一天會用到的代碼，要警惕。用不上的裝置總會擋我們的路，所以要儘量搬開。例如，沒有太大作用的abstract class，非必要的委託，沒有用到的函數參數，或者是函數的名稱帶有多餘的抽像的意味。
14、Temporary Field – 令人迷惑的暫時值域
如果某些變量只是爲了某種特定情況而設的，常會讓人不理解
15、Message Chains – 過度耦合的消息鏈
你常會看到用戶向一個對象請求另一個對象，然後再向後者請求另一對像，然後再繼續…形成了一個強耦合的消息鏈。一旦對像間的關係發生任何變化，客戶不得不做出大量修改。
16、Middle Man –中間轉手人
Encapsulation – 封裝，對外部世界隱藏內部細節。封裝常常伴隨delegation（委託），但如果被過度使用，就必須得重新考慮。如果你看到某個class中有一半的函數都委託給其它class，這時就是強烈地信號。
17、Inappropriate Intimacy – 狎暱關係
二個類之間的關係聯繫太過緊密，造成強耦合。一般來講，繼承往往會造成這樣結果，因爲subclass對superclass的瞭解總是超過superclass的主觀願望。
18、Alternative Classed with Different Interfaces? -- 異曲同工的類
二個函數做同樣的事，卻有着不同的名字。你該知道怎麼處理了吧。
19、Incomplete Library Class – 不完美的程序庫類
我們在運用程序類庫的時候，發現它並不是真正適合需要。
20、Data Class 純稚的數據類
找到Data Class 中可能存在的public的值域，如果它的fields中存在容器類，就要小心地檢查是不是得到了有效的封裝。
21、Refused Bequest – 被拒絕的遺贈
Subclasses 應該繼承superclass的函數和數據，但是如果subclass並不需要superclass的中某些功能，該怎麼辦呢。
22、Comments – 過多的註釋
這裏講並不是你不應當寫註釋，而是說，如果一段代碼有着長長的註釋，實際上說明這段代碼是不容易看懂的，如果到處都需要大段的註釋，那整體程序的可讀性就大大困難；如果你一定需要一段註釋來說明，那麼先試着重構，把可提出去Method 找出來，如果這之後仍然需要註釋來解釋其行爲，那就要試着Rename，使其擁有有一個能說明其行爲的類名或方法名，程序可讀性會大大增強