iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 2
2

昨天曾提到,難改的程式通常設計不會太好;程式會設計不好有很多因素,比方說,筆者最常看到的是:因趕上線而寫出設計不好的程式碼。

我們會因為某些因素,而寫出未來難以修改的程式,這個狀況稱之為「技術債」。技術債是一種隱喻,以債務來形容這個狀況,非常地貼切!同時也能讓非技術人員理解技術人員的處境。

為何要借貸?

在現實生活裡,通常我們會為了某個目的去跟銀行貸款,比方說買房、投資或是週轉等等。當然銀行沒那麼好心,肯定會要你付出一點代價--利息。只是因為達成目的所帶來的短期利益大過於利息,因此我們仍然會選擇借貸。

技術債也是一樣,一個快速開發且設計不良但能動的程式,如果提早推出市場搶得先機,勢必能收到短期成效。但在開始維護的時候,就得付出程式難改的代價--時間。有道是時間就是金錢,技術債所付出的代價一樣也是金錢。

為何會欠下技術債?

一般貸款都會經過各種評估,銀行才肯放款。技術債則不大一樣,開發人員有可能會不知不覺中欠下技術債。

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

這兩種維度剛好切出四個象限,如下圖:

技術債象限圖

圖片來源: TechnicalDebtQuadrant | Martin Fowler

有時我們很清楚現在這麼做會有什麼缺點,以及未來該如何移除這個問題,只是礙於現況不得不這麼做,這正是屬於右上角謹慎與有意的技術債。

但相反地,我們也很有可能無意中欠債,比方說,初學程式的新手,通常都會使用萬解複製貼上來解決類似的需求,但有設計經驗的老手都知道,這通常不是個好的實作方法,而這正好屬於左下角魯莽與無意的技術債。

技術債的種類

依欠債方法來看,技術債有以下種類:

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

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

如何避免技術債?

知道技術債的產生原因後,我們可以了解該如何避免產生技術債。

為程式寫文件

最簡單的方法是幫自己的程式寫註解、把開發過程遇到的問題和解法寫筆記、建置專案過程寫文件等等。撰寫文件是馬上能做的事,新專案可以避免欠債,舊專案也能馬上還債。

但通常遇到趕上線,而文件也不是必要的交付物,接著就會被忽略。而這問題會到越來越多不了解程式架構的協作者(甚至是三個月後的自己)加入專案時,才會漸漸被發現。最明顯的警訊就是:協作者開始要求寫文件,因為程式已經難以理解到需要文件支援了。

趕上線而沒寫文件,是屬於有意與魯莽的技術債。

為程式寫測試

在提測試前,先來聊聊人見人怕的 bug

大家都很怕系統有 bug 。換個角度想,事後被別人(或是未來的自己)發現的才叫 bug ,自己開發當下發現的不算(因為當下就會修好)。也因此 bug 最可怕的地方在於,它通常都是不知不覺寫下來的,而開發人員卻能一直與 bug 共存,甚至是使用它。直到 bug 被發現後,才注意到整個系統都依賴 bug ,這時要修 bug 已經是天方夜譚了。

這個 bug 也可以稱之為技術債--因為修改程式都可能要考慮如何跟 bug 共存。

寫測試,是開發者的職責一部分。測試除了驗證功能外,還能保護原始碼,讓開發人員在修改有測試保護的程式時,比較不會因為粗心而寫下 bug 。這就像是為程式買保險一樣。

可想而知,有保險的程式, bug 不容易出現,技術債當然會大幅減少。

粗心寫出 bug ,是屬於無意的技術債。

為程式做設計

除非是天才開發者,不然缺少設計的程式,通常會因為擴展性差、難以修改而成為未來的技術債。開發階段做的設計,如 DB schema 設計、程式物件導向設計、系統架構規劃等等,都能有效減少技術債產生。

雖然設計能減少技術債,但「天下武功,唯快不破」。產品只要能用,越早上線越好,不管是 POC 為了驗證產品可行性,或是提早進入市場獲得使用者回饋都是非常有價值的。而且「設計再怎麼好,都無法應付需求變化」,不管再怎麼謹慎,今天寫的每一行程式碼,明天還是有可能成為技術債,非常難以避免。

如何在「產生技術債與價值」和「高品質程式」之間取得平衡,這是企業所應該要面對的課題。

無意的技術債難以避免,但在可以選擇的時候,就跟銀行借錢一樣,當然還是謹慎地欠債好,而不是魯莽地欠債。

有借有還,再借不難

技術債會讓程式碼難以修改,而重構的目的之一,正是改善設計並讓其他人更容易地理解程式碼,換言之,重構正是在還債。

技術債跟信用卡的循環利息一樣,如果置之不理,會像滾雪球越滾越大。而技術債要付的利息是時間,團隊會發現估算開發時間越來越長,因為程式碼越來越難修改,直到團隊無法掌控專案被解散為止。

當團隊意識到產品有技術債時,應當把當它卡債一樣,訂定償還計畫--也就是定時重構,減少技術債,同時程式碼也能持續運作,為企業產生應有的價值。

今日回顧

  • 難改的程式,就有如欠一屁股債又要繳利息一樣難搞
  • 今天寫的程式碼,都有可能成為明天的技術債
  • 技術債跟卡債一樣,置之不理會很可怕,因此要定時重構來減少技術債

參考資料


上一篇
什麼是重構(Refactoring)
下一篇
非技術人員所要了解的警訊
系列文
看到 code 寫成這樣我也是醉了,不如試試重構?30

尚未有邦友留言

立即登入留言