重點摘要#
- 聰明（clever）的軟體是昂貴的、難以維護的、脆弱的
- 追求最「笨」的設計——適當的設計永遠不會是聰明的
- 如果聰明似乎是必要的，那表示問題框架有誤，需要重新定義問題
- 「笨」的解決方案每個元件只做一件事，更容易建立、修改和維護
詳細內容#
智慧、足智多謀、思慮周到、知識廣博而深入、追求精確——這些在任何人身上都是值得讚揚的特質，尤其是架構師。然而「聰明」（cleverness）有不同的含義——它暗示著一種依靠花招、伎倆或障眼法的快速解決方案。
不要聰明，要笨#
聰明的軟體昂貴、難以維護且脆弱。 不要追求聰明，盡可能保持「笨」，同時仍然創造適當的設計。適當的設計永遠不需要聰明。
如果聰明看起來是絕對必要的，那問題可能被錯誤地框架了。重置問題，重新定義它，直到你可以再次用「笨」的方式解決。用粗略的草圖工作，保持通用，放下當天的流行風格。聰明的架構師懂得如何保持笨。
我們不是 MacGyver#
我們的聰明讓我們能「騙」軟體運作起來。但不要成為那種靠技術細節讓軟體勉強運作的人。我們不是 Rube Goldberg，也不是只有迴紋針和口香糖就能解決問題的 MacGyver。
放下你對 closures、generics 和各種進階技巧的廣泛知識。清空你的頭腦，用最簡單的方式處理問題。有時候這些進階技術確實是我們需要的——但比我們想像的要少得多。
「笨」解決方案的優勢#
- 更多開發者能實作和維護
- 每個元件只做一件事
- 建立時間更短，修改時間更短
- 從使用的基礎元件中繼承優化
- 自然而然地展現出優雅和簡潔
聰明的設計會頑固地抵抗改變——它們的細節與整體畫面糾纏在一起，一碰就碎。而「笨」的設計像活的有機體一樣從頁面上浮現出來。
— By Eben Hewitt