人月神話

用戶評論 (總計(jì)10條)

•   　　《人月神話》乍看之下以為是一本神話小說，這就大錯(cuò)特錯(cuò)了。這是一本軟件工程的古老經(jīng)典，是軟件工程的必讀書籍。其中涉及項(xiàng)目管理、團(tuán)隊(duì)、人員、文檔等軟件工程必須的東西。作者用一個(gè)個(gè)生動(dòng)的實(shí)例來闡述觀點(diǎn)，而不是無聊透頂?shù)睦碚?，這讓讀者更易于接受其中道理，可讀性很高。翻譯組翻譯到尾，將文章翻譯的很好，沒有生搬硬套。三十多年經(jīng)久不衰就說明了這本書的影響力還在增加，軟件行業(yè)是一個(gè)急速發(fā)展的行業(yè)，但是這本書中很多理論還能夠跟上行業(yè)發(fā)展的腳步，說明這本書具有極強(qiáng)的前瞻性和理論性。建議所有想要進(jìn)入軟件工程，特別是項(xiàng)目管理的相關(guān)人員閱讀。
  　　
•   　　 每個(gè)隊(duì)伍擁有自己的任務(wù)、進(jìn)度、甚至如何定義、構(gòu)建、發(fā)布的過程。團(tuán)隊(duì)有4到5個(gè)專家組成，包括開發(fā)、測試、書寫文檔。有團(tuán)隊(duì)而不是老板對討論進(jìn)行仲裁。我無法形容授權(quán)和由團(tuán)隊(duì)自行負(fù)責(zé)項(xiàng)目的成功與否的重要性
•   　　一、對于編程，喜歡的理由（寫的很好）
  　　編程為什么有趣？作為回報(bào)，它的從業(yè)者期望得到什么樣的快樂？
  　　首先是一種創(chuàng)建事物的純粹快樂。如同小孩在玩泥巴時(shí)感到愉快一樣，成年人喜歡創(chuàng)建事物，特別是自己進(jìn)行設(shè)計(jì)。我想這種快樂是上帝創(chuàng)造世界的折射，一種呈現(xiàn)在每片獨(dú)特、嶄新的樹葉和雪花上的喜悅.其次，快樂來自于開發(fā)對其他人有用的東西。內(nèi)心深處，我們期望其他人使用我們的勞動(dòng)成果，并能對他們有所幫助。從這個(gè)方面，這同小孩用粘土為“爸爸辦公室”捏制鉛筆盒沒有本質(zhì)的區(qū)別。
  　　第三是整個(gè)過程體現(xiàn)出魔術(shù)般的力量——將相互嚙合的零部件組裝在一起，看到它們精妙地運(yùn)行，得到預(yù)先所希望的結(jié)果。比起彈珠游戲或點(diǎn)唱機(jī)所具有的迷人魅力，程序化的計(jì)算機(jī)毫不遜色。
  　　第四是學(xué)習(xí)的樂趣，來自于這項(xiàng)工作的非重復(fù)特性。人們所面臨的問題，在某個(gè)或其它方面總有些不同。因而解決問題的人可以從中學(xué)習(xí)新的事物：有時(shí)是實(shí)踐上的，有時(shí)是理論上的，或者兼而有之。
  　　最后，樂趣還來自于工作在如此易于駕馭的介質(zhì)上。程序員，就像詩人一樣，幾乎僅僅工作在單純的思考中。程序員憑空地運(yùn)用自己的想象，來建造自己的“城堡”。很少有這樣的介質(zhì)——?jiǎng)?chuàng)造的方式如此得靈活，如此得易于精煉和重建，如此得容易實(shí)現(xiàn)概念上的設(shè)
  　　想。（不過我們將會(huì)看到，容易駕馭的特性也有它自己的問題）
  　　二、關(guān)于開發(fā)語言很真實(shí)
  　　當(dāng)意識到進(jìn)度的偏移時(shí)，下意識（以及傳統(tǒng)）的反應(yīng)是增加人力。這就像使用汽油滅火一樣，只會(huì)使事情更糟。越來越大的火勢需要更多的汽油，從而進(jìn)入了一場注定會(huì)導(dǎo)致災(zāi)難的循環(huán)。
  　　無論多少個(gè)母親，孕育一個(gè)生命都需要十個(gè)月。
  　　1/3 計(jì)劃
  　　1/6 編碼
  　　1/4 構(gòu)件測試和早期系統(tǒng)測試
  　　1/4 系統(tǒng)測試，所有的構(gòu)件已完成
  　　人數(shù)和時(shí)間的互換僅僅適用于以下情況：某個(gè)任務(wù)可以分解給參與人員，并且他們之間不需要相互的交流（圖2.1 ）。這在割小麥或收獲棉花的工作中是可行的；而在系統(tǒng)編程中近乎不可能。
  　　四個(gè)圖印象非常深刻?。?！
  　　向進(jìn)度落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后。（Addin g man po we r to a l ate software project makes it later ）
  　　絕大多數(shù)大型編程系統(tǒng)的經(jīng)驗(yàn)顯示出，一擁而上的開發(fā)方法是高成本的、速度緩慢的、不充分的。
  　　概念的完整性要求設(shè)計(jì)必須由一個(gè)人，或者非常少數(shù)互有默契的人員來實(shí)現(xiàn)。
  　　而進(jìn)度壓力卻要求很多人員來開發(fā)系統(tǒng)。有兩種方法可以解決這種矛盾。第一種是仔細(xì)地區(qū)分設(shè)計(jì)方法和具體實(shí)現(xiàn)。第二種是前一章節(jié)中所討論的、一種嶄新的組建編程開發(fā)團(tuán)隊(duì)的方法。
  　　
  　　不能與系統(tǒng)基本概念進(jìn)行整合的良好想法和特色，最好放到一邊，不予考慮。
  　　
  　　三、關(guān)于分工
  　　產(chǎn)品負(fù)責(zé)人和技術(shù)主管是同一個(gè)人。這種方式非常容易應(yīng)用在很小型的隊(duì)伍中，可能是三個(gè)或六個(gè)開發(fā)人員。在大型的項(xiàng)目中則不容易得到應(yīng)用。原因有兩個(gè)：第一，同時(shí)具有管理技能和技術(shù)技能的人很難找到。思考者很少，實(shí)干家更少，思考者－實(shí)干家太少了。 第二，大型項(xiàng)目中，每個(gè)角色都必須全職工作，甚至還要加班。對負(fù)責(zé)人來，很難在承擔(dān)全部管理責(zé)任的同時(shí)，還能抽出時(shí)間進(jìn)行技術(shù)工作。對技術(shù)主管來說，很難在保證設(shè)計(jì)的概念完整性，沒有任何妥協(xié)的前提下，擔(dān)任管理工作。
  　　
  　　實(shí)踐是最好的老師，但是，如果不能從中學(xué)習(xí)，再多的實(shí)踐也沒有用。
  　　
  　　普遍的做法是，選擇一種方法，試試看；如果失敗了，沒關(guān)系，再試試別的。不管怎么樣，重要的是先去嘗試。
  　　
  　　大多數(shù)有豐富經(jīng)驗(yàn)的程序員擁有自己的私人開發(fā)庫，可以使他們使用大約30％的重用代碼來開發(fā)軟件。
  　　
  　　四、最后
  　　最后的《人月神話》的觀點(diǎn)就是全書的綱！
•   　　很久以前就聽到過這本書，但是一直沒有時(shí)間去看完它，而當(dāng)終于拜讀完之后，也確實(shí)明確了這本書在軟件工程中的重要，有些問題至今可以當(dāng)做規(guī)范來使用
  　　
  　　學(xué)習(xí)編程最困難的部分，是講故事的方式向最求完美的方向調(diào)整
  　　
  　　軟件進(jìn)度安排
  　　1/3 計(jì)劃
  　　1/6 編碼
  　　1/4 構(gòu)建測試和早起的系統(tǒng)測試
  　　1/4 系統(tǒng)測試，所有的構(gòu)建已完成
  　　
  　　概念的完整性需求設(shè)計(jì)必須由一個(gè)人活著少數(shù)有默契的人員來實(shí)現(xiàn)
  　　
  　　項(xiàng)目先決條件
  　　1、明確的目標(biāo)
  　　2、人力
  　　3、材料
  　　4、時(shí)間
  　　5、技術(shù)
•   　　很多智力型工作，比如寫作、繪畫、表演，一直以來都沒有太大進(jìn)步，軟件開發(fā)也是?！稕]有銀彈》在未來十年應(yīng)該依然存在。
  　　很多程序員崇拜技術(shù)大牛，因?yàn)樗麄兿嘈糯笈Ｄ軌驇砥渌俗叱鼋褂涂樱∵@種人是很稀缺的，除了技術(shù)過硬，在眼界、人際關(guān)系等方面都要過硬。我覺得這種大牛才知道佩服！
•   　　作為一個(gè)純粹的文科生，有點(diǎn)吃力~不過還是能夠?qū)W習(xí)一些東西，互聯(lián)網(wǎng)不是我想象中的那么簡單，是個(gè)系統(tǒng)性很強(qiáng)大的內(nèi)容，繼續(xù)學(xué)習(xí)，加油！我的心得，1、團(tuán)隊(duì)建設(shè)，強(qiáng)調(diào)核心領(lǐng)導(dǎo)力的重要性以保證概念設(shè)計(jì)的完整性；2、溝通交流，強(qiáng)調(diào)組織的系統(tǒng)性以促進(jìn)項(xiàng)目管理的實(shí)現(xiàn)；3、手冊文檔，強(qiáng)調(diào)手冊結(jié)構(gòu)的精確完整以控制信息的發(fā)布。
  　　完全是個(gè)菜鳥，還是總結(jié)一些自己內(nèi)容，希望對以后能有幫助。
  　　
•   　　讓我感到失望的地方如下：
  　　1.翻譯得太差，好多句子讀起來都特別別扭；尤其是章節(jié)標(biāo)題，非要賣弄文字；
  　　2.書中舉例太過陳舊；
  　　不過這本書也有幾點(diǎn)不錯(cuò)：
  　　1.作者對編程工作觀察得很仔細(xì)；
  　　2.本書非常實(shí)事求是；
  　　基于以上兩點(diǎn)，才沒有給予最差！
•   　　摘抄整理《人月神話》中的一些方法論。
  　　
  　　
  　　一、需求：required document 中要寫空間預(yù)算、測試用例
  　　
  　　二、開發(fā)：關(guān)注質(zhì)量，生產(chǎn)力自然會(huì)提高
  　　
  　　三、測試：每修復(fù)一個(gè)bug，就有有20%-50%引入新bug
  　　
  　　四、組織/管理：
  　　
  　　1.排期：
  　　
  　　準(zhǔn)確時(shí)間 ~ 估算的時(shí)間*2
  　　
  　　2. 項(xiàng)目必備要素
  　　- 任務(wù)需求細(xì)分
  　　- 產(chǎn)品負(fù)責(zé)人（主管左右手）
  　　- 技術(shù)負(fù)責(zé)人（主管）
  　　- 進(jìn)度表
  　　- 分工
  　　- 接口定義
  　　
  　　3. 組織結(jié)構(gòu)與交流結(jié)構(gòu)：
  　　
  　　組織是樹狀的，但交流是網(wǎng)狀的
  　　
  　　4. 培養(yǎng)優(yōu)秀人才的方法
  　　- 指派職業(yè)導(dǎo)師，負(fù)責(zé)技術(shù)成長和職業(yè)生涯規(guī)劃
  　　- 安排學(xué)習(xí)計(jì)劃
  　　- 提供交流和激勵(lì)機(jī)會(huì)
  　　
  　　5. 建議草案要在會(huì)議之前就有，并且發(fā)放
  　　
  　　
  　　6. 大型項(xiàng)目排期
  　　
  　　每兩周進(jìn)行一次計(jì)劃日期的修訂
  　　
  　　http://hi.baidu.com/xizhicat/blog/item/3f15b6321f8495f515cecb8c.html
•   　　現(xiàn)在我們對軟件工程的了解比1975年要多得多。那么在1975年版本的人月神話中，哪些觀點(diǎn)得到了數(shù)據(jù)和經(jīng)驗(yàn)的支持？哪些觀點(diǎn)被證明是不正確的？又有哪些觀點(diǎn)隨著世界的變化，顯得陳舊過時(shí)呢？為了幫助判斷，我將1975年書籍中的論斷毫無更改地抽取出來，以摘要的形式列舉在下面--它們是當(dāng)年我認(rèn)為將會(huì)是正確的：客觀事實(shí)和經(jīng)驗(yàn)中推廣的法則。（你也許會(huì)問，"如果這些就是那本書講的所有東西，為什么要花177頁的篇幅來論述？"）
  　　方括號中的評論是新增內(nèi)容。
  　　所有這些觀點(diǎn)都是可操作驗(yàn)證的，我將它們表達(dá)成刻板的形式是希望能引起讀者的思考、判斷和討論。
  　　第1章 焦油坑
  　　1.1 編程系統(tǒng)產(chǎn)品（Programming Systems Product）開發(fā)的工作量是供個(gè)人使用的、獨(dú)立開發(fā)的構(gòu)件程序的九倍。我估計(jì)軟件構(gòu)件產(chǎn)品化引起了3倍工作量，將軟件構(gòu)件整合成完整系統(tǒng)所需要的設(shè)計(jì)、集成和測試又強(qiáng)加了3倍的工作量，這些高成本的構(gòu)件在根本上是相互獨(dú)立的。
  　　1.2 編程行業(yè)"滿足我們內(nèi)心深處的創(chuàng)造渴望和愉悅所有人的共有情感"，提供了五種樂趣：
  　　.. 創(chuàng)建事物的快樂
  　　.. 開發(fā)對其他人有用的東西的樂趣
  　　.. 將可以活動(dòng)、相互嚙合的零部件組裝成類似迷宮的東西，這個(gè)過程所體現(xiàn)出令人神魂顛倒的魅力
  　　.. 面對不重復(fù)的任務(wù)，不間斷學(xué)習(xí)的樂趣
  　　.. 工作在如此易于駕馭的介質(zhì)上的樂趣--純粹的思維活動(dòng)，其存在、移動(dòng)和運(yùn)轉(zhuǎn)方式完全不同于實(shí)際物體
  　　1.3 同樣，這個(gè)行業(yè)具有一些內(nèi)在固有的苦惱：
  　　.. 將做事方式調(diào)整到追求完美，是學(xué)習(xí)編程的最困難部分
  　　.. 由其他人來設(shè)定目標(biāo)，并且必須依靠自己無法控制的事物（特別是程序）；權(quán)威不等同于責(zé)任
  　　.. 實(shí)際情況看起來要比這一點(diǎn)好一些：真正的權(quán)威來自于每次任務(wù)的完成
  　　.. 任何創(chuàng)造性活動(dòng)都伴隨著枯燥艱苦的勞動(dòng)，編程也不例外
  　　.. 人們通常期望項(xiàng)目在接近結(jié)束時(shí)，（bug、工作時(shí)間）能收斂得快一些，然而軟件項(xiàng)目的情況卻是越接近完成，收斂得越慢
  　　.. 產(chǎn)品在即將完成時(shí)總面臨著陳舊過時(shí)的威脅
  　　第2章 人月神話
  　　2.1 缺乏合理的時(shí)間進(jìn)度是造成項(xiàng)目滯后的最主要原因，它比其他所有因素加起來影響還大。
  　　2.2 良好的烹飪需要時(shí)間，某些任務(wù)無法在不損害結(jié)果的情況下加快速度。
  　　2.3 所有的編程人員都是樂觀主義者："一切都將運(yùn)作良好"。
  　　2.4 由于編程人員通過純粹的思維活動(dòng)來開發(fā)，所以我們期待在實(shí)現(xiàn)過程中不會(huì)碰到困難。
  　　2.5 但是，我們的構(gòu)思是有缺陷的，因此總會(huì)有bug。
  　　2.6 我們圍繞成本核算的估計(jì)技術(shù)，混淆了工作量和項(xiàng)目進(jìn)展。人月是危險(xiǎn)和帶有欺騙性的神話，因?yàn)樗凳救藛T數(shù)量和時(shí)間是可以相互替換的。
  　　2.7 在若干人員中分解任務(wù)會(huì)引發(fā)額外的溝通工作量--培訓(xùn)和相互溝通。
  　　2.8 關(guān)于進(jìn)度安排，我的經(jīng)驗(yàn)是為1/3計(jì)劃、1/6編碼、1/4構(gòu)件測試以及1/4系統(tǒng)測試。
  　　2.9 作為一個(gè)學(xué)科，我們?nèi)狈?shù)據(jù)估計(jì)。
  　　2.10 因?yàn)槲覀儗ψ约旱墓烙?jì)技術(shù)不確定，所以在管理和客戶的壓力下，我們常常缺乏堅(jiān)持的勇氣。
  　　2.11 Brook法則：向進(jìn)度落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后。
  　　2.12 向軟件項(xiàng)目中增派人手從三個(gè)方面增加了項(xiàng)目必要的總體工作量：任務(wù)重新分配本身和所造成的工作中斷；培訓(xùn)新人員；額外的相互溝通。
  　　第3章 外科手術(shù)隊(duì)伍
  　　3.1 同樣有兩年經(jīng)驗(yàn)而且在受到同樣的培訓(xùn)的情況下，優(yōu)秀的專業(yè)程序員的工作效率是較差程序員的十倍。（Sackman、Erikson和Grand）
  　　3.2 Sackman、Erikson和Grand的數(shù)據(jù)顯示經(jīng)驗(yàn)和實(shí)際表現(xiàn)之間沒有相互聯(lián)系。我懷疑這種現(xiàn)象是否普遍成立。
  　　3.3 小型、精干隊(duì)伍是最好的--盡可能的少。
  　　3.4 兩個(gè)人的團(tuán)隊(duì)，其中一個(gè)項(xiàng)目經(jīng)理，常常是最佳的人員使用方法。[留意一下上帝對婚姻的設(shè)計(jì)。]
  　　3.5 對于真正意義上的大型系統(tǒng)，小型精干的隊(duì)伍太慢了。
  　　3.6 實(shí)際上，絕大多數(shù)大型編程系統(tǒng)的經(jīng)驗(yàn)顯示出，一擁而上的開發(fā)方法是高成本、速度緩慢、不充分的，開發(fā)出的產(chǎn)品無法進(jìn)行概念上的集成。
  　　3.7 一位首席程序員、類似于外科手術(shù)隊(duì)伍的團(tuán)隊(duì)架構(gòu)提供了一種方法--既能獲得由少數(shù)頭腦產(chǎn)生的產(chǎn)品完整性，又能得到多位協(xié)助人員的總體生產(chǎn)率，還徹底地減少了溝通的工作量。
  　　第4章 貴族專制、民主政治和系統(tǒng)設(shè)計(jì)
  　　4.1 "概念完整性是系統(tǒng)設(shè)計(jì)中最重要的考慮因素"。
  　　4.2 "功能與理解上的復(fù)雜程度的比值才是系統(tǒng)設(shè)計(jì)的最終測試標(biāo)準(zhǔn)"，而不僅僅是豐富的功能。[該比值是對易用性的一種測量，由簡單和復(fù)雜應(yīng)用共同驗(yàn)證。]
  　　4.3 為了獲得概念完整性，設(shè)計(jì)必須由一個(gè)人或者具有共識的小型團(tuán)隊(duì)來完成。
  　　4.4 "對于非常大型的項(xiàng)目，將設(shè)計(jì)方法、體系結(jié)構(gòu)方面的工作與具體實(shí)現(xiàn)相分離是獲得概念完整性的強(qiáng)有力方法。"[同樣適用于小型項(xiàng)目。]
  　　4.5 "如果要得到系統(tǒng)概念上的完整性，那么必須控制這些概念。這實(shí)際上是一種無需任何歉意的貴族專制統(tǒng)治。"
  　　4.6 紀(jì)律、規(guī)則對行業(yè)是有益的。外部的體系結(jié)構(gòu)規(guī)定實(shí)際上是增強(qiáng)，而不是限制實(shí)現(xiàn)小組的創(chuàng)造性。
  　　4.7 概念上統(tǒng)一的系統(tǒng)能更快地開發(fā)和測試。
  　　4.8 體系結(jié)構(gòu)（architecture）、設(shè)計(jì)實(shí)現(xiàn)（implementation）、物理實(shí)現(xiàn)（realization）的許多工作可以并發(fā)進(jìn)行。[軟件和硬件設(shè)計(jì)同樣可以并行。]
  　　第5章 畫蛇添足
  　　5.1 盡早交流和持續(xù)溝通能使結(jié)構(gòu)師有較好的成本意識，以及使開發(fā)人員獲得對設(shè)計(jì)的信心，并且不會(huì)混淆各自的責(zé)任分工。
  　　5.2 結(jié)構(gòu)師如何成功地影響實(shí)現(xiàn)：
  　　.. 牢記是開發(fā)人員承擔(dān)創(chuàng)造性的實(shí)現(xiàn)責(zé)任；結(jié)構(gòu)師只能提出建議。
  　　.. 時(shí)刻準(zhǔn)備著為所指定的說明建議一種實(shí)現(xiàn)的方法，準(zhǔn)備接受任何其他可行的方法。
  　　.. 對上述的建議保持低調(diào)和平靜。
  　　.. 準(zhǔn)備對所建議的改進(jìn)放棄堅(jiān)持。
  　　.. 聽取開發(fā)人員在體系結(jié)構(gòu)上改進(jìn)的建議。
  　　5.3 第二個(gè)系統(tǒng)是人們所設(shè)計(jì)的最危險(xiǎn)的系統(tǒng)，通常的傾向是過分地進(jìn)行設(shè)計(jì)。
  　　5.4 OS/360是典型的畫蛇添足（second-system effect）的例子。[Windows NT似乎是90年代的例子。]
  　　5.5 為功能分配一個(gè)字節(jié)和微秒的優(yōu)先權(quán)值是一個(gè)很有價(jià)值的規(guī)范化方法。
  　　第6章 貫徹執(zhí)行
  　　6.1 即使是大型的設(shè)計(jì)團(tuán)隊(duì)，設(shè)計(jì)結(jié)果也必須由一個(gè)或兩個(gè)人來完成，以確保這些決定是一致的。
  　　6.2 必須明確定義體系結(jié)構(gòu)中與先前定義不同的地方，重新定義的詳細(xì)程度應(yīng)該與原先的說明一致。
  　　6.3 出于精確性的考慮，我們需要形式化的設(shè)計(jì)定義，同樣，我們需要記敘性定義來加深理解。
  　　6.4 必須采用形式化定義和記敘性定義中的一種作為標(biāo)準(zhǔn)，另一種作為輔助措施；它們都可以作為表達(dá)的標(biāo)準(zhǔn)。
  　　6.5 設(shè)計(jì)實(shí)現(xiàn)，包括模擬仿真，可以充當(dāng)一種形式化定義的方法；這種方法有一些嚴(yán)重的缺點(diǎn)。
  　　6.6 直接整合是一種強(qiáng)制推行軟件的結(jié)構(gòu)性標(biāo)準(zhǔn)的方法。[硬件上也是如此--考慮內(nèi)建在ROM中的Mac WIMP接口。]
  　　6.7 "如果起初至少有兩種以上的實(shí)現(xiàn)，那么（體系結(jié)構(gòu)）定義會(huì)更加整潔，會(huì)更加規(guī)范。"
  　　6.8 允許體系結(jié)構(gòu)師對實(shí)現(xiàn)人員的詢問做出電話應(yīng)答解釋是非常重要的，并且必須進(jìn)行日志記錄和整理發(fā)布。[電子郵件是一種可選的介質(zhì)。]
  　　6.9 "項(xiàng)目經(jīng)理最好的朋友就是他每天要面對的敵人--獨(dú)立的產(chǎn)品測試機(jī)構(gòu)/小組。"
  　　第7章 為什么巴比倫塔會(huì)失??？
  　　7.1 巴比倫塔項(xiàng)目的失敗是因?yàn)槿狈涣鳎约敖涣鞯慕Y(jié)果--組織。 交流
  　　7.2 "因?yàn)樽笫植恢烙沂衷谧鍪裁?，從而進(jìn)度災(zāi)難、功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)。"由于對其他人的各種假設(shè)，團(tuán)隊(duì)成員之間的理解開始出現(xiàn)偏差。
  　　7.3 團(tuán)隊(duì)?wèi)?yīng)該以盡可能多的方式進(jìn)行相互之間的交流：非正式、常規(guī)項(xiàng)目會(huì)議，會(huì)上進(jìn)行簡要的技術(shù)陳述、共享的正式項(xiàng)目工作手冊。[以及電子郵件。]
  　　項(xiàng)目工作手冊
  　　7.4 項(xiàng)目工作手冊"不是獨(dú)立的一篇文檔，它是對項(xiàng)目必須產(chǎn)生的一系列文檔進(jìn)行組織的一種結(jié)構(gòu)。"
  　　7.5 "項(xiàng)目所有的文檔都必須是該（工作手冊）結(jié)構(gòu)的一部分。"
  　　7.6 需要盡早和仔細(xì)地設(shè)計(jì)工作手冊結(jié)構(gòu)。
  　　7.7 事先制訂了良好結(jié)構(gòu)的工作手冊"可以將后來書寫的文字放置在合適的章節(jié)中"，并且可以提高產(chǎn)品手冊的質(zhì)量。
  　　7.8 "每一個(gè)團(tuán)隊(duì)成員應(yīng)該了解所有的材料（工作手冊）。"[我想說的是，每個(gè)團(tuán)隊(duì)成員應(yīng)該能夠看到所有材料，網(wǎng)頁即可滿足要求。]
  　　7.9 實(shí)時(shí)更新是至關(guān)重要的。
  　　7.10 工作手冊的使用者應(yīng)該將注意力集中在上次閱讀后的變更，以及關(guān)于這些變更重要性的評述。
  　　7.11 OS/360項(xiàng)目工作手冊開始采用的是紙介質(zhì)，后來換成了微縮膠片。
  　　7.12 今天[即使在1975年]，共享的電子手冊是能更好達(dá)到所有這些目標(biāo)、更加低廉、更加簡單的機(jī)制。
  　　7.13 仍然需要用變更條和修訂日期[或具備同等功能的方法]來標(biāo)記文字；仍然需要后進(jìn)先出（LIFO）的電子化變更小結(jié)。
  　　7.14 Parnas強(qiáng)烈地認(rèn)為使每個(gè)人看到每件事的目標(biāo)是完全錯(cuò)誤的；各個(gè)部分應(yīng)該被封裝，從而沒有人需要或者允許看到其他部分的內(nèi)部結(jié)構(gòu)，只需要了解接口。
  　　7.15 Parnas的建議的確是災(zāi)難的處方。
  　　組織架構(gòu)
  　　7.16 團(tuán)隊(duì)組織的目標(biāo)是為了減少必要的交流和協(xié)作量。
  　　7.17 為了減少交流，組織結(jié)構(gòu)包括了人力劃分（division of labor）和限定職責(zé)范圍（specialization of function）。
  　　7.18 傳統(tǒng)的樹狀組織結(jié)構(gòu)反映了權(quán)力的結(jié)構(gòu)原理--不允許雙重領(lǐng)導(dǎo)。
  　　7.19 組織中的交流是網(wǎng)狀，而不是樹狀結(jié)構(gòu)，因而所有的特殊組織機(jī)制（往往體現(xiàn)成組織結(jié)構(gòu)圖中的虛線部分）都是為了進(jìn)行調(diào)整，以克服樹狀組織結(jié)構(gòu)中交流缺乏的困難。
  　　7.20 每個(gè)子項(xiàng)目具有兩個(gè)領(lǐng)導(dǎo)角色--產(chǎn)品負(fù)責(zé)人、技術(shù)主管或結(jié)構(gòu)師。這兩個(gè)角色的職能有著很大的區(qū)別，需要不同的技能。
  　　7.21 兩種角色中的任意組合可以是非常有效的：
  　　.. 產(chǎn)品負(fù)責(zé)人和技術(shù)主管是同一個(gè)人。
  　　.. 產(chǎn)品負(fù)責(zé)人作為總指揮，技術(shù)主管充當(dāng)其左右手。
  　　.. 技術(shù)主管作為總指揮，產(chǎn)品負(fù)責(zé)人充當(dāng)其左右手。
  　　第8章 胸有成竹
  　　8.1 僅僅通過對編碼部分的估計(jì)，然后乘以任務(wù)其他部分的相對系數(shù)，是無法得出對整項(xiàng)工作的精確估計(jì)的。
  　　8.2 構(gòu)建獨(dú)立小型程序的數(shù)據(jù)不適用于編程系統(tǒng)項(xiàng)目。
  　　8.3 程序開發(fā)呈程序規(guī)模的指數(shù)增長。
  　　8.4 一些發(fā)表的研究報(bào)告顯示指數(shù)約為1.5。[Boehm的數(shù)據(jù)并不完全一致，在1.05和1.2之間變化。1]
  　　8.5 Portman的ICL數(shù)據(jù)顯示相對于其他活動(dòng)開銷，全職程序員僅將50％的時(shí)間用于編程和調(diào)試。
  　　8.6 IBM的Aron數(shù)據(jù)顯示，生產(chǎn)率是系統(tǒng)各個(gè)部分交互的函數(shù)，在1.5K千代碼行/人年至10K千代碼行/人年的范圍內(nèi)變化。
  　　8.7 Harr的Bell實(shí)驗(yàn)室數(shù)據(jù)顯示對于已完成的產(chǎn)品，操作系統(tǒng)類的生產(chǎn)率大約是0.6KLOC/人年，編譯類工作的生產(chǎn)率大約為2.2KLOC/人年。
  　　8.8 Brooks的OS/360S數(shù)據(jù)與Harr的數(shù)據(jù)一致：操作系統(tǒng)0.6～0.8KLOC/人年，編譯器2～3 KLOC/人年。
  　　8.9 Corbato的MIT項(xiàng)目MULTICS數(shù)據(jù)顯示，在操作系統(tǒng)和編譯器混合類型上的生產(chǎn)率是1.2KLOC/人年，但這些是PL/I的代碼行，而其他所有的數(shù)據(jù)是匯編代碼行。
  　　8.10 在基本語句級別，生產(chǎn)率看上去是個(gè)常數(shù)。
  　　8.11 當(dāng)使用適當(dāng)?shù)母呒壵Z言時(shí)，程序編制的生產(chǎn)率可以提高5倍。
  　　第9章 削足適履
  　　9.1 除了運(yùn)行時(shí)間以外，所占據(jù)的內(nèi)存空間也是主要開銷。特別是對于操作系統(tǒng)，它的很多程序是永久駐留在內(nèi)存中。
  　　9.2 即便如此，花費(fèi)在駐留程序所占據(jù)內(nèi)存上的金錢仍是物有所值的，比其他任何在配置上投資的效果要好。規(guī)模本身不是壞事，但不必要的規(guī)模是不可取的。
  　　9.3 軟件開發(fā)人員必須設(shè)立規(guī)模目標(biāo)，控制規(guī)模，發(fā)明一些減少規(guī)模的方法--就如同硬件開發(fā)人員為減少元器件所做的一樣。
  　　9.4 規(guī)模預(yù)算不僅僅在占據(jù)內(nèi)存方面是明確的，同時(shí)還應(yīng)該指明程序?qū)Υ疟P的訪問次數(shù)。
  　　9.5 規(guī)模預(yù)算必須與分配的功能相關(guān)聯(lián)；在指明模塊大小的同時(shí)，確切定義模塊的功能。
  　　9.6 在大型的團(tuán)隊(duì)中，各個(gè)小組傾向于不斷地局部優(yōu)化，以滿足自己的目標(biāo)，而較少考慮隊(duì)用戶的整體影響。這種方向性的問題是大型項(xiàng)目的主要危險(xiǎn)。
  　　9.7 在整個(gè)實(shí)現(xiàn)的過程期間，系統(tǒng)結(jié)構(gòu)師必須保持持續(xù)的警覺，確保連貫的系統(tǒng)完整性。
  　　9.8 培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)、面向用戶的態(tài)度是軟件編程管理人員最重要的職能。
  　　9.9 在早期應(yīng)該制訂策略，以決定用戶可選項(xiàng)目的粗細(xì)程度，因?yàn)閷⑺鼈冏鳛檎w大包能夠節(jié)省內(nèi)存空間。[常常還可以節(jié)約市場成本。]
  　　9.10 臨時(shí)空間的尺寸，以及每次磁盤訪問的程序數(shù)量是很關(guān)鍵的決策，因?yàn)樾阅苁且?guī)模的非線性函數(shù)。[這個(gè)整體決策已顯得過時(shí)--起初是由于虛擬內(nèi)存，后來則是成本低廉的內(nèi)存?，F(xiàn)在的用戶通常會(huì)購買能容納主要應(yīng)用程序所有代碼的內(nèi)存。]
  　　9.11 為了取得良好的空間－時(shí)間折衷，開發(fā)隊(duì)伍需要得到特定與某種語言或者機(jī)型的編程技能培訓(xùn)，特別是在使用新語言或者新機(jī)器時(shí)。
  　　9.12 編程需要技術(shù)積累，每個(gè)項(xiàng)目需要自己的標(biāo)準(zhǔn)組件庫。
  　　9.13 庫中的每個(gè)組件需要有兩個(gè)版本，運(yùn)行速度較快和短小精煉的。[現(xiàn)在看來有些過時(shí)。]
  　　9.14 精煉、充分和快速的程序。往往是戰(zhàn)略性突破的結(jié)果，而不僅僅技巧上的提高。
  　　9.15 這種突破常常是一種新型算法。
  　　9.16 更普遍的是，戰(zhàn)略上突破常來自于數(shù)據(jù)或表的重新表達(dá)。數(shù)據(jù)的表現(xiàn)形式是編程的根本。
  　　第10章 提綱挈領(lǐng)
  　　10.1 "前提：在一片文件的汪洋中，少數(shù)文檔形成了關(guān)鍵的樞紐，每個(gè)項(xiàng)目管理的工作都圍繞著它們運(yùn)轉(zhuǎn)。它們是經(jīng)理們的主要個(gè)人工具。"
  　　10.2 對于計(jì)算機(jī)硬件開發(fā)項(xiàng)目，關(guān)鍵文檔是目標(biāo)、手冊、進(jìn)度、預(yù)算、組織機(jī)構(gòu)圖、空間分配、以及機(jī)器本身的報(bào)價(jià)、預(yù)測和價(jià)格。
  　　10.3 對于大學(xué)科系，關(guān)鍵文檔類似：目標(biāo)、課程描述、學(xué)位要求、研究報(bào)告、課程表和課程的安排、預(yù)算、教室分配、教師和研究生助手的分配。
  　　10.4 對于軟件項(xiàng)目，要求是相同的：目標(biāo)、用戶手冊、內(nèi)部文檔、進(jìn)度、預(yù)算、組織機(jī)構(gòu)圖和工作空間分配。
  　　10.5 因此，即使是小型項(xiàng)目，項(xiàng)目經(jīng)理也應(yīng)該在項(xiàng)目早期規(guī)范化上述的一系列文檔。
  　　10.6 以上集合中每一個(gè)文檔的準(zhǔn)備工作都將注意力集中在對討論的思索和提煉，而書寫這項(xiàng)活動(dòng)需要上百次的細(xì)小決定，正是由于它們的存在，人們才能從令人迷惑的現(xiàn)象中得到清晰、確定的策略。
  　　10.7 對每個(gè)關(guān)鍵文檔的維護(hù)提供了狀態(tài)監(jiān)督和預(yù)警機(jī)制。
  　　10.8 每個(gè)文檔本身就可以作為檢查列表或者數(shù)據(jù)庫。
  　　10.9 項(xiàng)目經(jīng)理的基本職責(zé)是使每個(gè)人都向著相同的方向前進(jìn)。
  　　10.10 項(xiàng)目經(jīng)理的主要日常工作是溝通，而不是做出決定；文檔使各項(xiàng)計(jì)劃和決策在整個(gè)團(tuán)隊(duì)范圍內(nèi)得到交流。
  　　10.11 只有一小部分管理人員的時(shí)間--可能只有20%--用來從自己頭腦外部獲取信息。
  　　10.12 出于這個(gè)原因，廣受吹捧的市場概念--支持管理人員的"完備信息管理系統(tǒng)"并不基于反映管理人員行為的有效模型。
  　　第11章 未雨綢繆
  　　11.1 化學(xué)工程師已經(jīng)認(rèn)識到無法一步將實(shí)驗(yàn)室工作臺上的反應(yīng)過程移到工廠中，需要一個(gè)實(shí)驗(yàn)性工廠（pilot planet）來為提高產(chǎn)量和在缺乏保護(hù)的環(huán)境下運(yùn)作提供寶貴經(jīng)驗(yàn)。
  　　11.2 對于編程產(chǎn)品而言，這樣的中間步驟是同樣必要的，但是軟件工程師在著手發(fā)布產(chǎn)品之前，卻并不會(huì)常規(guī)地進(jìn)行試驗(yàn)性系統(tǒng)的現(xiàn)場測試。[現(xiàn)在，這已經(jīng)成為了一項(xiàng)普遍的實(shí)踐，beta版本。它不同于有限功能的原型，alpha版本，后者同樣是我所倡導(dǎo)的實(shí)踐。]
  　　11.3 對于大多數(shù)項(xiàng)目，第一個(gè)開發(fā)的系統(tǒng)并不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。
  　　11.4 系統(tǒng)的丟棄和重新設(shè)計(jì)可以一步完成，也可以一塊塊地實(shí)現(xiàn)。這是個(gè)必須完成的步驟。
  　　11.5 將開發(fā)的第一個(gè)系統(tǒng)--丟棄原型--發(fā)布給用戶，可以獲得時(shí)間，但是它的代價(jià)高昂--對于用戶，使用極度痛苦；對于重新開發(fā)的人員，分散了精力；對于產(chǎn)品，影響了聲譽(yù)，即使最好的再設(shè)計(jì)也難以挽回名聲。
  　　11.6 因此，為舍棄而計(jì)劃，無論如何，你一定要這樣做。
  　　11.7 "開發(fā)人員交付的是用戶滿意程度，而不僅僅是實(shí)際的產(chǎn)品。"（Cosgrove）
  　　11.8 用戶的實(shí)際需要和用戶感覺會(huì)隨著程序的構(gòu)建、測試和使用而變化。
  　　11.9 軟件產(chǎn)品易于掌握的特性和不可見性，導(dǎo)致了它的構(gòu)建人員（特別容易）面臨著永恒的需求變更。
  　　11.10 目標(biāo)上（和開發(fā)策略上）的一些正常變化無可避免，事先為它們做準(zhǔn)備總比假設(shè)它們不會(huì)出現(xiàn)要好得多。
  　　11.11 為變更計(jì)劃軟件產(chǎn)品的技術(shù)，特別是細(xì)致的模塊接口文檔--非常地廣為人知，但并沒有相同規(guī)模的實(shí)踐。盡可能地使用表驅(qū)動(dòng)技術(shù)同樣是有所幫助的。[現(xiàn)在內(nèi)存的成本和規(guī)模使這項(xiàng)技術(shù)越來越出眾。]
  　　11.12 高級語言的使用、編譯時(shí)操作、通過引用的聲明整合和自文檔技術(shù)能減少變更引起的錯(cuò)誤。
  　　11.13 采用定義良好的數(shù)字化版本將變更量子（階段）化。[當(dāng)今的標(biāo)準(zhǔn)實(shí)踐。]
  　　為變更計(jì)劃組織架構(gòu)
  　　11.14 程序員不愿意為設(shè)計(jì)書寫文檔的原因，不僅僅是由于惰性。更多的是源于設(shè)計(jì)人員的躊躇--要為自己嘗試性的設(shè)計(jì)決策進(jìn)行辯解。（Cosgrove）
  　　11.15 為變更組建團(tuán)隊(duì)比為變更進(jìn)行設(shè)計(jì)更加困難。
  　　11.16 只要管理人員和技術(shù)人才的天賦允許，老板必須對他們的能力培養(yǎng)給予極大的關(guān)注，使管理人員和技術(shù)人才具有互換性；特別是希望能在技術(shù)和管理角色之間自由地分配人手的時(shí)候。
  　　11.17 具有兩條晉升線的高效組織機(jī)構(gòu)，存在著一些社會(huì)性的障礙，人們必須警惕和積極地同它做持續(xù)的斗爭。
  　　11.18 很容易為不同的晉升線建立相互一致的薪水級別，但要同等威信的建立需要一些強(qiáng)烈的心理措施：相同的辦公室、一樣的支持和技術(shù)調(diào)動(dòng)的優(yōu)先補(bǔ)償。
  　　11.19 組建外科手術(shù)隊(duì)伍式的軟件開發(fā)團(tuán)隊(duì)是對上述問題所有方面的徹底沖擊。對于靈活組織架構(gòu)問題，這的確是一個(gè)長期行之有效的解決方案。
  　　前進(jìn)兩步，后退一步--程序維護(hù)
  　　11.20 程序維護(hù)基本上不同于硬件的維護(hù)；它主要由各種變更組成，如修復(fù)設(shè)計(jì)缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調(diào)整。
  　　11.21 對于一個(gè)廣泛使用的程序，其維護(hù)總成本通常是開發(fā)成本的40％或更多。
  　　11.22 維護(hù)成本受用戶數(shù)目的嚴(yán)重影響。用戶越多，所發(fā)現(xiàn)的錯(cuò)誤也越多。
  　　11.23 Campbell指出了一個(gè)顯示產(chǎn)品生命期中每月bug數(shù)的有趣曲線，它先是下降，然后攀升。
  　　11.24 缺陷修復(fù)總會(huì)以（20－50）%的機(jī)率引入新的bug。
  　　11.25 在每次修復(fù)之后，必須重新運(yùn)行先前所有的測試用例，從而確保系統(tǒng)不會(huì)以更隱蔽的方式被破壞。
  　　11.26 能消除、至少是能指明副作用的程序設(shè)計(jì)方法，對維護(hù)成本有很大的影響。
  　　11.27 同樣，設(shè)計(jì)實(shí)現(xiàn)的人員越少、接口越少，產(chǎn)生的錯(cuò)誤也就越少。
  　　前進(jìn)一步，后退一步--系統(tǒng)熵隨時(shí)間增加
  　　11.28 Lehman和Belady發(fā)現(xiàn)模塊數(shù)量隨大型操作系統(tǒng)（OS/360）版本號的增加呈線性增長，但是受到影響的模塊以版本號指數(shù)的級別增長。
  　　11.29 所有修改都傾向于破壞系統(tǒng)的架構(gòu)，增加了系統(tǒng)的混亂程度。即使是最熟練的軟件維護(hù)工作，也只是放緩了系統(tǒng)退化到不可修復(fù)混亂的進(jìn)程，從中必須要重新進(jìn)行設(shè)計(jì)。
  　　[許多程序升級的真正需要，如性能等，尤其會(huì)沖擊它的內(nèi)部結(jié)構(gòu)邊界。原有邊界引發(fā)的不足常常在日后才會(huì)出現(xiàn)。]
  　　第12章 干將莫邪
  　　12.1 項(xiàng)目經(jīng)理應(yīng)該制訂一套策略，以及為通用工具的開發(fā)分配資源，與此同時(shí)，他還必須意識到專業(yè)工具的需求。
  　　12.2 開發(fā)操作系統(tǒng)的隊(duì)伍需要自己的目標(biāo)機(jī)器，進(jìn)行調(diào)試開發(fā)工作。相對于最快的速度而言，它更需要最大限度的內(nèi)存，還需要安排一名系統(tǒng)程序員，以保證機(jī)器上的標(biāo)準(zhǔn)軟件是即時(shí)更新和實(shí)時(shí)可用的。
  　　12.3 同時(shí)還需要配備調(diào)試機(jī)器或者軟件，以便在調(diào)試過程中，所有類型的程序參數(shù)可以被自動(dòng)計(jì)數(shù)和測量。
  　　12.4 目標(biāo)機(jī)器的使用需求量是一種特殊曲線：剛開始使用率非常低，突然出現(xiàn)爆發(fā)性的增長，接著趨于平緩。
  　　12.5 同天文工作者一樣，系統(tǒng)調(diào)試總是大部分在夜間完成。
  　　12.6 拋開理論不談，一次分配給某個(gè)小組連續(xù)的目標(biāo)時(shí)間塊被證明是最好的安排方法，比不同小組的穿插使用更為有效。
  　　12.7 盡管技術(shù)不斷變化，這種采用時(shí)間塊來安排匱乏計(jì)算機(jī)資源的方式仍得以延續(xù)20年[在1975年]，是因?yàn)樗纳a(chǎn)率最高。[在1995年依然如此]
  　　12.8 如果目標(biāo)機(jī)器是新產(chǎn)品，則需要一個(gè)目標(biāo)機(jī)器的邏輯仿真裝置。這樣，可以更快地得到輔助調(diào)試平臺。即使在真正機(jī)器出現(xiàn)之后，仿真裝置仍可提供可靠的調(diào)試平臺。
  　　12.9 主程序庫應(yīng)該被劃分成（1）一系列獨(dú)立的私有開發(fā)庫；（2）正處在系統(tǒng)測試下的系統(tǒng)集成子庫；（3）發(fā)布版本。正式的分離和進(jìn)度提供了控制。
  　　12.10 在編制程序的項(xiàng)目中，節(jié)省最大工作量的工具可能是文本編輯系統(tǒng)。
  　　12.11 系統(tǒng)文檔中的巨大容量帶來了新的不理解問題[例如，看看Unix]，但是它比大多數(shù)未能詳細(xì)描述編程系統(tǒng)特性的短小文章更加可取。
  　　12.12 自頂向下、徹底地開發(fā)一個(gè)性能仿真裝置。盡可能早地開始這項(xiàng)工作，仔細(xì)地聽取 "它們表達(dá)的意見"。
  　　高級語言
  　　12.13 只有懶散和惰性會(huì)妨礙高級語言和交互式編程的廣泛應(yīng)用。[如今它們已經(jīng)在全世界使用。]
  　　12.14 高級語言不僅僅提升了生產(chǎn)率，而且還改進(jìn)了調(diào)試：bug更少，以及更容易尋找。
  　　12.15 傳統(tǒng)的反對意見--功能、目標(biāo)代碼的尺寸、目標(biāo)代碼的速度，隨著語言和編譯器技術(shù)的進(jìn)步已不再成為問題。
  　　12.16 現(xiàn)在可供合理選擇的語言是PL/I。[不再正確。]
  　　交互式編程
  　　12.17 某些應(yīng)用上，批處理系統(tǒng)決不會(huì)被交互式系統(tǒng)所替代。[依然成立。]
  　　12.18 調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時(shí)間是調(diào)試的禍根。
  　　12.19 有限的數(shù)據(jù)表明了系統(tǒng)軟件開發(fā)中，交互式編程的生產(chǎn)率至少是原來的兩倍。
  　　第13章 整體部分
  　　13.1 第4、5、6章所意味的煞費(fèi)苦心、詳盡體系結(jié)構(gòu)工作不但使產(chǎn)品更加易于使用，而且使開發(fā)更容易進(jìn)行以及bug更不容易產(chǎn)生。
  　　13.2 V.A.Vyssotsky提出，"許許多多的失敗完全源于那些產(chǎn)品未精確定義的地方。"
  　　13.3 在編寫任何代碼之前，規(guī)格說明必須提交給測試小組，以詳細(xì)地檢查說明的完整性和明確性。開發(fā)人員自己不會(huì)完成這項(xiàng)工作。（Vyssotsky）
  　　13.4 "十年內(nèi)[1965～1975]，Wirth的自頂向下進(jìn)行設(shè)計(jì)[逐步細(xì)化]將會(huì)是最重要的新型形式化軟件開發(fā)方法。"
  　　13.5 Wirth主張?jiān)诿總€(gè)步驟中，盡可能使用級別較高的表達(dá)方法。
  　　13.6 好的自頂向下設(shè)計(jì)從四個(gè)方面避免了bug。
  　　13.7 有時(shí)必須回退，推翻頂層設(shè)計(jì)，重新開始。
  　　13.8 結(jié)構(gòu)化編程中，程序的控制結(jié)構(gòu)僅由支配代碼塊（相對于任意的跳轉(zhuǎn)）的給定集合所組成。這種方法出色地避免了bug，是一種正確的思考方式。
  　　13.9 Gold結(jié)果顯示了，在交互式調(diào)試過程中，第一次交互取得的工作進(jìn)展是后續(xù)交互的三倍。這實(shí)際上獲益于在調(diào)試開始之前仔細(xì)地調(diào)試計(jì)劃。[我認(rèn)為在1995年依然如此。]
  　　13.10 我發(fā)現(xiàn)對良好終端系統(tǒng)的正確使用，往往要求每兩小時(shí)的終端會(huì)話對應(yīng)于兩小時(shí)的桌面工作：1小時(shí)會(huì)話后的清理和文檔工作；1小時(shí)為下一次計(jì)劃變更和測試。
  　　13.11 系統(tǒng)調(diào)試（相對于單元測試）花費(fèi)的時(shí)間會(huì)比預(yù)料的更長。
  　　13.12 系統(tǒng)調(diào)試的困難程度證明了需要一種完備系統(tǒng)化和可計(jì)劃的方法。
  　　13.13 系統(tǒng)調(diào)試僅僅應(yīng)該在所有部件能夠運(yùn)作之后開始。（這既不同于為了查出接口bug所采取 "合在一起嘗試" 的方法；也不同于在所有構(gòu)件單元的bug已知，但未修復(fù)的情況下，即開始系統(tǒng)調(diào)試的做法。）[對于多個(gè)團(tuán)隊(duì)尤其如此。]
  　　13.14 開發(fā)大量的輔助調(diào)試平臺（scaffolding 腳手架）和測試代碼是很值得的，代碼量甚至可能會(huì)有測試對象的一半。
  　　13.15 必須有人對變更進(jìn)行控制和文檔化，團(tuán)隊(duì)成員應(yīng)使用開發(fā)庫的各種受控拷貝來工作。
  　　13.16 系統(tǒng)測試期間，一次只添加一個(gè)構(gòu)件。
  　　13.17 Lehman和Belady出示了證據(jù)，變更的階段（量子）要么很大，間隔很寬；要么小和頻繁。后者很容易變得不穩(wěn)定。[Microsoft的一個(gè)團(tuán)隊(duì)使用了非常小的階段（量子）。結(jié)果是每天晚上需要重新編譯生成增長中的系統(tǒng)。]
  　　第14章 禍起蕭墻
  　　14.1 "項(xiàng)目是怎樣延遲了整整一年的時(shí)間？.一次一天。"
  　　14.2 一天一天的進(jìn)度落后比起重大災(zāi)難，更難以識別、更不容易防范和更加難以彌補(bǔ)。
  　　14.3 根據(jù)一個(gè)嚴(yán)格的進(jìn)度表來控制項(xiàng)目的第一個(gè)步驟是制訂進(jìn)度表，進(jìn)度表由里程碑和日期組成。
  　　14.4 里程碑必須是具體的、特定的、可度量的事件，能進(jìn)行清晰能定義。
  　　14.5 如果里程碑定義得非常明確，以致于無法自欺欺人時(shí)，程序員很少會(huì)就里程碑的進(jìn)展弄虛作假。
  　　14.6 對于大型開發(fā)項(xiàng)目中的估計(jì)行為，政府的承包商所做的研究顯示：每兩周進(jìn)行仔細(xì)修訂的活動(dòng)時(shí)間估計(jì)，隨著開始時(shí)間的臨近不會(huì)有太大的變化；期間內(nèi)對時(shí)間長短的過高估計(jì)，會(huì)隨著活動(dòng)的進(jìn)行持續(xù)下降；過低估計(jì)直到計(jì)劃的結(jié)束日期之前大約三周左右，才有所變化。
  　　14.7 慢性進(jìn)度偏離是士氣殺手。[Microsoft的Jim McCarthy說："如果你錯(cuò)過了一個(gè)最終期限（deadline），確保制訂下一條deadline。2">
  　　14.8 進(jìn)取對于杰出的軟件開發(fā)團(tuán)隊(duì)，同優(yōu)秀的棒球隊(duì)伍一樣，是不可缺少的必要品德。
  　　14.9 不存在關(guān)鍵路徑進(jìn)度的替代品，使人們能夠辨別計(jì)劃偏移的情況。
  　　14.10 PERT的準(zhǔn)備工作是PERT圖使用中最有價(jià)值的部分。它包括了整個(gè)網(wǎng)狀結(jié)構(gòu)的展開、任務(wù)之間依賴關(guān)系的識別、各個(gè)任務(wù)鏈的估計(jì)。這些都要求在項(xiàng)目早期進(jìn)行非常專業(yè)的計(jì)劃。
  　　14.11 第一份PERT圖總是很恐怖的，不過人們總是不斷進(jìn)行努力，運(yùn)用才智制訂下一份PERT圖。
  　　14.12 PERT圖為前面那個(gè)泄氣的借口，"其他的部分反正會(huì)落后"，提供了答案。
  　　14.13 每個(gè)老板同時(shí)需要采取行動(dòng)的異常信息以及用來進(jìn)行分析和早期預(yù)警的狀態(tài)數(shù)據(jù)。
  　　14.14 狀態(tài)的獲取是困難的，因?yàn)橄聦俳?jīng)理有充分的理由不提供信息共享。
  　　14.15 老板的不良反應(yīng)肯定會(huì)對信息的完全公開造成壓制；相反，仔細(xì)區(qū)分狀態(tài)報(bào)告、毫無驚慌地接收報(bào)告、決不越俎代庖，將能鼓勵(lì)誠實(shí)的匯報(bào)。
  　　14.16 必須有評審的機(jī)制，從而所有成員可以通過它了解真正的狀態(tài)。出于這個(gè)目的，里程碑的計(jì)劃和完成文檔是關(guān)鍵。
  　　14.17 Vyssotsky：我發(fā)現(xiàn)在里程碑報(bào)告中很容易記錄"計(jì)劃（老板的日期）"和"估計(jì)（最基層經(jīng)理的日期）"的日期。項(xiàng)目經(jīng)理必須停止對這些日期的懷疑。"
  　　14.18 對于大型項(xiàng)目，一個(gè)對里程碑報(bào)告進(jìn)行維護(hù)的計(jì)劃和控制（Plan and Control）小組是非?？少F的。
  　　第15章 另外一面
  　　15.1 對于軟件編程產(chǎn)品來說，程序向用戶所呈現(xiàn)的面貌與提供給機(jī)器識別的內(nèi)容同樣重要。
  　　15.2 即使對于完全開發(fā)給自己使用的程序，描述性文字也是必須的，因?yàn)樗鼈儠?huì)被用戶－作者所遺忘。
  　　15.3 培訓(xùn)和管理人員基本上沒有能向編程人員成功地灌輸對待文檔的積極態(tài)度--文檔能在整個(gè)生命周期對克服懶惰和進(jìn)度的壓力起促進(jìn)激勵(lì)作用。
  　　15.4 這樣的失敗并不都是因?yàn)槿狈崆榛蛘哒f服力，而是沒能正確地展示如何有效和經(jīng)濟(jì)地編制文檔。
  　　15.5 大多數(shù)文檔只提供了很少的總結(jié)性內(nèi)容。必須放慢腳步，穩(wěn)妥地進(jìn)行。
  　　15.6 由于關(guān)鍵的用戶文檔包含了跟軟件相關(guān)的基本決策，所以它的絕大部分需要在程序編制之前書寫，它包括了9項(xiàng)內(nèi)容（參見相應(yīng)章節(jié)）。
  　　15.7 每一份發(fā)布的程序拷貝應(yīng)該包括一些測試用例，其中一部分用于校驗(yàn)輸入數(shù)據(jù)，一部分用于邊界輸入數(shù)據(jù)，另一部分用于無效的輸入數(shù)據(jù)。
  　　15.8 對于必須修改程序的人而言，他們所需要程序內(nèi)部結(jié)構(gòu)文檔，同樣要求一份清晰明了的概述，它包括了5項(xiàng)內(nèi)容（參見相應(yīng)章節(jié)）。
  　　15.9 流程圖是被吹捧得最過分的一種程序文檔。詳細(xì)逐一記錄的流程圖是一件令人生厭的事情，而且高級語言的出現(xiàn)使它顯得陳舊過時(shí)。（流程圖是圖形化的高級語言。）
  　　15.10 如果這樣，很少有程序需要一頁紙以上的流程圖。[在這一點(diǎn)上，MILSPEC軍用標(biāo)準(zhǔn)實(shí)在錯(cuò)得很厲害。]
  　　15.11 即使的確需要一張程序結(jié)構(gòu)圖，也并不需要遵照ANSI的流程圖標(biāo)準(zhǔn)。
  　　15.12 為了使文檔易于維護(hù)，將它們合并至源程序是至關(guān)重要的，而不是作為獨(dú)立文檔進(jìn)行保存。
  　　15.13 最小化文檔負(fù)擔(dān)的3個(gè)關(guān)鍵思路：
  　　.. 借助那些必須存在的語句，如名稱和聲明等，來附加盡可能多的"文檔"信息。
  　　.. 使用空格和格式來表現(xiàn)從屬和嵌套關(guān)系，提高程序的可讀性。
  　　.. 以段落注釋，特別是模塊標(biāo)題的形式，向程序中插入必要的記敘性文字。
  　　15.14 程序修改人員所使用的文檔中，除了描述事情如何以外，還應(yīng)闡述它為什么那樣。對于加深理解，目的是非常關(guān)鍵的，但即使是高級語言的語法，也不能表達(dá)目的。
  　　15.15 在線系統(tǒng)的高級語言（應(yīng)該使用的工具）中，自文檔化技術(shù)發(fā)現(xiàn)了它的絕佳應(yīng)用和強(qiáng)大功能。
  　　原著結(jié)束語
  　　E.1 軟件系統(tǒng)可能是人類創(chuàng)造中最錯(cuò)綜復(fù)雜的事物（從不同類型組成部分?jǐn)?shù)量的角度出發(fā)）。
  　　E.2 軟件工程的焦油坑在將來很長一段時(shí)間內(nèi)會(huì)繼續(xù)地使人們舉步維艱，無法自拔。
•   　　如果你自稱是IT從業(yè)人員，卻沒有聽說過《人月神話》，那可就丟臉了。而30多年前的軟件工程書籍，在發(fā)展神速的IT行業(yè)，也稱得上是“古書”了。
  　　
  　　Brooks博士30多年前寫的軟件工程的書，到今天依然有些幫助，可見在有些問題上的認(rèn)識是非常深刻的。
  　　
  　　通過少量核心設(shè)計(jì)人員（Arch）來保證軟件/產(chǎn)品的概念一致性。
  　　
  　　提倡外科手術(shù)式的團(tuán)隊(duì)。（事實(shí)上agile方法上的人員配備，應(yīng)該或多或少的借鑒了這個(gè)建議）
  　　
  　　文檔的適度。
  　　
  　　以及IBM在大型軟件開發(fā)中的先驅(qū)地位。
  　　
  　　如果熟知項(xiàng)目管理的流程，理解傳統(tǒng)的瀑布開發(fā)流程，或者了解流行的敏捷開發(fā)，Brooks博士的這本書，其實(shí)并不會(huì)有任何實(shí)質(zhì)性的幫助。但是把自己置身于當(dāng)年，依然會(huì)感嘆他的睿智。
  　　
  　　與其說從《人與神話》中學(xué)到什么，不如說去感受點(diǎn)什么。否則，從實(shí)用主義的角度看，《人月神話》其實(shí)被過度神話了。
  　　
  　　《人月神話》 作者： Frederick P. Brooks, Jr
  　　
  　　總體評價(jià)：謹(jǐn)慎推薦
  　　

相關(guān)圖書

• 兒童國畫入門（四）
• 中學(xué)生人格理念精美短文導(dǎo)讀
• 雅思強(qiáng)化聽力
• 疼痛.疾病與治療
• 中國十大社會(huì)熱點(diǎn)批判
• 生物數(shù)學(xué)
• 心理衛(wèi)生/部隊(duì)衛(wèi)生防疫叢書
• 甲亢防治ＡＢＣ——常見病防治ＡＢＣ系列叢書
• 守法的故事——美德故事叢書
• 現(xiàn)代外科學(xué)(上.下)
• 希臘神話與傳說（一）
• 超越零點(diǎn)--學(xué)Excel
• 西洋美術(shù)家畫廊(63)--提埃波羅
• 數(shù)學(xué)猜想：數(shù)學(xué)篇——不知道的世界
• 鄭誦先章草《毛澤東詩詞》
• 肝纖維化的基礎(chǔ)研究及臨床（第二版）
• 大衛(wèi) 安格爾
• 藥劑學(xué)(第三版)
• 全國計(jì)算機(jī)等級考試考試要點(diǎn)、題解與模擬試卷（三級PC技術(shù)）（含光盤）
• 金魚
• 健美技巧圖解
• 中文版FLASH MX實(shí)例與操作(附光盤)
• 創(chuàng)新思維法(第二版)
• 消化系統(tǒng)常見病防治260問
• 奧運(yùn)競賽項(xiàng)目英漢知識手冊