技術債要不要還？

August 03 21:18~23:10

 

沒錢、沒富爸爸、長相善良但又想買最新的智慧型手機、出國旅遊、買名牌包，怎麼辦？俗話說「輸人不輸陣」，別人都有我也要有，刷卡先買了再說，反正每個月還利息還頂得住。債務就是這樣一點一滴累積下來。

軟體開發也有累積債務的問題，叫做技術債（technical debt）。這個說法是Ward Cunningham所提出的一種比喻，它是開發人員針對以下兩種狀況取捨之後的結果：

• 用比較高的成本寫出乾淨程式碼但可能發生延遲交付的成本。
• 用廉價成本快速寫出可以動但是亂七八糟的程式，但在產品釋出之後必須負擔較高的維護成本。

俗話說：「出來混總有一天要還。」欠債還錢，天經地義。談到技術債也是如此，有良心的人 一般人認為總有一天需要償還，只是時間早晚而已。但世風日下，人心不古。欠債真的需要還嗎？如果要還，怎麼還？針對這個問題，今天介紹2011年11/12月發表在IEEE Software上的文章「To Pay or Not to Pay Technical Debt」所提到的三種狀況。

***

債務償還

第一種狀況是準備清償債務，文中提到一個例子，某個作者曾參與開發的系統系統有一個元件的介面有高達350個以上的函數，而該系統的核心子系統約有9000個函數。導致這種現象的原因是因為一但介面發布之後，團隊嚴格遵守不修改已公布界面的規則。可想而知隨著系統演進，無用的函數越來越多，造成介面極度膨脹。

管理階層經過分析之後覺得需要啟動一個大規模的再造工程來確保投資。他們重新設計精簡的介面，然後再逐步轉移所有產品到這個新的系統上。

***

債務轉換

第二種轉況是不直接清償債務，但是用間接的方式將債務轉換成另一種形式加以償還。作者提到有一個系統因為模組化設計不良導致非常嚴重的執行效率問題。軟體架構並沒有反應系統問題領域的結構，而是反應出組織部門的結構。這個現象非常普遍，因為「喬不動組織文化只好喬軟體架構」。架構師也知道這個問題，但是為了加速程式開發，只好有意的累積技術債以便先繞過人（組織）的問題。

累積技術債的利息變成減少生意機會（因為系統效能不好）以及更高的效能調教費用。這個利息負擔太重，於是大家聚在一起討論如何以及何時改善這個問題。經過冗長的討論之後，還是沒有結論（就說人的問題很難喬啊）。最後團隊決定在不改變現有架構的前提之下，把一個直譯器元件（interpreter）換成執行期間編譯器（runtime compiler），解決了效能的問題。

原本的問題並沒有被解決，不良的系統模組還是存在。改用新方案之後，付出的代價是犧牲原本直譯器的執行期間彈性。但是這個「新利息」比起原本的利息（減少生意機會與較高的效能調教費用）划算許多，算是一種「借新債還舊債」的概念。

***

只付利息

最後一個情況是只付利息不還本金。鄉民們是否還記得在〈是什麼讓軟體架構師成功？〉提到軟體系統上線好一段時間之後可能處在維持狀態，在系統退休之前，公司不想投入更多資源在上面，只要技術債所付出的利息在可以接受的狀況之下，那就繼續付利息就好。

***

技術債從何而來？

相信很多鄉民都有接過銀行電話問你要不要借錢的經驗。就算利息很低，沒事應該不會跑去跟銀行借錢。同理，沒事不會特意累積技術債。累積技術債最好是「有意為之」，就好像生意人為了投資設備跟銀行借錢一樣，開發人員，尤其是專案負責人，必須清楚知道為什麼目的而欠下技術債以及思考償債計畫。例如，為了滿足短期商業目標（參加電腦展）累積技術債，在展覽之後如果客戶反應不佳就無須還債（產品直接終止開發）。但是，如果反應不錯準備持續開發，就需要主動思考何時以及如何還技術債。

***

結論

是否欠技術債、何時、如何還債，應該從商業角度做最優先考量。技術觀點當然也是考量的重要因素之一，但不應主導如何處置技術債的決定。講是這樣講，但做起來並不容易。因為實務上你期待累積技術債可以讓產品開發得比較快，在某個時間點之前的確是如此，但過了臨界點之後累積更多技術債只會讓你的軟體開發變得更慢而非更快。難就難在你不知道這個臨界點發生在什麼時候。

也許累積技術債所衍生的利息大於借債所帶來的潛在利潤時，就該思考是否要還債或準備倒債的時候了。

***

友藏內心獨白：需要請會計師來幫忙嗎XD。