夢斷代碼，Dreaming in Code， 是作者講述軟件開發路上一系列的坎坷與經驗之談。

第0章 軟件時間

　　從0開始的技術方式，自然也就講了計算機從0開始的原因。+1，-1正是我們對計算機所作的操作。

　　"Hello World " 程序能夠喚醒每個程序員心中樂觀的一面。既然能叫它說話，就能讓它做任何事！

　　為什麽就是不能像造橋那樣造軟件？

　　在現代軟件研究領域多有建樹的專家弗裏德裏克·布魯克斯(Frederick Brooks) 在1987 年寫了一篇題為（ 沒有銀彈(No Silver Bullet )〉的著名論文。布魯克斯在論文中稱，我們始終無法找到突破，無法得到銀彈。

第1章 死定了

　　軟件項目難以按進度安排實現，這種情況極為常見。在軟件開發的世界裏，進度延誤普遍到人們特意生造出—個委婉詞來描述它：slippage（失速）

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

　　所謂“人月", 是一種科學管理概念，它假定生產力可被拆分為不連續、無差異、可替換的單元。

　　布魯克斯發現，制作軟件的大量工作受困於“序列約束＂，它限制了任務分解的程度：完成某項任務是處理其他任務的先決條件，這與人力投入多少無關。

　　開源運動的興起，對於我們學生來說自然是益處多多，促進了計算機世界的發展，以與大教堂方式相對的立場成果林立。

第2章 Agenda之魂

　　蓮花公司有個叫做Agenda 的項目，為了解決卡普爾的小紙片問題而設立。即采用計算機人工智能來管理記錄信息的小紙片——名片、隨手貼、筆記頁等。蓮花公司於1988 年發布了Agenda 軟件。

　　Agenda的“自動分派”特性一一在意義模糊的短語裏面，如“ 下周五與約翰共進午餐"‘找出“下周五”這個曰子——如同魔法一般，沒有其他軟件能與之媲美。它還引入了一種管理數據的新手段——介於傳統計算機數據庫的嚴格結構和字處理軟件的自由格式之間。

　　Agenda的創建者們認定這樣一些超乎常規的原則：用戶不用關心軟件的存儲結構，只管輸入數據就好，用戶應該能夠容易地擴展和修改數據結構、添加新分類， 且不會導致數據丟失，用戶應該能夠用自己創建的新方式查看數據——也可以在自己創建的視圖中操作和修改數據。

關於Chandler，米奇.卡普爾只知道三個要素：它應當開源，它應當撓到Exchange 的癢處，它應當承繼Agenda 之精髓。

文章又介紹了很多失敗項目，並指出失敗的原因是項目需求的不斷變化。無法標準把心，時間一天天流逝，預算也會超支，最終導致項目破產。

第3章 原型與Python

　　Python 是一種“解釋型語言(interpreted language)" 。“編譯型語言(compiled language)" 通過編譯器先將程序員的源代碼翻譯為機器可讀的二進制代碼後再運行，而解釋型語言則是在運行時做類似的工作——解釋器逐行翻譯源代碼，再餵給處理器運行。解釋型語言效率較差，因為你要同時運行自己的程序和解釋器。但這也使得解釋型語言較為敏捷。

　　Python是一種動態語言，每次調用變量時都要去判斷變量的類型，但是在書寫代碼時就很方便

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

第4章 樂高王國

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

　　大概滿足需求的開源代碼我們都能找到很多，但是能恰好契合契合我們問題的卻很難，除非是很傳統的練習題，如果是創新性的項目就需要我們自己去解決這些差異。

第5章 管束奇客和狗

　　國外技術人員不願承擔項目經理這種管理崗位，而在國內正好相反，許多時候還是不會編程的人來管理。

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

關於奇客的2種定義：

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

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

　　我們在制作工具的時候，不要花費太多的時間，雖然磨刀沒有錯，但畢竟時間有限，我們的主要任務還是砍柴。

第6章 搞掂設計方案

　　持續集成應該更利於產品的定期發布。

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

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

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

　　應該要腳踏實地，不要妄想一口吃成個胖子，從小一步步積累，一步步提高自己的能力。

第7章 細節視圖

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

　　一定要弄清楚需求，否則白白浪費時間和人力。最好能讓負責這一塊的人復述一下讓他說一下自己的理解。

第8章 白板上的即時貼

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

　　貼紙法應該是在敏捷開發裏被重點推廣的，方便標註哪些功能暫未開始，那些正在進行，哪些已經完成，項目各個小版本的功能特性都清清楚楚。

第9章 方法

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

1）計劃是強制性的

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

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

祖爾測試的12個問題：

1）你們使用源代碼控制嗎？

2）你們一步就能完成構建嗎？

3）你們做每日構建嗎？

4）你們有缺陷數據庫嗎？

5）你們會在寫新代碼之前修復缺陷嗎？

6）你們有與當前工作吻合的進度安排嗎？

7）你們有規約嗎？

8）程序員工作環境安靜嗎？

9）你們采用了市面上最好工具嗎？

10）你們有測試人員嗎？

11）你們會要求應聘者在面試時寫代碼嗎？

12）你們做走廊可用性測試嗎？

CMM開發在國內還是比較困難的吧，比較註重過程，國內很多公司都把這個工程流於形式，很多都是為了向用戶提高價碼。

第10章 工程師和藝術家

　　squeak一種為少兒定制的samlltalk最新開源實現

　　如果說編程是一門藝術，那麽讓孩子今早的接觸好像沒有什麽不好，還有一種說法認為編程是一種工程。

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

第11章 通往狗食版之路

　　我們要嘗試下自己寫出來的軟件，把自己帶入到用戶的地位，想像一下用戶的體驗，如果我們自己都無法承受，那客戶要爆炸的吧。。。

集開發、測試與用戶與一身，如果把修復啥的都包給別人，自己做完就走有點像甩手掌櫃，全套負責開發出能讓人滿意的產品才能提高我們的境界。

夢斷代碼讀書筆記