《人月神話》中Brooks一直非常強調“概念完整性”對於系統的重要性。十年前看這本書的時候總是覺得不懂，是一種說不清，朦朦朧朧的感覺。

【轉載自http://blog.sina.com.cn/s/blog_a49b04f601017533.html】

定義

概念的完整性，是指針對於一個領域，不僅了解該領域的所有對象，並且了解所有對象之間的關系。比如，小學數學中的四則運算。所有的對象就是指有理數，所有的關系就是由加減乘除四種運算而能夠產生另外一個有理數。如果對這樣的計算完全了解的話，那麽使用這樣的領域來解決問題就不成問題。

人月神話

概念的完整性在一本20年了還是非常深刻的軟件工程書中被重點提出。這本書叫做《人月神話》。作者通過自己的經驗及大量的數據而找到軟件開發出現問題的主要原因——概念不完整。

概念不完整，就在開始註定一個軟件項目要失敗了。就本人的經驗來看，很多項目都因為沒有對問題了解得足夠細致，然後就進行了軟件開發，結果所寫的代碼不能實際解決問題，於是又改代碼，並且是不斷地去改代碼，期望通過改代碼來達到解決問題的目的。

其實，問題的根本在於，概念不完整，換言之，就是，始終都沒有搞明白問題域有那些對象，各個對象之間是什麽樣的聯系。能夠考慮這樣的問題的人，一般都是對完整的概念有著強烈的要求並且在這方面具備相當經驗的人。寫代碼的人很難考慮到所寫的這一部分代碼是否真的解決了問題。在被要求改寫代碼的時候，只是大概了解別人要改一個需求。

但是，需求從來就不需要改，需要改需求，只說明一點——沒有真正搞清楚對象及對象之間的聯系。從而沒有辦法了解問題。在沒有真正了解問題的時候，只能被動地等待問題的出現，然後去改代碼，以頭痛醫頭，腳痛醫腳的方式去解決問題。

而概念的完整性，是建立在已經完全了解領域的對象及對象之間的關聯。這種完全了解，並不是感性地了解，而是理性地了解。如，在小學數學這個領域，加法與乘法具有交換律。即，

a + b = b + a

那麽在考慮加法與乘法的時候，可以只考慮將小的數放在前面，大的數放在後面這樣的情形。從而可以得到簡化的加法與乘法口訣。即，只要知道 2+3=5 就可以知道 3+2 一定等於 5。

這樣的例子是為了說明，在了解關系的時候，要上升到理性認識，而不是停留在表象上。

又如，考慮社交網站的例子。表象上來看，社交網站要記錄每個人的興趣愛好，職業，曾經就讀的學校等。這就導致需要建立一個用戶表，建立一個愛好表，職業表，學校表：

而這樣的關聯完全可以抽象成：

User <--> User_Object <--> Object
name      user_id          name
          object_id
          type
          time

社交網站所需要記錄的是人與物的關系，及人與人的關系。一個人喜歡一個物（愛好），做一個物的事（職業），讀書於一個物（學校）。以上的抽象，就可以將人與物的關系及時間概念完整地表達出來。

也就是說，概念的完整性，並不是將所有的東西都知道就可以了，還需要真正達到一定的理性認識。達到一定的抽象才行。

軟件是一個修改起來代價相對較小的東西，比起造一輛車，一個軟件做得再差，也不會造成巨大的現實世界的變化，它最多改變的只是硬盤中某一個區域的磁性。而造一輛車子，需要現實世界中很多物質發生變化才可以做成。從而，這推動了人不把問題想清楚的惰性。一個軟件不再依賴於設計人員有著完整的概念，而依賴於開發人員不斷地去改。

因而，概念的完整性不僅僅因為要做到概念的完整性不容易，同時因為軟件失敗的代價很小，更因為根本就沒有認識到概念的完整性的意義，從而在軟件項目中被忽略了。其結果就是，花費大量時間做著重復的事情，改著冗余復雜的代碼。這就是為什麽《人月神話》中重點提出：因為沒有概念的完整性，從而造成大多數項目失敗。

如何完整

保證概念的完整性，一方面需要設計人員具備良好的經驗。同時，不要嘗試著去將所有人的意見都融入其中。

如，一個軟件，要考慮的是大多數人的使用場景，或者重要人物的使用場景。對於個別人物或者次要的使用者，可以少考慮或者不考慮。本人在多個項目需求討論中都會遇到這樣的情況：某個人提到要一個功能，其理由是：我就是喜歡這樣的功能。這樣的“我”往往是代表著極少數使用者。

而作為一個要求概念完整的人，如果這樣的功能影響概念的完整性，就需要果斷放棄。而不能牽就於極個別的“我”。

在《人月神話》中，提到解決概念完整性的方法——外科手術團隊式開發方法。在這樣的團隊中，外科醫生（首席程序員）一個人來決定一個軟件要做成什麽樣子，並且去寫主要的代碼。

也就是說，為了保證概念的統一性，需要有一個人或者一個團隊（解決巨大問題的時候需要一個團隊）來決定什麽東西做，什麽東西不做。而不是去牽就所有人的要求。這個人或者團隊是要有經驗的。

在哪裏用

在制造一批汽車或者制造一棟樓房之前，設計人員都會做好詳細完整的設計。之後再進行實施。一批汽車或者一棟樓房，如果沒有造好，會造成很大的損失（這裏的損失不是算錢，而是計算對現實世界的改變有效性）。

本人所遇到做得好的軟件，其基本流程是：原型→確認原型→開發→測試。原型與原型的確認，就是在實施之前想把概念了解得更加完整，而不是在實施之後不斷地去更改。

小結

本文介紹了軟件開發失敗的主要原因——沒有完整的概念。並且很多項目都還在不斷地因為這樣的原因繼續失敗。在考慮一個領域的概念完整性的時候，會因為各種原因而考慮不全，但努力方面是明確的——搞清楚完整的概念。

軟件系統最重要的一點 - 概念完整性