第一章 專業主義

• 了解領域知識
  軟件開發人員必須精通的知識：
  • 設計模式 GOF中的24種，POSA中的實戰經驗
  • 設計原則 SOLID原則，組件設計原則
  • 方法 Scrum、精益、看板、瀑布、結構化分析、結構化設計 等
  • 實踐 測試驅動開發、面向對象設計、結構化編程、持續集成、結對編程
• 學習和練習
  • 讀書、看文章、參加技術大會、參與討論小組
  • 做一些簡單的練習，讓手指習慣點擊快捷鍵或者習慣的使用某些重構技法。把這些當做 熱身練習 或者 靜心過程
• 合作
  • 嘗試與他人一起編程、一起練習、一起設計，從彼此身上學到東西
  • 獨處的時間也很重要
• 了解業務領域
  • 有義務了解自己開發的解決方案對應的業務領域
  • 開始一個新領域的項目時，應該讀一兩本該領域相關的書，了解該行業的原則和價值觀念
  • 要理解業務 為什么 那樣規定

第二章 說不

• 專業人士敢于說明真相而不屈從于權勢

• 試試看

  • 許諾 嘗試，意味著你承認自己之前未盡全力，承認自己還有余力可施，意味著只要你再加把勁還是可以達成目標的；而且這也是一種表示你將再接再厲去實現目標的承諾。因此，只要你許諾自己會去 嘗試，你其實是在承諾你會確保成功

第三章 說是

• 做出承諾包含三個步驟：口頭上說自己將會做；心里認真對待做出的承諾；真正付諸行動

• 逃避承擔責任傾向的幾個詞：需要/應當 希望/但愿 讓我們

• 真正的許諾： 我將在……之前完成……

• 幾個沒做到承諾的原因

  • 之所以沒成功，是因為我寄希望于某某去做這件事
    你只能承諾自己能 完全掌控 的事情，如果最終目標依賴于他人，那么你就應當采取些具體行動，接近最終目標

• 之所以沒成功，是因為我不太確信是否真能完成得了
  即使目標無法完成，你仍能全力前進，離目標更近些。比如發布前無法修復的bug，可以和QA一起努力重現這些bug，并在本周可支配的時間，嘗試逐一修復

• 之所以沒成功，是因為有些時候我真的無能為力
  因為有些事情事前的確沒有預料到，但是如果你仍然希望自己不負眾望，那就趕緊去調整別人對你的預期，越快越好！
  如果你無法兌現承諾，那么最重要的就是盡早向你的承諾對象發出預警，越快越早越好。你越早向各方利益相關方發出預警信號，整個團隊就越有可能抓住機會，并重新評估當前的活動，并決定是否采取措施或者作出改變

• 如何說是

  • 試試的另一面，可以回答是，但是同時可以措辭更清楚的表達自己的不確定性

• 堅守原則

  • 不能放棄自己的底線，比如不寫測試，不做完整的回歸測試，代碼的清晰整潔

• 專業人士對自己的能力極限了如指掌。他們十分清楚自己還能保持效率加班多長時間，也非常明白要付出的代價

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

第四章編碼

1. 做好準備

• 我最糟糕的代碼，是凌晨3點寫出來的。
  在經過18個小時高強度的編碼之后（還不算上每周工作60~70小時），我已經想不出更好的解決方案了。我記得，當時對自己能夠勝任長時間工作感覺非常良好。我記得那種獻身工作的感覺，自己當時認為，凌晨三點還在忘我工作是多么專業的表現啊。當時錯的實在離譜！那些代碼后來回過頭來一遍又一遍的肆虐我們……
  這個故事給我們的教訓是：疲勞的時候，千萬不要寫代碼。奉獻精神和職業素養，更多意義上指 要遵循紀律原則 而非成長為長時間的工作狂。要確保自己已經將睡眠、健康和生活方式調整到最佳狀況，這樣才能做到在每天的8小時工作時間內全力以赴。
• 焦慮時寫的代碼
  這時產出的任何代碼都會是垃圾，因此此時應該先解決焦慮情緒。
  當然有許多焦慮無法再一兩個小時內便能解決，而且老板也無法長期容忍我們因為要解決個人問題而不投入工作。關鍵所在是要學會如何關閉后臺進程，或至少要能夠降低其優先級，這樣焦慮就不會造成持續的干擾。
  理想情況下，應該使用個人時間去解決個人問題。專業開發人員善于合理分配個人時間，以確保工作時間段中盡可能富有成效。

2. 流態區
   很多程序員在編寫代碼是會進入的一種意識高度集中但思維事業卻會收攏到狹窄的狀態。在這種狀態下，他們會感到 效率極高；在這種狀態中，他們會感到絕無錯誤。
   但是，我們要 避免進入流態區。這種意識狀態并非真的極為高效，也絕非毫無錯誤。這其實只是一種淺層冥想的狀態，在這種狀態下，為了追求所謂的速度，理性思考的能力會下降。
   在流態區，你可能可以敲出更多的代碼，其實可能沒有估計全局，因此你很可能會做出一些后來不得不推倒重來的決策。在流態區寫代碼可能會快一些， 但是后面你將不得不更多的回頭重新審視這些代碼。
   當我感覺到自己將要滑入流態區時，就會走開幾分鐘，換換腦筋。

• 音樂
  音樂有可能有助于你編寫代碼，也有可能將你們帶入流態區
• 中斷
  粗暴相對的回應方式通常都是因為流態區所致。被他人從流態區中拉出來，或者當你正努力進入流態區卻被其他人干擾時，你可能都會十分生氣。不管哪種情況，粗暴方式都與你如何看待劉流態區相關。
  有時候并非是因為流態區，而只是你正在努力理解一些十分復雜的東西，這要求你必須全神貫注。
  中斷無法避免，總有干擾會打斷你、消耗你的時間。發生這種情況時要記住一點，也許下次也會輪到你去打斷別人請求幫助。因此，禮貌的表現出樂于助人的態度才是專業的態度。

3. 阻塞
   有時候死活就是寫不出代碼來，通常會去找一些其他事情干；或者有一個結伴編程的小伙伴
   創造性輸出 依賴 創造性輸入，比如懸疑小說，詩，科幻小說等等
4. 調試
   測試驅動開發 會顯著的降低調試時間，作者大約只有原來的十分之一
5. 保持節奏
   軟件開發是一場馬拉松，而不是短跑沖刺。你無法全程一直以最快的速度沖刺來贏得比賽，只有通過保存體力和維持穩定節奏來取勝。無論是賽前還是賽中，馬拉松選手都會仔細調整好自己的身體狀態。專業程序員也會同樣仔細的保存好自己的精力和創造力。

• 知道何時應該離開一會
• 開車回家路上
• 洗澡

6. 進度延遲

• 管理延遲的訣竅，便是早期檢測和保持透明。
  • 最糟糕的情況是，你一直都在告訴每個人你會按時完成工作，到最后期限來臨之前你還在這樣說，但最終你只能讓他們大失所望。相反，要根據目標定期衡量進度，使用三個考慮到多種因素的期限：樂觀預估、標稱預估、悲觀預估。把全部三個數字呈現給團隊和利益相關者，并每天修正這些數字
  • 不要盲目沖刺。 如果可憐的開發人員在壓力之下最終屈服，統一盡力趕上截止日期，結局會十分悲慘。那些開發人員會開始抄近路，會額外加班加點工作，抱著創造奇跡的渺茫希望。這是制造災難的最佳秘訣，因為這種做法給自己、給團隊以及利益相關方帶來了一個錯誤的期望。這樣每個人都可以避免面對真正的問題，把做出必要的艱難決定的實際不斷后延。
  • 加班確實有用，而且有時候也有必要。有時候，通過一天工作是個小時再加上周末加班一兩天，你確實能夠達到原本不可能的進度。但是這么做的風險也很高。在額外加班20%的時間內，其實你并無法完成20%的額外工作。而且如果連續兩三個星期都要加班工作，則加班的措施必敗無疑。
  • 最糟糕不專業行為就是明知道還沒有完成任務卻宣稱已經完成。我們自欺欺人的認為任務已經完成的足夠好，然后轉入下一項任務，我們自己給自己找借口說 ，其他還沒來得及完成的工作可以等有更充裕時間的時候再來處理。這種做法具有傳染性 。如果一個程序員這么做，其他程序員看見了也會消防。這些人中肯定會有人把“完成”的標準壓的更低，后面其他人將會采用新的定義……可以通過創建一個確切定義的完成標準來避免交付失誤

7. 幫助
   幫助他人 以及 接受他人的幫助

第五章 測試驅動開發 （很難做到……）

• TDD 的三項法則
  • 在編好失敗單元測試之前，不要編寫任何產品代碼
  • 只要有一個單元測試失敗了，就不要再寫測試代碼；無法通過編譯也是一種測試情況
  • 產品代碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多寫
• TDD的優勢
• 確定性：通過測試的產品確信可以被交付
• 勇氣：擁有一套值得新來的測試，可以打消對修改代碼的恐懼！
  當程序員不再懼怕整理代碼時，他們便會動手整理！整潔的代碼更易于理解，更易于修改，也更易于擴展，代碼更簡潔了，缺陷也更少了。

第九章 時間管理

• 會議
  關于會議，有兩條真理：1）會議室必需的； 2）會議浪費了大量的時間

• 拒絕
  受到邀請的會議沒有必要全部參加，你應該理智的使用時間，謹慎的選擇應當參加哪些，禮貌拒絕哪些。
  邀請你參加會議的人并不負責管理你的時間，為時間負責的只有你。

• 離席
  會議并不總是按計劃進行的。有時候你正參加某個會議，但是發現如果之前對此會議知道的多一點，就不會來。還有時候，會議臨時增加了一體，或者某個討厭的家伙霸占了討論。這些年來，我學到了一條簡單規則：如果會議讓人厭煩，就離席。
  仔細管理自己的時間是你的責任。如果你發現參加某個會議是在浪費時間，就應當像個禮貌地辦法退出來。如果必須出席，可以選個恰當的時間來問問大家。你可以解釋說 ，自己抽不去更多時間用于這場會議，問問有沒有辦法加快討論，或者另選時間。
  重要的是，你應當明白，繼續待在會議室是浪費時間；繼續參加對你沒有多大意義的會議，是不專業的行為。因為你有責任合理分配老板給你的時間和金錢，所以，選個格式的機會商量如何離席，并非不專業的做法。

• 確定議程和目標
  為了合理使用有用的時間，會議應當有清晰的議程，確定每個議題所化的時間，以及明確的目標。
  如果收到會議邀請，務必弄清楚指定的議題是什么，每個議題花多長時間，要取得什么成果。如果得不到確切的答案，你可以禮貌拒絕。
  如果你已經出席會議，但發現已經偏離或者是放棄了原有議程，你應當要求詳細列出新的議題和議程。如果沒有答案，也應當在合適的時候禮貌離席。

• 爭論/反對
  凡是不能再5分鐘內解決的爭論，都不能靠辯說解決。爭論之所以要花這么多時間，是因為各方都拿不出足夠有力的證據。所以這類爭論依據的不是事實，而是信念。
  技術爭論很容易走入極端。每一方都有各種說法來支持自己的觀點，知識缺乏數據，在沒有數據的情況下，如果觀點無法在短時間內達成一致，就永遠無法達成一致。
  唯一的出路是，用數據說話

  • 提高嗓門、近距離對視、擺出不屑的姿態，這都不重要，長期來看，強力是無法解決爭論的，最終還是需要數據；
  • 有人同意結束爭論后，消極的對待結果，拒絕為解決問題出一份力。他們會安慰自己說：“既然其他人想要這么辦，那就這么辦吧” 這可能是非專業行為中最糟糕的了。千萬不要這么做，如果你同意了，那就必須拿出行動來。
  • 如果問題解決了，這個選擇就是對的。如果遇到了麻煩，你可以退回來選擇另外一條路。明智的做法是，選定一個時間點或者設定一系列標準，來決定什么時候放棄。
  • 要小心這類會議：他們的目的是發泄情緒，或者讓大家戰隊，如果會議上只有一面之詞，就要避免參加。
  • 如果爭論必須解決，就應當要求爭論各方在5分鐘時間內向大家擺明問題，然后大家投票，這樣，整個會議花的時間不會超過15分鐘。

• 注意力點數

• 睡眠 專業的開發人員會安排好他們的睡眠， 保證清晨有飽滿的注意力點去上班

• 咖啡因 對于某些人來說，適量的咖啡因可以幫他們更有效的使用注意力點數

• 恢復 在你不集中注意力的時候，注意力點數可以緩慢恢復。漫步一段長路，與朋友聊天，看看窗外，都有助于恢復。 我發現，一旦注意力點數耗盡，你就沒辦法控制注意力。你仍然可以寫代碼，但是多半需要第二天重寫，或者幾周之后備受這段代碼的煎熬。所以更好的辦法還是花30到60分鐘換換腦子

• 肌肉注意力 搏擊、太極、瑜伽之類體力活動使用的注意力是不同的。即便需要全神貫注，這種注意力也不同于編程時的注意力，因為他們需要的是肌肉的注意力，而編程需要的是心智的注意力

• 時間拆分和番茄工作法

• 25分鐘之內，不要讓任何事情打擾你的工作，如果有人來打斷你問問題，禮貌的問他能否過25分鐘之后再來問。畢竟，幾乎沒有事情會緊急到25分鐘都等不了。等25分鐘一過，停下手頭的工作，去處理這25分鐘內遇到的其他事情，然后休息五分鐘。然后再設定25分鐘，開始一個新的番茄時間段。每完成4各番茄時間段時間，休息半小時。（可以參考其他書籍）

• 重要的事情是，番茄時間是有生產率的，你可以真正做點事情。用于應付干擾、參加會議、休息等非工作事宜的時間，屬于非番茄時間

• 不錯的情況下你每天可以有12_{14個番茄時間段，糟糕的只有2}3個

• 番茄工作法的真正好處在于，在25分鐘的高效工作時間內，你有底氣拒絕任何干擾

• 要避免的行為

• 優先級錯亂

  • 無論什么原因，我們都可以找到辦法逃避真正的工作。你說服自己有些工作更緊急，所以轉去處理，這種行為叫做優先級錯亂--提高某個任務的優先級，之后就有借口推遲真正急迫的任務。優先級錯亂是自我麻醉的謊言，因為不能面對真正需要做的事情，所以我們告訴自己，其他事情更重要。我們知道這不是真的，但還用它來欺騙自己。
  • 其實這不是在欺騙自己：我們真正做的是在準備謊言--如果有人問自己在做什么事情，為什么這么做，我們就會擺出這些謊言。我們是在為他人對自己的判斷尋找理由和借口。顯然，不是專業的行為，專業開發人員會評估每個人物的優先級，排除個人的喜好和需要，按照真實的緊急程度來執行任務。

• 死胡同

  • 比如你做了決定，選擇了而走不通的技術道路。你對這個決定越是堅持，浪費的時間就越多。如果你認為這關系到自己的專業信譽，就永遠也走不出來。
  • 慎重的態度和積累的經驗可以幫你避免某些死胡同，但是沒法完全避免所有的。所以你真正需要的是，在走入死胡同時可以迅速意識到，并有足夠的勇氣走回頭路。這就是所謂的 坑法則： 如果你掉進了坑里，別挖！
  • 專業開發人員不會執拗于不容放棄也無法繞開的注意。他們會保持開放的頭腦來聽取其他意見，所以即使走到盡頭，他們仍然有其他選擇。

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

第十章 預估

預估是軟件開發人員面對的最簡單、也是最可怕的活動之一了。預估影響到的商業價值巨大，關乎聲譽，也給我們帶來了很多的苦惱和挫折。預估是業務人員和開發人員之間最主要的障礙，橫亙在雙方之間的種種不信任，幾乎都由它引發。
業務方覺得預估就是承諾，開發方覺得預估就是猜測，兩者相差迥異。

• 承諾

• 承諾是必須做到的。如果你承諾在某天做成某事，就必須按時完成。即便他意味著你必須每天工作12個小時，放棄周末的休假，也不得不如此。既然承諾了，就必須兌現。

• 專業開發人員不隨便承諾，除非他們確切知道可以完成。道理就是這么簡單。如果你被要求承諾做自己不確定的事情，那么就應當堅決拒絕。如果要求你承諾在某天完成，但是需要每天加班，周末加班，取消休假，那么最后的決定取決于你；不過，不要違背自己的意愿去勉強。

• 預估

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

• 不幸的是，大多數軟件開發人員都很不擅長預估。這不是因為他們沒有掌握關于預估的訣竅--根本沒有這樣的訣竅。預估的偏差總是很大，原因在于我們并不理解預估的實質。

• 預估不是個定數，預估的結果是一種概率分布。不要只看到可能性最高的那個數字 ，而要估計最大的數字。

• 總結
  專業開發人員能夠清楚區分預估和承諾。只有在確切知道可以完成的前提下，他們才會給出承諾。此外，他們也會小心避免給出暗示性的承諾。他們會盡可能清楚地說明預估的概率分布，這樣主管就可以做出合適的計劃。

• PERT Program Evaluation and Review Technique

  • O 樂觀預估，為了保證樂觀預估有意義，這個數字對應的概率應該小于1%
  • N 標稱預估，這是概率最大的數字
  • P 悲觀預估，這是最糟糕的數字，也應該小于1%
    平均時間 = (O + 4N + P) / 6
    標準差 = (P - O) / 6

• 大數定律
  預估是非常容易出錯的，所以才叫做預估。控制錯誤的辦法之一是使用大數定律。該定律的意思是：把大任務分成許多小任務，分開預估再加總，結果會比單獨評估大任務要準確的多。這樣做之所以能提高準確度，是因為小任務的預估錯誤幾乎可以忽略，不會對總的結果產生明顯影響。
  坦率的說，這也是比較樂觀的想法。預估中的錯誤通常會被低估而不是高估，所以拆分再加總很南做到完美。不過，把大任務拆分成小任務分開預估，仍然是個好辦法。有些錯誤會被忽略，而且拆分成小任務也更利于理解任務本身及其他意外因素。

第十一章 壓力

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

• 承諾
  業務方總是期望能夠拿到這些承諾，因為他們想消除風險，我們要做的就是是風險定量化并將他們陳述給業務方，這樣他們就能做好相應的準備。做不切實際的承諾會阻礙目標的實現，對公司和個人都沒好處。有時有人會代我們做出承諾。比如業務人員可能在沒有事先咨詢我們的情況下就像客戶做出了承諾。發生這種事情時，處于責任感我們必須主動幫助業務方找到方法來兌現這些承諾，但是一定不能接受這些承諾。
  專業人士總會千方百計的幫助業務方找到達成目標的方法，但并不一定要接受業務方代為做出的承諾。最終，如果我們無法兌現業務方所作出的承諾，那么該由當時做出承諾的人來承擔責任。

• 保持整潔
  快速前進確保最后期限的方法，便是保持整潔。專業人士不會為了快點前進而亂來。他們明白 快速但臟亂 是自相矛盾的說法，臟亂只會導致緩慢！

• 危機中的紀律
  觀察自己在危機時刻中的反應，就可以了解自己的信念。如果在危機中依然遵循著你守持的紀律，就說明你確實相信那些紀律。反過來說，如果在危機中改變行為，就說明你并不真正相信常規行為中的原則。
  如果平常時候你會注意保持代碼整潔，但在危機時刻你卻會產出會亂的代碼，說明你并不真正相信混亂會導致速度下降。
  選擇那些你在危機時刻依然會遵循的紀律原則，并且在所有工作中都遵守這些紀律。遵守這些紀律原則是避免陷入危機的最好途徑。
  當困境降臨時，也不要改變行為。

• 應對壓力

• 不要驚慌失措
  呆坐著煩躁不安也于事無補，而你可能會煩的最嚴重的錯誤，就是魯莽倉促！ 要避免產生孤注一擲的想法。魯莽倉促只會把你帶入更深的深淵。

• 溝通
  讓你的團隊和主管知道你正深陷困境之中。告訴他們你所制定的走出困境的計劃，請求他們的支援和指引。避免制造意料之外的詫異。

• 依靠你的紀律原則
  當事情十分困難時，要堅信你的紀律原則。之所以你會將之奉為紀律，是因為他們可以指引你度過高壓時期。這時候要更加留意全部的紀律原則，這不是質疑或者無端放棄他們的時候。

• 尋求幫助
  結對！結對伙伴會幫助你堅守原則紀律，防止你手足失措。搭檔會捕捉住你疏忽遺漏的事情，會提出有幫助的想法，會在你注意力迷失的時候接過你手中的工作繼續前進。

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

第十二章 協作

對做的事情充滿激情是好的，但是最好把注意力集中在付我們薪水的老板所追求的目標上。
專業程序員的首要職責是滿足雇主的需求。這意味著要和你的經理們，業務分析師們，測試工程師們和其他團隊成員很好的協作，深刻理解業務目標。這并不是說你必須成為業務方面的老學究，而是說你需要理解手上正在編寫的代碼的業務價值是什么，了解雇你的企業將如何從你的工作中獲取回報。
專業程序員最糟糕的表現是兩耳不聞窗外事，只顧一頭將自己埋在技術堆里，甚至連公司業務火燒眉毛行將崩潰了也不聞不問。你的工作職責就要讓業務免于陷入困頓，讓公司可以長久發展下去。
因此，專業程序員會花時間去理解業務。他們會和用戶討論他們正在使用的軟件，會和銷售人員與市場人員討論所遭遇的問題，會和經理們溝通，明確團隊的短期目標和長期目標。
簡而言之，他們會將注意力放在如何與業務同舟共濟上