在與許多不同的團隊合作過之后，Greg Young發現大家做項目時經常會大幅度的過度設計。比如一個預計要開發9個月的項目，換個角度思考一下，卻可能只需要幾個星期就可以提交95%的功能。Young在最近倫敦舉行的DDD eXchange大會上著重闡述了這一點。

\\

過度設計的原因就是我們在開發錯誤的東西。在Young看來，我們并沒有對客戶到底需要什么給以予足夠的關注，我們關注的是我們認為客戶需要什么，而實際上這是兩件非常不同的事。大多數情況下，項目功能的使用情況會遵從帕雷托分布（80/20法則），即只要實現一小部分功能，就可以滿足絕大部分場景下的實際使用需要。如果繼續開發剩余的使用率極低的功能的話，會需要投入非常多的精力，而只能獲得非常少的收益。

\\

Young強調軟件只是一個大系統的一小部分。除了軟件我們還有一整套的業務流程，而某些細節問題是完全可以用業務流程去解決的，不一定全要通過軟件解決。平時我們過多的討論了最極端的情況下如何用軟件解決問題。其實我們完全可以把工作內容的99.9%用軟件自動化處理掉，然后把剩余的一小部分留給熟悉業務的人去手工解決。

\\

\

人工介入是有必要的，人類來了！

\

\\

“棕地項目”是有可能被過度設計的一類。對于Young來說，這些項目也是最容易避免過度設計的，因為人們對這樣的系統已經有了使用經驗和數據。根據熟悉業務的人的描述找到系統的基本用例，再對照實際的使用情況，就基本可以確認絕大部分的系統功能了。不幸的是，我們和熟悉業務的人討論得最多的卻常常是系統的邊緣功能，就是那些在編碼時需要大量復雜處理可實際上卻很少在生產環境中能用到的功能。Young也指出，考慮這些復雜處理事實上會誤導我們的項目模型設計。

\\

“綠地項目”則是經常被過度設計的一類，因為我們沒法接觸到實際的使用情況。為了避免過度設計，Young建議與需求方達成協議可以在項目首次提交的兩個月后再次部署和發布。期間，需求方要使用這個系統并盡早的提供反饋，這樣來避免實現那些幾乎用不上的功能。他也建議在第一次發布之后只解決故障而不開發新功能，這樣所有缺失的功能就都會被當成故障報告上來。根據他的經驗這樣工作非常有成效，因為大家只需要分析故障的嚴重程度來決定處理的優先級就可以了。但他也提到，這種工作方式只適用于給內部用戶使用的內部項目，對固定價格的合同或者公用的網站不適合。

\\

\

我們就是在夢想國里開發綠地項目的。

\

\\

項目經理或項目協調者是非常容易做過度設計的人。Young幾乎沒見過什么項目是可以兼顧多種用途而獲得成功的，最大的原因是要滿足各方面的細節需求就會導致最終做成一個龐大的項目。更過份的是有的項目甚至會迷失，想不明白自己最主要是想實現什么功能了，結果大家就只好把各種可能情況都列舉出來，事情就完全不可控了。

\\

Young總結到：我們應該記住現在軟件系統已經在取代人工工作了。大多數的情況下能讓軟件系統完成99%的人工工作就已經非常好了，想再把剩下的1%也搞定，這事算起賬來并不劃算。

\\

明年的DDD Exchange大會計劃在2017年四月下旬如開，現在正在開放注冊。

\\

查看英文原文：Stop Over-Engineering, Build What the Customer Really Needs

\\

---

感謝夏雪對本文的審校。

\\

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關注我們。