《夢(mèng)斷代碼》讀后感（第1~6章）

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

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

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 在現(xiàn)在比較成熟的社區(qū)模式中，代碼簽入還是有各種等級(jí)的人來(lái)批準(zhǔn)，不是誰(shuí)想干什么就干什么。 從這一點(diǎn)來(lái)說(shuō)，有點(diǎn)吸取了正式團(tuán)隊(duì)的做法。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。