這是一本像小說一樣好讀卻又像教材一樣重要的書，這本番外篇不像本傳一樣給你滿滿的燒腦與技術，這本更像是要給你個當頭棒喝要你好好做人 ，不然相遇的到。

好的程式架構

首先第一棒就要是討論何謂好的程式架構？大家都知道沒有完美的程式，但身為專業人士每次交付的都必須是有把握的程式碼。

但問題來了，什麼是沒有把握的程式碼呢？

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

從開頭就點出了測試的重要性。

不斷的重構

而要產出好的程式架構，有一種有效但也很有壓力的作法就是：

每次 Check in 程式碼的時候，都要讓程式碼比 Check out 的時候更好一點。
但你仔細想想，是不是很少人會對運作中的程式進行改動？

為什麼？

因為沒有寫足夠的單元測試啊！

測試驅動開發TDD（Test Driven Development）

作者本身更是 TDD 這個開法理念的傳教士，書中極力的推廣 TDD 的好處，而 TDD 的大方向其實也不難理解，就是下面三個要點：

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

不過以我個人的經驗來說，前端領域要採用 TDD 其實有其相應的困難性，不但有複雜多變的業務邏輯，還包含了 UI 層面的各種狀態、結構，TDD 的傾象屬於寫一小段測試後寫一小段 Code，但前端的頁面結構未明之前，其實測試相當難以撰寫，若以「頁面」為單位，又容易寫出過大、空泛的測試案例。

所以我比較傾向使用 TDD 開發共用方法、與共用組件，待需求開發完成後，再透過 BDD 行為驅動開發（Behavior Driven Development）的模式來補上業務邏輯與 UI 相關的測試。

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

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

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

那可真是一場悲劇，不是嗎？

說不的重要性

最後就是討論工程師最頭痛的話題了：時程。

作者不斷地強調： 不要對時程進度或是功能有樂觀的想法。

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

這點其實我自己也有過幾次發生的經驗，自以為只要多拼一下，晚上假日加個班就可以如期完成，滿足 PM 提出的時程需求，但往往都事與願違。

通常只要你沒有絕對的把握，那就絕對不會順利。

承諾

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

尤其協作中要特別警惕...

我盡力試試 這種 應付型承諾

也要警醒自己不要給出這樣的承諾，因為給出這種承諾的人，就是上面提到的「沒有絕對的把握」。

這只是一種給自己留退路的承諾，讓事情不如人意的時候還可以拿來推託的藉口。

預估時程

時程預估這件事情很有趣，書中有分享了一個調查，發現最後實際需要的時程不但很難是我們的樂觀預估，更是幾乎每次都會超出我們的常規預估。

這一點也又呼應了 不要對時程進度或是功能有樂觀的想法 這個要點。

所以最後就來分享一下作者建議的時程預估法： 三元分析法

• O：樂觀預估，一切順利的情況下可能完成的時間
• N：常規預估，算上可能遇到的阻礙、臨時的會議等等變數後評估的時間
• P：悲觀預估，把情況計算到最壞最壞，所有莫名其妙問題都算上去之後的時間

通常來說這三個數值會有相當大的落差，列出來之後就可以透過下面的公式來個簡單的計算

期望完成時間 = (O + 4N + P) / 6
偏差值 = (P - O) / 6

Be a Clean Coder