建議154：不要過度設計，在敏捷中體會重構的樂趣
有時候，我們不得不隨時更改軟體的設計：
以上分別從外部和內部描述了必須修改需求和設計的幾種場景。也就是說，在軟體開發過程中，變化幾乎總會發生。
為了捕捉需求上的不斷變化，軟體開發必須變得足夠「敏捷」。設計也應該停留在「高層次」上，具有指導作用，而功能模組（或者說**）則需要逐步改進。我們把改進的過程稱為「重構」.
傳統的瀑布開發由於不能滿足需求的變化，在軟體領域被各類敏捷開發框架所取代。
敏捷開發模式把整個開發過程分成了乙個乙個的迭代，每個迭代的週期大概是兩周到乙個月。每個迭代大致分為如下幾個步驟。
敏捷開發使用「使用者故事」（user story，在tfs敏捷規範中，它被歸類到backlog）來核定需求和工作量指標。在乙個迭代開始的時候，開發團隊應該挑選使用者故事作為本次迭代的目標；而在每一次迭代結束的時候，使用者故事應該開發完畢。整個開發部門必須發布乙個可以執行的版本交付給客戶（物件可以是真實的使用者，也可以是團隊運營部門）。這有助於客戶及時調整他們對產品的預期，並修正可能存在的需求變動。而作為開發團隊，也可以根據客戶的反饋修正需求，甚至是設計。
正是因為敏捷開發擁抱變化，所以站在整個開發流程來看，設計應該是可以修改的，而落實到**上來，也就是重構的地位提公升了。在敏捷開發體系中，我們可以將其作為乙個任務（task）引入整個開發流程中。
作為乙個團隊，需要定期審視模組是否可以被重構。而作為開發人員，建議一旦嗅到**的壞味道，就需要重構我們的**。
我們不追求讓**第乙個版本就保持非常整潔的程度，那不現實，而且會讓開發者覺得無從下手。當然，我們更不應該讓繁雜的**永遠保持在第乙個版本的狀態，那樣的**，讓我自己都不滿意。
**：《編寫高質量**改善c#程式的157個建議》陸敏技
設計不足 與 過度設計
什麼是設計不足 under engineering 設計出來的系統復用性差，擴充套件性不強，不能靈活的應對變化，簡言之，設計沒到位。設計不足，多半是因為經驗有限，設計能力有限。什麼是過度設計 over engineering 設 計出來的系統比恰到好處要複雜臃腫的多，過度的封裝 一堆繼承 介面和無用...
Unix文化 不要過度優化，有關演算法
這裡的過度也包括 提早 下面的話是rob pike,最偉大的c語言大師之一說的，放在這裡，已示驚醒 1.你無法斷定程式會在什麼地方耗費執行時間。瓶頸經常出現在想不到的地方，所以別急著胡亂找個地方改 除非你已經證明那兒就是瓶頸所在 2.估量。在你沒對 進行估量，特別是沒找到最耗時的那部分之前，別去優化...
如何避免過度設計
設計的初衷是提高 質量。在做 設計的時候，一定要理清楚，為什麼要這樣設計，為什麼要應用這種設計模式，這樣做是否能真正地提高 質量，能提高 質量的哪些方面。如果自己很難講清楚，或者給出的理由都比較牽強，沒有壓倒性的優勢，那基本上就可以斷定這是一種過度設計，是為了設計而設計。設計的過程是先有問題後有方案...