【記錄】ThePrimegen 與 Uncle Bob的直播訪談心得

前言

2024-04-26晚上跟到了在twitch上的直播，ThePrimeagen邀請到了Uncle Bob進行訪談—沒錯，就是那位《Clean Code》、《Clean Architecture》、《Clean Agile》等書的作者Robert C. Martin。

整體訪談時間約一小時半，不知道youtube上會不會放上直播存檔。

幾年前剛看過clean code的演講紀錄，陸陸續續找到其他訪談影片，Uncle Bob的主軸跟說詞在每個影片幾乎一致，帶給我的感覺是：我的書已經完整記錄了我的想法，我也為各個章節準備好完整的故事架構，遇到演講或是遇到特定的問題，我就把那個章節拿出來再闡述一次。

因此，這次的訪談我想看看有沒有不一樣的東西。以下為憑印象理解的問答，整理出一些心得記錄：

使用Clojure語言的契機

作為第一個開場問題，SICP(Structure and Interpretation of Computer Programs)果然又被搬了出來，網路上找的到的公開課是使用LISP語言講述，偏向計算思維跟問題解決的養成。

對設計模式Design Pattern的看法

比起在什麼狀況下套用什麼模式，或是學習辨認設計模式，這裡給出的答案相對單純：

在溝通上可以快速的對焦實作方式。

例如某段程式中不想要多個if判斷分支，打算改寫套用策略模式(Strategy Pattern)，那麼有學過的人自然理解會改成什麼樣的做法，至少出來的雛型會是類似的結果。

過早的抽象化

讀過SOLID原則跟有點經驗的工程師大多知道，依賴該建立在抽象層(Interface、Abstract class)而不是實作的類別上，保有軟體修改的彈性。只不過，大多時候或是初期的案子，需求僅是完成功能實作，需要在此時就已經定義好這些抽象的介面嗎?

老實說，聽完這題的討論後，並沒有一個完整的結論。

Uncle bob給出的方式是他會先花一個小時的時間思考整體架構設計，接續著手進行開發試試，之後再回來修改。ThePrimegen的做法是我比較可能採取的方式，先針對需要的功能實作，日後有需要進行抽象化的情況，再進行處理。

100%測試覆蓋率

以妥協的結果來說，測試有其必要，但不是絕對完美。畢竟，我只能在我知道的範圍內，盡量測到100%，而我所不知道的部分，那也是無能為力。

另外一個寫測試必要的重點，是為了進行安全的重構。

以Uncle Bob的說法，當改動了一項功能，也該只有一項測試失敗，意味著依賴項目也只能有一項。某種程度上來說不容易，尤其是在企業級的系統架構下。

因此，在這一部份歸納下列兩點

• 只對重要、相對容易出錯的部分進行測試，盡量提高測試覆蓋率
• 建立重構的安全及更改彈性、增加程式碼推上線後不會爆掉的信心

Function的拆分

如clean code一書中提到，function應該要小，小到IDE不能再進行提取方法，並且給予一個適當、明確的名稱。然而我也遇過喜歡全部內容只寫在同一個大function的前輩，不希望透過IDE跳來跳去，穿梭在不同資料夾之間再拼湊回原本的邏輯。

於是，Uncle bob在這裡講了個類似進行early return的方式，即是將這些拆分後具有語意的小function，安排整理他們的順序。

敏捷開發

作為17位敏捷宣言的元老之一，他的想法其實都寫在了書中。此次訪談礙於時間及篇幅，從表述中聽起來意思偏向是：

當初人數不多，大家都是很有經驗的工程師，快速聚焦問題快速處理，定期同步進度

所以其實也是小團隊，完成很多小事情，累積起來達成一項大的里程碑，似乎不像PMP或PMBOK建立起來相對明確的制度及方法論。

總結

必須很誠實地說，上面提到的書我並沒有完全看過，至於提到的內容及思想，網路上都有作者在公開演講的錄影。畢竟透過書籍、翻譯、自我解讀等，總比不上作者本人講述來的直接，避免曲解最初的本意。

另外，直播主也是Netflix超過10年經驗以上的資深工程師，提問也是大多實務開發上非常實際的問題，很顯然這也是多數在實踐Clean code、SOLID、Design Pattern、Agile、TDD等方法論時會產生的疑惑。

從對談結果而言，無關好壞對錯，只能說：

原則大體適用，原則想達到的目的才是根本。