無瑕的程式碼番外篇-專業程式設計師的生存之道(The Clean Coder) 讀書筆記
為The Clean Code(中譯無瑕的程式碼)的下集，作者為Robert C. Martin，人稱Uncle Bob
書籍介紹
無瑕的程式碼 番外篇－專業程式設計師的生存之道 (The Clean Coder: A Code of Conduct for Professional Programmers) 
本書是 無瑕的程式碼的下集，內容著重在如何成為一位專業的程式設計師。要成為一位專業的程式設計師，其實也就是成為一個負責任的人，對自己、自己寫的程式、公司、團隊、專案負責。這本書講述了滿多程式設計師會遇到的狀況，以及應對的方法，同時也提到了關於自身的技能培養與學習，我覺得是一本值得一看的書。
學習說不
作者在這一章強調，在自己沒把握的情況下，要堅守自己的原則說不，不能說試試看這種話，因為試試看就代表是一種承諾，而且說出試試看就代表之前都沒有全力以赴，這是一種不專業的行為。
我自己認為這個最難，因為主管與老闆們最不喜歡聽到的就是程式設計師說不，這會讓他們認為推託的感覺，我自己認為要提供一些資料輔助他們判斷，而不是憑空就說這個不行那個不行，要提出不行的原因在哪、以及一些解決方案，如果主管跟老闆們認為有時間壓力，就要跟他們溝通協調列出優先順序，商業價值含量高的先實作…等等，因為如果都全部照單全收，那最後累死的也會是自己，產出的東西質量也會很差。
學習說是
這個主題主要講的是承諾，一旦你給出承諾就一定要達成，但如果是有牽涉到其他組織或部門的工作，就不要輕易的承諾會完成，只承諾自己可以控制的範圍。
寫程式
作者在這一章講了幾個我覺得很有趣的內容，像是流態區(Flow zone) (又稱為神馳狀態)，一旦進入這個狀態之後寫程式的速度會飛快，會維持高度專注力。但作者認為在這個狀態會缺乏理性思考能力，反而對程式開發是有害的，只有在練習的時候這個狀態才會對你有幫助。
另一個主題是談到寫程式的情緒，如果感到焦慮或是心煩氣躁的時候，先讓自己冷靜下來，整理好情緒再繼續開發，最好的方式是先將情緒處理好，不要帶進公司影響自己的工作。
還有一個是關於幫助這件事，要成為一個專業的程式設計師，要不吝於幫助他人，也要學會請求別人的幫助。我自己就曾經遇過不願意接受別人幫助的同事，死命護住自己的地盤。我覺得程式設計是一種集體智慧，不是個人英雄式的單打獨鬥，一個人是走不遠的，果不其然，那位同事寫的程式發生問題，團隊的人都要幫他收拾殘局。我自己也是常常請其他同事幫我檢視看看我自己想的有沒有問題，因為明知道團隊有資源不用實在是太浪費了，況且同事們看法與角度一定與我不同，可以在這過程中學習。
關於超時加班這件事，作者裡面也有提到，除非你自己可以擠出這些時間、短期加班最多不超過兩周、你的老闆要有後備方案，否則不要輕易答應加班。我自己遇過的狀況是老闆在專案延遲時就要你固定加時工作，但加時工作讓團隊產出的效率更為降低，因為休息時間不夠，隔天帶著前一天的疲勞來上班，變成惡性循環，前一天開發的可能不是功能，而是BUG了。
練習
關於練習，作者提到Dojo(道場)與Kata(對打)，在工作之餘要經常練習，而且是利用自己的時間練習，因為雇主沒有義務要為你的職涯負責，作者也提到一周的工時是60小時，其中一周40(一天8小時)小時是為雇主工作，剩下的20小時是要為自己工作，等於一天要培養自己的技能3個小時。
不過我自己認為，如果工作上負擔沒有那麼重的話，在公司的資源與時間可以好好利用。
測試
關於測試，作者提了滿多建議，包含
完成的定義：程式碼完成、所有測試通過、QA測試通過、業務單位確認過，才叫完成
TDD(測試驅動開發)：程式設計師應該要學會TDD，這才是專業的表現，要確保自己開發的程式是正確沒有缺陷的，以攻守比喻來說，TDD是
攻，先寫功能在寫測試是守。驗收測試：要由業務人員與QA一起來撰寫驗收測試，它是需求文件，用來描述系統會提供什麼樣的功能，如果要由開發人員來寫，要與
開發功能的人不同。持續整合與自動化：要能將這些測試自動化，透過持續整合機制幫我們運行這些測試，如果有發生測試失敗，團隊要立即停下來修正程式，直到測試可以完全通過為止。
另一方面探討測試的策略，由上而下為
人工探索測試：就是非腳本化的測試，需要人工介入，確保系統在人工作業下運行良好。
系統測試：最終的整合測試，用來測試組裝好的系統各個部分是否可以正確交互操作，由架構師操作，在這個層級
必須包含性能與產能測試整合測試：是一種編排性的測試，確認元件組裝之後是否協調，由架構師撰寫，在這個層級已經可以進行
性能與產能測試了元件測試：是
驗收測試的一種，對業務規則的一種驗收測試，由QA與業務人員撰寫。主要測試成功路徑的狀況單元測試：由程式設計師撰寫，確保程式碼意圖沒有遭到破壞，且程式碼是運作正確的，要包含邊界與異常狀況
時間管理
作者有提到要管理自己的時間與專注力，要適時的拒絕沒效率的會議，以及要避免優先順序錯亂，另外也介紹了作者使用番茄工作法來管理自己的時間。
關於會議，我自己遇過的是，會議的主持方完全沒有準備，在會議上天馬行空的討論好幾個小時，但會議結束後完全沒有結論與決策方向，可能過個幾天又要再來一次，自己的時間完全被開會這件事吃掉，在開會的途中也不太能開發程式，實在是很浪費時間，我覺得最好的做法是，先確定開會的主題與方案，在會議前先發給所有與會的人，說明我們的主題聚焦在這幾個部分，單就這幾個部分做討論，在開會的時候只要決定方向就好了。
結語
整本書看下來，如果你的工作是從事程式開發，一定或多或少會遇到書中提及的狀況，這時候就會覺得自己並不孤單，因為連大師級的作者都會遇到了，沒道理自己不會遇到，我想作者就是經歷過這些，也有一套很好的處理的原則與方法，所以才會成為大師的吧。所以當你遇到困境，不知道該怎麼處理的時候，來翻翻這本書吧，或許大師的智慧能夠幫助你度過困境。