書評：管理技術債
開發軟體時，基於時間，選擇一些簡易但有副作用的方法，日後終究要償還...
書本第二章用了深刻的例子描述技術負債。首先有個軟體元件A，沒有妥善設計；接下來設計B有兩個策略
- B基於A，只要3小時即可完工，但有可能的技術風險
- 花3小時重新撰寫A'，修掉潛在問題，再花3小時編寫B，總計6小時
接下來如果要撰寫下一個元件C，又會再面臨三個選擇
- C基於A'，只要3小時
- C基於A，但是由於潛在的問題，花了5小時完工（3小時工時，2小時利息）
- 花3小時重新撰寫A'，修復潛在問題，再花3小時編寫B，最後再花3小時編寫C，總計9小時
因為原先架構不良，導致增加新的原件，都要更長的開發時間，支付利息；同時增加的軟體元件會提高系統複雜度，讓債務的本金增加。當我們編寫C，如果想修正最初的錯誤，就得同時修正A/B才行。當系統越來越大，技術債越來越高，就會越來越難修改；但是新增軟體元件，也會隨著技術債增加，因而越來越難開發
上述的隱喻代表
- 早日清償債務是好的
- 欠下債務，可以換取時間，代價是拿未來的時間交換
- 我們需要認真評估，什麼時候該欠下債務，什麼時候應該積極償債
所有系統都有技術債，有些技術債來自於開發者，也許人類多努力一下就能克服；有些來自技術變遷，比如雲端技術當紅，但是舊的軟體還是本機程式，幾乎改不動！整本書，其實就是圍繞著上述的範例，介紹怎麼管理技術負債，概念很簡單，網路上撈技術債，也有不少文章
出來跑，遲早要還的，我個人選擇盡量把債清掉，讓後面走得輕鬆一些。有些債來自系統層，例如架構的選擇，想還也還不起；只能一代一代的，有機會就加減修正；或是與債務共存下去
留言