這兩天花了點時間把《程序員修煉之道》這本書讀了，本來估計要一周時間才能讀完，讀了才發(fā)現(xiàn)作者絕對是人才啊，書寫的生動有趣，一口氣就讀完了。隨便摘錄一下。

1.做一個靠譜的程序員，純粹的程序員，脫離了低級趣味的程序員

本書一開篇就提出要做一個靠譜程序員，原文是pragmatic，我覺得翻譯成靠譜很靠譜。靠譜的程序員應該有以下幾個特點

I.對全局負責，而不是各種找借口推脫。在找借口之前想想別人聽了這個借口之后會怎么鄙視你。。。作者認為就算是不可挽回的問題，也不要找借口，而是告訴別人替代的解決方案。

II.防微杜漸，不要放縱小問題。下面鄭重的提出一個讓我眼前一亮的“破窗理論”：

破窗理論：社會學研究人員發(fā)現(xiàn)，導致一棟樓變得廢棄的原因不是什么很大的問題，而是始于一扇從未被修復的破窗子。這扇破窗子不斷的提醒樓里的人員這棟樓已經(jīng)廢棄了，沒搞頭了，所以大家都可以隨便亂搞了。所以這棟樓就廢了。軟件開發(fā)也是一樣，不能容忍有瑕疵的亂寫的代碼，這會廢掉這個工程的。

III.對變化敏感，不要做被煮熟的青蛙。

IV.做恰到好處的軟件，知道什么時候停止。作者舉了一個很生動的例子。程序員就像畫家一樣，開始的時候往一塊白板上面涂顏料畫，先畫框架，再畫細節(jié)，不斷的涂涂抹抹之后畫作可能已經(jīng)完成了，但如果作者沒有意識到，還在不斷的添加顏料，那么結果只能是化蛇添足了，反而毀了這幅作品。

V.重視知識的積累和與人交流。

?

2、對待bug的態(tài)度
　　有些開發(fā)人員，遇到bug，總先要辯解一下，“不可能”“不會吧”“我怎么沒發(fā)現(xiàn)”“你操作有問題吧”，就是不想承認。有的人則是出了問題先懷疑操作系統(tǒng)、懷疑庫函數(shù)、懷疑編譯器、懷疑硬盤、懷疑網(wǎng)絡，就是不懷疑自己寫的代碼有問題。當然不排除系統(tǒng)可能會有問題，可是這比買彩票中500萬的概率還要小，還是先從自己的代碼找原因吧。

3、Don't Assume It —-- Prove It
　　經(jīng)常遇到這種情況，開發(fā)人員遇到了一個bug，查了一下，覺得可能是這個原因，好，馬上修改代碼，提交，Done！其實有很多時候bug根本沒有被修正，首先要做的是重現(xiàn)bug，重現(xiàn)的步驟越簡單越好，修改完再用同樣的步驟，看bug是否不再出現(xiàn)，否則你怎么知道bug已經(jīng)被fix了呢。

4、Crash Early Crash, Don't Trash.
　　盡早暴露問題，而不是搞的一團糟。問題出現(xiàn)的越晚，你要修改的代碼就越多，

5、Don't Program by Coincidence
　　代碼為什么正常工作？不知道！反正寫了那么多，看起來是工作正常的。很多時候如果我們說不清楚，那是說明自己還沒有完全理解這個問題，代碼也只是幸運的運行起來了，深層的bug隱藏在里面，只是還沒有暴露出來，總有一天會以更具破壞性的方式去爆發(fā)，“出來混，總是要還的”。開發(fā)人員也常有僥幸心里，有時候自己測試也遇到了問題，可是不好重現(xiàn)，大多數(shù)情況下又是正常的，就會想“在客戶哪兒應該不會出問題”

6、Ruthless Testing --- 無情測試
　　“Extreme Programming”也有類似的口號“continuous integration and relentless testing”。“多數(shù)開發(fā)人員憎恨測試。他們傾向于小心翼翼地測試，知道代碼哪兒會出問題，就下意識避開” 很多問題，只要稍微用心去測，就會測出來，而不至于到用戶那兒再暴露出來。這一點也是我們需要加強的，建立測試的環(huán)境和機制，讓問題盡早暴露出來。

?

這里只是摘錄了一小部分有意思的內容，這本書讀起來很有意思，如果你感興趣，那就弄本來讀讀吧~

?

by 林萌

轉載于:https://www.cnblogs.com/meng-meng/archive/2011/10/28/2227525.html

總結

以上是生活随笔為你收集整理的做靠谱的程序员--《程序员修炼之道》读书报告的全部內容，希望文章能夠幫你解決所遇到的問題。

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