這兩天花了點時間把《程式設計師修煉之道》這本書讀了，本來估計要一周時間才能讀完，讀了才發現作者絕對是人才啊，書寫的生動有趣，一口氣就讀完了。隨便摘錄一下。
1.做乙個靠譜的程式設計師，純粹的程式設計師，脫離了低階趣味的程式設計師
本書一開篇就提出要做乙個靠譜程式設計師，原文是pragmatic，我覺得翻譯成靠譜很靠譜。靠譜的程式設計師應該有以下幾個特點
i.對全域性負責，而不是各種找藉口推脫。在找藉口之前想想別人聽了這個藉口之後會怎麼鄙視你。。。作者認為就算是不可挽回的問題，也不要找藉口，而是告訴別人替代的解決方案。2、對待bug的態度ii.防微杜漸，不要放縱小問題。下面鄭重的提出乙個讓我眼前一亮的「破窗理論」：
破窗理論：社會學研究人員發現，導致一棟樓變得廢棄的原因不是什麼很大的問題，而是始於一扇從未被修復的破窗子。這扇破窗子不斷的提醒樓裡的人員這棟樓已經廢棄了，沒搞頭了，所以大家都可以隨便亂搞了。所以這棟樓就廢了。軟體開發也是一樣，不能容忍有瑕疵的亂寫的**，這會廢掉這個工程的。
iii.對變化敏感，不要做被煮熟的青蛙。
iv.做恰到好處的軟體，知道什麼時候停止。作者舉了乙個很生動的例子。程式設計師就像畫家一樣，開始的時候往一塊白板上面塗顏料畫，先畫框架，再畫細節，不斷的塗塗抹抹之後畫作可能已經完成了，但如果作者沒有意識到，還在不斷的新增顏料，那麼結果只能是化蛇添足了，反而毀了這幅作品。
v.重視知識的積累和與人交流。
有些開發人員，遇到bug，總先要辯解一下，「不可能」「不會吧」「我怎麼沒發現」「你操作有問題吧」，就是不想承認。有的人則是出了問題先懷疑作業系統、懷疑庫函式、懷疑編譯器、懷疑硬碟、懷疑網路，就是不懷疑自己寫的**有問題。當然不排除系統可能會有問題，可是這比買彩票中500萬的概率還要小，還是先從自己的**找原因吧。
3、don't assume it —-- prove it
經常遇到這種情況，開發人員遇到了乙個bug，查了一下，覺得可能是這個原因，好，馬上修改**，提交，done！其實有很多時候bug根本沒有被修正，首先要做的是重現bug，重現的步驟越簡單越好，修改完再用同樣的步驟，看bug是否不再出現，否則你怎麼知道bug已經被fix了呢。
4、crash early crash, don't trash.
盡早暴露問題，而不是搞的一團糟。問題出現的越晚，你要修改的**就越多，
5、don't program by coincidence
**為什麼正常工作？不知道！反正寫了那麼多，看起來是工作正常的。很多時候如果我們說不清楚，那是說明自己還沒有完全理解這個問題，**也只是幸運的執行起來了，深層的bug隱藏在裡面，只是還沒有暴露出來，總有一天會以更具破壞性的方式去爆發，「出來混，總是要還的」。開發人員也常有僥倖心裡，有時候自己測試也遇到了問題，可是不好重現，大多數情況下又是正常的，就會想「在客戶哪兒應該不會出問題」
6、ruthless testing --- 無情測試
「extreme programming」也有類似的口號「continuous integration and relentless testing」。「多數開發人員憎恨測試。他們傾向於小心翼翼地測試，知道**哪兒會出問題，就下意識避開」 很多問題，只要稍微用心去測，就會測出來，而不至於到使用者那兒再暴露出來。這一點也是我們需要加強的，建立測試的環境和機制，讓問題盡早暴露出來。
這裡只是摘錄了一小部分有意思的內容，這本書讀起來很有意思，如果你感興趣，那就弄本來讀讀吧~
by 林萌
讀《程式設計師修煉之道》
記得四年前剛開始工作時從公司拿到的第一本書，就是這本 程式設計師修煉之道 英文版 作為新入職員工study group的學習材料，當時在senior engineer帶領下和其他同事一起學習了這本書。雖然之前就聽說這是一本好書，但當時看的時候只是覺得，講的都有道理，但這些是很自然的阿，幹嗎花這麼大的...
讀《程式設計師修煉之道》
這本書已經買了好久，但一直沒看 沒看過的書在我書架上還有好多 不過是偶然間從書架上拿下，翻看了幾頁，結果我再也放不下手。於是，花了約半月的空閒時間，斷斷續續將此書讀完。此書還有一名 從小工到專家 我現在明顯是小工，並且可能還是不熟練的那種。倒沒有奢求看完這本書就變成專家 這種書還沒有寫出來吧 不過，...
程式設計師修煉之道
在所有的弱點中，最大的弱點就是害怕自己暴露弱點。j.b bossuet,politics from holy writ,1709 provide options,don t make lame excuses 提供各種選擇，不要找蹩腳的藉口 don t live with broken window...