?????? 忙碌了一年了項目又到了交付了，雖然項目能成功上線（因為還有維護支持的團隊）。但是個人從技術上看，這是一個不那么成功的項目，因為后期艱難的修復bug,添加feature。這與簡單設計有什么關系呢？在某模塊開發起初，由于架構的經驗預見性的告訴我這模塊開發中會出現什么問題，所以選擇了提出某些比較好的解決方案，但是由于團隊成員一致的所謂簡單設計，通過TDD,重構達到”合適”的”完美”的設計，可是最后的結果如我所料一切的發生。這里插一句，現在在一家敏捷公司，敏捷強調是合作，所以沒有一個人統一規劃決策，不同之前的公司作為架構師決策一切架構設計。敏捷合作交流我不否認你正確性，因為我也相信軟件是人和時間的問題，方法論都是解決我和時間的問題。但是對于一個在成長中團隊，成員的設計或者某些預見性或者重構能力，力度相對不足的情形下，這樣是不是合理？

??? 回到主題，簡單設計英語 Keep It Simple, Stupid。我們常說的KISS原則，保持產品或設計的簡單性，同時功能的足夠性。我想說的是翻譯成為簡單這是一個錯誤的決定，因為這不是絕對的簡單，在我看來最簡單的系統就是沒代碼的系統，代碼越少，甚至沒有就沒有bug沒有維護。所以我更愿意以產品設計如家庭裝修一樣翻譯為”簡約”，簡約而不簡單。在《簡約至上-軟件交互式設計四策略》這本書以遙控器為例提供了刪除，隱藏，轉移，組織產品設計四策略，但是其簡化改善后仍然五臟俱在，核心價值仍在。但是對于軟件而言，我們最大對手是需求變化，所以我們常說“擁抱變化”，敏捷就是為了擁抱變化適應變化給用戶提供更好優質可用的卓越軟件。但真的所謂簡單設計，我們起初就不設計？靠我們的測試驅動，行為驅動，重構等方法論就能解決軟件設計？這些就是萬能的靈藥，軟件的銀彈？我還沒見過這樣的人，我不否認在這樣牛人的存在， Martin Fowler 在《重構改善既有代碼設計》一書提到XP發起一幫人能夠比較好的完美利用這些方法論將代碼改造為一個比較好的設計。但這畢竟是少數人的世界，我輩望山莫及，再加上項目開發周期中的由于時間，環境等等壓力導致重構力度大幅度縮減，或者根本就沒有把重構日常化，只是拿著重構這個感覺好nb的術語招搖撞騙（本人見過很多人或者博客將如果重構，但在鄙人鄙見下這更大程度的是重寫，重新設計，只是招搖撞騙的幌子），那所謂的簡單設計真的還能啟用？

????? 在回到簡單設計，在軟件變化的需求下，我認為簡單設計的目的是保持代碼的整潔，以及不要花費太多時間在無謂的設計猜測需求中，減少類數量的龐大，其目的是減少時間人力資源的浪費，其相對于過度設計而言。但絕對不是不做設計，不留任何一點擴展，起終點在于時間資源的投入。所以我認為基于資源的投入，如果不是那么大浪費或者必須的設計，我們讓然需要去做，因為程序員都是追求完美，適應以后潛在的變化。相反如果是將一個相對好的設計，或者擴展，花時間去做到所謂的簡單設計，喪失擴展等，這不是減少資源投入，這是在搗蛋，花時間精力去搞破壞，即使是你認為不變，何況誰能預測未來世界。

???? 如果我們不是牛人，你卻也追求卓越軟件，我覺得我們還是需要考慮下設計，不要一味的“簡單設計”，平衡各種方法論，權衡各種利弊，找到適合自己的方式方法論，如果只是”簡單設計“卻沒有足夠的重構力度，抑或完全的優先設計，不進行不斷的持續改進，逐步細化，做到“簡約而不簡單”記住所有的技術債早晚會需要你償還的。對于我來說沒有萬能的方法論，我也不是牛人，我選擇設計，重構等方法論的權衡。

轉載于:https://www.cnblogs.com/whitewolf/archive/2013/05/07/3063984.html

總結

以上是生活随笔為你收集整理的闲谈简单设计(KISS)疑惑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。