連 PM 也必須了解的存在 - 技術債與遺留程式碼

Messy desk

什麼是「技術債」? 什麼是「遺留的程式碼」?

技術債 (Technical Debt) 是指在某些情況或是因素,不得已只好暫時以堪用的方式撰寫的程式碼,而技術債常會與俗稱「遺留的程式碼」 (Legacy Code) 一同被提起。

技術債容易發生在專案功能開發時會造成的狀況:

  • 為了時程上所需,所以不得不先寫出能達到客戶需求,但是程式碼會較雜亂、省略了撰寫測試的時間,而讓產品在後續維護成本上提高。
  • 而撰寫雜亂的程式碼,會讓開發產能降低,為了解決產能,又新增更多人員來協助
  • Bug 一直存留在程式碼內,也沒有測試出來,結果後面才發現他是個 Bug ,但已經有太多功能仰賴在這個 Bug 上 (爆炸)

當積欠大量的技術債程式碼,也會讓在專案管理預測時間上多出很多不確定性(=未知的地雷)。

而遺留的程式碼造成的原因有好幾種可能:

  • 系統升級後,舊有程式碼還停留在原地沒有做改變
  • 時代變化,舊有程式碼跟不上新改版的速度
  • 撰寫程式碼的人已經不在職,無法交接
  • 程式碼沒有任何文件 / 測試可作為依循及參考

根據維基百科上對於遺留程式碼的敘述:

In practice, most source code has some dependency on the platform for which it is designed – even if a programmer uses a platform-independent programming language like Java, it is hard to write a large, useful program that is totally independent of its environment.

可以看出程式碼之所以會變成 Legecy code,可能是因為實際設計操作的環境改變,但並沒有修改程式碼去因應這種情況,另外,事實上,寫出能夠獨立於平台之外,不受到環境改變而被影響的程式碼,本身就是一件不易達成的事情。

後人接收到前人遺留下來的程式碼不免都會一陣皺眉,畢竟若沒有文件可依循及妥善交接,勢必要花上一大陣子時間去理解,且其中可能會有上述提及到的技術債包含在其內,而讓整個程式碼變的雜亂且難以理解,雪球越滾越大。

我們或許可以把技術債跟遺留的程式碼畫個因果輪迴循環。

面對技術債與遺留的程式碼

該還的債還是要還,該挖的陳年老 Code 還是要挖。

理想的開發狀態是有充裕的時間可以讓工程師撰寫程式碼, 但客戶的需求與功能持續的增多下,加上專案的時間總是刻不容緩, 技術債的產生便是難以避免,更別說若專案是同時維護 + 新功能的開發,在開發新功能的情況下,還要考慮一卡車舊有程式碼需要花費時間挖掘。

在專案管理的期間,當舊有程式碼會影響到新功能的開發時,我們不得不去思考如何解決這些會影響專案進行的東西。

Did_u_know_code_world_is_dangerous

將技術債與遺留程式碼解釋成客戶能理解的方式

在維護與開發新功能同時並行的狀況下, 技術債就難免的在累積當中,而遺留的程式碼達到一個水位便會開始影響到功能開發,此時我們就必須分配專案中的時間來修改舊有程式碼與還技術債。

而該如何讓客戶理解所謂的技術債與舊有程式碼會影響到功能開發呢? 必須抓住下列談話重點:

  • 為什麼會有這些東西產生?
  • 為什麼我們必須要解決這些東西?
  • 將衡量的單位轉變成客戶能理解的單位
  • 若解決這一部分的程式碼/技術債,可以將開發功能的時間減少多少繞遠路的工時?
  • 解決後,對於整體程式碼的健康程度敏捷及產能效益,甚至可以增加功能評估上時間的準確性。

用客戶能理解的方式去說明,才能夠說服客戶妥協開發的時間來進行程式碼的改善。

如何盡量避免技術債的產生

如同我們前面所提到,技術債的產生會基於:

  • 開發前的評估與開發時的需求有所不同。
  • 專案時間緊湊,為了要讓功能準時上線,先以堪用的程式碼讓開發速度變得更快。

為了避免後續開發維護上,我們需要花費大量時間來修改這些程式碼,在開發過程中,我們必須經常性地檢視程式碼,確認保持敏捷性。

而敏捷且經常維護的程式碼,也就減少變為遺留程式碼的可能。

專案管理評估上,也必須考量到商業與技術兩個層面,在解決這些問題時,我們必須:

  • 先列出技術債的處理優先順序,安排修復與重構
  • 減少因為時程與違反邏輯的需求而增加任何新技術債的可能
  • 撰寫文件 / 寫測試 / 進行完善的交接

重構與修復使程式碼降低複雜性,未來也比較好維護,且若有新系統與舊有系統的整合時,也方便做介接。

結語

針對上述的內容,我們可以來做個簡單的總結,

  • 任何程式碼都有可能因為任何原因變成技術債。
  • 完善的開發流程及文件/測試可以幫助程式碼在修改上變得容易理解且更好調整與處理。
  • 技術債你無法對它置之不理,否則哪一天就會反咬你一口。

相關文章