在與許多不同的團隊合作過之後，greg young發現大家做專案時經常會大幅度的過度設計。比如乙個預計要開發9個月的專案，換個角度思考一下，卻可能只需要幾個星期就可以提交95%的功能。young在最近倫敦舉行的ddd exchange大會上著重闡述了這一點。
\\ 過度設計的原因就是我們在開發錯誤的東西。在young看來，我們並沒有對客戶到底需要什麼給以予足夠的關注，我們關注的是我們認為客戶需要什麼，而實際上這是兩件非常不同的事。大多數情況下，專案功能的使用情況會遵從帕雷託分布（80/20法則），即只要實現一小部分功能，就可以滿足絕大部分場景下的實際使用需要。如果繼續開發剩餘的使用率極低的功能的話，會需要投入非常多的精力，而只能獲得非常少的收益。
\\ young強調軟體只是乙個大系統的一小部分。除了軟體我們還有一整套的業務流程，而某些細節問題是完全可以用業務流程去解決的，不一定全要通過軟體解決。平時我們過多的討論了最極端的情況下如何用軟體解決問題。其實我們完全可以把工作內容的99.9%用軟體自動化處理掉，然後把剩餘的一小部分留給熟悉業務的人去手工解決。
\\
\\\人工介入是有必要的，人類來了！
\
「棕地專案」是有可能被過度設計的一類。對於young來說，這些專案也是最容易避免過度設計的，因為人們對這樣的系統已經有了使用經驗和資料。根據熟悉業務的人的描述找到系統的基本用例，再對照實際的使用情況，就基本可以確認絕大部分的系統功能了。不幸的是，我們和熟悉業務的人討論得最多的卻常常是系統的邊緣功能，就是那些在編碼時需要大量複雜處理可實際上卻很少在生產環境中能用到的功能。young也指出，考慮這些複雜處理事實上會誤導我們的專案模型設計。
\\ 「綠地專案」則是經常被過度設計的一類，因為我們沒法接觸到實際的使用情況。為了避免過度設計，young建議與需求方達成協議可以在專案首次提交的兩個月後再次部署和發布。期間，需求方要使用這個系統並盡早的提供反饋，這樣來避免實現那些幾乎用不上的功能。他也建議在第一次發布之後只解決故障而不開發新功能，這樣所有缺失的功能就都會被當成故障報告上來。根據他的經驗這樣工作非常有成效，因為大家只需要分析故障的嚴重程度來決定處理的優先順序就可以了。但他也提到，這種工作方式只適用於給內部使用者使用的內部專案，對固定**的合同或者公用的**不適合。
\\
\\\我們就是在夢想國裡開發綠地專案的。
\
專案經理或專案協調者是非常容易做過度設計的人。young幾乎沒見過什麼專案是可以兼顧多種用途而獲得成功的，最大的原因是要滿足各方面的細節需求就會導致最終做成乙個龐大的專案。更過份的是有的專案甚至會迷失，想不明白自己最主要是想實現什麼功能了，結果大家就只好把各種可能情況都列舉出來，事情就完全不可控了。
\\ young總結到：我們應該記住現在軟體系統已經在取代人工工作了。大多數的情況下能讓軟體系統完成99%的人工工作就已經非常好了，想再把剩下的1%也搞定，這事算起賬來並不划算。
\\ 明年的ddd exchange大會計畫在2023年四月下旬如開，現在正在開放註冊。
\\檢視英文原文：stop over-engineering, build what the customer really needs
\\ 感謝夏雪對本文的審校。
\\
停止過度設計，開發客戶需要的軟體
在與許多不同的團隊合作過之後，greg young發現大家做專案時經常會大幅度的過度設計。比如乙個預計要開發9個月的專案，換個角度思考一下，卻可能只需要幾個星期就可以提交95 的功能。young在最近倫敦舉行的ddd exchange大會上著重闡述了這一點。過度設計的原因就是我們在開發錯誤的東西。在...
軟體開發過程中的過度設計
在軟體設計過程中，總有以下感慨 1.總以為自己了解了使用者的細節需求 2.在設計階段，花很多時間針對需求中的某些小功能做設計 3.使用者在實際使用中很少使用問題2的 某些小功能 總之，在設計過程中，使用80 的時間處理了20 的不常用的功能，而80 的主要功能，由於在設計階段考慮不周，導致問題百出。...
軟體測試中過度設計的那些事兒（轉）
過猶不及，這是古代 論語 中的乙個成語，做得過了就好比沒有做夠一樣。在軟體測試行業中同樣也會存在過度測試的情況，今天我就班門弄斧一下說說我對過度測試的理解。很詳細的需求文件會導致維護成本劇增 我所經歷過的專案中有過幾種很有代表性的prd product requirement document的簡稱...