由於本書的閱讀沒有先後之分，所以我跳過了幾章內容直接閱讀了第七章在專案開始之前和第八章注重實效的專案的內容，了解一些方法和理論。也得到了一些感悟。
1：需求之坑：不為收集需求，挖掘它們。有一種能深入了解使用者需求，卻未得到足夠利用的技術：成為使用者。與使用者一同工作，以像使用者一樣思考。描述需求文件時，要使用專案術語表。用web來收集和管理需求。
2.解開不可能解開的謎題：遇到不可能解決的問題時，退一步問問自己如下問題：1）有更容易的方法嗎？2）你是在設法解決真正的問題，還是被外圍的技術問題轉移了注意力？3）這件事情為什麼是乙個問題？4）是什麼使它如此難以解決？5）它必須以這種方式完成嗎？6）它真的必須完成嗎？
3.等你準備好：一件事沒有開始，是謹慎？還是在拖延？我覺得要通過自己的判斷，事情的優先循序和緊急情況還有你的準備，再決定是否要做。而不是魯莽的去做或者是不做拖延著。
4.規範陷阱：需求文件寫上幾百頁不成問題，但是一旦使用者看到了實際執行的系統，你就會被各種變更要求淹沒。對有些事情「做」勝於「描述」
5.圓圈與箭頭：有些設計圖是給程式設計師看的，對終端使用者沒有意義，不要認為用上了uml等形式化描述圖形就能製作出好的設計。
6.注重實效的團隊:不要留破窗戶，不要重複你自己，按功能劃分團隊
7.無處不在的自動化：持續整合的概念
8.無情的測試：早測試，常測試，自動測試
9.全都是寫:嵌入在**中的注釋，注釋應該討論為何要做某事、它的目的和目標。
10.極大的期望：給他們的東西要比他們期望的多一點。
11.靠巧合程式設計：軟體開發者，每天就像工作在雷區，有成百的陷阱等著抓住我們。
多餘的或不必要的**可能這次能夠正常執行，但換個環境可能就會崩潰，另外會使**變慢，或引入新的bug。總之，不要靠巧合程式設計。
要想著盡可能在開發周期的早期抓住並修正錯誤，道理很簡單，但在專案進度壓力大的時候，把這句話忘在腦後。
為編碼工作劃定優先順序，把時間花在重要的上面，經常也是最難的部分。但如果基礎設施不正確，再花哨的介面或裝飾也沒有什麼用。
12.演算法速率：沒有什麼可說的，就是o()表示法。
13.傲慢與偏見：在你的作品上簽名。
下面是一些書中的觀點解析：
足夠好的軟體就是俗話說的一鳥在手勝於二鳥在林.首先得確保軟體可用性,至於亮點,特色,在可用以後才需要考慮.而且還得明確使用者需求(雖然這點始終被強調).大家都知道系統不可能做的完美,但是自己著手開發的時候總是朝著盡可能完美的方向發展,欺騙自己說,這個功能多麼偉大,一定要加上去,那功能多麼驚天動地,最後反而成為四不像,使專案延期.在第一次企圖做那個todo list的時候,想著把calendar和task兩項功能完整的結合,同時還想著把contact功能也加入,甚至還有ms porject的管理功能,但是一切都太多,以致於設計了少數幾個介面以後就陷入了無止境的功能權衡中,因為太多東西又想完美所以第一次最終結果是除了最後那個簡陋的複雜的介面,什麼東西都沒有,當然如今**也已經不知道是不是被自己刪除,能夠留在自己硬碟上並且使用的還是那個簡簡單單的geetask,功能不多,但是的確對我來說,足夠好了,如果還有新的功能,新增就是了,不用一次就做乙個大而全的玩意出來.也想起在上乙個公司參與的第乙個專案,房地產的預警系統,先前同事通過研究,不知道從**搞到一些其他人做的預警系統,動用高深的所謂經濟學景氣迴圈演算法來計算,艱難的實現這些公式.當然我們自己也不知道這個是不是準.後來我負責去給客戶實施,在客戶處,得知了驚人的訊息:客戶需要的足夠好的軟體其實就是乙個新聞發布功能的東西,因為他們也不懂,是領導的要求---領導當然也是被上層領導要求.這個例子雖然特殊,但是也說明了一定要及早知道客戶心中的足夠好的軟體是什麼.
你的知識資產
關於學習的乙個章節,提學習是乙個過程,不會有立杆見影的效果,當然我們不是政客,不需要立馬可見的政績,那麼種種樹又何妨呢?學習也要有實踐,把學到的知識找機會就應用起來,起碼,自己沒用到,也可以看看別人怎麼用嘛.學的多了自然有了自己的判斷,前兩天不小心點開了jdk原始碼當中關於arrays.sort方法的實現.看到內部的合併排序法卻不如《演算法導論》中描述的那麼簡潔,那麼具有可讀性,這時候,有了判斷了,就不至於傻乎乎的研究它的寫法,當然,jdk裡面的mergesort又有一些額外的處理(小陣列優化),這個又是可以學習的地方.對了,這一小節裡面還有一段關於如何獲得答案的方法,和國內論壇風靡一時的《提問的智慧型》一文有多處相似之處,不知道作者是否參考了本書.
交流這個不用說就知道重要了.離開上一家公司最後乙個專案就是最好的例子,一開始其他同事從客戶處帶回來老系統的截圖以及一些需求的說明,然後我們就要按照這些支離破碎的東西進行開發.我們不是先知,不是某些領導人,可以自由的發揮,於是絞盡腦汁,開始努力向可以吻合的方向發展,這種日子很不好受,直到我可以與客戶聯絡上以後,直接的面對面的確認客戶的需求(又是需求) 才讓專案的進展在幾天裡面比前面乙個月都要好的多.
個人感受：
1》個人看這本書發現自己最大的不足是，不愛看書，要不是在建民老師的要求下，我大學四年可能都不會閱讀這本書。
2》如書中所說 ：「要學會把學習知識當作一種投資，這是乙個過程，不會有立竿見影的效果，但會在實踐中應用。」
3》在今後的時間中我應該學會主動閱讀與自己軟體相關的書籍，了解前輩的開發案例，充實自己，這樣才會避免在今後的開發中重蹈覆轍。
《程式設計師修煉之道》閱讀筆記03
工具能夠放大你的才幹，你的工具越好，你越是能更好地掌握它們的用法，你的生產力越高，從一套基本的通用工具開始，隨著經驗的獲得，隨著你遇到一些特殊的需求，你將會在其中增添新的工具，尋找更好的解決方式。作為注重實效的程式設計師，我們的基本材料是知識，我們蒐集需求，將其變為知識，隨後又在我們的設計 實現 測...
程式設計師修煉之道閱讀筆記03
探索的態度對於程式設計師也是尤為重要的。筆者在開始寫 的時候總是以 解決問題就萬事大吉 的標準，遇到了可能的坑卻睜乙隻眼閉乙隻眼。但是每每這樣的時候，後來總是會出bug。其實這就是逃避，就是一種缺乏探索精神的表現。其實我把那些坑弄懂了也不需要多少時間嘛。弄懂了，以後再遇到就穩穩當當搞定了。沒弄懂，就...
程式設計師修煉之道閱讀筆記03
第四章 注重實效的偏執 這章講的是程式設計師如何把 你不可能寫出完美的軟體 這一壓抑的事情轉變為有利條件。按合約設計 dbc 指的是做某事的期望和陳述。前條件，開始之前的必要條件。後條件，執行後悔導致的狀態。類不變項，類確保在呼叫者看來，該條件總是為真。死程式不說謊 要崩潰不要破壞，因為死程式帶來的...