程式設計師的無形債務：技術債

上週日電商最大的節日雙 11，因為流量過大讓 PChome 和 momo 網站雙雙掛掉，也讓大家開始注意到技術債這個議題，剛好我為了處理電子豹的技術債已經花了一年多的時間、繳了很多學費和白了好幾根頭髮 (還有很多來不及白就掉落的 T_T )，有些心得可以和大家分享。( 因為我這篇是想寫給大部份人看的，所以我盡可能不會使用技術的專有名詞。)

何謂技術債 ?

為了方便非圈內人了解，一開始先來說明一下，何謂技術債，根據維基百科的定義：技術負債（英語：Technical debt），又譯技術債，也稱為設計負債（design debt）、程式碼負債（code debt），是編程及軟體工程中的一個比喻。指開發人員為了加速軟體開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟體開發的方案，從而在未來給自己帶來的額外開發負擔。這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。軟體工程師必須付出額外的時間和精力持續修復之前的妥協所造成的問題及副作用，或是進行重構，把架構改善為最佳實作方式。

技術債如何形成 ?

就如字面上的”債”，債沒有人想欠，每個工程師在設計新系統時都會盡可能的把未來可能的需求想清楚、把未來需要的彈性盡可能的保留，使用最新的技術架構以滿足前述的需求，就如每次新年我們都會許下很多新願望、設定新目標一樣，充滿了期待，我當然也是。但大家也知道，理想終究是理想，六年前我剛開發電子豹的時候也是我經濟最困難的時候，即使我再有雄心壯志也不敵時間及財務的壓力，只能先讓堪用的系統 ( MVP ) 先上線，什麼叫堪用 ? 就是功能有但上線會讓你覺得有點丟臉，不好意思通知大家的那個階段就是了。當時的狀況就是如果二個人同時要寄信，系統就會掛掉需要人工重啟主機。可想而知，當時我的確很不願意的也欠了很多技術債 ( 錢都在欠了也不差這個了 )。
你以為那是因為我的狀況才讓我非欠技術債不可嗎 ? 不，欠技術債是一種常態，造成的原因就是時間和預算的壓力，這是我從退伍後去一間軟體公司上班後就明白的事，每個案子都有時間和預算的壓力，這會逼得你對於功能、技術、細節做些取捨，根本無法達到心目中的理想世界，而且說實在的，技術進步太快，當下覺得超棒的最佳解過了半年後自己又打臉自己，覺得仍有優化的空間，本來以為沒欠債的半年後又變成債。

技術債不還會怎樣 ?

有時技術債不還也不會怎樣，因為債是給活下來的人還的，如果公司都活不下去了，還在乎技術債幹麼 ?

何時該還技術債 ?

欠技術債的人自己是知道的，所以我一邊欠債也一邊還債，因為有些債不還你是無法借新的債 XD。
技術債是常態，因為時間和預算的壓力，它又是被默許的，那我是什麼時候意識到技術債大到非還不可了呢 ? 其實就是當這個債開始阻礙公司成長時你就會正視它了。我開始發現有很多客戶的需求我滿足不了了，我發現客戶愈多卻讓系統效能變慢了，我系統變慢的問題已經無法靠花錢加大機器規格解決了，我發現靠花錢硬解問題讓公司現金變少了，我發現我處理 bug 的時間拉長了，我發現如果我不還技術債我什麼事也沒辦法做 ….

技術債為何難還 ?

這原因也很好懂，小債不還累積成大債也還不了了，就欠下去吧。在開發電子豹時畢竟我也已經寫了十幾年的程式了，對於系統該有的彈性、程式該有的規範我都有一定程度的了解及信心，理論上我應該可以少欠一點債或是我可以邊欠邊還，但有些技術債即使是我自己欠下的我依然還不了，例如資料庫。
資料庫的特性是這樣，資料量少要查要改都簡單，隨著時間愈久資料量愈多、資料愈多元要變動就是非常非常困難的事，它的困難在於你每做的一次變動就是一個大量資料的搬移，你每作的一次查詢就是在大海中撈針，有時為了一個小調整可能就需要把網站停一天，初期我還可以利用假日的半夜做更新，反正一開始也沒什麼客戶，但後來真的就是一定會影響到一些客戶的使用了。以上的例子還只是資料庫而已，更別說程式的部份了。( 大家大約明白困難度就好了，不然再寫下去這篇寫不完了 )

技術債該誰來還 ?

很多人會覺得技術債應該要工程師來還，但如果你有認真看我上面寫的技術債如何形成，你就知道技術債的形成大部份是因為時間及財務的壓力，誰可以決定時間和財務 ? 當然就是老闆啊，所以技術債不只是要靠工程師，還需要老闆的支持，而老闆需要股東的支持和強大的心理建設 XDDD。會有人想了解這一年多我做了什麼掙扎和心理建設嗎 ? 可以在這篇 PO 文下方 +1。