軟件系統的設計和開發過程中，增加系統複雜性的12中危險信號：
危險信號1：淺層模塊
淺層模塊的接口相對於它提供的功能來說是複雜的。淺層模塊在與複雜性的鬥爭中幫助不大，因爲它們提供的好處(不需要了解它們內部如何工作)被學習和使用它們的接口的成本所抵消。小模塊往往是淺層的。
危險信號2：信息泄漏
當在多個地方使用相同的知識時，例如兩個不同的類都理解特定類型文件的格式，就會發生信息泄漏。
危險信號3：時間分解
在時間分解中，執行順序反映在代碼結構中：在不同時間發生的操作位於不同的方法或類中。如果在不同的執行點使用相同的知識，它就會被編碼到多個地方，從而導致信息泄漏。
危險信號4：傳遞方法
透傳方法是一種除了將其參數傳遞給另一個方法外什麼也不做的方法，通常使用與透傳方法相同的API。這通常表示類之間沒有明確的責任劃分。
危險信號5：重複代碼
如果同一段代碼(或幾乎相同的代碼)反覆出現，這是一個危險信號，說明您沒有找到正確的抽象。
危險信號6：特殊和通用的混合物
當通用機制還包含專門用於該機制特定用途的代碼時，就會出現此警告。這使得機制更加複雜，並在機制和特定用例之間產生信息泄漏：未來對用例的修改可能也需要對底層機制進行更改。
危險信號7：聯合方法
應該能夠獨立地理解每種方法。如果你不能理解一個方法的實現而不理解另一個方法的實現，那就是一個危險信號。此微信型號也可以出現在其他上下文中：如果兩段代碼在物理上是分開的，但是每段代碼只能通過查看另一段代碼來理解，這就是危險信號。
危險信號8：註釋重複代碼
如果註釋中的信息在註釋旁邊的代碼中已經很明顯，那麼註釋就沒有幫助。這方面的一個例子是，註釋使用與它所描述的事物名稱相同的單詞。
危險信號9：模糊的名字
如果一個變量或方法名足夠寬泛，可以引用許多不同的東西，那麼它就不能向開發人員傳遞太多信息，底層實體更有可能被誤用。
危險信號10：選擇很難的名字
如果很難爲創建底層對象的清晰圖像的變量或方法找到一個簡單的名稱，那麼這就暗示底層對象可能沒有一個乾淨的設計。
危險信號11：難以描述
描述方法或變量的註釋應該簡單而完整。如果你發現很難寫這樣的註釋，那就說明你所描述的東西的設計可能有問題。
危險信號12：不易理解的代碼
如果不能通過快速閱讀理解代碼的含義和行爲，這是一個危險信號。通常這意味着有一些重要的信息對於閱讀代碼的人來說不是很清楚。