忙碌了一年了項目又到了交互了，雖然項目能成功上線（因爲還有維護支持的團隊）。但是個人從技術上看，這是一個不那麼成功的項目，因爲後期艱難的修復bug,添加feature。這與簡單設計有什麼關係呢？在某模塊開發起初，由於架構的經驗預見性的告訴我這模塊開發中會出現什麼問題，所以選擇了提出某些比較好的解決方案，但是由於團隊成員一致的所謂簡單設計，通過TDD,重構達到”合適”的”完美”的設計，可是最後的結果如我所料一切的發生。這裏插一句，現在在一家敏捷公司，敏捷強調是合作，所以沒有一個人同意規劃決策，不同之前的公司作爲架構師決策一切架構設計。敏捷合作交流我不否認你正確性，因爲我也相信軟件是人和時間的問題，方法論都是解決我和時間的問題。但是對於一個在成長中團隊，成員的設計或者某些預見性或者重構能力，力度相對不足的情形下，這樣是不是合理？
回到主題，簡單設計英語 Keep It Simple, Stupid。我們常說的KISS原則，保持產品或設計的簡單性，同時功能的足夠性。我想說的是翻譯成爲簡單這是一個錯誤的決定，因爲這不是絕對的簡單，在我看來最簡單的系統就是沒代碼的系統，代碼越少，甚至沒有就沒有bug沒有維護。所以我更願意以產品設計如家庭裝修一樣翻譯爲”簡約”，簡約而不簡單。在《簡約至上-軟件交互式設計四策略》這本書以遙控器爲例提供了刪除，隱藏，轉移，組織產品設計四策略，但是其簡化改善後仍然五臟俱在，核心價值仍在。但是對於軟件而言，我們最大對手是需求變化，所以我們常說“擁抱變化”，敏捷就是爲了擁抱變化適應變化給用戶提供更好優質可用的卓越軟件。但真的所謂簡單設計，我們起初就不設計？靠我們的測試驅動，行爲驅動，重構等方法論就能解決軟件設計？這些就是萬能的靈藥，軟件的銀彈？我還沒見過這樣的人，我不否認在這樣牛人的存在， Martin Fowler 在《重構改善既有代碼設計》一書提到XP發起一幫人能夠比較好的完美利用這些方法論將代碼改造爲一個比較好的設計。但這畢竟是少數人的世界，我輩望山莫及，再加上項目開發週期中的由於時間，環境等等壓力導致重構力度大幅度縮減，或者根本就沒有把重構日常化，只是拿着重構這個感覺好nb的術語招搖撞騙（本人見過很多人或者博客將如果重構，但在鄙人鄙見下這更大程度的是重寫，重新設計，只是招搖撞騙的幌子），那所謂的簡單設計真的還能啓用？
在回到簡單設計，在軟件變化的需求下，我認爲簡單設計的目的是保持代碼的整潔，以及不要花費太多時間在無謂的設計猜測需求中，其目的是減少時間人力資源的浪費，其相對於過度設計而言。但絕對不是不做設計，不留任何一點擴展，起終點在於時間資源的投入。所以我認爲基於資源的投入，如果不是那麼大浪費或者必須的設計，我們讓然需要去做，因爲程序員都是追求完美，適應以後潛在的變化。相反如果是將一個相對好的設計，或者擴展，花時間去做到所謂的簡單設計，喪失擴展等，這不是減少資源投入，這是在搗蛋，花時間精力去搞破壞，即使是你認爲不變，何況誰能預測未來世界。
如果我們不是牛人，你卻也追求卓越軟件，我覺得我們還是需要考慮下設計，不要一味的“簡單設計”，平衡各種方法論，權衡各種利弊，找到適合自己的方式方法論，如果只是”簡單設計“卻沒有足夠的重構力度，抑或完全的優先設計，不不斷的持續改進，逐步細化，做到“簡約而不簡單”記住所有的技術債早晚會需要你償還的。對於我來說沒有萬能的方法論，我也不是牛人，我選擇設計，重構等方法論的權衡。