像小說一樣好讀卻又像教材一樣重要的 - The Clean Coder 無瑕的程式碼番外篇

Fri Sep 10 2021

前端開發

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

# 好的程式架構

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

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

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

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

# 不斷的重構

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

每次 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