《程式設計師的職業素養》讀後感：一本Bob大叔的錯誤大全

前段時間入手了一本《程式設計師的職業素養》，誰推薦的忘記了，斷斷續續看完了，覺得寫得還行，翻譯這本書的人是公司的同事，但是從來沒見過。

本書是Bob大叔的作品，他是一名程式設計師，編了40多年的程式了。書的序是這樣開頭的，“如果你選擇了這本書，那麼我不妨認為你是一名軟體工程師”這句話一針見血啊，如果你不是程式設計師，估計也沒有必要看這本書了。

“請你把這本書看成是我的錯誤大全，它記錄了我幹過的所有蠢事”這句話挺有意思的，和馬雲之前談的有點類似，他想寫一下阿里巴巴犯過的種種錯誤，而不是阿里巴巴是如何成功的。或許，我們從過往的錯誤中能夠學習到更多的東西吧。

書的第一章是“專業主義”，之所以這樣講，估計是Bob大叔覺得現在很多程式設計師不夠專業吧。“專業主義就意味著擔當責任”，這句話表示深深的認同，自己寫過的程式碼，如果後面出了問題，這時候站出來說，這是我的責任，我啥時候搞定它。我覺得這是值得尊敬的。

“要對自己的不完美負責。程式碼中難免會出現bug，但這並不意味著你不用對他們負責，沒人能夠寫出完美的軟體，但並不表示你不用對不完美負責。”這是對於“我們要追求完美？”的答覆。這時候Bob大叔對於專業人士做了個定義“所謂的專業人士，就是對自己犯下的錯誤負責的人，哪怕那些錯誤實際上是在所難免的”。

問題：什麼樣的程式碼是有缺陷的呢？

答：那些你沒有把握的程式碼都是。在日常的開發中，為了快速響應需求，我們使用了大量的第三方工具或者開源包，但是我們又對於這些缺乏瞭解，自然就對於程式碼沒有十足的把握。看來要有把握，還是有必要把程式碼的上線資訊梳理清楚。

問題：你怎麼知道程式碼能否正常執行？

答：很簡單，測試！一遍遍地測，翻來覆去、顛來倒去的測，使出渾身解數來測試。 而我們可能沒有那麼多時間，這時候就需要自動化測試。“如果那套測試可以隨時快速執行，那麼你根本不會害怕修改任何程式碼”，這個在工作中確實感受到了，有時候改了東西，不敢釋出，沒有詳細測試過，心裡還是沒有底，不過能夠實現自動化測試，需要付出的成本也是很高的，我們是測試人員負責維護自動化持續迴歸的指令碼，每天如果有失敗的話就需要看為啥失敗，需要很多時間，而大多數情況下排查發現的問題是構造基礎資料出現了問題，或許，自動化也需要一種權衡吧。

“把持續整合看成重要的事情”，持續整合不應該失敗，如果失敗了，團隊裡的所有人都應該停下手裡的活，看看如何讓測試通過。

“不能銘記過去的人，註定重蹈先人的覆轍”，是Bob在列舉每個軟體開發人員必須精通的事項前引用的話。設計模式、設計原則、結構化分析、結構化設計、測試驅動開發、物件導向的設計、持續整合以及各種專業圖，這些都需要啊。做程式設計師好不容易啊。

“能就是能，不能就是不能。不要說‘試試看’。”

“專業人士敢於說明真相而不屈從於權勢。專業人士有勇氣對他們的經理說不”。“不努力沒有權利說不，勞工或許也對說不有所顧忌，但是專業人士應該懂得說不”。

當被要求提前完成任務或者交工的時候，如果答覆是“試試看”，其實以比較危險的，之前沒有思考過這個問題，這本書有有完整的解釋。“許諾嘗試，就意味著承認之前自己未盡全力，承認自己還有餘力可施”。

問題：如何識別工作中的“缺乏承諾”？

答：在談話中識別關鍵字，“需要應當”、“希望但願”、“讓我們”。

“如果你不盡早告訴他人可能的問題，就錯失了讓他們幫助你達成目標、兌現承諾的機會”，這一點表示深深的認同，希望得到別人的幫助，最起碼也要告訴別人遇到的問題是啥吧。

“專業人士對自己的能力極限瞭如指掌，他們十分清楚自己還能保持效率加班多長時間，也非常明白要付出的代價。”，“專業人士不需要對所有的請求回答是，不過，他們應該努力尋找創新的方法，儘可能的做到有求必應。當專業人士給出肯定回答時，他們使用承諾用語，以確保各方能明白無誤的理解承諾內容”。

“如果感到疲勞或者心煩意亂，千萬不要編碼”，強而為之，最終只能再回頭返工。相反，要找到一種方法來消除干擾，讓心緒平靜下來。

有時候遇到場景，死活寫不出程式碼，Bob提供了一種方法，他自己覺得屢試不爽，“找一個搭檔結對程式設計”。其實就我的實踐來看，兩個人一起寫程式碼，應該是感覺比較不爽的事情，但是，我覺得在處理線上問題的時候，找個同事一起處理可能效果比較好。

“軟體開發是一場馬拉松，而不是短跑衝刺”，你無法全程一直以最快的速度衝刺來贏得比賽，只有通過儲存體力和維持節奏取勝。

保持不落伍的一種方法就是為開源專案貢獻程式碼，就像律師和醫生參加公益活動一樣。程式設計師用自己的時間來練習，老闆的職責不包括避免你的技術落伍，也不包括為你打造一份好看的履歷。

做業務的人和寫程式的人都容易陷入一個陷阱，即過早進行精細化。業務方還沒有啟動專案，就要精確知道最後能得到什麼，開發人員還沒有評估整個專案，就希望精確知道要交付什麼。雙方都貪求不現實的精確性，而且經常願意花大價錢來追求這種精確。需求是一定會變化，所以追求那種精確性是徒勞的。

交流細節資訊是件麻煩事。尤其是開發方和業務方交流關於程式細節時，更是如此。通常，雙方握手言歡，以為其他人都明白自己的意思。雙方以為取得了共識，然後帶著截然不同的想法離開，這種事情太平常不過了。解決這種資訊不同步問題很簡單，就是編寫驗收測試。

關於會議，有兩條真理，一個是會議是必須的，一個是會議浪費了大量的時間。受到邀請的會議，沒有必要全部參加，參加的會議太多，其實只能證明你不夠專業。如果覺得會議是在浪費時間，那就應該禮貌的退出會議。

凡是不能再5分鐘內解決的爭論，就不能靠辯說解決。唯一的出路，用資料說話。有些共識，一些人表現非常被動，他們同意結束爭論，之後卻消極對待結果，拒絕為解決問題出一份力。千萬不要這麼做，如果你同意了，必須拿出行動來。

程式設計是需要持續投入精力和注意力的智力活動。注意力是稀缺資源，如果你用光了自己的注意力點數，必須花一個小時或者更多的時間做不需要注意力的事情，來補充它。

番茄時間是有成率的，你可以真正做點事情，用於應付干擾、參加會議、休息等非工作事宜的時間，則屬於非番茄時間。番茄工作法的真正好處在於，在25分鐘的高效時間段裡，你有底氣拒絕任何干擾。

業務方覺得預估就是承諾，開發人員覺得預估就是猜測，兩者相差迥異。承諾是必須做到的，如果你承諾在特定時間完成，就必須按時完成。專業人員不隨便承諾，除非他們確切知道可以完成。

預估是非常容易出錯的，所以才叫預估。控制錯誤的辦法之一就是使用大數定律。把大任務分成許多小任務，分開預估再加總，結果會比單獨評估大任務要準確很多。

計算機方面的技術書籍很多的，一個主題就有很多，但是書寫程式設計師工作和人生的書卻是很少。希望後面這類的書越來越多。

本文作者： iamzhongyong
原文地址： http://blog.csdn.net/iamzhongyong/article/details/9297499