將技術債務視覺化

技術債務（Technical Debt）這個詞是Ward Cunningham提出的。當程式設計師為了時效，用一個又快又髒，後續維護成本卻很高的作法解決問題，後續需要多做整理，我們就說他是負債，後續該整理的工作就是"債務"。例如不當地使用copy-paste、做出超複雜沒人懂得的if-else分支，或是該寫註解而沒有寫，都是典型的例子。用"債務"一詞是非常好的比喻，教我們處理技術債務就像處理財務上的債務的方法一樣。

怎麼說呢？我們先想想房貸有什麼特性︰

1. 會讓我們早幾年住到一間舒適的房子，但是我們要長年背負著每個月負擔高額利息。
2. 有能力的話我們可能會選擇大額清償，還本金要一次拿出很多錢，但是之後負擔的利息就輕鬆多了。
3. 如果有一期還不出來，再去刷卡借錢來還，之後的利息就又更高了。
4. 萬一債越欠越多，信用破產，會轉向地下錢莊借高利貸，以債養債。有一天黑道會在停車場堵你，摀住你嘴巴，用車門夾你手指要你還債。
   

現在我們看看技術債務︰

1. 會讓我們快一點做出功能，但是專案後續的延伸跟維護要持續付出較高的成本
2. 情況允許的話，我們儘早做翻修與重構。短期要付出一些成本，但後續延伸與維護的成本會降低。
3. 如果你現在要改的程式碼本身就一團亂，不過時間很趕你不能好好處理，你被迫用另一個又快又髒的方法改，就像在違章建築上再蓋一層違章。之後延伸與維護的成本又比原來更高了。
4. 如果我們堅決不處理技術債務，反而一層一層加蓋違章建築，開發進度變慢而且不穩定。整個系統到處都是未爆彈，工程師用拆彈專家的心情熬夜趕程式，團隊因壓力情緒緊繃到極點。deadline越近，系統問題越多，客戶也越來越不安。
   
   

有感受到這個類比的巧妙之處嗎？所以該怎麼對待技術債務，也跟對待財務的債務很像。我們知道房貸不是壞事，早點有個安穩的家對事業與家庭都有幫助。只是要謹慎處理。貸款買房子要量力而為，不是籌得到頭期款就放心大膽地買下去。因為現在能買不表示未來養得起。

對待技術債務的正確態度也是一樣。有智慧地用一些技巧趕進度，會讓專案運作更順利。因為遵守時程會增加與客戶及主管的信任，早點做出功能也能提早跟客戶溝通，驗證可行性。只是要記得適時的翻修與重構。技術債務不能累積過多，累積過多可能造成未來無力清還利息。

貸款買房子，讓你看起來“擁有”一間房子，別人因為你的房子而誤以為你經濟狀況很好。雖然你窮到為了還利息，三餐吃泡麵而且沒錢坐公車。只要你沒說，別人不知道。在軟體專案裡，工程師做了又快又髒的處理的話，如果沒有說出來，專案經理不會知道，以為一切順利，而太過樂觀地計算專案進度。

所以工程師一旦製造了債務出來，應該要將技術債務視覺化，將它做成大家看得到的具體項目。讓專案經理知道這個債務，能納入專案計畫中。千萬不要只在原始碼中埋一句註解："這段程式很亂，需要再翻修"。依照你的團隊管理專案的方法與工具的不同，還債的工作可以是列在一張列表上，或是工程師的待辦事項中，或是直接排進MS Project裡面。

技術債務視覺化是個很重要的專案管理技巧，本來是隱藏在系統中神秘問題，現在變成專案團隊可以共同管理、計畫與解決的工作事項。專案經理隨時知道負債量多少，就不會錯估專案時程與進度。

在文章最後我要誠實地承認一點，如同Martin Fowler指出的，技術債務有一點跟財務的債務不同，就是難以量化。理財你可以用計算機或excel找出最適合你的財務規劃︰要貸款多少，幾時做大額清償，清償多少金額。但是技術債很難量化。你可以估算還債refactor的工時，但是你很難估算不去翻修的話，未來六個月你要多付出多少成本。這一切還是要靠經驗、專業判斷跟一些賭注。但我個人的經驗是，即使不能夠量化，將它視覺化也對專案管理有非常大的幫助。