這是一本調適與人與程式碼相處的狀態對應書
之前看完 無暇的程式碼 本篇，深深覺得這作者一定曾在職場上會被玩過好幾輪（如果是在台灣的話），雖然裡面的內容很實在，我也很認同，但是實際上到底可不可能，又是一回事吧，又或者他其實是拼了老命搞起來，比在台灣推行罷工法還要難的情況，成功推起來，只是用談笑風生得方式講得很像很容易。
在職場上，你的大老闆可能完全不在意你寫得code 到底乾不乾淨，他可能只在乎 schedule 有沒有 delay，這種情況在台灣更加嚴重，因此如何成為一個不讓自己加班到肝壞掉，又能寫出clean code的 clean coder 可能更加困難。那麼bob大叔在美國就沒有這問題嗎？
果不其然大叔還有出另外一本書，也就是番外篇 The Clean coder，敘述他部份的人生自傳，從年紀輕輕啥都不會後來位居高位，當然這只是他說得，其實他剛出道就很強了，但是這不是重點，這本書更重要的是他如何成為一個 clean coder(中文：專業程式設計師)的經驗談。
沒想到簡介我就自己掰出那麼多，但是其實一開始打算只是當作閒書看看，畢竟道理人人懂，實際要應用時又是一套。當然工作幾年了，還在業界鬼混，想必都有自己的一兩套手法。後面我就自己隨便貼上自己的經驗跟書中的驗證。 各位就不要太考究了
『專業主義』
專業人員該會得幾個項目：
- Design patterns：必須能描述GoF的24個設計模式，同時對於POSA書中所介紹的許多模式都有實戰經驗。
- Design principles：SOLID原則
- Methods：XP、Scrum、Lean、Kanban、Waterfall、Structured Analysis、Structured Design。
- Disciplines：TDD、Object-Oriented Design、Structured Programming、Continuous Integration、Pair Programming。
- Artifacts：UML、DFD、Structure Chart、Petri Net、State Transition Diagram and Table、Flow Chart、Decision Table。
（p.52）這東西很多連看都沒看過，但是可以作為下一階段要讀得東西，但是我覺得最重要得是 p.53 所提到的『堅持學習』
『堅持學習』
軟體行業飛速改變，這代表者軟體工程師必須堅持廣泛學習才不會被時代淘汰，我認為這是這行業一直以來最大的優點跟缺點，能不斷的學習代表這東西永遠在發展，可以拉出與一般行業的薪水差距，但也是因為這一點，造成你會非常累，如同此blog的標題『學海無涯這件事整個麻煩』，堅持學習大概是這一行業最高的門檻了吧
(p.53)
『說不』
奴隸沒有權利說不，勞工或許也對說不有所顧慮，但是專業人士應該懂得說不。事實上優秀的經理人對於敢說不的人總是求賢若渴。
(p.59) 老實說，台灣的優秀經理人可能都在國外，然後國內只有奴隸，結論就是這樣，『說不』等於沒有工作。
『說是』
這句話就是一種承諾，這需要三個步驟
1. 口頭上說自己將會去作
2. 心裡認真的對待自己做出去的承諾
3. 真的付諸行動去作
很多情況大家都會停在第一步驟，尤其是你委託非你自己的人，需要跨部合作的情況。bob 大叔有提到幾個他決得很可能只是說說的單字像是 need , should , hope , wish , let’s，這還蠻有趣的，各位可以試試看如何對應到中文單字裡。
那麼真正的承諾應該是？ 在你對自己將作何事明確描述之後，並能確定期限，像是 我將在xxxx日之前，把xxxx任務完成。
(p.81) 重點就是找出誰說謊，然後如何不讓自己說謊，但是發現工作到現在，幾乎都是先把對方當作沒作承諾的人，要一直催
『流態區(the flow zone)』
其實寫程式這整個章節就是在談要保持一個良好的狀態去執行寫程式，當你在焦慮，半夜想睡覺時寫得東西八成不會好到哪裡，而比較特別的是作者也把『專注時進入的高效率狀態』也視為一種不良好的狀態，理由就是你會無法顧及大局，造成後續的問題，而解決得這情況的方法就是 pair programing ，然後也不要聽音樂，對於別人的中斷也會感到火大。
(p.95) 其實我覺得流態區超棒的，這裡見仁見智，還有隨便中斷它人工作不太好吧。
『保持節奏』
進可能的保持節奏，不要和問題一直貼的那麼近，尤其是阻塞和出錯的時候。大部分的情況不要用盲目衝刺，也就是超時加班的方式，除非是以下三個條件都符合
1. 你個人能擠出這些時間
2. 短期加班，最多兩週
3. 你老闆要有備案（最關鍵）
(p.102) 真的不要變成常態
『幫助』
幫助他人與接受幫助
訂出明確的時間帶，讓他人可以向你尋求協助，不要死命護住自己的地盤拒絕他人的協助。
(p.106) 其實最怕的是，你打算幫助他人，結果被人當作來找碴，不然就是對方心中早有一套方案，來問你只是想尋求贊同，不同意見還會被當成找碴的
『TDD , Test driven development』
這部份詳細的規則可以回去看前面的章節，簡單來說就是 TDD 可以幫助你成為一名Clean coder，如過你不用的話，可能你還不夠專業。
(P.110) 專案類型的，像衛生紙的案子用起來可能就是其侷限
『練習』
要利用機會多作練習，養成練習的習慣。參與 Open source project，沒有壓力的寫程式可能是最高效率的方法。
『每周工作40 + 20小時』
(p.117)
『驗收測試』
細節的交流事件麻煩事情，尤其是開發方和業務方的程式細節交流，很多情況下雙方的『完成 (done)』 是完全不同的，但是雙方還是可以帶這微笑的回去報告交待，因此需要詳細的協商，並訂出自動化規範，並保持其權威姓。
『避免過早精細化』
在專案剛啟動，業務方盒開發方都希望能精確的能得知最後
不確定原則：如果你巷業務方展示你的部份成果，他門就獲得新的資訊，但同時也會回饋給你他門對愈這系統新的看法。在這連續影響之下，很高機率離完成越來越遠。
預估焦慮：簡單來說需求一定會變，即使有精確的資訊，但是預估起來還是存有據大的變數。
『測試策略』
任何團隊都要有一套好的策略，『自動化測試金字塔』是一個不錯的指標
1. 單元測試 100% xunit
2. 元件測試 50% api
3. 整合測試 20% api
4. 系統測試 10% gui
5. 人工探索式測試 5%
『QA應該找不到任何錯誤』 這只能說是一個目標，儘管公司可能有一支專業的QA團隊，再送測之前，要確保自己功能完整，沒有發現 bug，以下關於ＱＡ有機個準則可已參考
QA 也是團隊的一部份
QA 是需求規約定義者（ 英文更棒，QA as Specifiers）。
QA 是特性描述者 （QA as Characterizers）
(p.125-146)
『時間管理』
時間與專注力都是有限的，透過管理各種行為保持高效率。
『會議』
這東西有兩條真理
1. 會議是必須的，
2. 會議浪費了大量時間
根據bob大叔的說法，每人每小時兩百美金。在這樣昂貴的成本之下必須懂得『拒絕』『離席』，當然一個好老闆可以幫助你脫離冗長的會議，更重要的是為你自己的時間負責。
(p.148)
『立會』
1. 我昨天做了何事？
2. 我今天打算做何事？
3. 我遇到了捨麼問提？
開會議的時候每個人都必須站者回答，每個人的回答時間應該不超過一分鐘，整體不應該超過十分鐘。
(p.150) 按照我前一任老闆的玩法，只是變成大家站者40分鐘，聽他教你該做何事。
『爭論與反對』
kent beck 提到『凡事不能在五分鐘內解決的爭論，都不能靠辯論解決』，主要就是雙方都拿不出有利的證據，最後變成爭論的不是『事實』，而是『信念』，而唯一解決的方法就是『去取得資料，讓資料來說話』，但更多的情況是有人開始提高嗓門，也有人開始消極。
(p.153) 對於這一點，我認為爭論是好的，因為可能可以找出更棒的東西，但是我看到更常常是『信念』對決，而平常自己如果沒有累積對技術的累積，對方也沒有的話，就會很容易流入口角。
『蕃茄工作法』
直接看wiki
提供一個chrome 插件
(p.154)
『優先順序錯亂』
無論什麼原因，我們都可以找到辦法逃避真正的工作。你說服自己有些工作更緊急，所以轉而去處理，這種行為叫做優先順序錯亂──提高某項任務的優先順序，之後就有藉口延後真正急迫的任務。優先順序錯亂是自我麻醉的謊言，因為不能面對真正需要做的事情，所以我們告訴自己，其他事情更重要。我們知道這不是真的，但還用它來欺騙自己。
(p.155) 抱歉，這一段我只能哈哈哈認同，雖然我不太這樣幹，該怎麼說，事實上事件優先度還是該有的，這可以是根據不同專案的dead line來定義，或者跟pm談完後再來定義。
『預估』
這篇不錯
專業人員一旦作出了承諾，就會提供確定的數字，如果做不到，便不會給出『承諾』，但在大多數情況下都不會做出確切數字的承諾，而是提供機率預測，來描述『期望的完成時間』，及『可能的變數』
(p.157-168) 有關預估我還蠻喜歡我朋友說的，先切好任務後，一個一個推估時間，然後最後加起來乘二就可以啦
『壓力』
這篇無感，簡單來說就是預防勝於治療，一開始就不要做出會讓自己產生壓力的承諾，但是真的遇上時也要保持紀律的面對
(p.171)
『協作』
寫程式這件事情隨者程式越來越大，合作是必然的，因而掌控各個角色之間的關係是很重要的事情。當然這裡bob大叔還是最推 pair programing with other coder.
(p.175) 有點像在講廢話，不過bob大叔也是分享了他當年被玩壞（解僱）的故事
『團隊與專案』
專業的開發組織會把項目分配給已形成凝聚力的團隊，而不會圍繞著項目來組建團隊。配合前一章節的說法，有凝聚力的團隊代表者協作上已經很久，產生的效益自然也高
(p.184) 雖然我覺得這章節的重點沒啥好質疑，但是目前台灣的公司還是偏向以 pool 的方式，去指派開發者到各個專案去執行，對於這樣能產生的彈性好處是不能否認的，還記得大主管曾經對我說過，用pool方式很好分配工作，但是很難讓開發者專注在一個領域。對單一開發者是好還是不好很難說。
『輔導，學徒期與工藝典範』
學校能夠傳授電腦程式設計的理論，但是無法傳授你成為程式設計師的原則，實踐，技能。
(p.200) 要我來說的話，工作階段就只有 on job training , 我也不知道該說啥
『工具』
(p.210) 這部分沒啥好說的，就是『工欲善其事，必先利其器』，想到最近跟公司要個iphone 來測試，卻遲遲沒有下落，哀哀哀哀
感謝各位看官看到這裡，遮應該也是 clean code的最後一章節了，很多部分都是我自己的碎碎唸，不認同或是想聊聊都歡迎在底下留言討論。
前集回顧
Clean code: 無瑕的程式碼 – 書摘心得（一）
Clean code: 無瑕的程式碼 – 書摘心得（二）