《人月神話》中Brooks一直很是強調「概念完整性」對於系統的重要性。十年前看這本書的時候老是以爲不懂,是一種說不清,朦朦朧朧的感受。html
【轉載自http://blog.sina.com.cn/s/blog_a49b04f601017533.html】程序員
概念的完整性,是指針對於一個領域,不只瞭解該領域的全部對象,而且瞭解全部對象之間的關係。好比,小學數學中的四則運算。全部的對象就是指有理數,全部的關係就是由加減乘除四種運算而可以產生另一個有理數。若是對這樣的計算徹底瞭解的話,那麼使用這樣的領域來解決問題就不成問題。測試
概念的完整性在一本20年了仍是很是深入的軟件工程書中被重點提出。這本書叫作《人月神話》。做者經過本身的經驗及大量的數據而找到軟件開發出現問題的主要緣由——概念不完整。網站
概念不完整,就在開始註定一個軟件項目要失敗了。就本人的經驗來看,不少項目都由於沒有對問題了解得足夠細緻,而後就進行了軟件開發,結果所寫的代碼不能實際解決問題,因而又改代碼,而且是不斷地去改代碼,指望經過改代碼來達到解決問題的目的。設計
其實,問題的根本在於,概念不完整,換言之,就是,始終都沒有搞明白問題域有那些對象,各個對象之間是什麼樣的聯繫。可以考慮這樣的問題的人,通常都是對完整的概念有着強烈的要求而且在這方面具有至關經驗的人。寫代碼的人很難考慮到所寫的這一部分代碼是否真的解決了問題。在被要求改寫代碼的時候,只是大概瞭解別人要改一個需求。指針
可是,需求歷來就不須要改,須要改需求,只說明一點——沒有真正搞清楚對象及對象之間的聯繫。從而沒有辦法瞭解問題。在沒有真正瞭解問題的時候,只能被動地等待問題的出現,而後去改代碼,以頭痛醫頭,腳痛醫腳的方式去解決問題。htm
而概念的完整性,是創建在已經徹底瞭解領域的對象及對象之間的關聯。這種徹底瞭解,並非感性地瞭解,而是理性地瞭解。如,在小學數學這個領域,加法與乘法具備交換律。即,對象
a + b = b + a
那麼在考慮加法與乘法的時候,能夠只考慮將小的數放在前面,大的數放在後面這樣的情形。從而能夠獲得簡化的加法與乘法口訣。即,只要知道 2+3=5 就能夠知道 3+2 必定等於 5。blog
這樣的例子是爲了說明,在瞭解關係的時候,要上升到理性認識,而不是停留在表象上。開發
又如,考慮社交網站的例子。表象上來看,社交網站要記錄每一個人的興趣愛好,職業,曾經就讀的學校等。這就致使須要創建一個用戶表,創建一個愛好表,職業表,學校表:
而這樣的關聯徹底能夠抽象成:
User <--> User_Object <--> Object name user_id name object_id type time
社交網站所須要記錄的是人與物的關係,及人與人的關係。一我的喜歡一個物(愛好),作一個物的事(職業),讀書於一個物(學校)。以上的抽象,就能夠將人與物的關係及時間概念完整地表達出來。
也就是說,概念的完整性,並非將全部的東西都知道就能夠了,還須要真正達到必定的理性認識。達到必定的抽象才行。
軟件是一個修改起來代價相對較小的東西,比起造一輛車,一個軟件作得再差,也不會形成巨大的現實世界的變化,它最多改變的只是硬盤中某一個區域的磁性。而造一輛車子,須要現實世界中不少物質發生變化才能夠作成。從而,這推進了人不把問題想清楚的惰性。一個軟件再也不依賴於設計人員有着完整的概念,而依賴於開發人員不斷地去改。
於是,概念的完整性不只僅由於要作到概念的完整性不容易,同時由於軟件失敗的代價很小,更由於根本就沒有認識到概念的完整性的意義,從而在軟件項目中被忽略了。其結果就是,花費大量時間作着重複的事情,改着冗餘複雜的代碼。這就是爲何《人月神話》中重點提出:由於沒有概念的完整性,從而形成大多數項目失敗。
保證概念的完整性,一方面須要設計人員具有良好的經驗。同時,不要嘗試着去將全部人的意見都融入其中。
如,一個軟件,要考慮的是大多數人的使用場景,或者重要人物的使用場景。對於個別人物或者次要的使用者,能夠少考慮或者不考慮。本人在多個項目需求討論中都會遇到這樣的狀況:某我的提到要一個功能,其理由是:我就是喜歡這樣的功能。這樣的「我」每每是表明着極少數使用者。
而做爲一個要求概念完整的人,若是這樣的功能影響概念的完整性,就須要果斷放棄。而不能牽就於極個別的「我」。
在《人月神話》中,提到解決概念完整性的方法——外科手術團隊式開發方法。在這樣的團隊中,外科醫生(首席程序員)一我的來決定一個軟件要作成什麼樣子,而且去寫主要的代碼。
也就是說,爲了保證概念的統一性,須要有一我的或者一個團隊(解決巨大問題的時候須要一個團隊)來決定什麼東西作,什麼東西不作。而不是去牽就全部人的要求。這我的或者團隊是要有經驗的。
在製造一批汽車或者製造一棟樓房以前,設計人員都會作好詳細完整的設計。以後再進行實施。一批汽車或者一棟樓房,若是沒有造好,會形成很大的損失(這裏的損失不是算錢,而是計算對現實世界的改變有效性)。
本人所遇到作得好的軟件,其基本流程是:原型→確認原型→開發→測試。原型與原型的確認,就是在實施以前想把概念瞭解得更加完整,而不是在實施以後不斷地去更改。
本文介紹了軟件開發失敗的主要緣由——沒有完整的概念。而且不少項目都還在不斷地由於這樣的緣由繼續失敗。在考慮一個領域的概念完整性的時候,會由於各類緣由而考慮不全,但努力方面是明確的——搞清楚完整的概念。