讀書筆記：《夢斷代碼Dreaming in Code》

標籤：

讀書筆記：《夢斷代碼Dreaming in Code》

拿到《夢斷代碼》書後，一口氣翻了一遍，然後又用了3天時間仔細讀了一遍，也不禁掩卷長歎一聲，做軟體難。雖難，仍要繼續走下去，可以把軟體的範圍限制得小一些，用敏捷方法等過程會使軟體失敗的風險小一些，畢竟我們還沒有寫書上所說的那樣的大型軟體。

 

第0章 軟體時間

一開始看到第0章並沒有感覺多麼奇怪，可能程式員的思維方式已經固化在大腦中了，但讀到作者關於第0章無意搞笑時，也不禁啞然失笑，為什麼程式員要 從0開始計數？因為電腦從0開始計數！多麼直接的答案，程式員要學習電腦的計數方式，要從0計數轉換到真實使用者的從1計數，不停地在程式中進行+1 和-1操作。

讀到Hello World，上網google了一下這個200多個hello world的網頁，許多都是聞所未聞的語言。

http://www2.latech.edu/~acm/HelloWorld.html

http://www.roesler-ac.de/wolfram/hello.htm   這個不知道為什麼無法顯示，難道這東西也被QIANG了？

1987年Frederick Brooks寫了《沒有銀彈》的著名論文，1/4個世紀過去了，銀彈確實沒有發現，各種方法論產生了一大批。

 

第1章 死定了

Bugzilla軟體在我們的團隊裡沒有使用過，我們主要用JIRA，主要是在軟體快發布前用上一段時間，隨著時間的推移，一些項目就慢慢不用了。

布魯克斯法則：向已延誤的項目中補充人力，只會使其繼續延誤。

做軟體的人都聽說過這個法則，但在項目吃緊的時候確實都忽略它的存在，或者認為這法則對自己的項目不成立。此時領導的決策通常不是靠大腦，而是憑通常的直覺，人多力量大，但在軟體行業不適用。“十月懷胎，無論多少婦女參加都一樣”，是個非常形象的比喻。

 

第2章 Agenda之魂

卡普爾（Mitchell Kapor）在接受戴維·甘斯的採訪時說過的一段話：

在變成數字資本家之前，我曾教人超覺靜坐，還在一家社區醫院的精神科做過心理諮詢師，這些經曆對我影響極深。我擁有心理諮詢的碩士學位。所以，我另 有志趣。我只是誤入電腦領域，無意成為比爾·蓋茨----只有比爾·蓋茨才能做比爾·蓋茨。我向來不求做大公司、賺大錢。我只是辦了家叫做蓮花的小公 司，做了個幾百萬人爭相購買的軟體產品，結果這家小公司陡然暴長，員工數千，每年度營收數億美元。很不爽。至少對我個人來說，很不爽。所以我離開了。在某一 天，我離開了。

 

第3章 原型與Python

語言的選擇可能都是一個項目在前期選擇時必須要經曆的痛苦抉擇。

文中談到了彙編、Fortran、C、Perl，談到了編譯型語言和解釋型語言，最後項目用Python語言來實現。

這章裡提到了RDF（Resource Description Framework），好像在今年結題的國家863項目中也聽到過這個名詞，原來這玩意可以用來描述全球資訊網中的語義。

電梯遊說：就是當你有幸在電梯間遇到某位權錢人士時，能脫口而出，在短時間內說服他。

 

第4章 樂高王國

模組化和組件化是軟體人員的夢想，誰都想把幾個模組插到一起就可以完美的運行並完成任務，但現實卻相當殘酷，可以啟動並執行模組通常不能與自己想寫的程 序配合工作，好的原始碼由於商業利益也不太容易找到，程式員只能自己另起爐灶，搭建自己的模組，但結果還是一樣，做出來的東西難以讓他人共用，這個現象周 而復始，不斷地在多個程式員身上上演。

最近有一個叫組件管理方面的項目，聽起來讓人毫無信心，連運行在什麼平台上、給什麼使用者使用都不清晰，這樣的組件管理有什麼用？還不如就叫做文件管理算了。

書中提到一個叫考克斯的人，他創辦了一家叫做Stepstone的公司，致力於向C語言系統搭造者提供插入式晶片級軟體組件，最後的結論是：壞 訊息是這次實驗顯示，即便採用最新的技術，要想設計和製造既有用又真能複用的組件、為組件寫文檔以便於客戶理解、移植組件到潮水般不斷湧現的新硬體平台 上、確保最新的改進或發布版本不與現存介面衝突、將組件銷售到類似威廉姆斯堡槍械行業那種鼓勵從頭做起的價值體系，都是極其困難的。

可複用軟體之夢有一個悖論：幾乎總能找到一段滿足大部分需要的代碼。但這些拿來的代碼所不能做到的部分，恰恰是項目與眾不同的創新之處----也是建立這個項目的出發點。

 

第5章 管束奇客和狗

品質三角，既好、又快、還便宜，同時滿足的事情不太可能發生。

從程式員轉做經理常被說成是做了“前腦葉白質切除手術”，這個術語還是從剛從《How We Decide》這本書看到過，這種手術會讓患者更新喪失感情、不知愛恨悲喜。國外技術人員不願承擔專案經理這種管理崗位，而在國內正好相反，許多時候還是不會編程的人來管理。

用程式碼數做判斷標準只會鼓勵程式員寫臃腫、蹩腳的代碼。

閑逛式管理MBWA(Management by wandering around)好像不能移植到軟體領域中。

關於奇客的2種定義：

以（電腦）程式缺陷為食----不善社交、身有惡臭、面色蒼白的偏執狂，具有乳酪刨絲器一般的人格特點。

專註於己事的人；追求技術（特別是專業技術）和夢想、不融入主流社會的人。

群件Groupware：即時通訊、聊天室、缺陷跟蹤、源借故傳統的郵件清單等工具，個人感覺要慎用這些工具，否則你的工作時間會被這些工具吃得一乾二淨。

Wiki在chandler項目中也建立了起來，感覺這個chandler項目用到的工具太多，如果程式員不能合理地安排自己的時間，估計會被這些工具所淹沒。

對於程式員來說，確實有一種製造工具的衝動。磨刀不誤砍柴功本身沒錯，但程式員在磨刀的過程中會想弄到一塊最好的石頭，並花了大把的時間去把刀磨得吹毛斷髮，卻忘了還要砍柴。

 

第6章 搞掂設計方案

持續整合應該更利於產品的定期發布。

這一章出現了GTD，沒想到這本書的產品chandler竟然與GTD也有關係，原來這個軟體的UI設計師尹咪咪受到了戴維艾倫的Get Things Done書的影響，不過這裡翻譯為《搞掂》，而不是《搞定》，看來如果chandler早點發布，流行於世面上的GTD工具可能不會是omnifocus，而是chandler了。

在www.floklore.org網站裡有大量關於建立MAC作業系統的小故事，可惜這些英文看起來有點累。

關於Linux的作者李納斯托瓦茨的話：

別做大項目。從小項目開始，而且永遠不要期望它變大。如果這麼想（指做大型軟體），就會做過度設計，把它想象行過於重要。更壞的情 況是，你可能會被自己想象中的艱難工作所嚇倒。所以要從小處起步，著力考慮細節。別去想大圖景和好設計。如果項目沒解決某些需求，多半就是被過度設計了。

別指望在短時間內達到大成就，我致力於Linux達13年之久，我想後面還得花上好些時間。如果一早就妄想做個大東西，可能現在還沒動手呢。

 

第7章 細節視圖

需求搞錯的嚴重後果，18英尺的巨石拱門變成了18英寸的石樁子。

最著名也最聲名狼藉的匈牙利命名法，可能在用C++寫Windows程式的時代是需要，因為各種類型、結構、枚舉、控制項等等讓人眼花繚亂，讓人容易出錯，而在Java和C#等這種強型別的語言中，這類命名法完全是對程式員審美觀的踐踏。

prepBut nI vrbLike adjHungarian! qWhat’s artThe adjBig nProblem?

我就是喜歡匈牙利命名法！有什麼問題？

Chandler中的所有內容都是Item，對Item可以打戳算是一種創舉，有機會看來還是可以試試這款應用。

 

第8章 白板上的即時貼

非常敬佩寫標準的人，你要用5年為計量標準的眼光看問題。得花上5年時間，才能得到你真正想要的有用之物。

這裡也提到了WebDAV，好像這協議在Mac裡實現得比較全，但在Windows中都不完整。omnifocus也支援WebDAV同步。

這章裡提到了37Signals公司（寫《重來Rework》的那家公司），這種小型團隊專註於AJAX的WEB應用，同樣取得了成功。

用貼紙法來討論項目各個小版本應該具有的功能特性，也是敏捷開發裡重點推廣的。

 

第9章 方法

IBM執行強制進度紀律的成功基於兩條原則：

1）計劃是強制性的

2）計劃必須符合現實情況 ----“從底向上”，依據那些負責按計劃執行的程式員的經驗和知識而來，而不是“從頂至下”，靠管理者拍腦袋或對市場的期望而來。

CMM這個沉重的軟體開發成熟度等級模型在國內完全變了味，曾看著一個軟體公司為了通過CMM4，編出一堆從來無人細看的厚厚的文檔，CMM果然只重過程，而國內更把這種過程流於形式，通過CMM，只為了向使用者抬高價碼。TSP、PSP也看過，感覺相當繁瑣，在國內都難於實行。

2001年17位領軍人物，提出了敏捷式軟體開發 (Agile Software Development)宣言，向這種笨重的CMM宣戰，從此極限編程XP和SCRUM開始流行。

Google讓開發人員把五分之一的時間花在個人項目上。這種管理方式在國內想都不敢想。

祖爾測試的12個問題：

1）Do you use source control?      你們使用原始碼控制嗎？

2）Can you make a build in one step?     你們一步就能完成構建嗎？

3）Do you make daily builds?    你們做每日構建嗎？

4）Do you have a bug database?     你們有缺陷資料庫嗎？

5）Do you fix bugs before writing new code?     你們會在寫新代碼之前修複缺陷嗎？

6）Do you have an up-to-date schedule?     你們有與當前工作吻合的進度安排嗎？

7）Do you have a spec?    你們有規約嗎？

8）Do programmers have quiet working conditions?    程式員工作環境安靜嗎？

9）Do you use the best tools money can buy?    你們採用了市面上最好工具嗎？

10）Do you have testers?   你們有測試人員嗎？

11）Do new candidates write code during their interview?    你們會要求應聘者在面試時寫代碼嗎？

12）Do you do hallway usability testing?    你們做走廊可用性測試嗎？

 

第10章 工程師和藝術家

squeak一種為少兒定製的samlltalk最新開源實現，讓少兒過早接觸編程到底好不好？

編程是工程還是文學？是科學還是藝術？

高德納寫的書名叫《電腦程式設計藝術》，他在1984年獲得圖靈獎時發表感言說，“電腦編程是門藝術”。寫《電腦程式設計藝術》這本書他花了十年，寫TeX和metafont程式沒想到也花了近10年。他宣稱，寫軟體要比寫書“難多了”。

 

第11章 通往狗食版之路

吃自己的狗糧，這種思路確實有助於提升軟體品質和使用者體驗，想想連自己都不屑一用的軟體憑什麼去折磨使用者呢？

麥卡錫從本質上用LISP描述了LISP，有時間得看看這個大名頂頂的LISP，先把這段天書貼上，據說與Haskell一樣難學。

尾聲 長賭

可憐的海灣大橋在2012年完工，上網查了查，看來需要在2013年才能完工，看來建橋與軟體也有相似之處。

從網上搜了一張2013年完工時預計的樣子。

 

看完書後，我上網查了一下，原來chandler1.0 已經在2008年發布了，當前是1.0.3版本，也被稱為一種GTD工具，憑著一點好奇心裝上了，實在不會用，馬上就刪除了，滿屏的東西不知道該按哪個， 可能OmniFocus的概念已經徹底地佔據了我的大腦了，讓我放棄所有的omnifocus上的action全部匯入到這裡來管理，實在沒有這個勇氣。

 

讀書筆記：《夢斷代碼Dreaming in Code》