2020年2月26日 星期三

Changelog - 好的技術債


前言

"債"在工程界通常被認為是不好的例如技術債. 但在金融界, "債"卻是很中性的, 當一個人舉債買房的時候, 我們還會說聲恭喜. 差別在於"意圖": 我們是否"有意識"的欠下這筆債, 並且有未來的還債計劃. 如果在工程界, 我們也以同樣中性的態度來對待"技術債", 可行嗎? 如同金融界, 債有各種種類, 有貸款, 有呆帳... , 那麼在工程界, 什麼是"好的"技術債?

鷹架

對於一個大型的專案, 我們會先專注於它的核心或是不確定的部份, 但我們不應該僅是把不確定的元件先做出來就好, 我們要能夠驗證這些元件. 換言之, 我們要把整條使用路徑做出來, 但不是核心的部份不需要講究細節, 它們可能是先用一些用過即丟的實作方式 ( 要記得把這部份的實作包裝起來, 方便之後替換), 只是為了打通使用路徑, 好讓專案經理或測識人員可以驗證核心的元件, 並收到真實使用狀況的反饋, 收集資料, 確認使用者是否真的需要這個功能. 這些測試用的元件就像專案的鷹架, 它方便我們在過程中專心去打磨核心部份, 並在專案完成後拆除.

使用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-debt

https://changelog.com/podcast/379

沒有留言: