《程序員的職業素養》是編程大師Bob大叔40余年編程生涯的心得體會, 講解成為真正專業的程序員需要什么樣的態度、原則，需要采取什么樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為后來人引路，助其職業生涯邁上更高臺階。 《程序員的職業素養》適合所有程序員，也可供所有想成為具備職業素養的職場人士參考。
編程大師Bob大叔40年編程生涯心得體會
講解成為真正專業程序員所需態度原則
業界好評，廣受贊譽
助您職業生涯邁上更高臺階
Robert C. Martin，軟件開發大師，設計模式和敏捷開發先驅，敏捷聯盟首任主席，C++ Report 前主編，被后輩程序員尊稱為"Bob大叔"。20世紀70年代初成為職業程序員，后創辦Object Mentor公司并任總裁。Martin還是一名多產的作家，至今已發表數百篇文章、論文和博客，除本書外，還著有《代碼整潔之道》、《敏捷軟件開發：原則、模式和實踐》、《UML：Java程序員指南》等。他最近創辦了cleancoders.com網站，專為軟件開發人員提供教育視頻。
目 錄
第1章 專業主義 1
1.1 清楚你要什么 2
1.2 擔當責任 2
1.3 首先，不行損害之事 4
1.3.1 不要破壞軟件功能 4
1.3.2 不要破壞結構 7
1.4 職業道德 8
1.4.1 了解你的領域 10
1.4.2 堅持學習 11
1.4.3 練習 11
1.4.4 合作 12
1.4.5 輔導 12
1.4.6 了解業務領域 13
1.4.7 與雇主/客戶保持一致 13
1.4.8 謙遜 13
1.5 參考文獻 14
第2章 說"不" 15
2.1 對抗角色 17
2.2 高風險時刻 20
2.3 要有團隊精神 22
2.3.1 試試看 24
2.3.2 消極對抗 25
2.4 說"是"的成本 27
2.5 如何寫出好代碼 34
第3章 說"是" 37
3.1 保障用語 39
3.1.1 識別"缺乏保障"的征兆 40
3.1.2 真正的保障聽起來是怎樣的 41
3.1.3 總結 43
3.2 學習如何說"是" 43
3.2.1 "試試"的另一面 43
3.2.2 堅守原則 44
3.3 結論 47
第4章 編碼 48
4.1 做好準備 49
4.1.1 凌晨3點寫出的代碼 50
4.1.2 焦慮時寫下的代碼 51
4.2 流態區 53
4.2.1 音樂 54
4.2.2 中斷 55
4.3 阻塞 55
4.4 調試 57
4.5 保持節奏 60
4.5.1 知道何時應該離開一會 60
4.5.2 開車回家路上 61
4.5.3 洗澡 61
4.6 進度延遲 61
4.6.1 期望 62
4.6.2 盲目沖刺 62
4.6.3 加班加點 63
4.6.4 交付失誤 63
4.6.5 定義"完成" 64
4.7 幫助 64
4.7.1 幫助他人 64
4.7.2 接受他人的幫助 65
4.7.3 輔導 66
4.8 參考文獻 66
第5章 測試驅動開發 67
5.1 此事已有定論 69
5.2 TDD的三項法則 69
5.3 TDD的優勢 70
5.3.1 確定性 70
5.3.2 缺陷注入率 71
5.3.3 勇氣 71
5.3.4 文檔 72
5.3.5 設計 72
5.3.6 專業人士的選擇 73
5.4 TDD的局限 73
5.5 參考文獻 74
第6章 練習 75
6.1 引子 75
6.1.1 10的22次方 76
6.1.2 轉變 77
6.2 編程柔道場 79
6.2.1 卡塔 80
6.2.2 瓦薩 81
6.2.3 自由練習 81
6.3 自身經驗的拓展 82
6.3.1 開源 82
6.3.2 關于練習的職業道德 82
6.4 結論 83
6.5 參考文獻 83
第7章 驗收測試 84
7.1 需求的溝通 84
7.1.1 過早精細化 86
7.1.2 遲來的模糊性 87
7.2 驗收測試 89
7.2.1 "完成"的定義 89
7.2.2 溝通 91
7.2.3 自動化 92
7.2.4 額外工作 93
7.2.5 驗收測試什么時候寫，由誰來寫 93
7.2.6 開發人員的角色 94
7.2.7 測試的協商與被動推進 95
7.2.8 驗收測試和單元測試 96
7.2.9 圖形界面及其他復雜因素 97
7.2.10 持續集成 98
7.3 結論 98
第8章 測試策略 99
8.1 QA應該找不到任何錯誤 100
8.1.1 QA也是團隊的一部分 100
8.1.2 需求規約定義者 100
8.1.3 特性描述者 100
8.2 自動化測試金字塔 101
8.2.1 單元測試 101
8.2.2 組件測試 102
8.2.3 集成測試 103
8.2.4 系統測試 104
8.2.5 人工探索式測試 104
8.3 結論 105
8.4 參考文獻 105
第9章 時間管理 106
9.1 會議 107
9.1.1 拒絕 107
9.1.2 離席 108
9.1.3 確定議程與目標 109
9.1.4 立會 109
9.1.5 迭代計劃會議 109
9.1.6 迭代回顧和DEMO展示 110
9.1.7 爭論/反對 110
9.2 注意力點數 111
9.2.1 睡眠 112
9.2.2 咖啡因 112
9.2.3 恢復 112
9.2.4 肌肉注意力 112
9.2.5 輸入與輸出 113
9.3 時間拆分和番茄工作法 113
9.4 要避免的行為 114
9.5 死胡同 115
9.6 泥潭 115
9.7 結論 116
第10章 預估 117
10.1 什么是預估 119
10.1.1 保障 119
10.1.2 預估 120
10.1.3 暗示性保障 121
10.2 PERT 122
10.3 預估任務 125
10.4 大數定律 127
10.5 結論 127
10.6 參考文獻 128
第11章 壓力 129
11.1 避免壓力 131
11.1.1 保障 131
11.1.2 保持整潔 132
11.1.3 危機中的紀律 132
11.2 應對壓力 133
11.2.1 不要驚慌失措 133
11.2.2 溝通 133
11.2.3 依靠你的紀律原則 133
11.2.4 尋求幫助 134
11.3 結論 134
第12章 協作 135
12.1 程序員與人 137
12.1.1 程序員與雇主 137
12.1.2 程序員與程序員 140
12.2 小腦 142
12.3 結論 143
第13章 團隊與項目 144
13.1 只是簡單混合嗎 144
13.1.1 有凝聚力的團隊 145
13.1.2 如何管理有凝聚力的團隊 146
13.1.3 項目承包人的困境 147
13.2 結論 148
13.3 參考文獻 148
第14章 輔導、學徒期與技藝 149
14.1 失敗的學位教育 149
14.2 輔導 150
14.2.1 DIGI-COMP I, 我的及時臺計算機 150
14.2.2 高中時代的ECP-18 152
14.2.3 非常規輔導 154
14.2.4 艱難的錘煉 155
14.3 學徒期 156
14.3.1 軟件學徒期 158
14.3.2 現實情況 159
14.4 技藝 160
14.5 結論 161
附錄 工具 162
第1章
專業主義
"噢，笑吧，科廷，老伙計。這是上帝，或者也可以說是命運或自然，跟我們開的一個玩笑。不過，不管這家伙是誰或是什么，他真幽默！哈哈！"
——?霍華德，《碧血金沙》
這么說，你確實是想成為一名專業的軟件工程師，對吧？你希望能昂首挺胸向世界宣告"我是專業人士"，希望人們充滿敬意地注視著你，對你禮遇有加。希望母親們會指著你告訴自己的孩子要成為像你這樣的人。這些都是你想要的，對吧？
1.1 清楚你要什么
"專業主義"有很深的含義，它不但象征著榮譽與驕傲，而且明確意味著責任與義務。這兩者密切相關，因為從你無法負責的事情上不可能獲得榮譽與驕傲。
做個非專業人士可輕松多了。非專業人士不需要為自己所做的工作負責，他們大可把責任推給雇主。如果非專業人士把事情搞砸了，收拾攤子的往往是雇主；而專業人士如果犯了錯，只好自己收拾殘局。
如果你不小心放過了某個模塊里的一個bug，以致公司損失了1萬美元，結果將會怎樣呢？非專業人士會聳聳肩說："狀況總是難免的嘛。"然后像沒事兒人一樣繼續寫下一個模塊。而專業人士會自己為公司的那1萬美元買單！
哇，自掏腰包？那可真讓人心疼唉！但專業人士就必須這么做。實際上，專業主義的精髓就在于將公司利益視同個人利益。看到了吧，"專業主義"就意味著擔當責任。
1.2 擔當責任
想必你讀過前面的引言了，對吧？如果沒有，趕緊翻回去讀一遍，因為本書將要講的內容，都在其營造的語境里展開。
我曾因不負責任嘗盡了苦頭，所以明白盡職盡責的重要意義。
那是1979年，當時我是一家叫Teradyne的公司的"負責工程師"，所負責的軟件控制著一個測量電話線路質量的小型機系統和微機系統，該系統的中央小型機通過帶寬為300波特的撥號電話線與幾十臺控制測量硬件的外圍微機連接在一起，程序是用匯編語言編寫的。
我們的客戶是各大電話公司的客服經理，他們每個人都負責10萬條甚至更多的電話線路。我的系統負責幫助這些服務區經理搶在客戶之前發現各種線路故障并及時修復。這可以減少客戶投訴率，以免對此做監測的公共設施委員會相應下調電話公司收取的服務費。簡單地說，這些系統極其重要。
每天晚上，這些系統都會運行"夜間例行程序"，即中央小型機會通知外圍微機對所控制的電話線路進行檢測；每天早上，中央計算機就能獲取故障線路清單及其故障特征。根據這些報告，各服務區經理會安排人員修復故障，這樣就不會有客戶投訴了。
一次，我對幾十個客戶推出了一版新。"推出"這詞可真是形象啊。我把軟件寫在磁帶上，就把這些帶子"推出"給客戶了。客戶載入這些磁帶，然后重啟系統。
這一新修復了幾個小故障，還增加了客戶要求的一項新功能。之前我們曾保障會在截止日期之前提供那項新功能。我連夜趕工，總算在約定日期前交付了磁帶。
兩天后，我接到現場服務經理Tom的電話，他告訴我已經有好幾個客戶投訴"夜間例行程序"沒能執行完成，他們沒收到任何報告。我不由心頭一沉：為了按時交付軟件，我沒測試"例程"。我測試了系統的其他大部分功能，但測試"例程"要費好幾個小時，而當時我又必須交付軟件。因為故障修復部分都不涉及"例程"部分的編碼，所以我也沒擔心會有什么不妥。
收不到夜間報告，問題可就大了。修理工們會一時無事可忙但隨后又要超負荷工作，而且，有些電話客戶也可能會在這期間發現故障并投訴。要是弄丟一晚的數據，某一服務區經理肯定會打電話臭罵Tom。
我啟動實驗室系統，加載新軟件，然后開始對"夜間例行程序"進行測試。幾小時后，運行中斷。"例程"運行失敗！如果我在匆忙交付軟件前對此進行測試，就不會發生服務區丟失數據的事了，服務區經理們這時也不會炮轟Tom了。
我打電話給Tom，說我能重現問題了。Tom告訴我其他大部分客戶也已經打電話抱怨了，并問我什么時候能解決問題。我說我也沒把握，但正在努力。同時我告訴他應該建議客戶倒回去使用舊版軟件。Tom發火了，說那對客戶來說無疑是個雙重打擊，因為客戶不僅為此丟失了一整個晚上的數據，而且還無法使用事先保障的新功能。
故障排查非常困難，每次測試就要好幾個小時。及時次修復失敗了。第二次也沒能成功。我試了好幾次，等我發現問題所在時，好幾天已過去了。這期間，Tom每隔幾小時就打電話問我問題什么時候能解決，他也沒少讓我聽那些服務區經理對他喋喋不休的抱怨，并一再告訴我讓那些客戶重新起用舊軟件令他多么尷尬。
，我終于找出了缺陷所在，重新交付修復了問題的新程序，一切恢復正常。Tom也平靜下來，不再提這段插曲，畢竟，他不是我的上司。事后，我的老板過來對我說："你好別再犯同樣的錯誤。"我只能默默地點點頭。
經過反省，我意識到未對"例程"進行測試就交付軟件是不負責任的。為了如期交付產品，我忽略了測試環節，整個過程中只考慮要如何保全自己的顏面，卻沒顧及客戶和雇主的聲譽。我本該早點兒擔起責任，告訴Tom測試還未完成、自己不能按時交付產品。那么做絕非易事，Tom一定會不高興，但客戶不會丟失數據，客服經理也不會打電話來轟炸。
1.3 首先，不行損害之事
那么，我們該如何承擔責任呢？的確有一些原則可供參考。援引"希波克拉底誓言"或許顯得有點夸張，但沒有比這更好的引據了。的確，作為一名有追求有抱負的專業人士，他的首要職責與目標難道不正是盡其所能行有益之事嗎？
軟件開發人員能做出什么壞事呢？從純軟件角度看，他可以破壞軟件的功能與架構。我們會探討如何避免帶來這些破壞。
1.3.1 不要破壞軟件功能
顯然，我們希望軟件可以運行。沒錯，我們中的大部分人今天之所以是程序員，是因為我們曾帶來了可用的軟件，而且希望能再度體驗那種成功創作的喜悅。但希望軟件有用的不單單是我們，客戶和雇主也希望它們能用。是啊，他們出錢，讓我們去開發那些能按照他們意愿運行的軟件。
開發的軟件有bug會損害軟件的功能。因此，要做得專業，就不能留下bug。
"等等！"你肯定會說，"可是那是不可能的呀。軟件開發太復雜了，怎么可能會沒bug呢！"
當然，你說的沒錯。軟件開發太復雜了，不可能沒什么bug。但很不幸，這并不能為你開脫。人體太復雜了，不可能盡知其全部，但醫生仍誓言不傷害病人。如果他們都不拿"人體的復雜性"作托辭，我們又怎么能開脫自己的責任呢？
"你的意思是我們要追求嘍？"你可能會這樣抬杠吧？
不，我其實是想告訴你，要對自己的不負責。代碼中難免會出現bug，但這并不意味著你不用對它們負責；沒人能寫出的軟件，但這并不表示你不用對不負責。
所謂專業人士，就是能對自己犯下的錯誤負責的人，哪怕那些錯誤實際上在所難免。所以，雄心勃勃的專業人士們，你們要練習的及時件事就是"道歉"。道歉是必要的，但還不夠。你不能一而再、再而三地犯相同的錯誤。職業經驗多了之后，你的失誤率應該快速減少，甚至漸近于零。失誤率永遠不可能等于零，但你有責任讓它無限接近零。
1. 讓QA找不出任何問題
因此，軟件時，你應該確保QA找不出任何問題。故意發送明知有缺陷的代碼，這種做法是極其不專業的。什么樣的代碼是有缺陷的呢？那些你沒把握的代碼都是！
有些家伙會把QA當作抓蟲機器看待。他們把自己沒有全盤檢查過的代碼發送過去，想等QA找出bug再反饋回來。沒錯，有些公司確實按照所發現的bug數來獎勵測試人員，揪出的bug越多，獎金越多。
且不說這么做是否會大幅增加公司成本，嚴重損害軟件，是否會破壞計劃并讓企業對開發小組的信心打折扣，也不去評判這么做是否等同于懶惰失職，把自己沒把握的代碼發送給QA這么做本身就是不專業的。這違背了"不行損害之事"的原則。
QA會發現bug嗎？可能會吧，所以，準備好道歉吧，然后反思那些bug是怎么逃過你的注意的，想辦法防止它再次出現。
每次QA找出問題時，更糟糕的是用戶找出問題時，你都該震驚羞愧，并決心以此為戒。
2. 要確信代碼正常運行
你怎么知道代碼能否常運行呢？很簡單，測試！一遍遍地測，翻來覆去、顛來倒去地測，使出渾身解數來測！
你或許會擔心這么狂測代碼會占用很多時間，畢竟，你還要趕進度，要在截止日期前完工。如果不停地花時間做測試，你就沒時間寫別的代碼了。言之有理！所以要實行自動化測試。寫一些隨時都能運行的單元測試，然后盡可能多地執行這些測試。
要用這些自動化單元測試去測多少代碼呢？還要說嗎？全部！全部都要測！
我是在建議進行百分百測試覆蓋嗎？不，我不是在建議，我是在要求！你寫的每一行代碼都要測試。完畢！
這是不是不切實際？當然不是。你寫代碼是因為想執行它，如果你希望代碼可以執行，那你就該知道它是否可行。而要知道它是否可行，就一定要對它進行測試。
我是開源項目FitNesse的主要貢獻者和代碼提交者。在寫作本書的時候，FitNesse的代碼有6萬多行。在這6萬行代碼中有2000多個單元測試，共2.6萬多行。Emma的報告顯示，這2000多個測試對代碼的覆蓋率約為90%。
為什么只有90%呢？因為Emma會忽略一些執行的代碼。我確信實際的覆蓋率會比90%高許多。能達到嗎？不，達不到，只是個理想值。
但是有些代碼不是很難測試嗎？是的，但之所以很難測試，是因為設計時就沒考慮如何測試。的解決辦法就是要設計易于測試的代碼，好是先寫測試，再寫要測的代碼。
這一方法叫做測試驅動開發(TDD)，我們在隨后的章節里會繼續談到。
3. 自動化QA
FitNesse的整個QA流程即是執行單元測試和驗收測試。如果這些測試通過了，我就會軟件。這意味著我的QA流程大概需要3分鐘，只要我想要，可以隨時執行完整的測試流程。
沒錯，FitNesse即使有bug也不是什么人命關天的事，也不會有人為此損失幾百萬美元。值得一提的是FitNesse用戶上萬，但它的bug列表卻很短。
當然，也不排除有些系統因其任務極其關鍵特殊，不能只靠簡短的自動化測試來判斷軟件是否已經足夠高質量，是否可以投入使用。而且，作為開發人員，你需要有個相對迅捷的機制，以此判斷所寫的代碼可否正常工作，并且不會干擾系統的其他部分。因此，你的自動化測試至少要能夠讓你知道，你的系統很有可能通過QA的測試。
1.3.2 不要破壞結構
成熟的專業開發人員知道，聰明人不會為了新功能而破壞結構。結構良好的代碼更靈活。以犧牲結構為代價，得不償失，將來必追悔莫及。
所有軟件項目的根本指導原則是，軟件要易于修改。如果違背這條原則搭建僵化的結構，就破壞了構筑整個行業的經濟模型。
簡言之，你必須保障，不需太高代價就可以。
不幸的是，實在是已有太多的項目因結構糟糕而深陷失敗的泥潭。那些曾經只要幾天就能完成的任務現在需要耗費幾周甚至幾個月的時間。急于重新樹立威望的管理層于是聘來更多的開發人員來加快項目進度，但這些開發人員只會進一步破壞結構，亂上添亂。
描述如何創建靈活可維護的結構的軟件設計原則和模式已經有許多了。專業的軟件開發人員會牢記這些原則和模式，并在開發軟件時認真遵循。但是其中有一條實在是沒幾個軟件開發人員會認真照做，那就是，如果你希望自己的軟件靈活可變，那就應該時常修改它！
要想證明軟件易于修改，辦法就是做些實際的修改。如果發現這些改動并不像你預想的那樣簡單，你便應該改進設計，使后續修改變簡單。
該在什么時候做這些簡單的小修改呢？隨時！關注哪個模塊，就對它做點簡單的修改來改進結構。每次通讀代碼的時候，也可以不時調整一下結構。
這一策略有時也叫"無情重構"，我把它叫作"童子軍訓練守則"：對每個模塊，每檢入一次代碼，就要讓它比上次檢出時變得更為簡潔。每次讀代碼，都別忘了進行點滴的改善。
這與大多數人對軟件的理解相反。他們認為對可工作軟件不斷地做一系列修改是危險的。錯！讓軟件保持固定不變才是危險的！如果一直不重構代碼，等到不得不重構時，你就會發現代碼已經"僵化了"。
為什么大多數開發人員不敢不斷修改他的代碼呢？因為他們害怕會改壞代碼！為什么會有這樣的擔心呢？因為他們沒做過測試。
話題又回到測試上來了。如果你有一套覆蓋了全部代碼的自動化測試，如果那套測試可以隨時快速執行，那么你根本不會害怕修改代碼。怎樣才能證明你不怕修改代碼呢？那就是，你一直在改。
專業開發人員對自己的代碼和測試極有把握，他們會極其瘋狂隨意地做各種修改。他們敢于隨心所欲修改類的名稱。在通讀代碼時，如果發現一個冗長的方法，他們肯定會將它拆分，重新組織。他們還會把switch語句改為多態結構，或者將繼承層次重構成一條"命令鏈"。簡單地說，他們對待代碼，就如同雕塑家對待泥巴那樣，要對它進行不斷的變形與塑造。
1.4 職業道德
職業發展是你自己的事。雇主沒有義務確保你在職場能夠立于不敗之地，也沒義務培訓你，送你參加各種會議或給你買各種書籍充電。這些都是你自己的事。將自己的職業發展寄希望于雇主的軟件開發人員將會很慘。
有些雇主愿意為員工買各種書籍或送員工參加各種培訓課程和會議。那樣挺不錯的，說明他們待你不薄。但可千萬別就此認為這些是雇主該做的。如果他們不為你做這些，你就該自己想辦法去做。
另外，雇主也沒義務給你留學習時間。有些雇主會這么做，有些甚至要求你這么做。但是還是那句話，他們待你不薄，你應該適當表示感激。因為這些優待不是你理所當然就該享有的。
雇主出了錢，你必須付出時間和精力。為了說明問題，就用一周工作40小時的美國標準來做參照吧。這40小時應該用來解決雇主的問題，而不是你自己的問題。
你應該計劃每周工作60小時。前40小時是給雇主的，后20小時是給自己的。在這剩余的20小時里，你應該看書、練習、學習，或者做其他能提升職業能力的事情。
你肯定會說："那我的家庭該怎么辦？還有我的生活呢？難道我就該為雇主犧牲這些嗎？"
在此，我不是說要占用你全部的業余時間。我是指每周額外增加20小時，也就是大約每天3小時。如果你在午飯時間看看書，在通勤路上聽聽播客，花90分鐘學一門新的語言，那么你就都能兼顧到了。
做個簡單的計算吧。一周有168小時，給你的雇主40小時，為自己的職業發展留20小時，剩下的108小時再留56小時給睡眠，那么還剩52小時可做其他的事呢。
或許你不愿那么勤勉。沒問題。只是那樣的話你也不能自視為專業人士了，因為所謂"術業有專攻"那也是需要投入時間去追求的。
或許你會覺得工作就該在上班時完成，不該再帶回家中。贊成！那20小時你不用為雇主工作。相反，你該為自己的職業發展工作。
有時這兩者并不矛盾，而是一致的。有時你為雇主做的工作讓你個人的職業發展受益匪淺，這種情況下，在那20小時里花點時間為雇主工作也是合理的。但別忘了，那20小時是為你自己的。它們將會讓你成為更有價值的專業人士。
或許你會覺得這樣做只會讓人精力枯竭。恰恰相反，這樣做其實能讓你免于枯竭匱乏。假設你是因為熱愛軟件而成為軟件開發者，渴望成為專業開發者的動力也正是來自對軟件的熱情，那么在那20小時里，就應該做能夠激發、強化你的熱情的事。那20小時應該充滿樂趣！
1.4.1 了解你的領域
你知道什么是N-S(Nassi-Schneiderman)圖表嗎？如果不知道，那為什么不了解一下呢？你知道"米利型"(Mealy)和"摩爾型"(Moore)這兩種狀態機的差別嗎？你應該知道的。你能不需查閱算法手冊就可寫出一個快速排序程序嗎？你知道"變換分析"(Transform Analysis)這個術語的意思嗎?你知道如何用數據流圖進行功能分解嗎？你知道"臨時傳遞數據"(Tramp Data)的意思嗎？你聽說過"耦合性"(Conascence)嗎？什么是Parnas表呢？
近50年來，各種觀點、實踐、技術、工具與術語在我們這一領域層出不窮。你對這些了解多少呢？如果想成為一名專業開發者，那你就得對其中的相當一大部分有所了解，而且要不斷擴展這一知識面。
為什么要了解這些呢？這一行業發展迅速，許多舊見解似乎也已經過時了，不是嗎？前半句似乎是顯而易見的。確實，行業正迅猛發展，而有趣的是，從多個方面來看，這種進展都只是很淺層的。沒錯，我們不再需要為拿到編譯結果苦等上24小時，我們也已經可以寫出吉字節級別的系統，我們置身覆蓋全球的網絡之中，各種信息唾手可得。但另一方面，我們還是跟50年前一樣，寫著各種if和while語句。所以，改變說多也多，說少也少。
舊見解過時了這種說法明顯是不對的。過去50年中產生的理念，已經過時的其實很少。有一部分理論確實在慢慢淡出，比如說"瀑布式開發"的理論確實不再流行了。但這并不表示我們不需要了解它，不需要知道他的長處和短處。
總的來說，那些在過去50年中來之不易的理念，絕大部分在今天仍像過去一樣富有價值，甚至寶貴了。
別忘了桑塔亞納的詛咒："不能銘記過去的人，注定重蹈先人的覆轍。"
下面列出了每個專業軟件開發人員必須精通的事項。
? 設計模式。必須能描述GOF書中的全部24種模式，同時還要有POSA書中的多數模式的實戰經驗。
? 設計原則。必須了解SOLID原則，而且要深刻理解組件設計原則。
? 方法。必須理解XP、Scrum、精益、看板、瀑布、結構化分析及結構化設計等。
? 實踐。必須掌握測試驅動開發、面向對象設計、結構化編程、持續集成和結對編程。
? 工件。必須了解如何使用UML圖、DFD圖、 結構圖、Petri網絡圖、狀態遷移圖表、流程圖和決策表。
1.4.2 堅持學習
軟件行業的飛速改變，意味著軟件開發人員必須堅持廣泛學習才不至于落伍。不寫代碼的架構師必然遭殃，他們很快會發現自己跟不上時代了；不學習新語言的程序員同樣會遭殃，他們只能眼睜睜看著軟件業徑直向前，把自己拋在后面；學不會新原則和技術的開發人員必將淪落，他們身邊的人都日益。
你會找那些已經不看醫學期刊的醫生看病嗎？你會聘請那些不了解近期稅法和判例的稅務律師嗎？雇主們干嘛要聘用那些不能與時俱進的開發人員呢？
讀書，看相關文章，關注博客和微博，參加技術大會，訪問用戶群，多參與讀書與學習小組。不懂就學，不要畏難。如果你是.NET程序員，就去學學Java；如果你是Java程序員，就去學學Ruby；如果你是C語言程序員，就去學學Lisp；如果你真想練練腦子，就去學學Prolog和Forth吧！
1.4.3 練習
業精于勤。真正的專業人士往往勤學苦干，以求得自身技能的純熟精煉。只完成日常工作是不足以稱為練習的，那只能算是種執行性質的操作，而不是練習。練習，指的是在日常工作之余專門練習技能，以期自我提升。
對軟件開發人員來說，有什么可以用以操練的呢？乍一聽，這概念顯得荒唐。但是再仔細想一會兒，想想音樂家是如何掌握演練技能的。他們靠的不是表演，而是練習。他們又是如何練習的呢？首先，表演之前，都需要經歷過特別的訓練，音階、練習曲、不斷演奏等。他們一遍又一遍地訓練自己的手指和意識，保持技巧純熟。
那么軟件開發者該怎樣來不斷訓練自己呢？本書會用一整章的篇幅來談論各種練習技巧，所以在此先不贅述了。簡單說，我常用的一個技巧是重復做一些簡單的練習，如"保齡球游戲"或"素數篩選"，我把這些練習叫作"卡塔"(kata)。卡塔有很多類型。
卡塔的形式往往是一個有待解決的簡單編程問題，比如編寫計算拆分某個整數的素數因子等。做卡塔的目的不是找出解決方法(你已經知道方法了)，而是訓練你的手指和大腦。
每天我都會做一兩個卡塔，時間往往安排在正式投入工作之前。我可能會選用Java、Ruby、Clojure或其他我希望保持純熟的語言來練習。我會用卡塔來培養某種專門的技能，比如讓我的手指習慣點擊快捷鍵或習慣使用某些重構技法等。
不妨早晚都來個10分鐘的卡塔吧，把它當作熱身練習或者靜心過程。
1.4.4 合作
學習的第二個方法是與他人合作。專業軟件開發人員往往會更加努力地嘗試與他人一起編程、一起練習、一起設計、一起計劃，這樣他們可以從彼此身上學到很多東西，而且能在更短的時間內更高質量地完成更多工作。
并不是讓你花全部時間一直和別人共事。獨處的時間也很重要。雖然我很喜歡和別人一起編程，但是如果不能經常獨處，我也一樣會發瘋。
1.4.5 輔導
俗話說：教學相長。想迅速牢固地掌握某些事實和觀念，好的方法就是與由你負責的人交流這些內容。這樣，傳道授業的同時，導師也會從中受益。
同樣，讓新人融入團隊的好辦法是和他們坐到一起，向他們傳授工作要訣。專業人士會視輔導新人為己任，他們不會放任未經輔導的新手亂打亂撞。
1.4.6 了解業務領域
每位專業軟件開發人員都有義務了解自己開發的解決方案所對應的業務領域。如果編寫財務系統，你就應該對財務領域有所了解；如果編寫旅游應用程序，那么你需要去了解旅游業。你未必需要成為該領域的專家，但你仍需要勤勉，付出相當的努力來認識業務領域。
開始一個新領域的項目時，應當讀一兩本該領域相關的書，要就該領域的基礎架構與基本知識作客戶和用戶訪談，還應當花時間和業內專家交流，了解他們的原則與價值觀念。
最糟糕、最不專業的做法是，簡單按照規格說明來編寫代碼，但卻對為什么那些業務需要那樣的規格定義不求甚解。相反，你應該對這一領域有所了解，能辨別、質疑規格說明書中的錯誤。
1.4.7 與雇主/客戶保持一致
雇主的問題就是你的問題。你必須弄明白這些問題，并尋求的解決方案。每次開發系統，都應該站在雇主的角度來思考，確保開發的功能真正能滿足雇主的需要。
開發人員之間互相認同是容易的，但把一方換成雇主，人們就容易產生"彼"、"此"之分。專業人士會盡全力避免這樣的狹隘之見。
1.4.8 謙遜
編程是一種創造性活動。寫代碼是無中生有的創造過程，我們大膽地從混沌之中創建秩序。我們自信地無誤的指令，稍有差錯，機器的錯誤行為就可能造成無法估量的損失。因此，編程也是極其自負的行為。
專業人士知道自己自負，不會故作謙遜。他們熟知自己的工作，并引以為榮；他們對自己的能力充滿自信，并因此勇于承擔有把握的風險。專業人士不是膽小鬼。
然而，專業人士也知道自己會摔跟頭，自己的風險評估也有出錯的時候，自己也有力不從心的時候。這時候，如果他們攬鏡自照，會看到那個自負的傻瓜正對著自己笑。
因此，在發現自己成為笑柄時，專業人士會及時個發笑。他從不會嘲諷別人，自作自受時他會接受別人的嘲諷。反之，他則會一笑了之。他不會因別人犯錯就對之橫加貶損，因為他知
"毫無疑問，Bob大叔的這本新作又一次抬高了專業程序員的門檻。在書中，他從交互管理、時間管理、壓力管理、合作方法以及工具選擇等諸多方面，闡述了他對一名專業程序員的期望。Bob并不囿于對TDD和ATDD的傳授，他不僅解釋了每一名自視為專業人士的程序員所需要知道的東西，而且指出了他們需要在歷練尚淺的軟件開發職業生涯中需要不斷精進的內容。" —— Markus G?rtner，it-agile公司博學軟件開發者 "有一些技術書頗具啟發和教益，有一些則讀來輕松喜悅且富有趣味，但很少有技術書籍能夠同時兼具所有這四個特色。我感覺Martin所有的書都可歸入此列。本書也不例外。 閱讀、學習和守持書中的教誨，你將可以信心滿滿地把自己訓練為軟件專業人士。" ——George Bullock，微軟公司博學程序經理 "如果計算機科學學位要求有`畢業后必讀書單`，本書當在其列。在現實的職業生涯中，糟糕的代碼不會因學期結束就此消失，程序員也不會因加班加點開夜車編碼便可獲得A級評分，而雪上加霜的是，你還必須抽出精力與人打交道。就算你是個編程高手，也并不一定就可以稱為專業人士。本書描述了邁向專業程序員的修煉旅程……而且閱讀起來確實異常有趣。" ——Jeff Overvey，伊利諾伊大學厄本那-香檳分校 "本書遠不只是給出了一套規則或指導方針，它還包含了無數來之不易的智慧和知識，這些寶貴財富通常只有經歷過多年的試錯，歷經由初級學徒修煉成為大師級工匠的整個過程才能獲得。如果你期望自己能成為軟件專業人士，那么本書不容錯過。" ——R.L. Bogetti?，Baxter Healthcare公司系統主設計師
很好
還沒仔細看，看后再評價。
不多說，好東西
沒見過這么慢的物流
不錯
部分紙業有稍微破損
書很好 沒有質量問題 值得一買
好書 好書
不錯
很好的書
????
《程序員的職業素養》是編程大師Bob大叔40余年編程生涯的心得體會, 講解成為真正專業的程序員需要什么樣的態度、原則，需要采取什么樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為后來人引路，助其職業生涯邁上更高臺階。 《程序員的職業素養》適合所有程序員，也可供所有想成為具備職業素養的職場人士參考。
下了兩次單，一次兩本一次三本，都是今天送到為什么差別這么大呢？這兩本書壓皺了就算了，連封面都臟兮兮的好么？買書就是為了閱讀體驗，新書都這樣的話那還不如去看電子書了。當當買了這么多次書，這次最不爽了，本來以前買書都只在當當，這次真讓人傷心，以后要考慮換一家網站了。另外三本就非常好，連袋子膜都還在。
對于沉溺于技術世界的IT屌絲助益匪淺，理性太久了，來點感性吧。
老外的書（翻譯本）讀起來比較有感覺，里面案列都寫的不錯，很有收獲。
剛剛收到書，隨便翻閱了頁 感覺還是不錯的。值得一看
看了前面幾章，很有收獲，有一定工作經驗后再看體會更深
書很好，送貨的快遞太爛了！！！說是次日到貨，拖了4天！
思想不錯，對你的職業觀會產生影響，越早看越好
現在確實需要把軟件工程師職業道德與責任提到日是日程上來了，需要這類書籍的大量涌現。
看Bob大叔的書，還要追溯到《敏捷軟件開發——原則、模式與實踐》。這是一本改變我對軟件看法的書，也使得我徹底擺脫了一個純編碼者的思維，繼而轉向以研究設計架構、分析用戶需求為中心的軟件開發方式，可謂一部有重要影響力的書。這個以后會有專文描述，在此不贅述啦。 其后看了《Clean Code》（干凈代碼），此書可以認為是敏捷軟件開發一書的具體化。那本以思想為主，這本以代碼細節為主。
看了大師的經歷分享，感覺自己不再孤單。成長意味著歷練。專家之路其修遠兮，唯實戰才是根本。謝謝Bob大叔的分享~~~~
本來對這本書名不太感冒，由于是Robert.C.Martin的經典著作就翻來看看，一看進去就愛不釋手了，內容有很多前人的經驗和心血，非常受用
這本書篇幅不長，但是內容很不錯。不是學習代碼，而且學習如何做一名合格的程序員。
不僅是程序員，對于相關領域感興趣的人都可以讀一讀，深入淺出，詼諧幽默！而且干貨很多
Robert C.Martin的大名咱就不說啥了。這本書寫的深入淺出，感覺像讀一本小說，流暢自然，但自然而然的就學到了很多東西。結合工作經驗，常有種“確實如此”的感覺。看完此書第一個感覺就是：大叔也是跌跌撞撞一路走來，什么時候才能成為大叔這種級別的高手呢！成為一名專業的程序員有很長的路要走，這本書亦值得一再品讀。
程序員的職業素養，提高水平，就從這本書開始吧。
