【記錄】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等方法論時會產生的疑惑。
從對談結果而言，無關好壞對錯，只能說：
原則大體適用，原則想達到的目的才是根本。
你可能也想看
