程式設計師的職業素養（摘要）
————————————————————————
————————————————————————
一
專業主義的精髓就在於將公司的利益視同個人的利益。
不能忽略完整的測試環節，否則就交付軟體是不負責任的。
為自己的不完美負責。程式碼難免出現bug，但這並不意味著你不用對它們負責。
讓QA找不出任何問題。把自己沒把握的程式碼傳送給QA是不專業的，違背了“不行損害之事”的原則。
有些程式碼很難測試，是因為設計時就沒考慮如何測試。唯一的解決辦法就是要設計易於測試的程式碼，最好事先寫測試，再寫要測的程式碼。
專業開發人員不會為了釋出功能而破壞結構。結構良好的程式碼更靈活。
所有軟體專案的根本指導原則是，軟體要易於修改。
如果希望自己的軟體靈活可變，那就應該時常修改它。
職業發展是你自己的事。僱主沒有義務確保你在職場能夠立於不敗之地。
僱主出了錢，你必須付出時間和精力。一週工作60個小時，前40小時給僱主，後20小時是給自己的。你應該看書，練習，學習，做一些提升職業能力的事情。
每天大概是3個小時是給自己提升的，你可以在路上學習，在公交學習等，利用一些時間碎片。
一週有168小時，給你僱主40小時，為自己的職業發展留20小時，剩下的108小時再留56小時給睡眠，那麼還剩52小時可做其他的事。
其實這樣讓你免於枯竭匱乏，假設你熱愛軟體開發，渴望成為專業開發者，在那20個小時裡，就應該做能夠激發，強化你的熱情的事，那20小時是充滿樂趣！
IT行業發展迅猛，要時常瞭解自己的領域，堅持廣泛學習才不至於落伍，但並不意味著忘掉過去。別忘了桑塔亞納的詛咒：“不能銘記過去的人，註定重蹈先人的覆轍”。
每個軟體開發人員必須精通的事項：
設計模式。GOF書中的全部24種模式。
設計原則。必須瞭解SOLID原則，而且深刻了解元件設計原則。
方法。必須理解XP，Scrum，精益，看板，瀑布，結構化分析及結構化設計等。
實踐。必須掌握測試驅動開發，面向物件設計，結構化程式設計，持續整合和結對程式設計。
工件。必須瞭解如何使用UML圖，DFD圖，結構圖，Petri網路圖，狀態遷移圖表，流程圖和決策表。
練習。業精於勤，真正專業人士往往勤學苦幹，以求得自身技能的純屬精煉。
合作。學習的第二個最佳方法就是與他人合作。從彼此身上學到很多東西，而且能在更短的時間內更高質量地完成更多工作。
並不是要花全部時間一直和別人共事，獨處的時間也更重要。
輔導。教學相長，想迅速牢固地掌握某些事實和觀念，最好的方法就是與由你負責的人交流這些內容。傳道授業中，導師也會從中受益。
瞭解業務領域。瞭解自己所開發專案的業務領域，瞭解該領域的基本架構和基本知識，一邊同客戶和使用者訪談。花時間與業內專家交流，瞭解他們的原則和價值觀念。
僱主的問題就是你的問題。弄明白這些問題，並尋求最佳解決方案。開發系統時，站在僱主的角度思考，確保開發的功能真正滿足僱主的需要。
二
許諾“嘗試”，就意味著你承認自己之前未盡全力，承認自己還有餘力可施。
只要你許諾會去“嘗試”，你其實是在承諾你會確保成功。
從本質上講，承諾“嘗試”就是一種不誠實的表現。你這麼做的原因，可能是為了護住面子和避免衝突。
堅守專業主義精神，不能為了趕工而寫出糟糕的程式碼，如果不能做到，當初就應該說“不”。
三
口頭上說。心裡認真。付諸行動。
做出承諾，包含三個步驟。
1口頭上說自己將會去做。
2心裡認真對待做出的承諾。
3真正付諸行動。
沒有做到自己對他人之前的承諾，會讓自己難堪。言必信，行必果。
你只能承諾自己能完全控制的事。
如果你不盡早告訴別人可能的問題，就錯失了讓他們幫助你達成目標，兌現承諾的機會。
若為了趕工完成任務，週六日加班，那麼要求週三才上班也是應該的。
四
編碼是一項頗具挑戰也十分累人的智力活動。相比其他，編碼要求更加聚精會神。
自己的程式碼要讓其他人看得懂。
如果感到疲勞或者心煩意亂，千萬不要編碼。
奉獻精神和職業素養，更多意義上指要遵循紀律原則而非成為長時間工作的工作狂。
要確保自己已經將睡眠，健康和生活方式調整到最佳狀況，這樣才能做到每天的8個小時工作時間內全力以赴。
焦慮的時候不要急著編碼，否則那些程式碼都會很糟糕，要先處理或降低一下自己的焦慮情緒。
聽音樂是可能無法寫好程式碼。事實上，聽音樂似乎消耗了至為重要的一部分腦力資源，而這些資源本該用於編碼設計良好的整潔程式碼。
中斷無法避免，總有人會打斷你，消耗你的時間。發生這種情況時要記住一點，也許下次也會輪到你去打斷別人請求幫助。
因此，禮貌地表現出樂於助人的態度才是專業的態度。
“創造性輸出”依賴於“創造性輸入”。
軟體開發人員或許會認為除錯時間並非編碼時間，但對公司來說，除錯時間和編碼時間是一樣昂貴的。
當大腦已經無法正常思考卻硬逼自己在深夜還加班解決問題，你只會把自己折騰得更累，回家洗澡之類的反而會豁然開朗。
當碰到困難而受阻時，當你感到疲倦時，就離開一會兒，讓富有創造力的潛意識接管問題。
精力分配得當，你將能在更短的時間內以更少的精力完成更多的事情。讓自己保持好節奏，讓團隊保持好節奏。
瞭解你的創造力和智力執行的模式，充分發揮它們的優勢而非與之背道而馳。
埋頭忙於解決問題時，有時候可能會由於和問題貼得太近，無法看清楚所有的可選項。由於大腦中富有創造力的部分被緊張的專注力所抑制，你會錯過漂亮的解決方案。
互相幫助是每個程式設計師的職責所在。作為專業人士，要以隨時幫助別人為榮。
當然你需要獨處時間，你可以直接並禮貌的告訴別人你在某個時間段不希望被人打擾。
接受他人的幫助。如果有人向你伸出援手，要誠摯接受，心懷感激地接受幫助並誠意合作。
不要因為自己進度壓力很大，就推開伸來的援手。不妨給他半個小時的時間。如果到時那個人不能真正幫到你，再禮貌地致歉用感謝結束談話也不遲。要記住，如同要以樂於助人為榮一樣，也要以樂於接受別人的幫助為榮。
要學會如何求助。如果幫助唾手可得卻讓自己一個人堵在那兒，是很不專業的表現。
輔導缺乏經驗的程式設計師是那些經驗豐富的程式設計師的職責。向資深導師尋求輔導也是年輕程式設計師的專業職責。
五
測試驅動開
TDD三項法則：
1在編好失敗單元測試之前，不要編寫任何產品程式碼。
2只要有一個單元測試失敗了，就不要再寫測試程式碼；無法通過編譯也是一種失敗情況。
3產品程式碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多寫。
TDD是專業人士的選擇。它是一項能夠提升程式碼確定性，給程式設計師鼓勵，降低程式碼缺陷率，優化文件和設計的原則。對TDD的各項嘗試表明，不使用TDD就說明你可能還不夠專業。
有些情況下，TDD也會有侷限。
六
保持不落伍的一種方法是為開源專案貢獻程式碼。
職業程式設計師是用自己的時間來練習。老闆的職責不包括避免你的技術落伍，也不包括為你打造一份好看的履歷。
既然你是用自己的時間練習，就不必限制在老闆規定的語言和平臺。可以選擇你喜歡的語言，練習你喜歡的技術。
七
八
九
受到邀請的會議沒有必要全部參加。參加的會議太多，其實只能證明你不夠專業。理智使用時間，謹慎選擇，禮貌拒絕。
邀請你參加會議的人並不負責管理你的時間，為時間負責的只有你。
領導最重要的責任之一，就是幫你從某些會議脫身。好的領導一定會主動維護你拒絕出席的決定，因為他和你一樣關心你的時間。
如果會議讓人厭煩，就離席。如果你發現參加某個會議是在浪費時間，就應當想個禮貌的方法退出來。
重要的是，你應當明白，繼續呆在會議室裡是浪費時間；繼續參加對你沒有太多意義的會議，是不專業的行為。
如果受到會議邀請，務必弄清楚指定的議題是什麼，每個議題花多長時間沒要取得什麼成果。如果得不到確切的答案，你可以禮貌拒絕。
專業開發人員會安排好他們的睡眠，保證清晨有飽滿的注意力去上班。
運動需要肌肉的注意力，而程式設計需要的是心智的注意力。肌肉注意力有助於改善心智注意力。
時間拆分與番茄工作法。
專業開發人員會評估每個任務的優先順序，排除個人喜好和需要，按照真實的緊急程度來執行任務。
選擇了走不通的技術道路，你對這個決定越是堅持，浪費時間就越多。
專業開發人員不會執拗於某個不容放棄的主意，他們會保持開放的頭腦來聽取其他意見，讓自己有多種選擇，一旦看清楚，就會避開。
十
專業開發人員能夠清楚區分預估和承諾。只有在確切知道可以完成的前提下，他們才會給出承諾。而且會盡可能清楚說明預估的概率分佈，這樣主管就可以做出合適的計劃。
大多數情況下，專業人士都不會給出確切的承諾，而是提供概率預估，來描述期望完成時間及可能的變數。
十一
即使有壓力，專業人士也會冷靜果斷。儘管壓力不斷增大，他仍然會堅守所受的訓練和紀律，他知道這些是他賴以戰勝有最後期限和承諾所帶來的壓力感的最好方法。
快速前進確保最後期限的方法，便是保持整潔。專業人士不會為了快點前進而亂來。髒亂只會導致緩慢。
觀察自己在危機時刻的反應，就可以瞭解自己的信念。如果在危機中依然遵循著你守持的紀律，就說明你確信這些紀律。
如果在平常時候你會注意保持程式碼整潔，但在危機時刻你卻產出混亂的程式碼，就說明你並不真正相信混亂會導致速度下降。
如果你遵守的紀律原則是工作的最佳方式，那麼即使是深度危機中，也要堅決秉持這些紀律原則。
十二
專業程式設計師最糟糕的表現就是兩耳不聞窗外事，只顧一頭將自己埋在技術堆裡，甚至連公司業務火燒眉毛行將崩潰了也不聞不問。
你的工作職責就是要讓業務免於陷入困頓，讓公司可以長久發展下去。
專業程式設計師會花時間去理解業務。他們會和使用者討論他們正在使用的軟體，會和銷售人員與市場人員討論所遭遇的問題，會和經理們溝通，明確團隊的短期目標和長期目標。
不正常的團隊最糟糕的症狀是，每個程式設計師在自己程式碼周邊築起一道高牆，拒絕讓其他程式設計師接觸到這些程式碼。
這樣會造成許多重複程式碼，模組間的介面完全是雜亂混淆而非正交的。
將程式碼所有權的各種隔斷全部打破，由整個團隊共同擁有全部程式碼的做法，相較於此要好得多。
專業開發人員不會阻止別人修改程式碼的。他們通過合作來達到學習的目的。
十三
十四
計算機科班畢業生的質量一直令我頗感失望。究其原因，並不是這些畢業生不夠聰明或缺乏天份，而是由於大學並沒有教授真正的程式設計之道。
我們今天的做法和我所提倡的理想化的學徒制程式，這兩者之間的主要差異在於技術方面的傳授，培訓，督導和檢查。
觀念上最大差別在於，專業主義價值觀和技術敏銳度需要進行不斷的傳授，培育，滋養和文火慢燉，直至其深植入文化當中。
我們當前的做法之所以傳承無力， 主要是因為其中缺少了資深人士輔導新人向其傳授技藝的環節。
------------------------------------------------------------------------------------------------------------------
編輯推薦
程式設計大師Bob大叔40年程式設計生涯心得體會講解成為真正專業程式設計師所需態度原則業界權威好評，廣受讚譽助您職業生涯邁上更高臺階
媒體推薦
Bob大叔的這本新作又一次擡高了專業程式設計師的門檻，指出了他們需要在歷練尚淺的軟體開發職業生涯中需要不斷精進的內容。——Markus Gartner,it-agile公司資深軟體開發者有一些技術書頗具啟發與教益，有一些則讀來輕鬆喜悅且富有趣味，但很少有技術書籍能夠同時兼具所有這四個特色。我感覺Martin所有的書都可歸入此列。
作者簡介
Robert C.Martin世界級軟體開發大師，設計模式和敏捷開發先驅，敏捷聯盟首任主席，C++ Report前主編，背後輩程式設計師尊稱為“Bob大叔”。20世紀70年代初成為職業程式設計師，後創辦Object Mentor公司並任總裁。Martin還是一名多產的作家，至今已發表數百篇文章、論文和部落格，除本書外，還著有《程式碼整潔之道》、《敏捷軟體開發：原則、模式和實踐》、《UML：Java程式設計師指南》等。他最近創辦了cleancoders.com網站，專為軟體開發人員提供教育視訊。
目錄
目 錄第1章 專業主義 11.1 清楚你要什麼 21.2 擔當責任 21.3 首先，不行損害之事 41.3.1 不要破壞軟體功能 41.3.2 不要破壞結構 71.4 職業道德 81.4.1 瞭解你的領域 101.4.2 堅持學習 111.4.3 練習 111.4.4 合作 121.4.5 輔導 121.4.6 瞭解業務領域 131.4.7 與僱主/客戶保持一致 131.4.8 謙遜 131.5 參考文獻 14第2章 說“不” 152.1 對抗角色 172.2 高風險時刻 202.3 要有團隊精神 222.3.1 試試看 242.3.2 消極對抗 252.4 說“是”的成本 272.5 如何寫出好程式碼 34第3章 說“是” 373.1 承諾用語 393.1.1 識別“缺乏承諾”的徵兆 403.1.2 真正的承諾聽起來是怎樣的 413.1.3 總結 433.2 學習如何說“是” 433.2.1 “試試”的另一面 433.2.2 堅守原則 443.3 結論 47第4章 編碼 484.1 做好準備 494.1.1 凌晨3點寫出的程式碼 504.1.2 焦慮時寫下的程式碼 514.2 流態區 534.2.1 音樂 544.2.2 中斷 554.3 阻塞 554.4 除錯 574.5 保持節奏 604.5.1 知道何時應該離開一會 604.5.2 開車回家路上 614.5.3 洗澡 614.6 進度延遲 614.6.1 期望 624.6.2 盲目衝刺 624.6.3 加班加點 634.6.4 交付失誤 634.6.5 定義“完成” 644.7 幫助 644.7.1 幫助他人 644.7.2 接受他人的幫助 654.7.3 輔導 664.8 參考文獻 66第5章 測試驅動開發 675.1 此事已有定論 695.2 TDD的三項法則 695.3 TDD的優勢 705.3.1 確定性 705.3.2 缺陷注入率 715.3.3 勇氣 715.3.4 文件 725.3.5 設計 725.3.6 專業人士的選擇 735.4 TDD的侷限 735.5 參考文獻 74第6章 練習 756.1 引子 756.1.1 10的22次方 766.1.2 轉變 776.2 程式設計柔道場 796.2.1 卡塔 806.2.2 瓦薩 816.2.3 自由練習 816.3 自身經驗的拓展 826.3.1 開源 826.3.2 關於練習的職業道德 826.4 結論 836.5 參考文獻 83第7章 驗收測試 847.1 需求的溝通 847.1.1 過早精細化 867.1.2 遲來的模糊性 877.2 驗收測試 897.2.1 “完成”的定義 897.2.2 溝通 917.2.3 自動化 927.2.4 額外工作 937.2.5 驗收測試什麼時候寫，由誰來寫 937.2.6 開發人員的角色 947.2.7 測試的協商與被動推進 957.2.8 驗收測試和單元測試 967.2.9 圖形介面及其他複雜因素 977.2.10 持續整合 987.3 結論 98第8章 測試策略 998.1 QA應該找不到任何錯誤 1008.1.1 QA也是團隊的一部分 1008.1.2 需求規約定義者 1008.1.3 特性描述者 1008.2 自動化測試金字塔 1018.2.1 單元測試 1018.2.2 元件測試 1028.2.3 整合測試 1038.2.4 系統測試 1048.2.5 人工探索式測試 1048.3 結論 1058.4 參考文獻 105第9章 時間管理 1069.1 會議 1079.1.1 拒絕 1079.1.2 離席 1089.1.3 確定議程與目標 1099.1.4 立會 1099.1.5 迭代計劃會議 1099.1.6 迭代回顧和DEMO展示 1109.1.7 爭論/反對 1109.2 注意力點數 1119.2.1 睡眠 1129.2.2 咖啡因 1129.2.3 恢復 1129.2.4 肌肉注意力 1129.2.5 輸入與輸出 1139.3 時間拆分和番茄工作法 1139.4 要避免的行為 1149.5 死衚衕 1159.6 泥潭 1159.7 結論 116第10章 預估 11710.1 什麼是預估 11910.1.1 承諾 11910.1.2 預估 12010.1.3 暗示性承諾 12110.2 PERT 12210.3 預估任務 12510.4 大數定律 12710.5 結論 12710.6 參考文獻 128第11章 壓力 12911.1 避免壓力 13111.1.1 承諾 13111.1.2 保持整潔 13211.1.3 危機中的紀律 13211.2 應對壓力 13311.2.1 不要驚慌失措 13311.2.2 溝通 13311.2.3 依靠你的紀律原則 13311.2.4 尋求幫助 13411.3 結論 134第12章 協作 13512.1 程式設計師與人 13712.1.1 程式設計師與僱主 13712.1.2 程式設計師與程式設計師 14012.2 小腦 14212.3 結論 143第13章 團隊與專案 14413.1 只是簡單混合嗎 14413.1.1 有凝聚力的團隊 14513.1.2 如何管理有凝聚力的團隊 14613.1.3 專案承包人的困境 14713.2 結論 14813.3 參考文獻 148第14章 輔導、學徒期與技藝 14914.1 失敗的學位教育 14914.2 輔導 15014.2.1 DIGI-COMP I, 我的第一臺計算機 15014.2.2 高中時代的ECP-18 15214.2.3 非常規輔導 15414.2.4 艱難的錘鍊 15514.3 學徒期 15614.3.1 軟體學徒期 15814.3.2 現實情況 15914.4 技藝 16014.5 結論 161附錄 工具 162