題圖來自Pixabay

Chapter 1. 專業主義

作為一名“專業人士”，不僅僅是一種榮耀，它更多的意味著義務，正所謂欲戴王冠,必承其重。當項目中有某個“臨時工”犯了錯誤，他大可不必承擔責任，只需要攤攤手，說幾句自我安慰的話；如果是“職業”人員，你必須為自己寫的每一行代碼負責，出了bug必須承擔相應的責任。
“職業”的程序員也應當有自己的職業道德，Bob大叔把它概括為以下8點：

• 了解你的領域
• 堅持學習
• 練習
• 合作
• 輔導
• 了解業務領域
• 與雇主/客戶保持一致
• 謙遜

Chapter 2. Say No

職業的程序員敢于與現實抗爭，敢于說“不”。尤達說過：“能就是能，不能就是不能。不要說‘試試看’”。如果某項任務你無法勝任，拒絕接受總比臨近交付日期才告訴產品經理你無法完成好；同樣的，如果沒辦法在某個時間內完成，就不要說“試試看”。試試看意味著你會嘗試著去完成，而大多數人都是樂觀主義者，這樣說無異于一種承諾。礙于情面的人也許覺得不妥，需要指出的是：“say no”并不意味著拒絕合作，而且為了團隊更好的發展。

Chapter 3. Say Yes

如果你覺得“say no”讓你很難為情，那么，“say yes”（做出承諾）也很有挑戰性。做出承諾包含了三個步驟：

• 口頭上說自己將會去做
• 心里認真對待做出的承諾
• 真正付諸行動

“職業的”程序員對自己做出的承諾會做到言必行，行必果，甚至承擔相應的責任，職場上可不允許隨便說說而已。

Chapter 4. 編碼

“職業的”程序員應該具備良好的編碼能力。代碼要整潔、符合規范，特別是在趕進度的情況下。Bob大叔在《Clean Code》（《代碼的整潔之道》）中說到，一個外科醫生不會因為時間緊急而答應病人的請求——不要洗手就做手術，因為這樣并不是職業的做法（更別說犯罪）。同樣地，職業的程序員不會因為時間緊急就寫出混亂的代碼或者上百行代碼的函數，這樣談不上快，只會讓進度更加慢。整潔的代碼也需要從平時不斷的訓練養成，這方面的書有《The Art of Readable Code》、Bob大叔的《Clean Code》、《Code Complete》。

Chapter 5. 測試

Bob大叔的書有一個特點（雖然我只看過兩本…），他會在不經意中特別地插入測試方面的內容。看他的書都會對TDD有一定的了解，此處略去n個字……
不管是否采用TDD的方式，“職業的”程序員都必須具有一定的測試能力。最為開發人員，寫的最多就是單元測試，雖然單元測試不能保證程序一定不出錯，但是寫好的單測是對自己代碼負責的一種體現。如果代碼沒有測試過就簽入代碼庫，無異于放進去一個定時炸彈。《Code Complete》里面介紹了一些辦法，可以在寫更少量的單測的情況下覆蓋到更多的代碼，例如結構化的基礎測試。

Chapter 6. 預估

軟件開發過程中最常出現的問題就是延期交付，因為進度延遲往往導致開發人員需要連續的加班，甚至通宵達旦的趕進度，而這個日期很多時候都是由于項目組過于樂觀的預估。

• 時間預估——三元分析法
  三元分析法是1957年美國海軍的潛艇極地航行計劃中的一部分內容，是一種對預估的計算方法，這種技術簡單而有效，把預估變成概率分布。你可以更具三個數字預估某項任務：

  • O：樂觀預估。這是非常樂觀的數字，也就是我們經常說的最快時間，快到程序沒有異常，開發過程中不會出岔。實際上，為了保持樂觀預估有意義，這個數字對應的概率應當小于1%（正常分布下具體數字是3個西格瑪或者0.13%）。
  • N：標稱預估。這個數字概率最大。如果畫一張柱狀圖，標稱預估就是最高的那個。
  • P：悲觀預估。這是最糟糕的數字，因為它考慮到各種意外，比如颶風啊，戰爭啊。為了保證這個數字有意義，它的概率也應當小于1%。

  有了以上三個預估，我們可以這樣描述概率分布：
  μ = （O+4N+P）/ 6
  μ 是任務的期望完成時間。
  σ = （P - O）/ 6
  σ 是任務的概率分布的標準差，用來衡量不確定性。數字大就表示非常不確定。
  所以一項任務的預估時間就是 μ/σ 。

Chapter 7. 壓力

書中有一段描述：

你看見自己躺在一張手術臺上，以為外科醫生給你做開胸手術。醫生竭力挽救你的性命，但是時間有限……
你期望醫生的表現如何？你希望他冷靜、井井有條嗎？你希望他清楚準確地吩咐助手嗎？你希望他嚴格遵循當初訓練時的做法堅守手術規程嗎？
還是想讓他汗流浹背、咒罵之聲不斷？想讓他亂扔手術器械、把東西摔的哐當響嗎？想讓他滿腹怨氣責怪管理人員設定的不現實的手術時間，一直嚷嚷時間不夠用嗎？你期望他表現得像一名專業人士，還是像我們常見的某些開發人員的那種做派？

關于壓力，最好的做法就是避免壓力：

• 承諾：不要輕易做出承諾，承諾的時候也要正確地預估，避免過于樂觀。
• 保持整潔：快速前進確保最后期限的方法就是保持整潔。專業人士不會為了快點兒亂來。“快速但臟亂”是自相矛盾的說法。
• 危機中的紀律：Bob大叔說過，觀察自己在危機時刻中的反應就可以了解自己的信念。如果在危機中依然遵循你守持的紀律，就說明你確實相信那些紀律。選擇那些你在危機中依然會遵循的紀律原則，并且在所有工作中都遵守這些紀律。遵守這些紀律原則是避免陷入危機的最好途徑。

如果壓力已經產生，不可避免的，“職業”的做法是不要驚慌，而是從容不迫、努力尋找解決方案，同時尋求幫助。

Chapter 8. 協作

大多數軟件都是靠團隊開發出來的，單打獨斗與游離于團隊之外都是不專業的表現。即使是Linus Torvalds這種單兵作戰能力超強的，也需要一堆優秀程序員來幫忙維護Linux。想象一下deadline到來之前你拼了命趕進度，恨不得多找幾個人來幫忙，這時候你是堅定不移的相信團隊開發這個守則的。那為什么平時卻不肯相信？
協作主要有兩點：

• 與開發人員的協作：這要求我們按照規范寫好代碼、注釋和文檔，便于其他程序員更快理解。這也要求程序員要有良好的表達能力和寫作能力。Joel Spolsky在《軟件隨想錄》中給計算機系學生的建議中，第一條就是：畢業前練好寫作。
• 與雇主的協作：代碼應該是為了業務服務，有的開發人員只知道為了開發方便，隨意的砍需求，或者想出一些不切實際的想法。所以Joel的建議（3）是：畢業前學好微觀經濟學。