不可能不欠技術債

在前文中我們其實已經提到了，技術債與金錢上的債務，有很多的共同點。在產品開發過程中，有時候為了搶奪商機，你不得不在深思熟慮後，決定用比較快速的方法解決問題，盡快將產品推上線，以獲取利益。就像開店做生意一樣，如果要累積到一定的資金才要投入市場，那商機早就已經被瓜分掉了，所以在有一定的信因與信用後，就可以利用借貸方式先踏入市場，日後再來償還這些債務。

為什麼這裡會強調深思熟慮這四個字？因為我們其實很常見到一些工程師，明明有足夠的時間與技術，去做出比較好的決定，卻選擇比較欠缺彈性、耦合度比較高的設計框架，導致後續維護成本提高，同事拚命加班幫忙擦屁股，產品擴展速度越來越慢，錯誤率越來越高等。唯有經過成熟考慮的欠債決定，才是我們能忍受的技術債。

技術債需要被管理

如同上一段說的，我們不能認受的，是『幼稚無知的(Naive)』技術債。這樣的債務是無論如何都不可以欠的。容我再說一次：

『幼稚無知的(Naive)』技術債，是無論如何都不可以欠的。

我們能夠容忍的，是策略性的技術債，與草創期不得不欠下的技術債。然而，也像金錢債務一樣，技術債一旦欠下了，就一定要管理這些債務，因為，建立在技術債之上的開發，不只利息重 (工程師的加班費)，以後『債上加債』的風險也會更高，等你的產品來到了龐大又笨重的臨界點，你就不得不放棄他又重新再造一次，那個沉沒成本也是很沉重的。

管理的第一步就是要知道我們欠了哪些債。這裡當然大家的管理方式不一樣，有些人特地開啟專案記錄下來，有些人編輯成冊，定期拿出來審視。不管你怎麼做，絕對不可以的，就是這樣放著，讓它隨著時間淡淡而去。接著就是要安排時間償還了。你償還得越快，你就越早進入財務自由的生活，而技術債償還得越快，你每天每天付出的利息就會越來越少。所以，『先還利息高的』則是還債策略的原則。

危險的償還方法

『我們這個月正在做重構』、『我們的xxx產品正準備進行結構性的大重構』這樣的對話，筆者每次聽到都會為對方捏一把冷汗，尤其最嚴重的：『我們OOO功能和xxx功能的連合大重構已經完成了，剛進QA了，等QA測完就可以上線了。』簡直是要用盡畢生功力才可以不當場翻白眼，阿彌陀佛。

為了快速償還技術債，將目前線上正在營運的產品，徹頭徹尾地進行一次大重構，是非常非常危險的作法。這就像你為了盡快還債，於是都不要吃飯，把每個月賺到的錢全部拿去還債一樣，那是會餓死人的！都說要『債務協商』，債務協商就是討論你的收入與債務情形，擬定出一套可行的，不會餓死的方法，這個月還李先生，下個月還王太太，再下個月...，在處理一般債務時，你會分批還款，那麼在處理技術債時，怎麼不會呢？

『打著重構的大旗』，是危險的。為什麼？因為你會有一段時間，也許是一個月或是兩個月，什麼新需求都不能接，不管客戶要什麼，你因為有了『重構』這個擋箭牌，於是在這段時間，產品完全都沒有進度。要知道，重構是解決你的問題，但你的問題客戶關心嗎？不要鬧了，客戶一點也不擔心。

另外，因為你花了很長時間進行大規模的、結構性的重整，影響範圍是很大的。依照工程師的習慣，你花2個月寫的東西，會給QA測2個月嗎？不會的，因為東西寫完丟給QA，你的事就結束啦！QA當然只要給他2周測就夠啦！反正到時候線上出狀況再回頭怪QA為什麼沒測出來就好啦！

但其實最可怕的是，你已經告訴全世界，說這個月我除了重構，什麼東西都不做，你覺得，客戶會這麼體諒你嗎？我業務生意都談回來了，這個宜上線就是多少又多少的收入，你在那邊跟我談什麼軟體工程個屁！現在就要給我做！好啦，老闆都說了，就做唄！於是開了兩條支線，一邊開發新功能，一邊重構舊功能做完還不忘時不時地merge一下，別的客戶看到了，嚷嚷著我也要我也要，於是開出了一個重構支線，8個新功能支線，可憐了妳小小的腦袋瓜兒。

出錯率能不高嗎？

較實際可執行的還債方法

『我們還是來債務協商吧。』

先前說的，你可以造冊管理，慢慢修，慢慢還。造冊管理還不夠，你還得排序，我們在意的不是還了多少條債，我們在意的是怎樣還才可以快速地降低每期的利息。於是，排序就很重要了，先把那些『痛苦指數超高』的拿出來還，再慢慢還那些沒那麼痛的。

還的過程也要注意，在一個sprint中，我們不能整個sprint都拿來還債，我們必須說好一個特定比例，譬如還債時間不可以超過此sprint工時的1/4等。這是『特地安排』還債的情形。那有『不特意安排』的嗎？有，當然有。

有讀過一些DevOps或是Agile相關書籍的人，大概就聽過所謂的『童子軍法則』，亦即，我每次在一個地方紮營，離開後我要把營地收拾乾淨，甚至要比原本還乾淨。這就是最安全又可行的還債方法。舉例，今天你要為了登入葉面增加一個新功能，於是打開後端程式，準備要加一個新method，這時發現原有個兩個函式，有一段長的很像的程式碼，裡面也有些魔術數字，令人不容易閱讀，於是你就順手把這兩段code抽成共用函式，並且在你的新函式裡也引用。不只如此，你還順手幫這些函式都加上了簡單基礎的test case，以確保這個小修正不會導致功能錯誤。

所謂的『童子軍法則』說起來未免嫌有些洋派，我比較喜歡另一種說法：『路過幫修』。聽起來不是親切多了？不論怎樣，路過幫修的好習慣，可以在開發新功能時，順便還掉一些技術債，這樣一來，需要特地安排時間還的債就又少了一筆了。