“拿來的代碼所不能做到的部分，恰是項目與眾不同的創新之處”。

《夢斷代碼》

終于看完了《夢段代碼》。 ???? 其實整本書就是講圖靈機的不可判定性————軟件開發過程中，很多過程都不知道什么時候能不能結束，甚至說能不能做出來，這導致整個軟件工程不能夠停止，這不是暗合了“停機問題”？純屬玩笑，問題并沒有這么簡單，否則Scott Rosenberg的書也不會這么暢銷。 ? ???? 我最感興趣的是如何能夠在10個小時之內讀完這本書的英文版，因為我十個小時才剛完成中文版的一半，而且只是大概的了解。不得不說，我不是很習慣作者的寫作風格，以記敘文的風格去寫說明文，必然會給信息的提取帶來很多的不便，說白的就是文章中的“廢話”太多，以至于不認真看還真找不到課上講的東西，比如“Feature Driven”之類。不過話說回來，Scott Rosenberg真乃神人，能夠把這么一件很理性的事情以如此幽默的方式表現出來而且不失深厚的文化底蘊，使得全文行云流水，酣暢淋漓的展現自己在項目管理和代碼編寫方面的才華，獲得這么多讀者的支持也是有理由的。 ? ???? 《夢斷代碼》以OSAF開發的名叫Chandler的PIM軟件的開發過程為主要的線索，闡述了這個軟件的4年來開發過程，這個夢并不是很美好，實際上是痛苦的，軟件開發過程中的典型問題在Changler的開發過程中到能找到。不過本書主要還是要說明如何有效的應對由于生產力的發展而導致預期目激增而導致項目目標發生的變更，這樣的變更通常是不可預知的，似乎在和你進行一場不公平的游戲，你在明處，他卻在暗處————被動的總是你。 ? 1、信仰 ? ???? 如果一個軟件項目沒有任何追求，那么可以做的很平庸，這樣也就很難遇到Chandler開發過程中的種種困難。這不是作者考慮的范圍，作者希望一個軟件開發出來，必須要有“殺手級”特性，比如文中提到的Lotus 1-2-3，這樣便是軟件開發中目標變更的源泉。軟件必須是有區別其他軟件的特性，而不是簡單的仿照，我們不希望做出復制品。我覺得Chandler開發過程中的主角卡普爾堅信“Agenda之魂”便是一個似乎不可完成的特性，他希望PIM能夠任意的整合個人數據，這個“任意”就讓人摸不到邊了。不過正是卡普爾堅信這樣的信仰，才是他能夠在OSAF看著Changler舉步維艱的前行了6年（今年初卡普爾貌似從OSAF撤資了，不過Chandler似乎還在繼續前行）。 ? 2、一個接一個的問題 ? ???? 很多問題看似簡單，實際上卻很難解決。比如“代碼復用”問題，是重用他人的成果，還是另起爐灶，從頭開始，這有點像哈姆雷特的抉擇。文中提到了，“代碼復用”實際上非常困難，因為沒有兩片相同的樹葉，任何功能都不是完全相同；即使有適用的代碼，如何在浩如煙海的代碼庫中找到也是個問題。實際上“代碼復用”和軟件的信仰有點相悖，重復他人的成果還是自我創新，不過文中還是給出了答案，“拿來的代碼所不能做到的部分，恰是項目與眾不同的創新之處”。 ? ?????軟件開發過程中遇到的最多的問題是“項目的進度遠遠落后于計劃”。Chandler計劃是3~4個月發布一個版本，但是每個版本都花了6個月以上的時間，這里面有諸多的原因。首先合理的衡量開發進度本身就是一件非常難的事情，也就是說計劃本身太苛刻了。即使是檢測軟件開發的進度也是一件很痛苦的事情，用代碼數量或者缺陷減少數目來衡量有過偏頗，文中提到了MBWA的方法，但是這個方法很難得到一個總體的開發進度。其次是軟件開發的計劃往往超出了能預見的范圍，致使軟件開發一只停留在設計階段，引用文中的一句話,“用今天的工具和過程，加上昨天的內存限制，我們真的能做的更好”。另外就是軟件的缺陷，Chandler在開發過程似乎中似乎掉進了缺陷的泥潭中，他們花了大量的時間用于修復軟件的缺陷，如何減少軟件開發過程的缺陷也是個頭大的事情。 ? ????? 還有就是開發者的心態也是需要注意的，如果軟件長時間停留在設計階段，沒有任何的程序甚至是代碼，那么很容易讓人悲觀，會影響生產力的發展。文中記敘了一件很有趣但是也很無奈的事情，Chandler 0.2發布的時候，發布者在Blog中懇求大家不要下載，甚至不要去宣傳，原因是Chandler 0.2是一個幾乎不能用的版本。但為什么要發布呢？“如果沒有中間版本期限的話，就會導致在充滿各種編碼可能性的土地上漫無目的地四處游蕩”。 ? 3. 我們要迎難而上 ? ???? 當然，作者不是簡單羅列Chandler開發中的問題，他還是提出了許多開發過程中的一些方法和注意事項。作者很看重方法的選擇，對于不通的情況，應該采用不同的方法，他說“決定采用何種工具和方法有可能成就或毀掉項目”。 ? ???? 首先是如何設計項目的目標。這個和項目的信仰很矛盾，理想是做一個很出色很優秀的軟件，但是很多情況下是力不從心的，項目過大很容易埋葬自己。文中有一段很有意思的對話：“你對那些剛開始做大型開源項目的人有何建議？”“別做大項目”。卡普爾在Chandler的設計過程中一直想堅持“Agenda之魂”，現實卻一次次的消磨這種想法。后來他只期望做出一個“狗食版”，但是“狗食版”都是一件多么奢侈的愿望。實際上大家都希望看到自己的努力有實質性的成果，做出一個“狗食版”有利于較大目標的實現。“盡快的做出可用的軟件”（原文中“狗食版”是指給自己用的版本，來源于一個美國賣狗食公司的廣告，該公司的老板用自己生產的狗食喂自己的狗） ? ???? 其次是進度管理，這在軟件工程中是不可預知的。首先是進度的衡量難，不能單一的用代碼數量和缺陷減少數量。在軟件過程中有很多很頑固的缺陷，在當前很難快速的解決。還有就是人與人之間是很難協調的，比如新加了個成員，需要新成員培訓；比如更換了項目經理等等。文中提到“特性驅動”“進度驅動”等，在實際的管理過程中兩者兼有，只是側重點不通罷了。對于是否需要用強制進度紀律來管理，作者謹慎的給出了說明：這要看情況來定。有些程序員不喜歡被強制管理，那么強制紀律最好不要用。如果進行強制進度管理，那么在評估進度的時候要符合現實，采用“自底向上”的方法評估。比如文中的CMM管理。 ? ???? 還有缺陷管理。現在的編程模式基本上都是先編些代碼，然后修正缺陷，實際上很難寫出沒有缺陷的代碼來。直覺上，文中也是這么說的，在開發過程中越晚修正缺陷，代價就會越高。所以要盡早的發現缺陷。如何減少缺陷，文中給出了一些方法，比如“螺旋模型”、“極限編程”、“祖爾測試”等等。作者還提到了OOD的思想，要合理的抽象和模塊化，同時鼓勵使用代碼注釋。（實際上代碼注釋可以很好的發泄自己的情緒~~） ? ????? 當然，一個項目的成員自然需要交流，交流的方法有很多，可以用Blog、wiki等等，但是不要忘了一些非正式的交流方法，比如在“冷水機”旁邊交流。 ? -------by Hu Wei from ?http://springgreen9527.spaces.live.com/default.aspx?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&sa=43775437

總結

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

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