應人民郵電出版社圖靈公司的邀請，我有幸參與了Bob大叔所著Clean Coder的翻譯。

　　與前作Clean Code不同，這本書著重講述的是開發人員的“職業素養”，也即職業開發人員應當如何做事。在閱讀中，我時常會忍俊不禁，也會拍案叫絕，感嘆Bob大叔把深刻的道理講得這樣通透。我雖然沒有Bob大叔那樣好的文筆，不過對“開發人員的職業素養”這個話題，仍然有很多話想說，索性分幾個方面寫下來。

　　學習

　　開發人員在工作之前，一般都已經經過大學階段的專業學習。眾所周知，大學的很多課程已經相當落后，教材也非常保守，所以我見過的好開發人員，不少都是自學成才。但是，這些問題并不能否認通過專業課程學習知識的意義，職業開發人員理解的“學習”，應當明確地區分知識、課程、教材：知識是重要的、穩定的，課程和教材是不那么重要的、變化的。

　　可以非常肯定地說，數據結構、編譯原理、操作系統這類知識，是整個計算機世界的基石，是任何時候也不會過時的。即便畢業后不從事專門的科研，這類知識也會從你接觸到的各種現象中體現出來。我在大學時基本拋棄了學校指定的課程和教材，但自己反復啃過影印版的《現代操作系統》，反復做過北大屈婉玲老師的三本《離散數學習題集》，后來在工作中受益匪淺??調優程序的性能，很可能需要理解調度、死鎖、用戶空間與系統空間等知識;重構復雜的布爾邏輯，很可能要依賴數理邏輯中的定律。如果當時沒有反復的研習，沒有深入理解這背后的原理，并且沒有領悟到這些原理和各種現象之間的聯系，遇到很多問題我很可能會兩眼抓瞎，充其量憑經驗試錯，無論如何，其效率遠不及知識體系指導下的實踐。

　　據我觀察，大學生之所以對課程不感冒，除去學校和教師的原因，另一個因素是，幾乎很少有教材能把看起來乏味的原理，和生活中遇到的問題講清楚。學習圖算法時，你是否想過“人、狼、羊、草過河”的問題可以直接由它來解決?學習內存管理時，你是否想過為什么Windows 95、Windows 98都那么容易藍屏，到了Windows XP才有了長足的進步?我相信，如果能把原理與這類例子對應起來，你的理解會深刻許多，印象也會深刻許多。不幸的是，這類“聯系”的工作，在國內教材基本是一片空白，國外教材也只有部分涉及。其結果是，不少“有經驗”的開發人員面對“32位機為什么只能支持4G內存”、“一個字是多少個字節”、“進程間通訊有哪幾種方式，各有什么優劣”之類基本的問題一臉茫然，不要小看了這些問題，不懂它們，你開發出來的程序只能湊合用，后期遇到問題要重構、調優，簡直難比登天。

　　對此，我的建議是：如果你現在還在學校，不妨仔細想想知識、課程、教材之間的聯系，確定重要的知識，選擇好的教材，自己安排自己的課程。如果你已經離開學校，而且感覺自己的基礎并不牢靠，不妨從手頭的工作開始，想想它用到了哪些原理，對應哪些知識，逐步、有針對性地補習。這其實并沒有太多難度??我的朋友張東亮(@zhasm)，之前幾乎沒有任何計算機基礎知識，只是因為對正則表達式的愛好，找到了一份開發人員的工作，一年之后，他已經開始啃編譯原理之類的書籍了。

　　以上說的主要是“專門”的學習，如果是工作之后的學習，會有很大的不同。

　　首先，工作之后的學習更多依靠自覺，沒有幾家公司會付出代價讓員工像學生那樣“學習”，所以更多時候，你只能花自己的時間、自己的金錢來學習。很多人一想到要花自己的時間，自己的金錢，心里打了退堂鼓。要明確的是，公司沒有老師那樣強烈的責任培養員工“成長”，如果你找不到好的、薪水高的工作，恐怕很難責怪上一家公司沒給你好的培訓。所以，擔心金錢和時間而放棄學習，終的結果是自己停止了成長，逐漸喪失競爭優勢。相反，投入時間和金錢來學習，不但可以保持甚至擴大你的競爭優勢，如果這種行為可以堅持、內化到生活中，也有助于保持健康、飽滿的精神狀態。

　　其次，工作以后的學習，需要努力擺脫工作環境的限制。我見過不少開發人員，因為工作限定在某個平臺，某種語言，業余時間的學習便全部投入到這種平臺、這種語言上，而沒有思考自己是否合適做這些平臺和語言，這些平臺和語言是否在走下坡路。在學校里，考分或許往往是的度量，但在工作中，行將沒落的語言和平臺，你運用再熟練，也于事無補。況且，過于專精于一門語言、一個平臺，反而會限制你的思維和視野，影響迅速學習陌生知識的能力??要在短時間內熟悉陌生平臺和語言的例子，在我們工作中并不少見，在整個IT業界中更是家常便飯。為了讓它真的成為“便飯”，平時還是應當有意識地擺脫工作環境的限制，挑戰自己的思維慣性。

　　責任

　　我曾經見過很多的簡歷，在“工作經歷”里，項目描述寫得天花亂墜，如何先進，如何復雜，采用了多少新技術，但是具體到個人責任，或者語焉不詳，或者極其潦草。這樣簡歷，體現的是責任感的缺失??對于自身責任沒有明確的認知，也沒有足夠的擔當;這樣的人，通常不用面試，可以知道并不是合格的“職業開發人員”。

　　另一方面，我在面試時，經常會問兩個問題，其中很重要的一個是：在你的工作經歷中，收獲大或者印象深的事件是什么。一般來說，如果能回答得有條理、有依據，大多可以判定為合格的職業開發人員。因為，有責任感的開發人員，大多不會把程序看成身外之物，更多地會把程序與自己的道德、聲譽等等聯系起來，甚至把程序看成自己的孩子;所以，必然會投入時間精力去總結、反思、完善、改進，像照顧自己的孩子那樣。其實，我的經驗看，真正的職業開發人員，不但能很好地回答這個問題，而且說起自己做過的事情，多有種充沛的自信感：XX項目是我做的，其特點是什么，我是如何如何做的，遇到什么問題，是如何解決的……涉及的技術不必很先進，開發的系統也不必很復雜，只要能夠這么自信滿滿地一條條歷數下來，你的職業素養是無可厚非的。

　　業務

　　軟件開發中，需求變化是無可避免的。雖然敏捷開發、極限編程宣稱要“擁抱變化”，但真正做到擁抱變化，卻是難上加難。原因在于：一方面，不少開發人員對變化本身持懷疑甚至抵觸態度;另一方面，許多需求
　　這個問題非常普遍，也很嚴重。我思考了很久，發現比較合適的解決辦法是進行角色的互換，尤其是開發方(包括開發人員)，不能局限于“按照規程實現功能”的角色，而應當深入思考和理解業務。

　　不少開發人員“理想”的工作環境是：根本不關心自己的工作成果給誰用，怎么用，會產生什么結果，他們更喜歡這樣的描述：什么類型的數據從哪里來，怎樣處理之后，后交給哪里。在架構清晰、流程完備的大公司里，或許你只需要安心填格子即可，但是擁有這樣工作環境的開發人員，占總數的多少呢?更多的人面對的還是變化不定的需求，甚至連業務部門自己都不清楚自己要的是什么，這種情況下，只關心“數據從哪里來，怎樣處理，交給哪里”之類的問題，無異于盲人騎瞎馬，無異于挖坑埋葬自己。

　　相反，如果你清楚某個實現方案的緣由，知道它是基于何種應用場景，如何設計出來的，可以在相當程度上把握它的價值和所需的工作量。如果更主動一些，可以和業務部門談，這么做，將來會遇到什么問題，如果將來要改，哪些環節是可以改的，哪些環節是不能改的??如果你設身處地地為對方考慮，給出的建議一定比技術味道濃厚的“做不出來”更有說服力。如果做不到這么主動，你也可以預估，哪些業務是穩定不變的，哪些業務是一定會遇到問題需要改變的，然后可以合理分配工作量：對那些明顯沒什么前途的項目，可以適當保留資源，以免將來竹籃打水;對那些目前業務部門認為不重要，其實又相當有價值的項目，可以適當多投入精力，以免將來措手不及??要知道，業務部門提的“緊急”需求，多半不會考慮開發的工作量。

　　需要補充的是，做到上面這點，其實有相當的難度：一方面，你的技術功底必須足夠扎實，在滿足需求時，不僅僅是“模仿”現實，而應當知道這種現實，在數字世界里應當如何表達，如何重構，受到哪些條件和規則的限制(比如同一個抽象操作的不同實現，到底是選擇Switch語句還是多態，其實是有章可循的，必須根據實際情況選擇);另一方面，又要能跳開技術的局限，從更全面的視角理解、把握業務。不過，這是非常值得花功夫的??從某種意義上可以說，當前熱門的“領域驅動開發(Domain Driven Development)”，說的大抵是這回事。

　　時間

　　在軟件開發中，時間是一個非常重要的因素。在這方面，已經有無數的巨著，無數的案例，無數的先烈，但是時間，仍然是一個值得討論的話題。

　　總的來說，人月是一個神話，我們不可能精確地把握開發時間，但是這并不意味著，我們不能從某種程度上把握時間。我個人的經驗是，計劃是在現實參照下的不斷調整和修正中逐漸準確的。重要的，并不是確定遠大的目標，然后限定多長時間必須完成;而是可以把大的項目拆分為不同的模塊，把整個開發流程劃分為不同的階段。如果你的模塊劃分得足夠細致，可以以每個模塊的工作量，相對準確地得知整個項目的耗時;如果你的流程劃分得足夠合理，可以在各個階段拿出看得見、用得著的結果，供業務方使用。這樣，一方面避免了“到后一起推出，卻發現與業務方想象大相徑庭”的尷尬;另一方面，在開發過程中，每個階段結束，可以提供一個階段的生產力，作為開發方，在面對質疑時，有足夠的資本和底氣。

　　從個人方面，我注意到，職業開發人員還有另一個特點：是可以相當精確地估計某個“小活”的工作量。以我自己和我的一些朋友為例，面對一些細致而且明確的需求，我們經常可以精確估計到工作量，時間精確到以半小時計。在緊密協作的“背靠背”編程中，我會說：現在是幾點，所以我會在幾點之前，給你提供怎樣的功能，其行為是怎樣的，接口是怎樣的(行為和接口可以事先約定)。這樣的自信，既要求對所需技術、會遇到難題的把握，也要求在頭腦里對任務有完整清晰的模型。雖然難度不小，但能做到這一點，確實是職業素養的典型體現。