人月神話

出版時(shí)間:2002-11  出版社:清華大學(xué)出版社  作者:[美] 弗雷德里克·布魯克斯  譯者:汪穎  
Tag標(biāo)簽:無  

內(nèi)容概要

作者為人們管理復(fù)雜項(xiàng)目提供了頗具洞察力的見解,既有很多發(fā)人深省的觀點(diǎn),也有大量的軟件工程實(shí)踐。書中的內(nèi)容來自布魯克斯在IBM公司System 360家族和OS 360中的項(xiàng)目管理經(jīng)驗(yàn)。初版的20年后,布魯克斯重新審視了他原先的觀點(diǎn),增加了一些新的想法和建議。新增加的章節(jié)包括:原著中一些核心觀點(diǎn)的精華;在經(jīng)過了一個(gè)時(shí)代以后,Brooks博士對(duì)原先觀點(diǎn)新的認(rèn)識(shí);1986年的經(jīng)典文章《沒有銀彈》;對(duì)1986年所下論斷(在10年內(nèi)不會(huì)出現(xiàn)銀彈)現(xiàn)在的認(rèn)識(shí)。

作者簡(jiǎn)介

弗雷德里克·布魯克斯(Frederick P. Brooks, Jr.)是北卡羅萊納大學(xué)Kenan-Flagler商學(xué)院的計(jì)算機(jī)科學(xué)教授。他曾榮獲圖靈獎(jiǎng),美國(guó)計(jì)算機(jī)協(xié)會(huì)(ACM)稱贊他“對(duì)計(jì)算機(jī)體系結(jié)構(gòu)、操作系統(tǒng)和軟件工程做出了里程碑式的貢獻(xiàn)。”
布魯克斯被認(rèn)為是IBM 360系統(tǒng)之父,他曾擔(dān)任360系統(tǒng)的項(xiàng)目經(jīng)理、360操作系統(tǒng)項(xiàng)目設(shè)計(jì)階段的經(jīng)理。因在這兩個(gè)項(xiàng)目中的杰出貢獻(xiàn),布魯克斯和Bob Evans、Erich Bloch在1985年獲得美國(guó)國(guó)家技術(shù)獎(jiǎng)(National Medal of Technology)。布魯克斯早期還曾擔(dān)任IBM公司Stretch和Harvest計(jì)算機(jī)的體系結(jié)構(gòu)設(shè)計(jì)師。布魯克斯創(chuàng)立了北卡羅萊納大學(xué)的計(jì)算機(jī)科學(xué)系,在1964-1984年期間擔(dān)任系主任。他還曾任職于美國(guó)國(guó)家科技局和國(guó)防科學(xué)技術(shù)委員會(huì)。他目前的教學(xué)和研究方向是計(jì)算機(jī)體系結(jié)構(gòu)、分子模型繪圖和虛擬環(huán)境設(shè)計(jì)。
UMLChina翻譯組的成員汪穎(Adams Wang)翻譯了這本《人月神話》。UMLChina是中文世界訪問量最大的軟件工程網(wǎng)站。譯者汪穎畢業(yè)于華中理工大學(xué),從事軟件開發(fā)以及流程改進(jìn)方面的工作。

圖書封面

圖書標(biāo)簽Tags

評(píng)論、評(píng)分、閱讀與下載


    人月神話 PDF格式下載


用戶評(píng)論 (總計(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ā)、測(cè)試、書寫文檔。有團(tuán)隊(duì)而不是老板對(duì)討論進(jìn)行仲裁。我無法形容授權(quán)和由團(tuán)隊(duì)自行負(fù)責(zé)項(xiàng)目的成功與否的重要性
  •     一、對(duì)于編程,喜歡的理由(寫的很好)
      編程為什么有趣?作為回報(bào),它的從業(yè)者期望得到什么樣的快樂?
      首先是一種創(chuàng)建事物的純粹快樂。如同小孩在玩泥巴時(shí)感到愉快一樣,成年人喜歡創(chuàng)建事物,特別是自己進(jìn)行設(shè)計(jì)。我想這種快樂是上帝創(chuàng)造世界的折射,一種呈現(xiàn)在每片獨(dú)特、嶄新的樹葉和雪花上的喜悅.其次,快樂來自于開發(fā)對(duì)其他人有用的東西。內(nèi)心深處,我們期望其他人使用我們的勞動(dòng)成果,并能對(duì)他們有所幫助。從這個(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ì)上。程序員,就像詩(shī)人一樣,幾乎僅僅工作在單純的思考中。程序員憑空地運(yùn)用自己的想象,來建造自己的“城堡”。很少有這樣的介質(zhì)——?jiǎng)?chuàng)造的方式如此得靈活,如此得易于精煉和重建,如此得容易實(shí)現(xiàn)概念上的設(shè)
      想。(不過我們將會(huì)看到,容易駕馭的特性也有它自己的問題)
      二、關(guān)于開發(fā)語言很真實(shí)
      當(dāng)意識(shí)到進(jìn)度的偏移時(shí),下意識(shí)(以及傳統(tǒng))的反應(yīng)是增加人力。這就像使用汽油滅火一樣,只會(huì)使事情更糟。越來越大的火勢(shì)需要更多的汽油,從而進(jìn)入了一場(chǎng)注定會(huì)導(dǎo)致災(zāi)難的循環(huán)。
      無論多少個(gè)母親,孕育一個(gè)生命都需要十個(gè)月。
      1/3 計(jì)劃
      1/6 編碼
      1/4 構(gòu)件測(cè)試和早期系統(tǒng)測(cè)試
      1/4 系統(tǒng)測(cè)試,所有的構(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è)角色都必須全職工作,甚至還要加班。對(duì)負(fù)責(zé)人來,很難在承擔(dān)全部管理責(zé)任的同時(shí),還能抽出時(shí)間進(jìn)行技術(shù)工作。對(duì)技術(shù)主管來說,很難在保證設(shè)計(jì)的概念完整性,沒有任何妥協(xié)的前提下,擔(dān)任管理工作。
      
      實(shí)踐是最好的老師,但是,如果不能從中學(xué)習(xí),再多的實(shí)踐也沒有用。
      
      普遍的做法是,選擇一種方法,試試看;如果失敗了,沒關(guān)系,再試試別的。不管怎么樣,重要的是先去嘗試。
      
      大多數(shù)有豐富經(jīng)驗(yàn)的程序員擁有自己的私人開發(fā)庫(kù),可以使他們使用大約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)建測(cè)試和早起的系統(tǒng)測(cè)試
      1/4 系統(tǒng)測(cè)試,所有的構(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)樗麄兿嘈糯笈D軌驇砥渌俗叱鼋褂涂樱∵@種人是很稀缺的,除了技術(shù)過硬,在眼界、人際關(guān)系等方面都要過硬。我覺得這種大牛才知道佩服!
  •     作為一個(gè)純粹的文科生,有點(diǎn)吃力~不過還是能夠?qū)W習(xí)一些東西,互聯(lián)網(wǎng)不是我想象中的那么簡(jiǎn)單,是個(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、手冊(cè)文檔,強(qiáng)調(diào)手冊(cè)結(jié)構(gòu)的精確完整以控制信息的發(fā)布。
      完全是個(gè)菜鳥,還是總結(jié)一些自己內(nèi)容,希望對(duì)以后能有幫助。
      
  •     讓我感到失望的地方如下:
      1.翻譯得太差,好多句子讀起來都特別別扭;尤其是章節(jié)標(biāo)題,非要賣弄文字;
      2.書中舉例太過陳舊;
      不過這本書也有幾點(diǎn)不錯(cuò):
      1.作者對(duì)編程工作觀察得很仔細(xì);
      2.本書非常實(shí)事求是;
      基于以上兩點(diǎn),才沒有給予最差!
  •     摘抄整理《人月神話》中的一些方法論。
      
      
      一、需求:required document 中要寫空間預(yù)算、測(cè)試用例
      
      二、開發(fā):關(guān)注質(zhì)量,生產(chǎn)力自然會(huì)提高
      
      三、測(cè)試:每修復(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ù)成長(zhǎng)和職業(yè)生涯規(guī)劃
      - 安排學(xué)習(xí)計(jì)劃
      - 提供交流和激勵(lì)機(jī)會(huì)
      
      5. 建議草案要在會(huì)議之前就有,并且發(fā)放
      
      
      6. 大型項(xiàng)目排期
      
      每?jī)芍苓M(jìn)行一次計(jì)劃日期的修訂
      
      http://hi.baidu.com/xizhicat/blog/item/3f15b6321f8495f515cecb8c.html
  •     現(xiàn)在我們對(duì)軟件工程的了解比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頁(yè)的篇幅來論述?")
      方括號(hào)中的評(píng)論是新增內(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ì)、集成和測(cè)試又強(qiáng)加了3倍的工作量,這些高成本的構(gòu)件在根本上是相互獨(dú)立的。
      1.2 編程行業(yè)"滿足我們內(nèi)心深處的創(chuàng)造渴望和愉悅所有人的共有情感",提供了五種樂趣:
      .. 創(chuàng)建事物的快樂
      .. 開發(fā)對(duì)其他人有用的東西的樂趣
      .. 將可以活動(dòng)、相互嚙合的零部件組裝成類似迷宮的東西,這個(gè)過程所體現(xiàn)出令人神魂顛倒的魅力
      .. 面對(duì)不重復(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)件測(cè)試以及1/4系統(tǒng)測(cè)試。
      2.9 作為一個(gè)學(xué)科,我們?nèi)狈?shù)據(jù)估計(jì)。
      2.10 因?yàn)槲覀儗?duì)自己的估計(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)理,常常是最佳的人員使用方法。[留意一下上帝對(duì)婚姻的設(shè)計(jì)。]
      3.5 對(duì)于真正意義上的大型系統(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ì)的最終測(cè)試標(biāo)準(zhǔn)",而不僅僅是豐富的功能。[該比值是對(duì)易用性的一種測(cè)量,由簡(jiǎn)單和復(fù)雜應(yīng)用共同驗(yàn)證。]
      4.3 為了獲得概念完整性,設(shè)計(jì)必須由一個(gè)人或者具有共識(shí)的小型團(tuán)隊(duì)來完成。
      4.4 "對(duì)于非常大型的項(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ī)則對(duì)行業(yè)是有益的。外部的體系結(jié)構(gòu)規(guī)定實(shí)際上是增強(qiáng),而不是限制實(shí)現(xiàn)小組的創(chuàng)造性。
      4.7 概念上統(tǒng)一的系統(tǒng)能更快地開發(fā)和測(cè)試。
      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)師有較好的成本意識(shí),以及使開發(fā)人員獲得對(duì)設(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)備接受任何其他可行的方法。
      .. 對(duì)上述的建議保持低調(diào)和平靜。
      .. 準(zhǔn)備對(duì)所建議的改進(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)師對(duì)實(shí)現(xiàn)人員的詢問做出電話應(yīng)答解釋是非常重要的,并且必須進(jìn)行日志記錄和整理發(fā)布。[電子郵件是一種可選的介質(zhì)。]
      6.9 "項(xiàng)目經(jīng)理最好的朋友就是他每天要面對(duì)的敵人--獨(dú)立的產(chǎn)品測(cè)試機(jī)構(gòu)/小組。"
      第7章 為什么巴比倫塔會(huì)失敗?
      7.1 巴比倫塔項(xiàng)目的失敗是因?yàn)槿狈涣?,以及交流的結(jié)果--組織。 交流
      7.2 "因?yàn)樽笫植恢烙沂衷谧鍪裁?,從而進(jìn)度災(zāi)難、功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)。"由于對(duì)其他人的各種假設(shè),團(tuán)隊(duì)成員之間的理解開始出現(xiàn)偏差。
      7.3 團(tuán)隊(duì)?wèi)?yīng)該以盡可能多的方式進(jìn)行相互之間的交流:非正式、常規(guī)項(xiàng)目會(huì)議,會(huì)上進(jìn)行簡(jiǎn)要的技術(shù)陳述、共享的正式項(xiàng)目工作手冊(cè)。[以及電子郵件。]
      項(xiàng)目工作手冊(cè)
      7.4 項(xiàng)目工作手冊(cè)"不是獨(dú)立的一篇文檔,它是對(duì)項(xiàng)目必須產(chǎn)生的一系列文檔進(jìn)行組織的一種結(jié)構(gòu)。"
      7.5 "項(xiàng)目所有的文檔都必須是該(工作手冊(cè))結(jié)構(gòu)的一部分。"
      7.6 需要盡早和仔細(xì)地設(shè)計(jì)工作手冊(cè)結(jié)構(gòu)。
      7.7 事先制訂了良好結(jié)構(gòu)的工作手冊(cè)"可以將后來書寫的文字放置在合適的章節(jié)中",并且可以提高產(chǎn)品手冊(cè)的質(zhì)量。
      7.8 "每一個(gè)團(tuán)隊(duì)成員應(yīng)該了解所有的材料(工作手冊(cè))。"[我想說的是,每個(gè)團(tuán)隊(duì)成員應(yīng)該能夠看到所有材料,網(wǎng)頁(yè)即可滿足要求。]
      7.9 實(shí)時(shí)更新是至關(guān)重要的。
      7.10 工作手冊(cè)的使用者應(yīng)該將注意力集中在上次閱讀后的變更,以及關(guān)于這些變更重要性的評(píng)述。
      7.11 OS/360項(xiàng)目工作手冊(cè)開始采用的是紙介質(zhì),后來?yè)Q成了微縮膠片。
      7.12 今天[即使在1975年],共享的電子手冊(cè)是能更好達(dá)到所有這些目標(biāo)、更加低廉、更加簡(jiǎn)單的機(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 僅僅通過對(duì)編碼部分的估計(jì),然后乘以任務(wù)其他部分的相對(duì)系數(shù),是無法得出對(duì)整項(xiàng)工作的精確估計(jì)的。
      8.2 構(gòu)建獨(dú)立小型程序的數(shù)據(jù)不適用于編程系統(tǒng)項(xiàng)目。
      8.3 程序開發(fā)呈程序規(guī)模的指數(shù)增長(zhǎng)。
      8.4 一些發(fā)表的研究報(bào)告顯示指數(shù)約為1.5。[Boehm的數(shù)據(jù)并不完全一致,在1.05和1.2之間變化。1]
      8.5 Portman的ICL數(shù)據(jù)顯示相對(duì)于其他活動(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ù)顯示對(duì)于已完成的產(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 在基本語句級(jí)別,生產(chǎn)率看上去是個(gè)常數(shù)。
      8.11 當(dāng)使用適當(dāng)?shù)母呒?jí)語言時(shí),程序編制的生產(chǎn)率可以提高5倍。
      第9章 削足適履
      9.1 除了運(yùn)行時(shí)間以外,所占據(jù)的內(nèi)存空間也是主要開銷。特別是對(duì)于操作系統(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è)小組傾向于不斷地局部?jī)?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é)約市場(chǎng)成本。]
      9.10 臨時(shí)空間的尺寸,以及每次磁盤訪問的程序數(shù)量是很關(guān)鍵的決策,因?yàn)樾阅苁且?guī)模的非線性函數(shù)。[這個(gè)整體決策已顯得過時(shí)--起初是由于虛擬內(nèi)存,后來則是成本低廉的內(nèi)存。現(xiàn)在的用戶通常會(huì)購(gòu)買能容納主要應(yīng)用程序所有代碼的內(nèi)存。]
      9.11 為了取得良好的空間-時(shí)間折衷,開發(fā)隊(duì)伍需要得到特定與某種語言或者機(jī)型的編程技能培訓(xùn),特別是在使用新語言或者新機(jī)器時(shí)。
      9.12 編程需要技術(shù)積累,每個(gè)項(xiàng)目需要自己的標(biāo)準(zhǔn)組件庫(kù)。
      9.13 庫(kù)中的每個(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 對(duì)于計(jì)算機(jī)硬件開發(fā)項(xiàng)目,關(guān)鍵文檔是目標(biāo)、手冊(cè)、進(jìn)度、預(yù)算、組織機(jī)構(gòu)圖、空間分配、以及機(jī)器本身的報(bào)價(jià)、預(yù)測(cè)和價(jià)格。
      10.3 對(duì)于大學(xué)科系,關(guān)鍵文檔類似:目標(biāo)、課程描述、學(xué)位要求、研究報(bào)告、課程表和課程的安排、預(yù)算、教室分配、教師和研究生助手的分配。
      10.4 對(duì)于軟件項(xiàng)目,要求是相同的:目標(biāo)、用戶手冊(cè)、內(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)備工作都將注意力集中在對(duì)討論的思索和提煉,而書寫這項(xiàng)活動(dòng)需要上百次的細(xì)小決定,正是由于它們的存在,人們才能從令人迷惑的現(xiàn)象中得到清晰、確定的策略。
      10.7 對(duì)每個(gè)關(guān)鍵文檔的維護(hù)提供了狀態(tài)監(jiān)督和預(yù)警機(jī)制。
      10.8 每個(gè)文檔本身就可以作為檢查列表或者數(shù)據(jù)庫(kù)。
      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è)原因,廣受吹捧的市場(chǎng)概念--支持管理人員的"完備信息管理系統(tǒng)"并不基于反映管理人員行為的有效模型。
      第11章 未雨綢繆
      11.1 化學(xué)工程師已經(jīng)認(rèn)識(shí)到無法一步將實(shí)驗(yàn)室工作臺(tái)上的反應(yīng)過程移到工廠中,需要一個(gè)實(shí)驗(yàn)性工廠(pilot planet)來為提高產(chǎn)量和在缺乏保護(hù)的環(huán)境下運(yùn)作提供寶貴經(jīng)驗(yàn)。
      11.2 對(duì)于編程產(chǎn)品而言,這樣的中間步驟是同樣必要的,但是軟件工程師在著手發(fā)布產(chǎn)品之前,卻并不會(huì)常規(guī)地進(jìn)行試驗(yàn)性系統(tǒng)的現(xiàn)場(chǎng)測(cè)試。[現(xiàn)在,這已經(jīng)成為了一項(xiàng)普遍的實(shí)踐,beta版本。它不同于有限功能的原型,alpha版本,后者同樣是我所倡導(dǎo)的實(shí)踐。]
      11.3 對(duì)于大多數(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à)高昂--對(duì)于用戶,使用極度痛苦;對(duì)于重新開發(fā)的人員,分散了精力;對(duì)于產(chǎn)品,影響了聲譽(yù),即使最好的再設(shè)計(jì)也難以挽回名聲。
      11.6 因此,為舍棄而計(jì)劃,無論如何,你一定要這樣做。
      11.7 "開發(fā)人員交付的是用戶滿意程度,而不僅僅是實(shí)際的產(chǎn)品。"(Cosgrove)
      11.8 用戶的實(shí)際需要和用戶感覺會(huì)隨著程序的構(gòu)建、測(cè)試和使用而變化。
      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 高級(jí)語言的使用、編譯時(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ù)人才的天賦允許,老板必須對(duì)他們的能力培養(yǎng)給予極大的關(guān)注,使管理人員和技術(shù)人才具有互換性;特別是希望能在技術(shù)和管理角色之間自由地分配人手的時(shí)候。
      11.17 具有兩條晉升線的高效組織機(jī)構(gòu),存在著一些社會(huì)性的障礙,人們必須警惕和積極地同它做持續(xù)的斗爭(zhēng)。
      11.18 很容易為不同的晉升線建立相互一致的薪水級(jí)別,但要同等威信的建立需要一些強(qiáng)烈的心理措施:相同的辦公室、一樣的支持和技術(shù)調(diào)動(dòng)的優(yōu)先補(bǔ)償。
      11.19 組建外科手術(shù)隊(duì)伍式的軟件開發(fā)團(tuán)隊(duì)是對(duì)上述問題所有方面的徹底沖擊。對(duì)于靈活組織架構(gòu)問題,這的確是一個(gè)長(zhǎng)期行之有效的解決方案。
      前進(jìn)兩步,后退一步--程序維護(hù)
      11.20 程序維護(hù)基本上不同于硬件的維護(hù);它主要由各種變更組成,如修復(fù)設(shè)計(jì)缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調(diào)整。
      11.21 對(duì)于一個(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)行先前所有的測(cè)試用例,從而確保系統(tǒng)不會(huì)以更隱蔽的方式被破壞。
      11.26 能消除、至少是能指明副作用的程序設(shè)計(jì)方法,對(duì)維護(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)版本號(hào)的增加呈線性增長(zhǎng),但是受到影響的模塊以版本號(hào)指數(shù)的級(jí)別增長(zhǎng)。
      11.29 所有修改都傾向于破壞系統(tǒng)的架構(gòu),增加了系統(tǒng)的混亂程度。即使是最熟練的軟件維護(hù)工作,也只是放緩了系統(tǒng)退化到不可修復(fù)混亂的進(jìn)程,從中必須要重新進(jìn)行設(shè)計(jì)。
      [許多程序升級(jí)的真正需要,如性能等,尤其會(huì)沖擊它的內(nèi)部結(jié)構(gòu)邊界。原有邊界引發(fā)的不足常常在日后才會(huì)出現(xiàn)。]
      第12章 干將莫邪
      12.1 項(xiàng)目經(jīng)理應(yīng)該制訂一套策略,以及為通用工具的開發(fā)分配資源,與此同時(shí),他還必須意識(shí)到專業(yè)工具的需求。
      12.2 開發(fā)操作系統(tǒng)的隊(duì)伍需要自己的目標(biāo)機(jī)器,進(jìn)行調(diào)試開發(fā)工作。相對(duì)于最快的速度而言,它更需要最大限度的內(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ù)和測(cè)量。
      12.4 目標(biāo)機(jī)器的使用需求量是一種特殊曲線:剛開始使用率非常低,突然出現(xiàn)爆發(fā)性的增長(zhǎng),接著趨于平緩。
      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)試平臺(tái)。即使在真正機(jī)器出現(xiàn)之后,仿真裝置仍可提供可靠的調(diào)試平臺(tái)。
      12.9 主程序庫(kù)應(yīng)該被劃分成(1)一系列獨(dú)立的私有開發(fā)庫(kù);(2)正處在系統(tǒng)測(cè)試下的系統(tǒng)集成子庫(kù);(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á)的意見"。
      高級(jí)語言
      12.13 只有懶散和惰性會(huì)妨礙高級(jí)語言和交互式編程的廣泛應(yīng)用。[如今它們已經(jīng)在全世界使用。]
      12.14 高級(jí)語言不僅僅提升了生產(chǎn)率,而且還改進(jìn)了調(diào)試:bug更少,以及更容易尋找。
      12.15 傳統(tǒng)的反對(duì)意見--功能、目標(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)編程中很慢和較困難的部分,而漫長(zhǎ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ī)格說明必須提交給測(cè)試小組,以詳細(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è)步驟中,盡可能使用級(jí)別較高的表達(dá)方法。
      13.6 好的自頂向下設(shè)計(jì)從四個(gè)方面避免了bug。
      13.7 有時(shí)必須回退,推翻頂層設(shè)計(jì),重新開始。
      13.8 結(jié)構(gòu)化編程中,程序的控制結(jié)構(gòu)僅由支配代碼塊(相對(duì)于任意的跳轉(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)對(duì)良好終端系統(tǒng)的正確使用,往往要求每?jī)尚r(shí)的終端會(huì)話對(duì)應(yīng)于兩小時(shí)的桌面工作:1小時(shí)會(huì)話后的清理和文檔工作;1小時(shí)為下一次計(jì)劃變更和測(cè)試。
      13.11 系統(tǒng)調(diào)試(相對(duì)于單元測(cè)試)花費(fèi)的時(shí)間會(huì)比預(yù)料的更長(zhǎng)。
      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)試的做法。)[對(duì)于多個(gè)團(tuán)隊(duì)尤其如此。]
      13.14 開發(fā)大量的輔助調(diào)試平臺(tái)(scaffolding 腳手架)和測(cè)試代碼是很值得的,代碼量甚至可能會(huì)有測(cè)試對(duì)象的一半。
      13.15 必須有人對(duì)變更進(jìn)行控制和文檔化,團(tuán)隊(duì)成員應(yīng)使用開發(fā)庫(kù)的各種受控拷貝來工作。
      13.16 系統(tǒng)測(cè)試期間,一次只添加一個(gè)構(gòu)件。
      13.17 Lehman和Belady出示了證據(jù),變更的階段(量子)要么很大,間隔很寬;要么小和頻繁。后者很容易變得不穩(wěn)定。[Microsoft的一個(gè)團(tuán)隊(duì)使用了非常小的階段(量子)。結(jié)果是每天晚上需要重新編譯生成增長(zhǎng)中的系統(tǒng)。]
      第14章 禍起蕭墻
      14.1 "項(xiàng)目是怎樣延遲了整整一年的時(shí)間?.一次一天。"
      14.2 一天一天的進(jìn)度落后比起重大災(zāi)難,更難以識(shí)別、更不容易防范和更加難以彌補(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 對(duì)于大型開發(fā)項(xiàng)目中的估計(jì)行為,政府的承包商所做的研究顯示:每?jī)芍苓M(jìn)行仔細(xì)修訂的活動(dòng)時(shí)間估計(jì),隨著開始時(shí)間的臨近不會(huì)有太大的變化;期間內(nèi)對(duì)時(shí)間長(zhǎng)短的過高估計(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)取對(duì)于杰出的軟件開發(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)系的識(shí)別、各個(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ì)對(duì)信息的完全公開造成壓制;相反,仔細(xì)區(qū)分狀態(tài)報(bào)告、毫無驚慌地接收?qǐng)?bào)告、決不越俎代庖,將能鼓勵(lì)誠(chéng)實(shí)的匯報(bào)。
      14.16 必須有評(píng)審的機(jī)制,從而所有成員可以通過它了解真正的狀態(tài)。出于這個(gè)目的,里程碑的計(jì)劃和完成文檔是關(guān)鍵。
      14.17 Vyssotsky:我發(fā)現(xiàn)在里程碑報(bào)告中很容易記錄"計(jì)劃(老板的日期)"和"估計(jì)(最基層經(jīng)理的日期)"的日期。項(xiàng)目經(jīng)理必須停止對(duì)這些日期的懷疑。"
      14.18 對(duì)于大型項(xiàng)目,一個(gè)對(duì)里程碑報(bào)告進(jìn)行維護(hù)的計(jì)劃和控制(Plan and Control)小組是非??少F的。
      第15章 另外一面
      15.1 對(duì)于軟件編程產(chǎn)品來說,程序向用戶所呈現(xiàn)的面貌與提供給機(jī)器識(shí)別的內(nèi)容同樣重要。
      15.2 即使對(duì)于完全開發(fā)給自己使用的程序,描述性文字也是必須的,因?yàn)樗鼈儠?huì)被用戶-作者所遺忘。
      15.3 培訓(xùn)和管理人員基本上沒有能向編程人員成功地灌輸對(duì)待文檔的積極態(tài)度--文檔能在整個(gè)生命周期對(duì)克服懶惰和進(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)該包括一些測(cè)試用例,其中一部分用于校驗(yàn)輸入數(shù)據(jù),一部分用于邊界輸入數(shù)據(jù),另一部分用于無效的輸入數(shù)據(jù)。
      15.8 對(duì)于必須修改程序的人而言,他們所需要程序內(nèi)部結(jié)構(gòu)文檔,同樣要求一份清晰明了的概述,它包括了5項(xiàng)內(nèi)容(參見相應(yīng)章節(jié))。
      15.9 流程圖是被吹捧得最過分的一種程序文檔。詳細(xì)逐一記錄的流程圖是一件令人生厭的事情,而且高級(jí)語言的出現(xiàn)使它顯得陳舊過時(shí)。(流程圖是圖形化的高級(jí)語言。)
      15.10 如果這樣,很少有程序需要一頁(yè)紙以上的流程圖。[在這一點(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)闡述它為什么那樣。對(duì)于加深理解,目的是非常關(guān)鍵的,但即使是高級(jí)語言的語法,也不能表達(dá)目的。
      15.15 在線系統(tǒng)的高級(jí)語言(應(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 軟件工程的焦油坑在將來很長(zhǎng)一段時(shí)間內(nèi)會(huì)繼續(xù)地使人們舉步維艱,無法自拔。
  •     如果你自稱是IT從業(yè)人員,卻沒有聽說過《人月神話》,那可就丟臉了。而30多年前的軟件工程書籍,在發(fā)展神速的IT行業(yè),也稱得上是“古書”了。
      
      Brooks博士30多年前寫的軟件工程的書,到今天依然有些幫助,可見在有些問題上的認(rèn)識(shí)是非常深刻的。
      
      通過少量核心設(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
      
      總體評(píng)價(jià):謹(jǐn)慎推薦
      
 

250萬本中文圖書簡(jiǎn)介、評(píng)論、評(píng)分,PDF格式免費(fèi)下載。 第一圖書網(wǎng) 手機(jī)版

京ICP備13047387號(hào)-7