書籍地址：http://book.douban.com/subject/11614538/
一句話點評該書：Bob大叔的職業生涯經驗總結，現身說法，可信可敬！
（一）專業主義
（1）“專業主義”就意味着擔當責任；
（2）所謂專業人士，就是能對自己犯下的錯誤負責的人，哪怕那些錯誤實際上在所難免；
（3）你寫的每一行代碼都要測試。如果你希望自己的軟件靈活可變，那就應該時常修改它！
（4）每個專業人士必須精通的事項；
1）設計模式：必須能描述GOF書中全部24種模式，同時還要有POSA書中多數模式的實戰經驗；
2）設計原則：必須瞭解SOLID原則，而且要深刻理解組件設計原則；
3）方法：必須理解XP、Scrum、精益、看板、瀑布、結構化分析及結構化設計等；
4）實踐：必須掌握測試驅動開發、面向對象設計、結構化編程、持續集成和結對編程；
5）工件：必須瞭解如何使用UML圖、DFD圖、結構圖、Petri網格圖、狀態遷移圖、流程圖和決策表；
（5）堅持學習。
不寫代碼的架構師必然遭殃，他們很快會發現自己跟不上時代了；不學習新語言的程序員同樣會遭殃，他們只能眼睜睜看着軟件業徑直向前，把自己拋在後面；學不會新原則和技術的開發人員必將淪落，他們身邊的人都是益卓越；
（6）業精於勤。
我常用的一個技巧是重複做一些簡單練習：不妨早晚都個10分鐘的卡塔吧！學習的第二個最佳方法是與他人合作。
（7）每位專業軟件人員都有義務瞭解自己開發的解決方案所對應的業務領域；
（8）僱主的問題就是你的問題，每次開發系統，都應該站在僱主的角度來思考，確保開發的功能真正能滿足僱主需要；
（二）說“不”
（1）專業人士敢於說明真相而不屈從於權勢。專業人士有勇氣對他們的經理說“不”！
（2）最要說“不”的是那些高風險的關鍵時刻。越是關鍵時刻，“不”字就越具價值。
（3）許諾“嘗試”，就意味着你承認自己之前未盡全力，承認自己還有餘力可施。如果承諾嘗試，你其實也在承諾將改自己原來的方案。你是在承認原來的方案中存在不足。
（三）說“是”
（1）做出承諾包含三個步驟：
1）口頭上說自己將會去做；
2）心裏認真對待做出的承諾；
3）真正付諸行動；
（2）識別“缺乏承諾”的徵兆，注意搜尋如下詞語：“需要/應當”、“希望/但願”、“讓我們”
（3）真正的承諾是，你對自己將來做某件事做清晰的事實陳述，而且還明確說明了完成期限；
（4）如果你無法兌現承諾，那麼最重要的就是儘早向你的承諾對象發出預警、越快越好，越早越好；
（5）專業人士不需要對所有請求都回答“是”。不過，他們應該努力尋找創新的方法，儘可能做到有求必應。當專業人士結出肯定回答時，他們會使用承諾用語，以確保各方能明白無誤地理解承諾內容；
（四）編碼
（1）編碼原則
1）首先，代碼必須能夠正常工作；
2）代碼必須能夠幫你解決客戶提出的問題；
3）代碼必須要能和現有系統結合得天衣無縫；
4）其他程序員必須能讀懂你的代碼；
（2）如果感到疲勞或心煩意亂，千萬不要編碼。強而爲之，最終只能再回頭返工。相反，要找到一種方法來消除干擾，讓心緒平靜下來；
（3）結對是應對中斷的一種好方法，另一種有幫助的方法便是採用TDD；
（4）廣泛閱讀包括軟件、政治、生物、航天、物理、化學、數學等，能激發創造力：“創造性輸出”依賴於“創造性輸入”，創造力會激發創造力；
（5）軟件開發是一場馬拉松，而不是短跑衝刺。你無法全程一直以最快的速度衝刺來贏得比賽，只有通過保存體力和維持穩定節奏來取勝；
（6）管理延遲的訣竅，便是早期檢測和保持透明；
（五）測試驅動開發
（1）TDD的三項原則
1）在編好失敗單元測試之前，不要編寫任何產品代碼；
2）只要有一個單元測試失敗了，就不要再寫測試代碼，包括無法通過編譯；
3）產品代碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多寫；
（2）TDD是專業人士的選擇。它是一項能夠提升代碼確定性、給程序員鼓勵、降低代碼缺陷率、優化文檔和設計的原則。
（六）練習
（1）專業人士都需要藉助專門訓練來提升自己的技能；
（2）保持不落伍的一種方法是爲開源項目貢獻代碼；
（3）我的理解：練習就像是學生時代的課後作業，日事日畢，練習內容可包括：經典算法、常用數據結構、設計模式等；
（七）驗收測試
（1）做業務的人和寫程序的人都容易陷入一個陷阱，即過早進行精細化；
（2）驗收測試定義爲業務方與開發方合作編寫的測試，其目的在於確定需求已經完成；
（3）業務分析員測試“正確路徑”，以證明功能的業務價值；QA則測試“錯誤路徑”、邊界條件、異常、例外情況；
（4）實現某項功能的代碼，應該在對應的驗收測試完成後開始；
（5）驗收測試不是單元測試。單元測試是程序員寫給程序員的，它是正式的設計文檔，描述了底層結構及代碼的行爲；驗收測試是業務方寫給業務方的，它們是正式的需求文檔，描述了業務方認爲系統應該如何運行；
（6）整套持續集成系統應該由源代碼管理系統來觸發。只要有人提交了代碼，持續集成系統就會開始構建，並運行所有的測試，測試結果會用電子郵件發送給團隊所有人；
（八）測試策略
（1）開發小組要把“QA”應該找不到任何錯誤“作爲努力的目標；
（2）QA在團隊中扮演的是需求規約定義者和特性描述者；
（3）專業開發人員遵循測試驅動開發的要求來創建單元測試。專業開發團隊使用驗收測試定義系統需求，使用持續集成保證質量穩步提升；
（4）測試金字塔，由下至上的順序是：單元測試-->組件測試-->集成測試-->系統測試-->人工探索式測試，其中單元測試是基石。
（九）時間管理
（1）站立會議的核心：
1）我昨天干了什麼？
2）我今天打算做什麼？
3）我遇到了什麼問題？
（2）迭代計劃會議用來選擇在下一輪迭代中實現的開發任務；
（3）凡是不能在5分鐘內解決的爭論，都不能靠辯說來解決。這類爭論依據的不是事實，而是信念。唯一出路是，用數據說話。
（4）用番茄工作法管理時間。（呵，沒想到Bob大叔也用這個）
（5）睡眠的重要性怎麼強調都不爲過，保證7小時睡眠！
（6）要避免的行爲：優先級錯亂、死衚衕、泥潭；如果你掉進入坑裏，別繼續再挖！
（十）預估
（1）專業開發人員不隨便承諾，除非他們確切知道可以完成；
（2）專業開發人員能夠清楚區分預估和承諾。只有在確切知道可以完成的前提下，他們纔會給出承諾。此外，他們也會小心避免給出暗示性的承諾。他們儘可能清楚地說明預估的概率分佈，這樣主管就可以做出合適的計劃；
（3）預估實踐方法之三元分析法，即劃爲樂觀預估O、標稱預估N、悲觀預估P，結果u=(O+4N+P)/6；
（4）預估實踐方法之德爾菲法：一組人集合起來，討論某項任務，預估完成時間，然後重複”討論--預估“的過程，直到意見統一；
（5）預估是非常容易出錯的，控制錯誤的方法之一是大數定律：把大任務分成許多小任務，分開預估再加總。
（十一）壓力
（1）即使有壓力，專業開發人員也會冷靜果斷。儘管壓力不斷增大，他仍然會堅守所受的訓練和紀律，他知道這些是他賴以戰勝由最後期限和承諾所帶來的壓力感的最好方法；
（2）在壓力下保持冷靜的最好方式，便是規避會導致壓力的處境；
（3）避免壓力的方法
1）不做不切實際的承諾；
2）讓系統、代碼和設計儘可能整潔；
3）在危機中依然遵守紀律原則；
（4）應對壓力
1）避免孤注一擲的想法，魯莽倉促只會把你帶入更深的深淵。相反，要放鬆下來，對問題深思熟慮。
2）和團隊、主管溝通；
3）堅信並依靠你的紀律原則；
4）結對尋求幫助；
（十二）協作
（1）不正常的團隊最糟糕的症狀是，每個程序員在自己的代碼周邊築起一道高牆，拒絕讓其他程序員接觸到這些代碼；
（2）專業開發人員是不會阻止別人修改代碼的；期望擁有代碼的是整個團隊，而非個人；
（3）專業人士結對工作，是解決程序間合作的最有效方法，也是分享知識的最好途徑；
（4）最有效率最有效果的代碼複查方法，就是以互相協作的方式完成代碼編寫；
（十三）團隊與項目
（1）形成團隊是需要時間的。團隊成員需要首先建立關係。他們需要學習如何互相協作，需要了解彼此的癖好，強項、弱項，最終，才能凝聚成團隊。否則，那就是團伙，而非團隊！
（2）最理想的團隊是12人，7名程序員，2名測試人員，2名分析師和1名項目經理；
（3）創建有凝聚力的團隊，然後不斷地把新項目分派給他們，而不是圍繞項目來構建團隊；
（4）團隊對項目更難構建。因此，組建穩健的團隊，讓團隊在一個又一個項目中整體移動共同工作是較好的做法；
（十四）輔導、學徒期與技藝
（1）所謂大師
已經領導過多個重要軟件項目的程序員。一般說來，他們已經擁有10年以上的從業經驗，曾在多個不同類型的系統、語言和操作系統上工作過。他們懂得如何領導和協調多個團隊，他們是熟練的設計師和架構師，能夠遊刃有餘地編程。
（2）專業主義價值觀和技術敏銳度需要進行不斷地傳授、培育、滋養和文火慢燉，直至其深植入文化當中；
【Bob大叔使用的開發工具】
使用Git來管控源代碼，使用Tracker來管理Bug，使用Jenkins來進行持續構建，使用IntelliJ作爲集成開發環境，使用XUnit來做單元測試，使用FitNesse來做組件測試
【附Bob大叔不完全Resume】
（1）1968年自學計算機編程，時年15歲，學習PDP-8彙編器、FORTRAN、COBOL、PL/1；
（2）1970年，沒有上大學，被ASC公司聘爲程序員，時年17歲；
（3）1973年，20歲與妻子Ann
Marie永結連理，妻子那年剛18歲過去3天。Bob大叔深情地說：“38年來，她一直是我堅定不移的伴侶，是我的舵和我的帆，是我的愛與生命。我期待同她攜手再走40年！”看來，一個卓越的程序員，也一定是一個深愛妻子與家庭的人！這點倒是與我不謀而合！
（4）到目前爲止，Bob編了42年的程序，與妻子育有二女一子！
