寫程式的各位或多或少都會欠下技術債,但是真的都會還清嗎?說真的,不還技術債會怎麼樣嗎?如果債主不上門,那又何必還債呢?你我當然清楚知道債主終究會上門,不過債主只會打 RD 而已。
技術債的嚴重性似乎總是很難傳達給非技術背景的人,Poga 在 《Why Server less》 一文中提出了 Serverless 架構的好處之一,就是可以直接用金錢來量化技術債:你的程式效能越差,你要花的成本就會越高。提升程式效能就是節省成本 — — 有了這樣直接的關係掛勾後,就很容易溝通還技術債這件事。
這的確是一個很棒的想法,不過並非所有技術債都能直接體現在程式執行期的效能上。可能是架構上的缺陷,需要因應現況調整,不然很容易出問題;又或者是會拖慢開發者的開發速度等等……。這類的技術債就無法用這樣的武器來作為溝通的手段。
時間和資源有限,能要到投入在還技術債的部分又更少了,很明顯沒辦法像信用卡帳單一樣在次月結帳日一次繳清,那肯定需要評估每個不同債主還債的先後順序。
我們平常在評估技術債的時候,通常都會使用「嚴重性」(Impact) 和「還債成本」(Fix cost) 這兩個面向來評估,直觀上當然是低成本,高影響的債會優先處理,但其實 Impact 一項中又包含了很多其他的面向。
在 Bill “LtRandolph” Clark 的《A Taxonoy of Tech Debt》 一文中,作者介紹了另一個評估技術債的面向:「傳染性」(Contagion)。傳染性指的是,如果這個技術債繼續存在下去,它會不會擴散到其他的部分?有可能是一個不好的寫法被用在更多地方,或者是隨著時間增多的錯誤的資料等等。如果一個技術債的擴散範圍已經被控制在一個非常小的地方,不太會隨著時間擴散出去,那麼儘管他的 Impact 很高,修復他的急迫性就沒那麼高了。
其實我們以往下意識也都會意識到傳染性這個面向,不過一般都是直接把他歸在 Impact 裡面一起去考慮,這樣在區分優先級的時候就很難評估哪一個應該先處理。現在將傳染性獨立拉出來看以後,就更容易決定哪些技術債是需要被優先處理的。
除此之外,作者也介紹了一個反轉傳染性的技巧,將原本大範圍,難以修復的技術債,透過擴散疫苗的方式漸漸轉為隨著時間過去,會越來越好的狀況。在文中舉的例子是,原本在 League of Legends 中大量使用 std::string
但使用起來比較麻煩,效能也較差。因此他們根據自己的需求實做了 AString
,因為用到的地方太多,沒有辦法一次全部換完,兩者必須共存一段時間。不過因為 AString
更容易使用,效能也更好,所以新寫的地方都會使用 AString
,舊的程式碼有改動的時候也有機會將 std::string
改為 AString
,在這個 case 中,這個傳染性就被反轉為負的,不需要急著大刀闊斧的一次把他修正完畢。
透過將 Contagion 獨立成一個評估的面向,加上原本有的 Impact 和 Fix cost,團隊就能更清楚的評估技術債的影響範圍,嚴重程度以及修復成本來決定優先順序。原文中作者也將他們團隊碰到的技術債分類,提供了常見的還債策略,以及列舉了他們實際碰到的例子,非常有趣的一篇文章,推薦各位閱讀(下面留言的討論也很精彩)。