重構 (Refactoring) 學習心得筆記 – 技術債 (Technical debt)

文章最後更新於 2021 年 2 月 11 日

技術債 – Technical debt 是什麼?

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

1992年,沃德·坎寧安 (Ward Cunningham)首次將技術的複雜比作為負債。

想想看,在專案的一開始,每個人都盡全力的寫出最好的程式碼,怎麼會有人故意寫一些不乾淨的程式碼,造成專案未來負擔?是什麼時候開始程式碼變的不乾淨呢?

技術債的分類

馬丁·福勒提出了把技術債分為四個象限

魯莽Reckless謹慎Prudent

故意Deliberate
 
我們沒有時間做設計我們必須馬上交付,後果以後再說

疏忽Inadvertent
 
什麼是分層(設計)?現在我們才知道該如何做了

導致技術債形成的原因

簡單來說,就是:能力不足意願不足資源(時間)不足

下列是一些常導致技術債形成的原因:

商務壓力、時程壓力 (Business pressure)

有時候專案時程就是很趕,必需要能及時上線,「先求有,再求好」之類的話就出現了。通常在這種情況下,就會用一些所謂的「Quick Solution」來達成一些功能(Features),可能連測試都先略過不寫,技術債因此產生。

缺乏對技術債產生的後果的了解 ( Lack of understanding of the consequences of technical debt)

有時就老闆不了解技術債是會產生”利息”的,隨著技術債的累積,會漸漸的拖慢了專案發產的速度,當管理階層不了解重構的價值時,是很難去要求開發團隊把時間花在做程式重構的工夫上的。(Boss: 功能正常可以動就好啦,不要再去改了,新功能開始進行開發了嗎?)

無法對抗緊耦合、層層關聯的組件 (Failing to combat the strict coherence of components)

這像專案是一大塊的巨石或是俗稱的大泥球,而不是一個一個獨立的模組所組成,功能不是模組化,軟體不夠靈活應對商務上的變化,更改一部分的程式會影響到其他部分,在開發上很難獨立開來處理。

缺乏測試 (Lack of tests)

缺乏自動化的測試能即時反應問題或是bug,導致程式上線時,問題或bug一發生,工程師會緊急使用一些高風險的workarounds去解決,在最壞的情況下,這些沒事先測試的程式就會部署到Production中,後果可能會是個更大的災難。舉例來說,沒有預先測試的保護下,一個小小的hotfix可能造成程式寄了奇怪的email給客戶,或是不小心把整個資料庫刪了。

缺乏文件 (Lack of documentation)

如果沒有文件,當有新進員工進來時,就需要花時間口頭介紹給新人聽,如果有文件的話,新人可以自己看。另外如果專案開發的核心人員離職了,在沒有文件的狀況下來可以造成整個專案停頓。常常就會聽到「打掉重練」,偷懶不寫文件或整合文件自動產生工具,就是一種技術債。

團隊成員之間缺乏互動 (Lack of interaction between team members)

當最新的技術知識沒有讓全公司的人知道時,知識沒有得到共享,可能導致還有人使用過時的技術,更可怕的是,還把這些舊技術教給新人,或是對新手缺乏監督輔導。

不同分支同步進行時間過長 (Long-term simultaneous development in several branches)

在兩個或多個分支上平行開發而累積了技術債。由於工作最終需要合併兩個分支的代碼,拖延越晚,需要工作代價越大。

拖延做重構 (Delayed refactoring)

在需求不斷變化下,有時有些程式碼已經過時,變的笨重,必需重新設計以滿足新的需求,但並沒有及時重構。重構拖延越晚,需要修改的代碼越多。

缺乏規範與監控 (Lack of compliance monitoring)

如果沒有一個Coding Style的規範,每個人都按照自己的方式寫Code,然後如果又沒有Code Review,就會產生這種情況。

缺少相關知識 (Incompetence)

開發人員不知道如何寫出乾淨的程式,或沒有重構的能力。

最後突然改變需求 (Last minute specification changes)

最後一分鐘規範改變。這有可能滲透到整個專案中,沒有時間或預算通過文件或檢查來發現它們。

參考資料

原文同步於Medium: 重構 (Refactoring) 學習心得筆記 — 技術債 (Technical debt)

關於作者

卡哥
卡哥
我是Oscar (卡哥),現為Verizon Media (Yahoo) 資深工程師、高智商同好組織Mensa會員,超過十年的工作經驗,服務過Yahoo關鍵字廣告業務部門、電子商務及搜尋部門,喜歡彈吉他玩音樂,也喜歡投資美股、虛擬貨幣,樂於與人分享交流!

如果對文章內容有任何問題,歡迎在底下留言讓我知道。
如果你喜歡我的文章,可以按分享按鈕,讓更多的人看見我的文章。

網友留言