The Clean Coder

無瑕的程式碼番外篇

因為接下來會開始進行主題「開發」的篇章了，而只要提到開發，程式碼品質就是很重要的要素，但程式碼的好壞有時相對主觀，畢竟在現實中往往沒有完美的方案，只有適合的方案。

但是比起程式碼的好壞，成為 The Clean Coder 我想是更具體更有方向的目標，就在正式進入開發環節之前，先來分享一下我讀完 The Clean Coder 這本書後的感想與摘要吧。

好的程式架構

沒有完美的程式，但專業人士每次交付的都必須是有把握的程式碼

而什麼是沒有把握的程式碼呢？

沒有經過測試的程式碼都是！

不斷的重構

有一種有效但也很有壓力的作法就是：
每次 Check in 程式碼的時候，都要讓程式碼比 Check out 的時候更好一點。

但是很少人會對運作中的程式進行改動
為什麼？

測試驅動開發TDD

（Test Driven Development）

1. 編寫測試前不可編寫程式
2. 編寫測試
3. 編寫剛好能通過該測試的 Code

放棄專業素養是失敗的主因

為了滿足客戶不合理的時程，也許開發者會選擇比較 硬幹 的方式，只為了能多擠出一些時間

但其實這只會因為更多不可預期的狀況，讓自己陷入泥潭之中，而且往往客戶所想要的功能，實際開發起來會比一開始說的還要複雜且多變，如果處處都是難以擴展不可維護的程式碼...

說不的重要性

不要對時程進度或是功能有樂觀的想法。

只要確信有執行上有無法完成的項次，就必須準確並堅定的表達，以此才能有真正解決問題的機會，畢竟抱持著沒有根據的樂觀，往往只會讓狀況處在既糟糕又難以應變的情境中。

承諾

專業人士不輕易承諾，但是一旦承諾就必須做到

協作中特別警惕...

我盡力試試

這種 應付型承諾

預估時程

三元分析法
O：樂觀預估
N：常規預估
P：悲觀預估
期望完成時間 = (O + 4N + P) / 6
偏差值 = (P - O) / 6