前言
"債"在工程界通常被認為是不好的, 例如技術債. 但在金融界, "債"卻是很中性的, 當一個人舉債買房的時候, 我們還會說聲恭喜. 差別在於"意圖": 我們是否"有意識"的欠下這筆債, 並且有未來的還債計劃. 如果在工程界, 我們也以同樣中性的態度來對待"技術債", 可行嗎? 如同金融界, 債有各種種類, 有貸款, 有呆帳... , 那麼在工程界, 什麼是"好的"技術債?鷹架
對於一個大型的專案, 我們會先專注於它的核心或是不確定的部份, 但我們不應該僅是把不確定的元件先做出來就好, 我們要能夠驗證這些元件. 換言之, 我們要把整條使用路徑做出來, 但不是核心的部份不需要講究細節, 它們可能是先用一些用過即丟的實作方式 ( 要記得把這部份的實作包裝起來, 方便之後替換), 只是為了打通使用路徑, 好讓專案經理或測識人員可以驗證核心的元件, 並收到真實使用狀況的反饋, 收集資料, 確認使用者是否真的需要這個功能. 這些測試用的元件就像專案的鷹架, 它方便我們在過程中專心去打磨核心部份, 並在專案完成後拆除.使用Hardcode實作
舉個例子, 專案想要開發一個功能：當網站內容更新的時候, 使用者可以收到通知. 要實作這個功能包含數個部份, 例如使用者要有"訂閱"按紐來啟動這個通知, 也需要"取消"來停止通知, 需要有機制偵測內容更新, 需要可以寄信給有訂閱的使用者等, 但一開始, 我們可以先省略訂閱/取消等步驟, 寄信的對象可以hardcode, 寄信的方式可以不用考慮使用者的數量, 只要能夠寄給少數使用者即可, 那麼我們就可以在很短的時間裡面完成這個功能並驗證它. 或者, 如果專案經理想知道有多少使用者需要"內容更新通知"功能, 第一步可能是hardcode假的按紐, 收集按紐的點擊狀況, 通知的功能先不實作, 而是人工通知.使用"Hardcode"實作必須確認 (1) 你的專案是否需要即時更新？ Hardcode有個明顯的缺點, 就是當也內容需要更新時, 就需要布署新的code, 需要時間. (2) 是否可以使用既存的架構？ 如果使用hardcode 可以省下開發新的元件或架構, 就很值得.
不用修正所有的極端case
舉個例子, 有時我們在開發分散式系統時, 會碰到race conditon的問題. 如果要"完美的"修正, 就必須加上distributed lock. 但實作lock, 可能會帶來更多其他複雜的問題, 因此我們可以先觀察看看race condtion發生的機率. 如果發現根本不會踩到. 我們可以考慮留下這個已知的問題, 節省修正的時間.總結
我們擁有債務的原因是：即使我們現在沒有足夠的現金, 我們也可以今天擁有房子, 而不是三十年後. 有時候我們推出一個服務, 不需要完美的實作, 但我們需要在正確的時機讓服務上市.很多不在計劃中的技術債是因為一開始野心太大, 想的太多, 無法收尾. 如果我們在一開始盡量做得簡單, 做得少, 之後發現缺少什麼, 或是不適用, 可以再加上去或替換掉.
為了達到這個目的, 我們也會做到元件化, 減少元件間的相依性, 方便之後替換. 好的技術債會清楚知道可以做到什麼, 不能做到什麼, 也應留下清楚的文件來說明.
那麼, 什麼時候是我們該清償這些技術債的時候呢? (1) 我們很清楚哪些是鷹架元件, 鷹架在房子完成時, 就會拆除, 同理亦然. 專案的鷹架會在完成時拆除, 不然就不叫完成 (2) 當這些準備未來替換的元件開始與其他元件有相依性時, 就代表我們該拆除它了, 不然這些元件可能會互相影響, 危及我們並沒有計劃替換的元件.
reference source:
https://engineering.squarespace.com/blog/2019/three-kinds-of-good-tech-debthttps://changelog.com/podcast/379
