今天繼續把之前提過的鐵人賽看完。今天抽出來轉貼的是聊技術債的這兩篇：

技術債的產生可能有很多原因，例如為了趕快上線所以先妥協實作方式，又或者是複製貼上而產生更多債務。

在這篇文裡也引用了許多前輩的文章來介紹技術債。例如：

抄捷徑的技術債，遲早要還的 - 王建興

技術債和財務領域中的債務觀念，有一些可以類比的地方。人們會產生財務上的債務，通常是因為對於立即性資金的需求，也就是說，可以在短期內得到好處。但是，無論是向銀行或是其他個人借貸，總是需要付出代價，也就是利息。

無論是不夠完備的架構設計，或是具有壞味道的程式碼，都會隨著時間，持續地讓開發團隊付出代價。但是，只要付出的代價是可以接受的（小於得到的好處），那麼，欠下技術債的決策就很有可能是個合理的決策。不過隨著債務積欠愈來愈多，或是固定的債務始終沒有償還，那麼就得付出愈來愈多的利息，或是持續長久的付出利息，最終就可能發生得不償失的情況。

技術債（Technical Debt） - 看到 code 寫成這樣我也是醉了，不如試試重構？

Martin Fowler 把技術債產生原因分成了兩種維度，分別是魯莽（reckless）、謹慎（prudent）與有意（deliberate）、無意（inadvertent）

依欠債方法來看，技術債有以下種類：

  • 設計缺陷，這也是一般最常見的技術債。
  • 文件不足，包括沒寫註解或是專案文件等。
  • 缺少測試，原本應該要正確的功能，會因為沒有測試好而產生 bug 。
  • 明知該實作，卻沒實作。比方說：明知沒實作快取，會讓服務反應時間過久，但沒實作也能動，就先交貨了。

廣義來說，只要技術上會難以修改的理由，都可以算是技術債。

但我更喜歡內文對技術債直接粗暴的介紹：

只要是留給別人修改的 code 都是糙 code

這篇文也列出了前面幾種技術債該面對的心情，例如文件不足、設計缺陷等等。搭配作者引用的相關參考，應該能對技術債的概念有些認識

看了這些文章的時候，呃，對後續維護我的 Code 的朋朋們還真是不好意思 xD

最後，提到技術債一定要引用最經典的這篇：工程師應該放心大膽地創造技術負債

如果你在一家公司寫了一大堆完全不考慮耦合關係、程式邏輯糾纏不清、命名混亂、使用大量 anti-pattern、到處都是怪氣味、效能極差而且宛若天書的程式碼，而你開始為了繼續維護這樣的技術負債感到痛苦的時候，其實只代表一件事情：你已經在這家公司獃得太久，而且還沒有升上去當主管。

太痛苦了。

今天的轉貼就到這，有興趣的朋友可以一篇一篇看過去，然後一起捨棄專業成就事業。明天見～