您是否曾經進行過代碼審查，記錄了非常高的WTF / m？ 您是否想知道所有這些錯誤代碼的原因是什么？ 在大多數情況下，導致原因1的主要原因是使用設計和編碼反模式。

如果您喜歡定義，請參見以下內容：AntiPattern是一種文學形式，它描述了對問題的普遍存在的解決方案，該解決方案產生肯定的負面影響。 AntiPattern可能是由于經理或開發人員不了解更好，沒有足夠的知識或經驗來解決特定類型的問題或在錯誤的情況下應用了完美的模式而導致的。

重新發明輪子

IMO經常發生的反模式是缺乏對某些有用框架/庫的了解。 Apache commons lang和commons集合是每個Java項目中都應該存在的依賴項。

您可以編寫自己喜歡的循環過濾或選擇集合中的某些對象的方法，也可以使用CollectionUtils.select（…）或CollectionUtils.filter（…）。

您可以執行一些花哨的非null檢查，最后以巨大的if-else構造結束，或者可以使用StringUtils.isNotBlank（…）。 由你決定。

一般規則是不要試圖重新發明輪子。 有些人喜歡編寫自己的Reflection utils，而Apache的commons beanutils ，Spring的BeanUtils和BeanWrapper可以解決問題。

貨物崇拜編程

貨物崇拜編程是一種編程樣式，其中使用模式和方法而不了解原因。 “貨運邪教”一詞最初是指第二次世界大戰后在南太平洋長大的土著宗教。 這些團體的做法集中在建造精美的飛機和軍事起落跑道的模型上，以期召喚在戰爭中帶來奇妙貨物的神似飛機。

大多數情況下，熟練的或經驗不足的程序員都會使用這種編程方式，從其他地方復制粘貼某些代碼。
例子：
–在自說明代碼中添加不必要的注釋 –為沒有問題的垃圾將自動收集的對象添加刪除代碼 –創建工廠以構建簡單的對象

通過例外/期望處理進行編碼

代替 檢查某些特定的轉折情況值（例如null值）的方法，有些人喜歡捕獲NullPointerException并在catch塊中執行一些邏輯。 這種編碼方式稱為期望處理，因為預期會發生異常。

發明了異常是為了通知您以下事實：確實發生了一些非常糟糕的事情，但并不意味著經常將它們拋出。 這就是為什么它們被稱為“例外”。 如果發生這種情況，請仔細處理它們，但不要濫用它們以執行某些本可以通過簡單的if-else檢查實現的邏輯。

避免/吞咽異常

參考前面的反模式，當引發異常時，意味著發生了意外情況。 您應該做的最后一件事是吞下這些異常，而不是處理其有用的信息。

例如，如果您有一個只希望返回一個對象的方法，因為它希望它是唯一的，則對返回結果列表的數據庫查詢進行性能檢查，檢查該列表的大小是否等于1，然后執行只能返回1個唯一對象的查詢。結果（如果沒有拋出異常）。 如果要實現類似的東西，則意味著預期的對象可能不是唯一的，這意味著實現與分析中所說的有所不同。

繼承地獄

繼承應謹慎處理。 它非常有用，但是您只能使用它的預期用途。 如果繼承樹變得腫，那是不對的。 不要為1種特定情況編寫抽象類。 請改用合成。 策略模式可以在這里派上用場。

例如，如果您的JSF托管bean'EditUserManagedBean'擴展了AbstractEditingManagedBean，又擴展了AbstractSelectionManagedBean，又擴展了AsbtractParentDetailManagedBean，又擴展了AbstractManagedBean，則您應該知道有些錯誤，并且應該有其他方法可以實現此行為

鍍金 和過早優化

有些人喜歡通過繼續努力來改進代碼，直到付出額外的努力才增加了價值，而不是堅持要求。 此處犯的錯誤是，使最終用戶看到產品中的其他或增強功能比用戶要求或期望的功能更加高興。 用戶可能對結果感到失望，而開發人員的額外努力可能是徒勞的。 該過程稱為鍍金。

鍍金與過早的優化有關。 過早的優化是指考慮將來可能會出現的問題，但目前還不是這種情況。 您應該只考慮所要求的內容和要求的內容，而不要考慮最終可能對將來的目的有用的內容。 頻繁發生的過早優化是過早的性能優化。 如果此時不存在性能問題，請不要嘗試處理它們，當它們發生時再進行處理。

參考文獻

• 由我們的JCG合作伙伴 Glenn Dejaeger在about：software development中 編程反模式 。
• http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns

• JDK中的設計模式
• 正確記錄應用程序的10個技巧
• 每個程序員都應該知道的事情
• Java教程和Android教程列表