《程式員的職業素養》讀書筆記萬字總結【建議收藏】

引言

        成功的程式員在以往的工作和生活中都曾經曆過大大小小的不确定性，承受過永無休止的壓力。他們之是以能夠成功，是因為擁有一個共同點，都深切關注建立軟體所需的各項實踐。他們将軟體開發視為一種需要精雕細琢加以修煉的技藝，他們以專業人士的标準要求自己，他們具有職業素養。

        在你過去的工作中，你遇到的問題可能很容易也可能很難，但實際上最重要的并不是問題的難度，而是解決問題的方式、步驟以及反思的深度。職業素養它強調的并不是天賦的神秘，也不是技藝的高深，而是持續積澱的結晶：一方面，它展現了能力和素質；另一方面，它又強調了持續的積累和養成。作為職業開發人員，基本技能不夠熟練，當然談不上職業素養。如果隻會迅速地編寫代碼，卻不關心代碼背後的意義，不能迅速判斷、解決程式運作中的各種問題，不能自信滿滿地為自己傳遞的程式承擔責任，同樣是與職業素養絕緣的 —— 許多所謂的 “高手”，其實正是缺乏職業素養的典型。

第一章 - 專業主義

        “專業主義” 有很深的含義，它不但象征着榮譽與驕傲，而且明确意味着責任與義務。這兩者密切相關，因為從你無法負責的事情上不可能獲得榮譽與驕傲。

擔當責任

        如果你不小心放過了某個子產品裡的一個bug，以緻公司出現了資損。非專業人士會聳聳肩說：“狀況總是難免的嘛。” 然後像沒事人一樣繼續寫下一個子產品，而專業人士會主動承擔責任。實際上，專業主義的精髓就在于将公司利益視同為個人利益。

首先，不行損害之事

不要破壞軟體功能

        開發的軟體有 bug 會損害軟體的功能。是以，要做得專業，就不能留下bug。會有人認為軟體開發太複雜了，不可能沒有bug。但這并不能為你開脫。就像人體這麼複雜，不可能盡知其全部，但醫生仍誓言不傷害病人。

        沒人能寫出完美的軟體，但這并不表示你不用對不完美負責。專業人士需要練習的第一件事就是 “道歉”。道歉是必要的，但還不夠。你不能一而再、再而三地犯同樣的錯誤。你有責任讓你的失誤率無限接近零。

        作為開發人員，你需要有個相對迅捷可靠的機制，以此判斷所寫的代碼可否正常工作，并且不會幹擾系統的其他部分。

不要破壞結構

        聰明人不會為了釋出新功能而破壞結構。結構良好的代碼更靈活。以犧牲結構為代價，得不償失，将來必追悔莫及。        

        所有軟體項目的根本指導原則是：軟體要易于修改。如果違背這條原則搭建僵化的結構，就破壞了構築整個行業的經濟模型。

職業道德

了解你的領域

下面列出了每個專業軟體開發人員必須精通的事項

• 設計模式：必須能描述GOF書中的全部24種設計模式且有實戰經驗
• 設計原則：必須了解SOLID原則，且需要深刻了解元件設計原則
• 設計方法：必須了解結構化分析以及結構化設計方法等
• 實踐：必須掌握測試驅動開發、面向對象設計、結構化程式設計、持續內建和結對程式設計
• 工件：必須了解如何使用UML圖、結構圖、流程圖等

堅持學習

軟體行業的飛速發展，意味着軟體開發人員必須堅持廣泛學習才不至于落伍。

這裡推薦以下幾種學習方式：

• 廣泛閱讀技術書籍以及技術文章
• 參加技術大會
• 學習多種程式設計語言

練習

        業精于勤。真正的專業人士往往勤學苦幹，以求得自身技能的純熟精煉。Bob大叔常用的一個技巧是重複做一些簡單的練習，如 “保齡球遊戲” 或 “素數篩選” 【可以了解為一些簡單的程式算法題】

合作

        專業軟體開發人員往往會更加努力地嘗試與他人一起程式設計、一起練習、一起設計、一起計劃，這樣他們可以從彼此身上學到很多東西，而且能在更短的時間内更高品質地完成更多工作。 

輔導

        想迅速牢固地掌握某些事實和觀念，最好的方法就是與由你負責的人交流這些内容。專業人士會視輔導新人為己任，他們不會放任未經輔導的新手亂打亂撞。

了解業務領域

        每位專業軟體開發人員都有義務了解自己開發的解決方案所對應的業務領域。你未必需要成為該領域的專家，但你仍需要勤勉，付出相當的努力來認識業務領域。

         在開始一個新領域的項目時，應當讀一兩本該領域相關的書，還應當花時間與業内人士交流，了解他們的原則與價值觀念。

客戶至上

        要将客戶的問題化作自己的問題，你必須弄明白并尋求最佳的解決方案。站在客戶的角度思考問題，確定開發的功能真正能滿足客戶的需求。

謙遜

        任何時候都不要自負，時刻保持謙遜。要對自己的能力充滿信心，并勇于承擔有把握的風險。

        不要嘲諷别人犯下的錯誤，一笑了之吧，因為下一個犯錯的可能就是你自己。

第二章 - 勇于說 “不” 

        能就是能，不能就是不能。不要說 “試試看” —— 尤達

高風險時刻

        最要說 “不” 的是那些高風險的關鍵時刻。越是關鍵時刻，“不” 字就越具價值。

要有團隊精神

        具備團隊精神，意味着恪盡職守，意味着當其他隊員遭遇困境時你要援手相助。有團隊精神的人會頻繁與人交流，會關心隊友，會盡最大可能地做到盡職盡責。 

試試看

        “嘗試” 一詞有許多定義。或是 “一種積極的舉動”，又或是 “付出額外的精力”。許諾 “嘗試”，就意味着你承認自己之前未盡全力，承認自己還有餘力可施。許諾 “嘗試”，意味着隻要你再加把勁還是可以達成目标的。

第三章 - 說 “是”

前面學會了說 “不”，但是，學會如何說 “是” 也同樣重要。

說 “是” 的成本

        大多數時間，我們都希望能夠說 “是”。确實，健康的團隊都會努力尋求給他人以肯定的答複。運作良好的團隊的經理和開發人員，會互相協商，直至達成共同認可的行動方案。

承諾用語

做出承諾，包含三個步驟

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

識别 “缺乏承諾” 的征兆

        在承諾做某事時，應當留意自己的用詞，這些詞透露了我們對待承諾的認真态度。實際情況當然不隻是注意在我們所說的話中是否有某幾個詞這麼簡單。

        以下示例中包含的幾個用詞和短語，會透露 “缺乏承諾” 的蛛絲馬迹，要注意搜尋。

•         需要/應當：“我需要把活做完”
•         希望/但願：“我希望程式運作沒有bug”
•         可能/應該：“我可能在xx日前能完成任務” 

真正的承諾

        識别真正承諾的訣竅在于，要去搜尋與下列相似的語句：我将在 ··· 之前 ··· （如：我将在周二之前完成這個任務。）

        這句話的關鍵在于你對自己将會做某件事做了清晰的事實陳述，而且還明确說明了完成期限。那不是指别人，而是說的自己。你談的是自己會去做的一項行動，而且，你不是可能去做，或是可能做到，而是會做到。

        這時，你的措辭已經轉變到 “承諾” 模式了，之後便要繼續走完下面兩個步驟：

        言必行，行必果。

小結

        今天的程式員肯定得去面對諸如估算、确定最後期限以及面對面交流等溝通活動。做出承諾或許聽來令人有點害怕，但它能夠幫助程式員解決在溝通中可能發生的不少問題。如果你能一直信守承諾，大家會以為你是一名 “嚴謹的開發人員”。 

        專業人士不需要對所有請求都回答 “是”。不過，他們應該努力尋求創新的方法，盡可能做到有求必應。當專業人士給出肯定回答時，他們會使用承諾用語，以確定各方能明白無誤地了解承諾内容。

第四章 - 編碼

        編碼是一項頗具挑戰也十分累人的智力活動。相比其他類型的活動，編碼要求更加聚精會神。因為在編碼時你必須平衡互相牽制的多種因素。

四項挑戰

        首先，代碼必須能夠正常工作。必須了解目前要解決的是什麼問題以及該如何解決。必須確定編寫的代碼忠實遵循解決方案。必須管理好解決方案的每一處細節，并且使語言、平台、現有架構以及目前系統的所有問題和平共處。

        代碼必須能夠幫你解決客戶提出的問題。很多時候，客戶提出的需求其實并沒能真正解決他們自己的問題。這有賴于你去發現這些問題并及時與客戶進行交流，以確定代碼能夠滿足客戶的真實需求。

        代碼必須要能和現有系統結合得天衣無縫。你的代碼不能讓系統變得更僵硬、更易碎、更晦澀，必須要妥善管理好各種依賴關系。簡而言之，編寫代碼時必須遵循穩健的工程原則。

        其他程式員必須能讀懂你的代碼。這不僅包括要寫好注釋這類事，還包括要精心錘煉代碼，使它能夠表達你的程式設計意圖。要做到這點很不容易。事實上，這可能是程式員最難精通的一件事。

不要帶着焦慮寫代碼

        如果你内心焦躁不安，這時根本不應該編寫代碼，而應該先解除焦慮情緒。當然，有許多焦慮無法在一兩個小時内解決，而且老闆也無法長期容忍我們因為要解決個人問題而不投入工作。

        關鍵所在是要學會如何關閉背景程序，或至少要能降低其優先級，這樣焦慮就不會造成持續的幹擾。

避免進入 “流态區”

        這是程式員在編寫代碼時會進入一種意識高度專注但思維視野卻會收攏到狹窄的狀态。在這種狀态下，他們會感到 “效率極高，絕無錯誤”。

        在流态區，你可能可以敲出更多的代碼。你會收獲一種愉悅感或征服感。問題在于，在流态區狀态下，你其實沒有顧及全局，是以，你很可能會做出一些後來不得不推倒重來的決策。是以，請盡量避免進入 “流态區”。

理性面對中斷

        中斷無法避免，總有幹擾會打擾你、消耗你的時間。發生這種情況時請記住，也許下次也會輪到你去打斷别人請求幫助。是以，禮貌地表現出樂于助人的态度才是專業的态度。

阻塞

        有的時候，死活就是寫不出代碼來。這時候，通常需要去找一些其他事情幹。去檢視郵件或者讀點文檔。不必死盯着螢幕，幹坐在那裡。 

導緻阻塞的原因 

• 睡眠
• 焦慮
• 恐懼

• 沮喪

  解決辦法：找一個結對程式設計搭檔。

  這個方法很有效也很神奇。當坐到别人旁邊的時候，本來擋住去路的問題忽然就會消失了。你是能真切感覺到這種變化的，這種變化能幫助你沖破阻塞繼續前進。

調試 

        衡量你是否是一名專業人士的一個重要方面，便是看你是否能将調試時間盡量降到最低。絕對的零調試時間是一個理想化的目标，無法達到，但要将之作為努力方向。

        醫生不喜歡打開病人的胸腔去修複此前犯下的錯誤。律師不喜歡再度接手此前搞砸的案子。同樣，軟體開發人員也不喜歡為自己埋下bug的軟體返工。

保持節奏

        軟體開發是一場馬拉松，而不是短跑沖刺。你無法全程一直以最快的速度沖刺來赢得比賽，隻有通過儲存體力和維持穩定節奏來取勝。無論是賽前還是賽中，馬拉松選手都會仔細調整好自己的身體狀态。專業程式員也會同樣仔細地儲存好自己的精力和創造力。 

知道何時應該離開一會兒

        當碰到困難而受阻時，當你感到疲倦時，就離開一會兒，讓富有創造力的潛意識接管問題。精力配置設定得當，你将能在更短的時間内以更少的精力完成更多的事情。讓自己保持好節奏，讓團隊保持好節奏。了解你的創造力和智力運作的模式，充分發揮它們的優勢而非與之背道而馳。

進度延遲

        你總有一天會遭遇延遲的情況。即使是最優秀的程式員、最敬業的員工，也不能避免碰到延遲。有時候，則隻是因為我們預估時過于樂觀誇下了海口，最後延遲的情況無可避免。 

切勿盲目沖刺

        如果經理極力要求你盡力趕上最後截止期限，你需要堅決維持你的估算！唯一能夠加快進度的方法便是縮減範圍。

        如果在壓力之下最終屈服，同意盡力趕上截止日期，結局會十分悲慘。那些開發人員會開始抄近路，會額外加班加點工作，抱着創造奇迹的渺茫希望。但需要明白一點，額外加班20%的時間無法完成20%的額外工作。這是制造災難的最佳秘訣，因為這種做法給自己、給團隊以及利益相關方帶來了一個錯誤的期望。這樣每個人都可以避免面對真正的問題，把做出必要的艱難決定的時機不斷後延。

正确定義 “完成” 避免傳遞失敗

        在程式員所能表現的各種不專業行為中，最糟糕的是明知道還沒有完成任務卻宣稱已經完成。或是我們自欺欺人地認為任務已經完成得足夠好，然後轉入下一項任務。如果一個團隊陷入此種誤區之中，管理者聽到的将是諸事順利。所有的狀态報告表明，每個人的工作完成得都很準時。這就像是一群盲人坐在鐵軌旁邊野餐：沒有人能夠看見滿載未完成工作的火車馬上将會把他們壓垮，而等他們發現時，一切都已經來不及了。

        避免傳遞失敗的最好方法是通過建立一個确切定義的 “完成” 标準。例如讓業務分析師和測試人員建立一個自動化的驗收測試，隻有完全通過這些驗收測試，開發任務才能算已經完成。

幫助

        程式設計很難，事實上，僅憑一己之力無法寫出優秀的代碼。即使你的技能格外高超，也肯定能從另外一名程式員的思考與想法中獲益。

幫助他人

        将自己封閉在格子間或者辦公室裡與世隔絕，有悖于專業的職業精神。你的工作不可能重要到你不能花一丁點兒時間來幫助别人。事實上，作為專業人士，要以能夠随時幫助别人為榮。

        幫助别人的時候，可以坐下來和他一起寫代碼，不要讓自己看起來十分倉促，仿佛隻是随便應付，要全情投入到任務中。當你離開時，可能會發現自己從中收獲的東西比給予的還要多。

接受他人的幫助

        如果有人向你伸出援手，要誠摯接受，心懷感激地接受幫助并誠意合作。不要死命護着自己的地盤拒絕别人的幫助。 

        要學會如何請求幫助。當你受阻時，或者有點犯暈時，或者隻是繞一個問題繞不出去時，不妨請求别人的幫助。

第五章 - 測試驅動開發

測試驅動開發（TDD）意味着程式設計需要先寫測試程式。誰會這麼做呢？先寫單元測試？誰會做這麼蠢的事呢？

TDD的優勢

确定性

        在TDD的開發模式下，任何時刻，一旦修改了工程中的任何部分，隻需再次運作全部的單元測試即可。如果單元測試全部通過，差不多就可以确信修改沒有破壞任何東西。

勇氣

        這是TDD最強大之處。用有一套值得信賴的測試，便可完全打消對修改代碼的全部恐懼。當看見糟糕的代碼時，就可以放手整理。代碼會變得具有可塑性，你可以安全地将之雕琢成簡單而滿意的結構。 

文檔

        單元測試即是文檔。它們描述了系統設計的最底層設計細節。它們清晰準确，以讀者能夠了解的語言寫成，并且形式規整可以運作。它們是最好的底層文檔。 

設計

        測試代碼的一個問題是必須隔離出待測試的代碼。如果一個函數調用了其他函數，單獨測試它通常會比較困難。為了編寫測試，你必須找出将這個函數和其他函數解耦的辦法。換言之，測試先行的需要，會迫使你去考慮什麼是好的設計。

TDD的局限

        盡管TDD有諸多優點，但是它既非宗教信仰，也非魔力公式。即使做到了測試先行，仍有可能寫出糟糕的代碼。因為寫出的測試代碼可能就很糟糕。 

第六章 - 練習

        專業人士都需要借助專門訓練提升自己的技能，無一例外。樂手練習音階，球員練習繞樁，醫生練習動手術和縫針，律師練習論辯，士兵練習執行任務。如果重視最終的成績，專業人士就會選擇練習。

卡塔

        在國術裡，卡塔是一套設計好的、用來模拟搏鬥一方的招式。目标則是要逐漸把整套招式練習到純熟。習武者努力訓練自己的身體來熟悉每一招，把它們連貫成流暢的套路。訓練有素的卡塔看起來相當漂亮。 

        與之類似，程式設計卡塔也是一整套敲擊鍵盤和滑鼠的動作，用來模拟程式設計問題的解決過程。練習者不是在解決真正的問題，因為你已經知道了解決方案。相反，你是在練習解決這個問題所需要的動作和決策。

        程式設計卡塔的最終目标，也是逐漸練習以達到純熟。反複的練習會訓練大腦和手指如何動作和反應。在不斷練習當中，你或許會發現動作的細微進步，或者解決問題效率的小幅提升。

瓦薩

        瓦薩基本可以說是兩個人的卡塔。其中的招式需要精确地記憶，反複演練。一個人負責攻，另一個人負責守。攻守雙方互換時，各種動作要一而再、再而三地重複。 

自身經驗的拓展

        職業程式員通常會受到一種限制，即所解決問題的種類比較單一。經驗不夠豐富的程式員，履曆和思維中都存在某種贻害無窮的盲區。經常可以看到這樣的情景：程式員發現，面對行業的周期性變化造成的新局面，自己并沒有做好準備。 

開源

        保持不落伍的一種方法是為開源項目貢獻代碼，就像律師和醫生參加公益活動一樣。開源項目有很多，為其他人真正關心的開源項目做一點貢獻，應該可以算是提升技能的最好辦法了。 

第七章 - 驗收測試

        驗收測試這個名詞用得太多太泛了。有人認為，驗收測試就是在接受正式釋出之前由使用者執行的程式，也有人認為它是QA測試。驗收測試可以定義為業務方與開發方合作編寫的測試，其目的在于确定需求已經完成。

溝通

需求的溝通

        開發方與業務方之間最常見的溝通是關于需求的。業務方描述他們認為自己需要的東西，程式員按照自己了解的業務方表達的需求來開發。至少從理論上來說，應該是這樣。但在現實裡，關于需求的溝通是及其困難的，其中會出現各種問題。 

       專業開發人員既要做好開發、也要做好溝通。“輸入糟糕，輸出也會糟糕” 對程式員同樣适用，是以職業程式員會重視與團隊及業務部門的溝通，確定這種溝通的準确、流暢。

過早精細化

        做業務的人和寫程式的人都容易陷入一個陷阱，即過早的進行精細化。業務方還沒有啟動項目，就要精确知道最後能得到什麼；開發方還沒有評估整個項目，就希望精确知道要傳遞什麼。

“完成” 的定義

        不同的團隊對 “完成” 的定義各不相同。專業開發人員的 “完成” 隻有一個含義：完成，就是完成。完成意味着所有的代碼都寫完了，所有的測試都通過了，QA 和需求方已經認可。這，才是完成。

自動化測試

        驗收測試都應當自動進行。在軟體開發的周期中，确實有時候需要手動測試，但是驗收測試不應當手工進行，原因很簡單：要考慮成本。

測試的協商與被動推進

        寫測試的人也是普通人，也可能犯錯誤。有時候你剛開始實作某個功能，就會發現有些測試沒什麼意義。有些太複雜，有些不靈活，有些包含愚蠢的假定，還有些幹脆就是錯的。身為專業開發人員，與編寫測試的人協商并改進測試是你的職責。

驗收測試和單元測試

        驗收測試是測試方寫給業務方的。它們是正式的需求文檔，描述了業務方認為系統應該如何運作。關心驗收測試結果的是業務方和程式員。而單元測試是程式員寫給程式員的，它是正式的設計文檔，描述了底層結構及代碼的行為。

        它們的主要目的是如實描述系統的設計、結構、行為。它們真正的價值并不在測試上，而在具體名額上。

持續內建

        請務必確定在持續內建系統中，單元測試和驗收測試每天都能運作好幾次。整套持續內建系統應該由源代碼管理系統來觸發。隻要有人送出了代碼，持續內建系統就會開始建構，并運作所有的測試。

第八章 - 測試政策

        專業開發人員會測試自己的代碼。但是，測試并不就是寫一些單元測試或者驗收測試那麼簡單。編寫這些測試隻是萬裡長征的第一步。每個專業的開發團隊都需要一套好的測試政策。

自動化測試金字塔

單元測試

        在金字塔底部是單元測試，這些測試由程式員使用與系統開發相同的語言來編寫，供程式員自己使用。編寫這些測試的目的是在最低層次上來定義系統。

        單元測試可以做到接近100%的覆寫率，通常而言這個數字應該保持在90%以上。

元件測試

        元件測試是驗收測試的一種，它們是針對系統的各個元件而編寫的。系統的元件中封裝了業務規則，是以對這些元件的測試便是對其中業務規則的驗收測試。

        元件測試差不多可以覆寫系統的一半，它們更主要測試的是成功路徑的情況以及一些明顯的極端情況、邊界狀态和可選路徑。

內建測試

        內建測試是編排性測試，它們并不會測試業務規則，而是主要測試元件裝配在一起時是否協調。它們是裝配測試，用以确認這些元件之間已正确連接配接，彼此間通信暢通。

系統測試

        系統測試是針對整個內建完畢的系統來運作的，自動化測試是最終的內建測試。它們不會直接測試業務規則，而是測試系統是否已經正确組裝完畢，以及系統各個元件部件之間是否能正确互動。在這個層次的測試集中，應該包含吞吐率測試和性能測試。

人工探索式測試

        這是需要人工介入、敲擊鍵盤、盯牢螢幕的測試。它們既非自動化的測試，亦非腳本化的測試，這些測試的意圖是需要在驗證預期行為的時候，探索系統預期之外的行為。

第九章 - 時間管理

        8小時其實十分短暫，隻有480分鐘，28800秒。身為專業開發人員，你肯定希望能在這短暫的時間裡盡可能高效的工作，取得盡可能多的成果。

會議

拒絕 

        受到邀請的會議沒必要全部參加，參加的會議太多，其實隻能證明你不夠專業，你應該理智的使用時間，是以必須謹慎選擇應當參加的一些會議，禮貌拒絕哪些會議。邀請你參加會議的人并不負責管理你的時間，為時間負責的隻有你，是以如果你收到會議邀請，務必確定出席會議可以給自己目前的工作帶來切實一些顯著的成效，否則不必參加。

離席

        會議并不總是按計劃進行的，有時候你正參加某個會議，但是發現如果之前對此會知道的多一些就不會來。再說一次，仔細管理自己的時間是你的責任，如果你發現參加某個會議是在浪費時間，就應當想個禮貌的辦法退出來。

确定議程和目标

        如果收到會議邀請，務必弄清楚指定的議題是什麼，每個議題花多長時間要取得什麼成果，如果得不到确切的答案，你可以禮貌拒絕。

疊代計劃會議

        疊代計劃會議用來選擇在下一輪疊代中實作的開發任務，在會議召開前務必完成兩項任務。評估可選擇任務的開發時間，确定這些任務的業務價值。如果組織得足夠好，業務驗收元件測試也應當在會議召開前完成，或者至少要有概略方案。

注意力點數

        程式設計是需要持續投入精力和注意力的智力活動，注意力是稀缺的資源，它類似魔力點數，如果你用光了自己的注意力點數，必須花一個小時，或更多的時間做不需要注意力的事情來補充它。

        注意力點數也會随時間流逝而減少，如果不及時使用，它們就會消失。會議之是以具有巨大的破壞力，原因之一就在于此，如果你所有的注意力點數都用在了會議上，程式設計時就大腦空空了。

睡眠

        睡眠的重要性再怎麼強調都不為過，美美一覺醒來，注意力點數是最充裕的，好好睡上七個小時。你将有足夠的注意力點順序做好八個小時的工作，專業開發人員會安排好他們的睡眠，保證清晨有飽滿的注意力點數去上班。

咖啡因

        毋庸置疑，對有些人來說，适量的咖啡因可以幫他們更有效的使用注意力點數。但是請小心，咖啡因也會給你的注意力添亂，太多的咖啡因會把你的注意力轉到奇怪的方向，太濃的咖啡會搞得你一整天都沉溺于不重要的事情。

恢複

        在你不集中注意力的時候，注意力點數可以慢慢恢複。漫步一段長路，與朋友聊天，看看窗外都有助于恢複注意力點數。有些人選擇沉思檢討，也有些人選擇小睡一會兒，還有人選擇聽部落格。或者翻翻雜志。

肌肉注意力

        肌肉注意力有助于改善心智注意力，而且不僅僅是簡單的恢複。定期訓練肌肉注意力，可以提升心智注意力的上限。

避免進入死胡同和泥潭

死胡同

        所有軟體開發者都要遇到死胡同，比如你做了決定，選擇了走不通的技術道路。你對這個決定越是堅持，浪費的時間就越多。如果你認為這關系到自己的專業信譽，就永遠也走不出來。慎重的态度和積累的經驗可以幫你避免某些死胡同，但是沒法完全避免所有的。是以你真正需要的是在走入死胡同時，可以迅速意識到，并有足夠的勇氣走回頭路。這就是所謂的 “坑” 法則：如果你掉進了坑裡，别挖。

泥潭

        比起死胡同更糟的是泥潭，泥潭會減慢你的速度，但不會讓你徹底停下來，泥潭會阻礙你前進，但如果使盡全力，你仍然可以取得進展，之是以說泥潭比起死胡同更麻煩，因為在泥潭中你仍然可以看到前進的道路，而且看起來總是比回頭路要短。

        如果發現自己身處泥潭還要固執前進，這是是最嚴重的優先級錯亂。繼續沉浸無異于欺騙自己，欺騙團隊，欺騙公司，欺騙客戶。你一邊帶大家走向煉獄，一邊告訴其他人所有問題都會解決。

小結

        專業開發人員會用心管理自己的時間和注意力。他們知道優先級錯亂的誘惑，他們也珍視自己的聲譽，是以會抵制優先級錯亂。他們永遠有多種選擇，永遠敞開心扉聽取其他解決方案，他們從來不會執拗于某個無法放棄的解決方案，他們也時刻警惕着正在顯露的泥潭，一旦看清楚，就會避開。最糟糕的事情，莫過于看到一群開發人員正在徒勞的拼命工作，結果卻陷入越來越深的泥潭。

第十章 - 預估 

        預估是軟體開發人員面對的最簡單，也是最可怕的活動之一了。預估影響到的商業價值巨大，關乎聲譽，也給我們帶來了很多苦惱和挫折。預估是業務人員和開發人員之間最主要的障礙。存在雙方之間的種種不信任，幾乎都由它引發。

什麼是預估

        預估是一種猜測，它不包含任何承諾的色彩，它不需要做任何約定，預估錯誤無關聲譽，我們之是以要預估，是因為不知道到底要花多少時間。

        不同的人對預估有不同的看法，業務方覺得預估就是承諾，開發方認為預估就是猜測，兩者相差迥異。

承諾

        承諾是關于确定性的，其他人會把你的承諾當真，據此拟定計劃，如果不能兌現承諾，他們的損失以及你的聲譽受到的影響都是巨大的，承諾不能兌現也是欺騙，隻不過比公然的欺騙好一點。

大數定律

        預估是十分容易出錯的。控制錯誤的辦法之一，就使用大數定律。該定律的意思是把大任務分成許多小任務，分開預估在加總，結果會比單獨評估大任務要準确很多。這樣做之是以能夠提高準确度，是因為小任務的預估錯誤幾乎可以忽略，不會對總的結果産生明顯影響。

小結

        專業開發人員懂得如何為業務人員提供可信的預估結果，以便做出計劃。如果做不到或者不确定能做到專業開發人員不會給出承諾。

第十一章 - 壓力

避免壓力

        在壓力下保持冷靜的最好方式，便是規避會導緻壓力的處境。規避的方式也許無法完全解除壓力，但是可以大大降低壓力并縮短高壓力期的時間。

保持整潔

        讓系統代碼的設計盡可能整潔，就可以避免壓力。這并非是說我們要花無窮無盡的時間去清理代碼，而隻是說不要容忍混亂。混亂會降低速度，導緻工期延誤，承諾失信。是以，要盡力保持輸出成果整潔幹淨。

危機中的紀律

        觀察自己在危機時刻中的反應，就可以了解自己的信念，如果在危機中依然遵循着你守持的紀律，就說明你确實相信那些紀律。反而來說如果你在危機中改變行為，就說明，你并不真正相信正常行為中的原則。

        當困境降臨時，也不要改變行為。如果你遵守的紀律原則是工作的最佳方式，那麼即使在深度危機中也要堅決秉持這些紀律原則。

應對壓力

        能遇見壓力、轉移壓力和消除壓力是很好的。但是有時候不管你多麼千方百計的求防患于未然，依然會有壓力降臨到你頭上。有時候項目周期就是比任何人此前所預計的要長，有時候原始設計就是有錯誤，必須返工。

不要驚慌失措

        正确應對壓力，長夜漫漫，無心睡眠，無助于更快的解決問題。幹坐着煩躁不安也于事無補。而你可能會犯的最嚴重的錯誤就是魯莽倉促，要避免産生孤注一擲的想法，魯莽倉促隻會把你帶入更深的深淵。

        相反，要放松下來，對問題深思熟慮，努力尋找可以帶來最好結果的路徑，然後沿着那條路徑以合理穩定的節奏向前。

溝通

        讓你的團隊和主管知道你正深陷困境之中，告訴他們你所制定的走出困境的最佳計劃，請求他們的資源和指引，避免制造意料之外的麻煩。

小結

        應對壓力的訣竅在于，能回避壓力時盡可能地回避，當無法回避時則勇敢直面壓力。可以通過慎重承諾，遵循自己的紀律原則，保持整潔來回避壓力。直面壓力時，則要保持冷靜，與别人多多溝通，堅守自己的原則紀律，并尋求他人的幫助。

第十二章 - 協作

        大多數軟體都是由團隊開發出來的，當團隊成員能夠十分專業的互相協作時，整個團隊是最為高效的，單打獨落與遊離于團隊之外都是不專業的表現。

程式員與Boss

        專業程式員的首要職責是滿足 Boss 的需求。就意味着你要和你的經理們、業務分析師們、測試工程師們和其他團隊成員有很好地協作，深刻了解業務目标。

        專業程式員最糟糕的表現是兩耳不聞窗外事，隻顧一頭将自己埋在技術堆裡，甚至連公司業務火燒眉毛了也不聞不問，你的工作職責就是要讓業務避免陷入困頓，讓公司可以長久發展下去。

程式員與程式員

        專業人士結對工作，因為這是分享知識的最好途徑。專業人士并不會僅憑一己之力從零開始建立知識，而是通過互相結對來學習系統的不同部分和業務。他們明白，盡管每位團隊成員都有自己的位置，但是在緊要關頭，每位團隊成員也要能夠接替其他人的位置。

第十三章 - 團隊與項目

有凝聚力的團隊

        形成團隊是需要時間的，團隊成員首先需要建立關系，他們需要學習如何互相協作，需要了解彼此的癖好、強項和弱項，最終才能凝聚成團隊。有凝聚力的團隊，他們可以一起創造奇迹，他們互為知己，能夠替對方着想，互相支援，激勵對方拿出自己最好的表現，他們攻無不克。

        團隊比項目更難建構。是以，組建穩健的團隊，讓團隊在一個又一個項目中整體移動共同工作是最好的做法。并且，團隊也可以同時承接多個項目，在組建團隊時，要給予團隊充足的時間讓他們形成凝聚力，一起共同工作，成為不斷傳遞項目的強大引擎。    

第十四章 - 輔導、學徒期與技藝

        學校能夠傳授的是計算機程式設計的理論，但是學校并不會也無法傳授作為一名程式設計匠者所需要掌握的原則、實踐和技能。這些東西隻有經由師徒個體間多年的細心監督和輔導才能獲得。軟體行業必須要面對這一事實，下一代軟體開發人員成熟起來的重任無法寄希望于大學教育，建立一種包含學徒期，實習期和長期指引的機制也是迫在眉睫。