《人月神話》讀書筆記⑤：總結與更新

十七、根本與次要問題：再論「沒有銀彈」"No Silver Bullett"Refired

• 創造性活動包括：概念性結構的形式規格化、使用現實的介質來實現、在實際使用中與用戶交互
• 如果開發的次要部分少於整個工作的9/10，幾十不佔用任何時間，也不會給生產率帶來數量級的提高。
• 複雜性是層次化的，通過分層的模塊或對象
• 軟體系統增加必要的複雜性，增量化，可使系統持續地運行。
• 質量帶來生產率，很多代價高昂的後續項目投入了大量的時間和精力來尋找和修復規格說明、設計和實現上的錯誤。
• 系統化軟體開發方法的發展是未來解決質量問題（特別是避免大型災難），而不是出於生產率方面的考慮
• 成品軟體這個大眾市場是軟體工程領域中，意義最深遠的開發方向，購買、而非開發
• 面向對象編程特徵：強制的模塊化和清晰的介面；強調封裝；強調繼承和伴隨著的層次化類結構及虛函數；強調強抽象數據類型化
• 代碼重複使用的問題：現階段零部件的庫是無法滿足的，需要複合產品讓人去學習代碼的意義

十八、《人月神話》的觀點：是與非Propositions of The Mythical Man-Month;True or False

• 本章是再版時，對前面17章的一個總結，現摘錄如下
• 第一章：編程系統產品內高成本的構件在根本上是相互獨立的；編程行業「滿足我們內心深處的創造渴望和愉悅所有人的共有情感」
• 第二章：缺乏合理時間進度是造成項目滯後的最主要原因；所有編程人員都容易過於樂觀；圍繞成本核算的估計技術，混淆了工作量和項目進度；時間安排，1/3計劃、1/6編碼、1/4構件測試，1/4系統測試；為進度落後的項目增加人手，只會使項目更加落後
• 第三章：經驗和實際表現之間沒有相互聯繫；由少數頭腦產生的產品完整性，再由多位協助人員達到總體生產率，減少溝通的工作量
• 第四章：概念完整性是系統設計中最重要的考慮因素；體系結構、設計實現、物理實現的許多工作可以並行
• 第五章：儘早交流和持續溝通能使結構師有較好的成本意識；牢記是開發人員承擔創造性的實現工作，結構師只能提出建議
• 第六章：形式化地設計定義，記敘性地理解定義；大型團隊，也必須只能由一個或兩個人來完成設計結果
• 第七章：缺乏交流是恐怖的；但是每個人看到每件事的目標是完全錯誤的，每個部分應該被封裝，大家只需要看到介面即可
• 第八章：僅僅通過代碼部分時間的估計，然後乘以其他部分的相對係數，是無法得出對整項工作的精確估計的；使用適當的高級語言
• 第九章：開發人員必須控制規模；系統結構師必須保持持續警覺，確保連貫的系統完整性
• 第十章：不管大小項目，都應該對文檔進行規範化處理
• 第十一章：做好系統的丟棄和重新設計的準備；開發人員交付的是用戶滿意程度，而不僅僅是實際的產品；程序維護就是前進兩步、後退一步的過程
• 第十二章：一次分配給一個小組的連續目標時間塊是最好的安排方法；編程中，節省最大工作量的工具可能是文本編輯系統
• 第十三章：規格說明必須提交給外部測試小組，以仔細檢查說明的完整性和明確性；自上而下地進行設計（逐步細化）是最重要的新型形式化軟體開發方法
• 第十四章：一天一天的進度落後比起重大災難更難識別；進度表裡的里程碑必須是具體的、特定的和可度量的事件；必須有人對里程碑進行維護和控制；老闆不要越俎代庖
• 第十五章：描述性文字在程序里是必要的；文檔中整個生命周期對克服懶惰和進度的壓力起促進和激勵作用；測試用例包括校驗輸入數據、邊界輸入數據、無效的輸入數據
• 總結：軟體系統可能是人類創造中最複雜的十五
• 軟體工程的焦油坑將在未來很長一段時間內使人舉步維艱

以上內容為《人月神話》（作者：[美]小弗雷德里克·布魯克斯）的第17-18章讀書筆記及部分摘要，本人加入一定量自己的理解；因水平有限，歡迎大家交流指正，謝謝~

另：《人月神話》是比較偏技術側的書籍，翻譯過來有點佶屈聱牙，我這裡更多只是列了提綱，大家有機會自己去看、可以有更多收穫~

推薦閱讀：