《夢斷代碼》讀后感（第1~6章）

??? 書名："Dreaming in Code"，作者：Scott Rosenberg（中譯本：《夢斷代碼》，翻譯：韓磊，電子工業出版社出版）。 ?

• 第1章 【死定了】
  ??? 在這一章中，作者主要討論的一個問題是——在項目進展遲緩，面臨延期交付窘境的情況下，是否應該征召新人加入團隊？
  ??? 很顯然，這樣做的好處是：會有更多的人參與到項目開發中來，更多的人閱讀代碼，從而獲得更大的發現并解決錯誤的可能性。作者在書中援引瑞蒙德（Eric S. Raymond，《大教堂與集市（The Cathedral and the Bazaar）》一文的作者）的原話“只要有足夠多的beta版測試人員和開發者隊伍，幾乎所有問題都會很快被發現，而且總有人知道該怎么修復。或者用不太正式的說法，‘眼球足夠多，缺陷無處躲。’我把這叫做‘李納斯法則’。“而Linux操作系統和許多開源項目成功的案例就為這條法則做了十分生動的注腳。
  ??? 但是與‘李納斯法則’相對應的，還有一條‘布魯克斯法則’（《人月神話（The Mythical Man-Month）》，Frederick Brooks）：”往已延誤的項目中補充人力，只會使其繼續延誤“。這條法則也有其合理的依據：每加入一個新人，都需要開發團隊暫緩開發進度，為新人講解工程結構，使其融入整個工程，而這個過程本身便會拖累項目進度。
  ??? 我想這兩條法則各有其成立的背景，而其中非常重要的一點就是團隊內的交流成本。開源項目背后往往有一個龐大的開源社區，這個社區內的程序員們通常都是出于自己的個人愛好而為項目出力。一個新人在社區上提出的問題往往有很多人知道答案并能很快得到解答，這些人可能只是由于加入社區或關注項目更早，獲得了更多的信息和經驗，而非真正的核心開發人員，因而這個”幫助新人融合”的環節就不太會拖累工程的進度。總而言之，開源社區因其規模效應使得核心開發人員可以將精力集中在開發上，而每加入一個新人的“融合成本”均攤到余下的“社區志愿者”身上以后就變得十分渺小了。可是像卡普爾的這個規模相當有限的Chandler團隊，成員是領受薪水的，每個人都承擔了相當的任務，幾乎都是項目開發中不可或缺的一員。這樣的情況下，任何一個人的進度遲緩都會影響到整個項目的進展，因而布魯克斯法則就會起主要作用。
  ??? 對于我們這個Focus小組來說（其實其他的軟工小組也一樣），還是和Chandler更像一些：每個成員負責項目中的某一塊，且一個成員的延誤會拖累整個項目。況且征召新人對我們來說也不現實，因此，為了保證項目進度的正常進行，PM就要保證每個開發人員都在正常的運作，并且最關鍵的是：在關鍵的時間節點上能夠出活。在這一點上，我們也是深有體會的：項目開發的初期階段，PM早早地制定好了項目框架和接口設計，負責數據存取和與Google Calendar同步的開發人員也較快地完成了任務，UI部分則相對進展慢一些，尤其是負責實現Task Pool的成員，因為忙于其他事情而較晚將精力投入到項目開發中來。期間PM向組內不定期的發郵件通告項目各部分的進展，讓進展較慢的開發人員時時感受到壓力的存在。最終，進展較慢的開發人員也通過在alpha release前4天開始拼命干活完成了預定任務，保證了整個項目的正常進度。

12:38 PM?| Add a comment?| Read comments (1)?| Permalink?| Blog it?| [ASE課程] http://scheduleyourlife.spaces.live.com/blog/cns!A564B56821C5E3FA!186.entry#comment xin 鄒欣 - Dec. 13, 2009 - Delete 在現在比較成熟的社區模式中，代碼簽入還是有各種等級的人來批準，不是誰想干什么就干什么。 從這一點來說，有點吸取了正式團隊的做法。

總結

以上是生活随笔為你收集整理的现代软件工程系列 学生读后感 梦断代码 布鲁克斯法则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。