琛哥說了，出來混，遲早要還的。工程師出來職場上打滾，不論專業度高或低，責任心好或壞，都或多或少會累積出一些技術債。技術債這種東西，有很多點都跟真實生活中的借貸一樣。當年大師Ward Cunningham提出『技術債』這個概念，而後來因為比喻得太好，而把這三個字變成一個專有名詞，代表那些『因為某種原因，而做了技術上較差，並產生出來一些負面效應的較草率的決定。』

『技術債』的比喻之恰當，就連後來出版的專業DevOps與Agile相關書籍，如Continuous Delivery與Essential Scrum都為此專闢篇幅論述，可見其對技術與品質的影響之深遠。

說真的，技術債這個主題實在是太大，於是我決定把它拆成兩個部分來陳述。本篇會介紹技術債的種類、成因、與影響，而在下一篇。我才會解說對於技術債的管理與修正，有哪些原則與策略。前言至此，那我們就開始吧：

分類

一般我們很常把『技術債』的定義講得很廣泛，而實務上，技術債可以分為三類：

1. 無法避免的 (Unavoidable)：指公司或產品草創期，對於技術與未來發展方向都還不是很清楚，於是不得不做了一些早期決策，雖然後續回頭看起來不事很洽當，但卻是當時的時空背景下不得不的選擇。
2. 幼稚無知的 (Naive)：指在開發過程中，因為團隊的知識不足，要求不嚴謹，或是流程上的缺失，導致在明明有更好的選擇情況下，應是走了技術上比較差的路（大多數是因為這樣比較方便）。
3. 策略性的 (Deliberate)：只在面臨技術決策時，與商業利益衝突（譬如：為了搶奪市場先機），權衡長期利益後做出積欠技術債的決定。

影響

一旦技術債生成，一開始可能沒什麼感覺，但是一旦同樣的商品要再做擴充或是修正時，苦難就來了。大部分的情況下，形成技術債的第一個犧牲對象都是耦合度。為什麼？因為他不影響功能，只影響擴充性，這點我們待會會再聊到。然而，一旦技術債形成，管理上就會變得困難，因為耦合度高，所以交付時間會變得難以預估、同樣的需求的變更成本會變高，成果的可預期性都會下降。同時，你的產品要再順應潮增加新功能時，困難度會比你的同業高出許多，這將使你自市場上很快遞失去競爭力。在越是成熟龐大的產品上越是如此。

對於私人來說，績效當然就降低了。這是你，一個成熟的工程師，樂意見到的嗎？相信不是。

成因

其實由分類就可以看出，有些技術債是不得不然的無奈決定，而有些卻是工程師貪圖一時眼前方便所下的草率決定。上述的第二項：『幼稚無知的』技術債，則是我們一定要避免，並且一旦發生了，就要盡量去修正的。這種技術債的成因有很多，但大部分都可以歸咎成兩種：『假加速』與『對於測試的迷思』。

假加速：

在產品開發時，我們大多會在心中有一個規劃好的功能與框架，然而當時程很趕時，我們經常去『簡化』原定要做的事情。在一個產品開發過程中，『做出功能』與『規劃框架』都是需要時間的。然而，客戶要的功能又不能討價還價，這時候怎麼辦？當然就是犧牲設計框架嚕，因為客戶看不出來呀。

一旦產品上了線，這個被犧牲掉的殘缺框架就會變成永久框架，因為只要他功能不出錯，就沒有人會去改。你的維護成本客戶在意嗎？客戶不在意。於是這樣高耦合又缺乏延展彈性的程式框架就這樣留了下來，形成典型的技術債。

對測試的迷思：

雖然大家都知道測試對品質是有幫助的，但是坊間（尤其是台灣的資訊業）有很多人對於測試卻有一個迷思：『測試會導致延遲』。這件事，我覺得要認真的看待。我記得我在前文中有提到，維護品質是大家的責任。也許你會認為這麼簡單的邏輯沒有必要測，花時間寫測試會耽誤商機。問題來了，不花時間寫測試你怎麼維護品質？難道你要真的像我們經常開玩笑說的：『把客戶當成QA』，就這樣把一份未經測試的程式碼放上產線？

就讓你上線吧，也跑了一段時間，在半年一年後，你能保證所有邏輯你都記得一清二楚？如果不行，你怎麼能肯定每一次在A處的修改或新增功能不會破壞原本B處的邏輯？誰能證明？難道又要叫客戶幫你QA一次？

犧牲測試，或是減少測試，除了把傷害延後發生，以及把不確定品質的商品推出去給客戶測試以外，他並不能真的減少成本，因為你總有一天一定會付出代價的。

不管是假加速，還是對測試的迷思，如果再往下深究，其實發生的時間點，都是在感受到時程的壓力時，所做出來的決定。所以，安排時程時沒有考慮到品質，才是造成技術債的關鍵因素。