適用情形:適用于任何項目，所有大型的或復雜的系統和項目都應該采用該原則。
應用方式:讓同同行來檢查解決方案是否好理解，抵制過度設計的強烈欲望。
應用理由:復雜的解決方案實施成本高，而且會產生大量長期成本。要點:過度復雜的系統會限制擴展能力。簡單的系統更容易維護和擴展，且成本更低。
維基百科解釋說，過度設計分為兩大類。一類是指設計與實現超出了有用需求的產品。出于完整性的考慮，我們只簡單地討論一下這個問題。相對于第二類問題來說，這類問題對可擴展性的影響較小。過度設計的另一類問題指過于復雜的產品。如前所述，我們最關心的是第二類問題對可擴展性的影響。不過，還是先來了解一下第一個問題吧。
要解釋過度設計的第一類問題，即超出產品有用需求的問題，就要先搞清楚楚“有用的”這個術語的含義，這個術語在這里表示的只是“能夠伸用”。例如。為家庭住房設計一種空調，能夠在室外溫度為0開時把整個房子的溫度加熱到300華氏度，這毫無意義，純屬浪費，我們只需要一個能夠在室外溫度為-20華氏度時把房子加熱到舒適溫度的產品。這種過度設計會產生過度的成本，其中開發的成本會更高，實施該方案的硬件和軟件成本也會更高。如果研發這種過度設計系統的時間比研發有用系統的時間更長，還可能拖延產品的發布，對公司造成進一步的影響。成本高，利潤就低。研發時間長，收入或收益就會被延遲，所有這些成本都會影響到利益相關者。范圍蔓延，或者最初的產品定義和最初的產品發布之間的范圍差異，是過度設計的一種表現。
說個更接近我們工作的例子，是開發一個員工打卡系統，這個系統能夠處理的員工數量是整個地球上人數的100倍。在這個軟件的使用期限內，地球上的人口升至100倍的可能性是微乎其微的，而所有人都為一家公司工作的可能性則更小。我們當然想讓構建的系統滿足客戶需求但也不想浪費時間來實現和部署遠遠超出需求的系統。
過度設計的第二類表現是使系統過度復雜，或者用復雜的方式來實現它。簡而言之，就是要花費過大的力氣去完成一項工作，或者是讓用戶花費過大的力氣去完成一項任務，或者是讓程序員花費過大的力氣去理解一個功能。讓我們來逐一分析過度復雜的系統的這三種情況。
什么是花費過大的力氣去完成一項工作呢?現實世界有最簡單的例子。假設你讓某人去雜貨店買東西，你告訴他，店里面的所有商品都拿一個，排隊結賬時給你打電話。等他打電話給你時，你再告訴他到底想要哪幾個，讓他從所拿的無數籃商品中選出來，然后把其他商品都倒在地上。你一定會說:“別開玩笑了。”可是，你在自己的代碼中用過select(大)schema_nane.tab1e_name這樣的SQL語句，只是為了從返回的集合中找出自己想要的結果嗎?我們這個雜貨店的例子，和上述的se1ect(*)正是異曲同工。在你的代碼中，有幾個條件語句是處理個別情況的，它們是按照什么順序執行的?是不是最可能發生的情況最先執行?你是不是經常剛查詢完一個結果，又重復查詢一次?是不是經常剛顯示了HML面，這種情況隨處可見，卻又經常被忽視。
什么是讓一位用戶花費過大的力氣去完成一項任務呢?答案非常簡單。在許多情況下，少就是多。為追求系統的靈活性，我們總是想給它硬加上盡可能多的奇怪功能。但生活的情趣并不總在于多種多樣。許多時候，用戶只是想無干擾地盡可能快地從A到達B。如果你的市場中有99%的用戶不需要把日志文件存成pdf文件，那么就不要構建一個提示框詢問他們是否想把日志文件保存成pdf文件。如果你的用戶想把.wav文件轉換成MP3文件，那么他們已經不在乎損失精度了，所以不必再提示他們轉換成無損壓縮的FLAC文件，那樣只會干擾他們。
最后一種情況，就是軟件復雜得讓其他程序員難以理解。創建復雜的代碼讓他人難以理解曾經非常流行(還有過比賽)。有時，代碼寫得復雜，是為了讓它比一般程序員所開發的代碼運行更快。而更多的情況是代碼的復雜度(就其理解的難度而言)成了程序員才華的象征，或者說是功夫高低的象征。那些開發的代碼能讓做代碼檢查的高級開發人員欲苦無淚的人反而頗受推崇。復雜度成了智慧的牢籠，編程極客們會在公司內部爭強好勝。對于樂此不疲的人來說，這是很好的比賽，但對于公司和股東來說，則要為一場無人關心的牢籠大賽買單。對于那些仍然沉浸于這場極客盛宴的人，如果不想損害利益相關者的利益，又想真刀真槍地拼一場，那建議你參加國際混淆C代碼競賽。
我們都應該努力去寫讓每個人都能理解的代碼。衡量一個偉大程序員的真正標準，是他能夠多快把一個復雜的問題簡化，多快能開發出一個既容易理解，又容易維護的解決方案。容易執行的解決方案意味著一般程序員就可以快速地掌握系統，為它提供支持。容易理解的解決方案則意味著在查找問題時能夠甲
方式把系統恢復到正常工作狀態。容易執行的解決方案可以提高公司和解決方案的可擴展性。
要測試系統是否太復雜，一個很好的方法是讓負責解決復雜問題的程序員把他的解決方案陳述給公司內的一組程序員。這組程序員應該代表公司內不同的編碼水平，不同的工作年限(加入這一條，是因為可能有些有經驗的程序員在公司的工作經驗不多)。要通過這一測試，需要這組程序員中的每一位都能夠輕松理解該解決方案，能夠在無幫助的情況下向他人描述它，而不只是知道它。如果這組程序員中的任何一位不能理解該解決方案，那么就要小組討論該系統是不是過度復雜了。
過度的網站設計是可擴展性的一個敵人。開發一個超出有用需求的解決方案，既浪費金錢又浪費時間。此外，還可能進一步步浪費處理資源，增加擴展成本，限制系統的整體擴展能力(即系統能被擴展到什么程度)。構建過度復雜的解決方案會造成類似的后果。運行吃力的系統會增加成本，限制最終發展規模。讓用戶用起來吃力的系統，會放慢吸引客戶的速度，從而限制業務增長的速度。太復雜以至于難以理解的系統，則會扼制司的生產力，讓你無從增加程序員，或者難以給系統增加功能。
本文地址：http://m.knowyourextract.com//article/3442.html
