不良設計的標準
生活很簡單：通常，要聰明，你只需要不做傻事。這也適用於軟件開發：在大多數情況下，要想把一件事做好，你只需要不把它做得不好。
大多數程序員都有過設計糟糕的系統部分的經驗。但更可悲的是，你們中的大多數人都會有悲傷的經歷，意識到自己是這樣一個系統的作者。我們想要最好的，但結果一如既往。
大多數開發人員並不渴望糟糕的架構，對於許多系統來說，他們開始說它的架構很糟糕。為什麼會這樣？架構設計是從一開始就不好，還是隨著時間的推移變得不好？
這個問題的根源是缺乏“壞”設計的定義。
在我看來，理解設計質量及其“衰退”的原因是任何程序員最重要的素質。與大多數其他情況一樣，最主要的是確定問題，解決問題將是技術問題。
“不良設計”的定義
如果你決定在其他程序員面前吹噓你的代碼，你很可能會得到嘲笑：“這是誰做的？”，“為什麼會這樣？” 和“我會做不同的事情。” 這種情況經常發生。
所有人都是不同的，但你仍然為你的程序員夥伴編寫代碼，所以在開發每個功能的過程中，當其他人看你的代碼時，你總是需要一個審查階段。
但即使很多事情可以用不同的方式完成，也有一套所有開發人員都會同意的標準。任何滿足其要求但仍表現出一個（或多個）特徵的代碼都是糟糕的設計。
糟糕的設計：
- 很難更改，因為任何更改都會影響系統的太多其他部分。（剛性，剛度）。
- 進行更改時，系統的其他部分會意外中斷。（脆弱性，脆弱性）。
- 代碼很難在另一個應用程序中重用，因為很難將其從當前應用程序中取出。（不動性，不動性）。
有趣的是，幾乎不可能找到一個不包含任何這些特性（即靈活、可靠和可重用）的系統，滿足要求，同時它的設計很糟糕.
因此，我們可以通過這三個特徵來明確地判斷一個設計是“壞”還是“好”。
“不良設計”的成因
是什麼讓設計變得僵硬、脆弱和不可移動？模塊的剛性相互依賴。
如果設計不能輕易改變，那麼它就是死板的。這種僵化是由於對編織系統中一段代碼的單一更改會導致相關模塊的級聯更改。當一個人在編寫代碼時，總是會發生這種情況。
這立即使整個商業開發過程複雜化：當設計人員或開發人員無法預測級聯更改的數量時，就無法估計這種更改的影響。因此，他們試圖無限期推遲此類更改。
而這反過來又使變革的成本變得不可預測。面對這樣的不確定性，管理者不願意做出改變，所以設計正式變得死板。
在某個時候，您的項目會越過“事件視界”，注定會落入僵化架構的“黑洞”。
脆弱性是系統在一次更改後在多個地方崩潰的趨勢。通常新問題發生在概念上與變更地點無關的地方。這種脆弱性嚴重破壞了對系統設計和維護的信心。
當沒有私有方法時，通常就是這種情況。將所有方法公開就足夠了，你注定會出現脆弱的架構。封裝有助於在微觀層面處理這個問題。但在宏觀層面，你需要一個模塊化的架構。
當項目具有脆弱的架構時，開發人員無法保證產品的質量。
應用程序一部分的簡單更改會導致其他不相關部分出現錯誤。糾正這些錯誤會導致更多的問題，護送過程變成追自己尾巴的名犬。
當系統的必要部分與其他不需要的細節緊密相關時，設計就是固定的。太多他們自己的代碼，他們自己獨特的方法和解決方案。
您還記得 JUL 記錄器嗎，它的開發人員無緣無故地想出了自己的日誌記錄級別？僅此而已。
要讓設計人員了解重用現有設計有多麼容易，只需考慮在新應用程序中使用它會有多容易。
如果設計是緊密耦合的，那麼將系統的必需部分與不必要的細節分開所需的工作量會讓這位設計師感到震驚。在大多數情況下，這樣的設計是不可重用的，因為分離它的成本超過了從頭開始開發它的成本。
關聯
一切都變了，但一切都保持不變。（中國諺語）
上面提出了很好的問題。脆弱和僵硬的系統有哪些危險？是的，因為管理這樣一個項目的過程變得不可預測和不可控制。而且價格天價。
如果經理不知道實際需要多少時間，他怎麼能同意或不同意添加某些功能？如果無法充分估計任務實施的時間和復雜性，如何確定任務的優先級？
當我們支付費用時開發人員如何還清相同的技術債務，而在我們支付之前我們無法了解我們將支付多少費用？
代碼重用或測試的問題也非常相關。單元測試不僅用於測試關於被測單元的一些假設，而且可以確定其內聚程度，並可以作為重用的指標。
這是 Bob Martin 對這個案例的引用：“為了重用你的代碼，你需要使重用它的努力少於從頭開始開發的成本。 ” 否則，根本就沒有人會理會這件事情。
設計原則和模式的使用服務於一個目的——讓設計變得更好。如果它們的使用沒有給您帶來任何好處（反之亦然，違反了“良好設計”的原則），那麼您的溫室中的某些東西是不對的，也許該工具已開始用於其他目的。