《人月神話》讀書筆記

人月神話

（如需高清無碼大圖能夠私信）

沒有銀彈

軟件活動包括：

• 一、根本任務：打造由抽象軟件實體構成的複雜概念結構

• 二、次要任務：使用編程語言表達這些抽象實體，在空間和時間限制內將它們映射成機器語言

軟件開發困難：

• 一、根本的：軟件特性中固有的困難

• 二、次要的：出如今目前生產上的，但並不是那些與生俱來的困難

軟件開發中困難的部分是規格化、設計和測試這些概念上的結構，而不是對概念進行表達和對實現逼真程度進行驗證

軟件系統中沒法規避的內在特性：

• 一、複雜度

• 二、一致性

• 三、可變性

• 四、不可見性

以往解決次要困難的一些突破：

• 一、高級語言

• 二、分時

• 三、統一編程環境

銀彈的但願：

• 一、高級編程語言

• 二、面向對象編程

• 三、人工智能

• 四、專家系統

• 五、「自動」編程

• 六、圖形化編程

• 七、程序驗證

• 八、環境和工具

• 九、工做站

針對概念上根本問題的頗具前途的方法：

• 一、購買和自行開發

• 二、需求精煉和快速原型

• 三、增量開發-增加，而非搭建系統

• 四、卓越的設計人員

總體部分

剔除bug的設計

• 一、防範bug的定義

• 二、測試規格說明

• 三、自頂向下的設計：設計是一系列精化的步驟

  • S一、勾畫能獲得主要結果的，但比較粗略的任務定義和大概的解決方案

  • S二、對該定義和方案進行細緻的檢查，以判斷結果與指望之間的差距。同時，將上述步驟的解決方案在更細的步驟中進行分解

• 四、結構化編程

構件單元調試

• 本機調試

• 內存轉儲

• 快照

• 交互式調試

• 測試用例

系統集成調試

• 一、使用通過調試的構件單元

• 二、搭建充分的測試平臺：供調試使用的全部程序和數據

  • 一、僞構件

  • 二、微縮文件

• 三、控制變動

• 四、一次添加一個控件

• 五、階段（量子）化、按期變動

削足適履

規模控制

• 對項目經理而言，規模控制是技術以及管理工做的一部分

  • S一、研究用戶和應用，設置系統的規模

  • S二、將系統劃分爲若干部分，並設定每一個部分的規模目標

• 幾個道理：

  • 一、和制訂駐留空間預算同樣，應該制訂整體規模的預算；和制訂規模預算同樣，應該制訂後臺存儲訪問的預算

  • 二、在指明模塊有多大的同時，確切定義模塊的功能

  • 三、培養開發人員從系統總體出發、面向用戶的態度是軟件編程管理人員最重要的職能

空間技能

• 一、用功能交換尺寸

• 二、時間-空間的折衷

數據的表現形式是編程的根本

• 創造出自精湛的技藝，技藝的改進的結果每每是戰略上的突破，戰略上的突破常來自於數據或表的從新表達，這是程序的核心所在

多此一舉

結構師的交互準則和機制

• 一、牢記是開發人員承擔創造性和發明性的實現責任，因此結構師只能建議，不能支配

• 二、時刻準備着爲所指定的說明建議一種實現的方法，一樣準備接受其餘任何能達到目標的方法

• 三、對上述建議保持低調和平靜

• 四、準備放棄堅持所做的改進建議

自律-開發第二系統所帶來的後果

• 產生緣由：設計第一個系統時結構師會面對不斷產生的潤色功能，這些功能被擱置，成爲下一個項目的內容。作下一個項目時，結構師信心十足，會向系統添加大量修飾功能和想法，然而不少是多此一舉之舉

• 結構師沒法跳過第二個系統，但他能夠有意識關注那個系統的特殊危險，運用特別的自我約束準則來避免那些功能上的修飾；根據系統基本理念及目的變動，捨棄一些功能

• 項目經理爲了不多此一舉，必須堅持至少擁有兩個系統以上開發經驗結構師的決定

焦油坑

編程系統產品

職業的樂趣

• 一、建立事物

• 二、開發對他人有用的東西

• 三、組裝的魔力

• 四、學習的樂趣

• 五、工做的介質易於駕馭

職業的苦惱

• 一、追求完美

• 二、沒法控制的目標、資源和信息

• 三、瑣碎的BUG

• 四、易於陳舊

人月神話

項目滯後的最主要緣由：

缺少合理的時間進度

• 一、缺少有效的估算技術

• 二、誤覺得人和月能夠互換

• 三、難以持續耐心地估算

• 四、對進度缺乏跟蹤和監督

• 五、單純增長人力只會火上澆油

樂觀主義：全部的

編程人員都是樂觀主義者

• 緣由：介質易於駕馭，咱們期待在實現過程當中不會碰到困難；然而咱們的構思是有缺陷的

人月

• 用人月做爲衡量一項工做的規模是一個危險和帶有欺騙性的神話。它暗示着人員數量和時間能夠相互替換。實際上，添加人手須要更多的交流成本，反而延長了時間進度。

• Brooks法則：向進度落後的項目中增長人手，只會使進度更加落後

軟件任務進度安排

• 1/3 計劃

• 1/6 編碼

• 1/4 構件測試和早期系統測試

• 1/4 系統測試（不爲系統測試安排足夠的時間簡直就是一場災難）

貫徹執行

文檔化的規格說明-手冊

• 手冊是產品的外部規格說明，它描述和規定了用戶所見的每個細節；一樣，它也是結構師主要的工做產物

形式化定義

會議和大會

• 周例會：每週半天，全部結構師、硬件和軟件實現人員表明和市場計劃人員參與，由首席系統結構師主持

  • 在會議以前，任何人能夠提出問題和意見，以書面形式

  • 對詳細的變動建議做出決策

  • 卓有成效的緣由

    • 一、數月內，相同小組的結構師、用戶和實現人員每週交流一次，所以你們對項目內容比較熟悉，不須要安排額外時間進行培訓

    • 二、上述小組十分睿智和敏銳，深入理解所面對的問題，而且與產品密切相關。沒有人是「顧問」的角色，每一個人都要承擔義務

    • 三、當問題出現時，在界限的內部和外部同時尋求解決方案

    • 四、正式的書面建議集中了注意力，強制了決策的制定，避免了會議草稿紀要方式的不一致

    • 五、清晰地授予首席結構師決策的權力，避免了妥協和拖延

• 年度大會：隨着時間推移，一些決定沒有很好地貫徹，這些問題周例會沒有從新考慮，慢慢的，小問題就會積累。爲了解決這些積累的問題，舉行年度大會，通常持續兩週

提綱挈領

爲何要有正式的文檔

• 一、書面決策是必要的

• 二、文檔可以做爲同其餘人的溝通渠道

• 三、項目經理的文檔能夠做爲數據基礎和檢查列表

禍起蕭牆

里程碑仍是沉重的負擔

• 根據進度表來控制項目，進度表上的每一件事被稱爲「里程碑」。好的里程碑對團隊來講其實是一項服務，能夠用來向項目經理提出合理要求的一項服務，而不確切的里程碑是難以處理的負擔。

「其餘的部分反正會落後」

• 必須關係每一天的滯後，它們是大災禍的基本組成元素

地毯的下面

• 一線經理髮現問題後，並不會當即向老闆彙報，而是本身想辦法解決。所以，因此污垢都被隱藏在地毯之下。兩個把污垢展示給老闆的方法：

  • 一、減小角色衝突：老闆要區別行動信息和狀態信息

  • 二、猛地拉開地毯：不論協做與否，瞭解狀態真相的評審機制是必要的

成竹在胸

Portman的數據

• Portman發現他的編程隊伍落後進度大約1/2，每項工做花費的時間大約是估計的兩倍

Aron的數據

Harr的數據

OS/360的數據

Corbato的數據

• 對經常使用編程語言而言，生產率彷佛是固定的，這個固定的生產率包括了編程中須要註釋、並可能存在錯誤的狀況

• 使用適當的高級語言，編程的效率能夠提升5倍

干將莫邪

目標機器

• 目標機器是軟件所服務的對象，程序必須在該機器上進行最後的測試

輔助機器和數據服務

• 輔助機器是那些在開發系統中提供服務的機器

高級語言和交互式編程

• 使用高級語言的主要緣由是生產率和調試速度

未雨綢繆

爲捨棄而計劃

惟一不變的就是變化自己

爲變動計劃系統

• 細緻的模塊化、可拓展的函數、精確完整的模塊間接口設計、完備的文檔，可能還有調用隊列和表驅動的一些技術

• 最重要的措施是使用高級語言和自文檔技術，以減小變動引發的錯誤

爲變動計劃組織架構

• 設計人員不肯意爲設計書寫文檔的緣由，不只僅是惰性或時間壓力。相反，設計人員一般不肯意提交嘗試性的設計決策，再爲它們進行辯解

前進兩步，後退一步

• 軟件維護主要包含對設計缺陷的修復，而缺陷修復總會以20%-50%的概率引入新的bug

前進一步，後退一步

• 全部修改都傾向於破壞系統的架構，增長系統的混亂程度。隨着時間的推移，系統變得愈來愈無序，修復工做早晚失去根基。每一步前進都伴隨着一步後退

爲何巴比倫塔

會失敗

巴比倫塔的管理教訓

• 他們具備的條件

  • 清晰的目標

  • 人力

  • 材料

  • 足夠的時間

  • 足夠的技術

• 他們失敗的因素

  • 交流

  • 組織

大型編程項目中的交流（溝通途徑）

• 一、非正式的途徑：清晰定義小組內部的相互關係和充分利用電話，能鼓勵大量的電話溝通，從而達到對所寫文檔的共同理解

• 二、會議：常規項目會議，團隊一個接一個地進行簡要的技術陳述。這種方式很是有用，能澄清成百上千的細小問題

• 三、工做手冊：在項目的開始階段，應該準備正式的項目工做手冊。

項目工做手冊

• 是什麼：對項目必須產出的一系列文檔進行組織的一種結構。項目全部的文檔都必須是該結構的一部分

• 爲何：技術說明必不可少；控制信息發佈

• 處理機制：每間辦公室應保留一份工做手冊的拷貝。工做手冊的實時性很關鍵，因此採用活頁夾的方式，僅僅更換變動頁

大型編程項目的組織架構

• 團隊組織的目的是減小沒必要要的交流和合做的數量

• 減小交流的方法是人力劃分和限定職責範圍

• 樹狀編程隊伍，爲使它行之有效，每棵子樹必須具有的基本要素：

  • 一、任務

  • 二、產品負責人：組建團隊，劃分工做及制定進度表，要求必要的資源，確保進度目標的實現

  • 三、技術主管和結構師：構思設計，識別系統的子部分，提供設計的一致性和完整性；控制系統複雜程度；提供問題解決方案

  • 四、進度

  • 五、人力的劃分

  • 六、各部分之間的接口定義

• 技術做爲總指揮，產品負責人充當其左右手。這是對小型團隊最好的選擇

另一面

須要什麼樣的文檔

• 使用程序

  • 一、目的：主要功能是什麼？開發程序緣由是什麼？

  • 二、環境：程序運行在什麼樣的機器、硬件配置和操做系統上？

  • 三、範圍：輸入的有效範圍是什麼？容許顯示的合法範圍是什麼？

  • 四、實現功能和使用的算法。精確地闡述它作了什麼

  • 五、輸入-輸出格式。必須是確切和完整的

  • 六、操做指令。包括控制檯及輸出內容中正常和異常結束的行爲

  • 七、選項。用戶的功能選項有哪些？如何在選項之間進行挑選？

  • 八、運行時間。在指定的配置下，解決特定規模問題所須要的時間？

  • 九、精度和校驗。指望結果的的精確程度？如何進行精度的檢測？

• 驗證程序

  • 一、針對遇到的大多數常規數據和程序主要功能進行測試的用例

  • 二、數量相對較少的合法數據測試用例

  • 三、數量相對較少的非法數據測試用例

• 修改程序

  • 一、流程圖或子系統的結構圖

  • 二、對所用算法的完整描述，或者對文檔中相似描述的引用

  • 三、對全部文件規劃的理解

  • 四、數據流的概要描述-從磁盤或磁帶中，獲取數據或程序處理的序列-以及在每一個處理過程當中完成的操做

  • 初始設計中，對已預見修改的討論；特性、功能回調的位置以及出口；原做者對可能擴充的地方以及可能處理方案的一些意見。另外，對隱藏缺陷的觀察也一樣頗有價值

流程圖

• 一頁紙的流程圖，成爲表達程序結構、階段或步驟的一種很是基本的圖示

自文檔化的程序

• 將文檔整合到源代碼

  • 方法一、藉助那些出於語言的要求而必須存在的語句，來附加儘量多的「文檔」信息

  • 方法二、儘量地使用空格和一致的格式提升程序的可讀性，表現從屬和嵌套關係

  • 三、以段落的形式，向程序中插入必要的記敘性文字

貴族專制、民主政治

和系統設計

概念一致性

• 在系統設計中，概念完整性是最重要的考慮因素。即爲了反應一系列連貫的設計思路，寧肯省略一些不規則的特性和改進，也不提倡獨立和沒法整合的系統

得到概念的完整性：目標是易用性，易用性須要設計的一致性和概念上的完整性

• 在語義上，應具備一樣的類似性

• 在語法上，每一個部分應使用相同的技巧

• 每一個部分必須反映相同的原理、原則和一致的折衷機制

貴族專制和民主政治

• 貴族：結構師；人民：實現人員

• 結構師和實現人員都有創意，但創意要符合系統的概念完整性

• 只能存在少許結構師，他們處於貴族專制的地位。爲了系統概念完整性，他們必須控制概念

• 外部技術說明與具體實現都富有創造性。

• 外部的體系結構實際上加強了而不是限制實現小組的創造性

外科手術隊伍

問題

• 精幹隊伍效率很是高，但開發大型系統時仍然遠遠不夠，只能須要大量人手。這二者矛盾須要調和

Mills的建議

• 10人的編程隊伍角色分工-Mills建議項目隊伍以相似外科手術的方式組建，每一部分由一個團隊解決。即一我的進行問題分解，其餘人給予其所需的支持

  • 外科醫生：首席程序員，極高的天分，十年的經驗，及其餘知識

    • 定義功能和性能技術說明書

    • 設計程序

    • 編制源代碼

    • 測試以及書寫技術文檔

  • 副手：外科醫生後備，能完成一部分工做，但經驗較少

    • 設計的思考者、討論者和評估人員

  • 管理員：外科醫生是老闆，在人員、加薪方面具備決定權，但不能在這些事物上浪費時間，須要有人管理

  • 編輯：外科醫生負責產生文檔，編輯須要根據外科醫生草稿或口述進行分析和從新組織

  • 兩個祕書：管理員和編輯各須要一個

  • 程序職員：維護編程產品庫中全部團隊的技術記錄

  • 工具維護人員：保證全部基本服務的可靠性

  • 測試人員：外科醫生須要大量測試用例進行測試

  • 語言專家：尋找一種簡潔、有效的使用語言的方法解決複雜問題

如何運做：「兩人隊伍」與「外科醫生-副手」的區別

• 一、傳統團隊中每人負責一部分任務；外科手術團隊中，外科醫生和副手都瞭解全部的設計和所有代碼

• 二、傳統隊伍人人平等，出現問題須要討論和妥協；外科手術團隊中由外科醫生當方面決定

團隊的擴建

• 擴建過程的成功依賴於：每一個部分的概念完整性獲得了完全的提升