序
最近在讀一本軟體工程領域的一部經典著作：《人月神話》。初看書名，肯定想不到這是一本關於軟體工程的書籍，或許是一本神話**，但事實就是如此。這本書細緻入微地從多個方面，多個角度切入，深入**了軟體專案開發的各個過程和可能存在的問題。用通俗易懂的語言和生動形象的例子為我們展現出了真是的軟體工程過程。
有人說：《人月神話》這本書已經暢銷20年經久不衰，是計算機和it領域的「聖經」。通過閱讀，個人認為這部著作的確不太容易理解。像這樣的書籍，僅僅閱讀一次是不夠的。或許在我年到半百，從業多年以後再次翻開此書，一定會有完全不一樣的感悟吧。人類的智慧型真的是無窮無盡的，從上世紀中期的巴貝奇分析機、到2023年第一台電子計算機「埃尼阿克」的誕生，在到現在的大資料、物聯網等新技術的逐漸普及。計算機或it其實是一項非常年輕的技術。短短不到100年的時間，資訊科技已經發展到讓人驚嘆的地步。對於現在的我們，已經不再需要去研究先人已經研究過的東西，也沒有必要去走先人已經走過的彎路。我們應該給予前人的經驗，繼續深入研究。《人月神話》就是多去千萬資訊科技從業人員積累的寶貴經驗。
什麼是軟體工程？這個問題在筆者大學本科時就在考慮。網上可以找到各種機構對其的不同定義。比較通用的是：用工程化的方法去研究如何構建可靠的、易用的、高質量的軟體產品的學科。過去筆者認為，所謂的軟體工程，其實就是程式設計序，用程式的**來解決實際生活中的問題。但事實並不是這樣，書中告訴我們，軟體工程的確是程式設計序，但準確地講，是一大群人在一起程式設計序。如何去協調不同的個體的工作？如何去指導乙個團隊有條不紊地進行軟體開發？如何處理和客戶的關係？如何估算和分配具體專案的時間？這就是軟體工程要研究的內容。
問題的提出
焦油坑。書中這樣描述軟體專案開發的狀態。沒有好的組織和規劃，在乙個軟體開發的中後期，就會面臨這樣的問題。當軟體的具有相當的規模是，就會出現各種各樣的問題，而此時投入越多的工作量，專案就越糟糕。就如同陷入焦油坑的野獸，越掙扎，就陷得越深。就這一點而言，筆者在做課程設計時，就深有體會。由於前期的設計上考慮問題不夠周全，導致後期的**實現時遇到了瓶頸，這個時候，如果你強制修改，那麼就會牽一髮而動全身。前期的設計至關重要。軟體領域有一種說法叫：破窗效應。意思是說，當一座大樓的一扇窗戶被打破時，過不了多久，其他的窗戶也會被打破。軟體開發的過程也是如此，當我們發現軟體的乙個bug或缺陷，在我們試圖修復它時，新的問題就會出現，就如同掉進了無底洞。
這就是為什麼我們學了各種各樣的技術，各式各樣的程式語言，看似懂得很多，卻無法做出乙個成熟的產品。其實軟體工程重要的不是具體的技術，而是工程化的思想和方法。而這需要進行通過大量的實踐來積累。對於乙個專案的開發，要關心的問題不僅僅是技術，專案的需求，專案開發的時間估算，經費預算，專案組成員之間溝通和交流的方式，都會影響到乙個專案的最終結果。
軟體工程是乙個團隊的工作
其實書中一直在強調，軟體工程是乙個團隊的工作。事情往往就是這樣，當乙個人做時，可能並不會有太大的問題，但同樣的工作一群人一起去做時，就得考慮很多問題。既要充分發揮每個個體的能力，還有兼顧團隊整體成果，這基本上是魚和熊掌不可兼得的事情。有時候，我們會發現，就乙個軟體專案小組而言，並不是參與的人員越多，專案的效率就越高。過多的成員意味著更高的溝通成本。
這裡筆者闡述乙個簡單的例子：包餃子。如果乙個人自己去做的話，這項工作確實非常費時。和面、剁餡兒、包餃子、煮餃子，步驟很費時，也很繁瑣。如果是多個人一起做，有些步驟就可以並行執行，相對就會節省一些時間。但是這裡有乙個問題：如果是多個人一起包餃子，要做的餃子的個數也會增加。乙個人做只需要做一人份就好，比如30個餃子。如果5個人同時做，就得做5人份，包150個餃子。這樣算下來，消耗的時間未必會比人少的時候要少，另外如果參加工作的一些個人工作效率很低的話，或許還會消耗更多的時間。筆者認為，這裡一定有乙個平衡點，當參與工作的人數的個數是這個平衡點時，消耗的時間是最少的。
《人月神話》中提出了這樣的乙個觀點，如果乙個200人的團隊中有20個人是精英，那就開除剩餘的180人，他們的工作有專案經理自己完成。也就是說，乙個小規模的精英團隊的生產效率要比乙個大規模的平庸的團隊高。人力增加的同時，溝通和交流的成本也在增加，而整個團隊的工作能力是二者的差值。書中詳細剖析了不同種類的工作的情況。如果乙個工作的各個部分是可以分解的，並且各個部分沒有關聯，那麼，參與的人員越多，專案的效率就越高，例如收割小麥；而對於各個部分由嚴格的時序邏輯的工作，人力的增加，並不會明顯提高工作的效率；而對於各個部分具有錯綜複雜的聯絡的工作，人力的增加只會起到***。工作的效率反而會降低。書中揭示了這樣乙個道理：人力和時間有時候是不能互換的，即「人」和「月」不一定是互通的。這的確很有道理。
團隊工作的另乙個問題就是團隊成員之間的溝通和決策的問題。乙個軟體專案小組如何去溝通？是類似於軍隊，由領導發號施令，小組成員負責執行？還是類似於議會？團隊的決策由小組所有成員共同作出？其實這兩種方式各有利弊。軍隊的管理保證了整個團隊的步調一致，令行禁止的方式可以很好地將每個成員的力量積聚在一起，但由於所有的決策都是團隊的leader作出的，團隊其他成員的能力就不能得到充分的發揮。如果是團隊成員共同討論決策的話，可以很好地利用到每個人的能力，但卻會造成一種喋喋不休的局面，即花費很長時間去討論，卻遲遲得不到統一的意見。這種情況下團隊成員之間的力量可能會互相抵消。也不會有太好的效果。
書中提出了一種外科醫生團隊的模式。由少數人做決策，其他人為其提供支援。工作是多方面的，乙個人在工作的某一方面是leader，在另一方面為其他人提供支援。也就是說每個成員都有專攻的領域，同時為其他人提供一定的支援。這種方式看起來結合了以上兩種方式的優點，但筆者認為，如果不同的成員之間的工作有衝突的話，這種模式又結合了前兩種方式的缺點。是「貴族**」？還是「民主政治」？或許要依具體情況而定吧？
沒有銀彈，擁抱變化
《人月神話》中提出的另外乙個概念就是：銀彈。銀彈的含義最初**於19世紀歐洲民間傳說和哥特**。這些傳說和**中將銀色的子彈描述為驅魔的利器，是針對狼人的特效**。《人月神話》的作者就將我們要開發的軟體比喻為「狼人」，因為軟體和「狼人」是類似的，看似正常的軟體只要有細微的問題，就會變得「面目全非」。書中提出這樣的觀點：可以應對所有軟體問題的「銀彈」是不存在的。作者還在一篇**中斷言：在近10年內，不會有特定的技術和方法，可以使軟體專案開發的能力有突破性的進展。如今距離**發表的10年已經過去，事實證明這樣的論斷是正確的。
為什麼「沒有銀彈」，作者認為主要原因在於軟體的特性：複雜性、一致性、可變性、和不可見性。筆者認為最根本的原因還是變化。正式可變性造成了軟體工程的複雜性，非一致性，和不可見性。其實開發乙個軟體和建造一座大樓，在思想上是類似的。最大的差別在於，建築工程的設計實在具體實施前就決定了的，而軟體的開發在實現過程中需求的變更時很常見的。軟體專案的開發過程必須要適應這種隨機的變化。擁抱變化，才是軟體工程的精髓所在。
沒有「銀彈」，也就意味著沒有乙個軟體是完美無缺的。這裡引用軟體測試領域的依據名言：我們只能通過測試證明軟體存在bug，卻永遠無法通過測試證明軟體沒有bug。it領域也是優勝劣汰的，乙個軟體要想生存下來，就必須不停地修改和維護。
長久以來，人們一直在研究好的軟體開發模型去適應這樣的變化。從最初的瀑布模型，到後來提出的敏捷軟體開發、極限程式設計，scrum每一種模式都有它的利弊。過去，筆者一直認為，瀑布模型是落後的模式，敏捷軟體開發等其他新提出的方法是先進的做法。但事實可能並不是這樣。據了解，為乙個火車站或飛機場開發乙個運營系統時，從專案開始到最後落成，肯能需要數十年的時間。敏捷開發可能確實在適應需求變更的方面有較好的效果，但是對於這種龐大的系統，前期的設計業是至關重要的。這一點筆者在課程專案的設計上也是深有體會的。
所以，「沒有銀彈」並不是意味著我們在軟體開發前期不需要周密的設計，進而在出現變更時在作具體的調整。相反，軟體的可變化性要求在設計的過程中更加周密，以便可以在需求發生變化時，對軟體不會造成太大的影響。乙個好的軟體工程師眼光要高，要能在短時間內**到這種變化，從而找到最優的設計。這裡闡述乙個簡單的例子：如果客戶需要乙個話筒，程式設計師為他製作了乙個有線的話筒，而過一段時間，客戶反映話筒的活動範圍太小。這時，普通的程式設計師會把話筒的線加長，而一流的軟體工程師會修改為無線話筒。在無線話筒沒有出現的年代，顯然第乙個設計出無線話筒的企業會具有競爭優勢。分析和**需求變更的導向是很難的，這完全取決於軟體工程師的經驗和閱歷。
總結
有不少朋友認為it行業變數太多，所以是「青春飯」，意思就是，當你乾到一定的歲數，就一定會被年輕的一輩所取代。 這說明他還沒有完全理解軟體工程的核心。軟體工程的精髓不在具體的技術，而在與其工程學的思想。如何分析市場的需求並**其未來的導向，如何管理乙個軟體專案團隊，如何去對乙個軟體專案進行評估和經費預算，不論技術如何發展和更新，這些東西都不會發生太大的變化。近期大資料和雲計算技術發展迅猛，好多人都在趨之若鶩地去研究這方面的內容。筆者認為研究具體的技術其實意義不大，大資料技術目前的確很熱門，但它總有冷門那一天。當然，軟體工程的思想的培養也是建立在對技術的充分了解為的前提的。
據說每乙個成功的軟體工程師都讀過《人月神話》。本書和其他介紹軟體工程的教材不同，重點介紹了軟體專案管理的具體細節，而不是去介紹不同的開發模型。很不錯的一本書，值得反覆拜讀。
人月神話 人月
缺乏合理的進度安排是造成專案滯後的最主要的原因，它比其他所有因素加起來的影響還大 引起的原因 a.估算技術不嚴謹科學，缺乏有效研究，建立在不真實的假設 一切會執行良好 b.對進度缺少跟蹤和監督 c.認為人月可以互換，進度與工作量不等同 程式設計人員的樂觀主義 人月關係 a.人員和時間的關係 完全可以...
《人月神話》讀書筆記
p8,程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。p19,用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。因為它暗示人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況 某個任務可以分解參與人員，並且他們之間不需要相互交流。p23,...
人月神話讀書筆記
人數和時間的互換僅僅適用於以下情況 某個任務可以分解給參與人員，並且他們之間不需要相互的交流。當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。溝通所增加的負擔由兩個部分組成，培訓和相互的交流。相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作，則工作量按照n n 1...