iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 2
0
Software Development

軟體開發隨筆談系列 第 2

重構的時機

就讀碩士時,在拜讀《重構─改善既有程式的設計》後,就熱衷於重構相關議題。認為重構很治癒,把壞味道變成美好的架構是一門讓人陶醉的藝術,直到現在仍然如此。

但是在職場上,想要重構遇到的最大問題在於,對於 PM 或是客戶來說,重構是沒有價值的,至少他們很難感受到。儘管工程師希望能夠好好重構,為未來的開發與維護打好地基,但通常都沒有一個空下來的時間能夠滿足他們的奢望。

而對雙方最大的災難,就是為期好幾週的純重構工作進度。身為開發者很難有把握在這種時候只重構一小部分,對其他壞味道視而不見。於是重構的成本大於規劃或預期,軟體開發的時程延宕,更可怕的是,軟體可能還在重構過程中不小心埋下缺陷、漏洞。這類事情的一再發生,拖垮了開發者的自信、動力,擊潰了主管、客戶對於工程的信任。

但是因此放棄重構嗎?「不!」我想多數的開發者都很難接受。但要因此和主管或業主槓上嗎?這聽起來也不是好主意。那該怎麼辦呢?或許我們該理解重構的時機與配套的方法。

重構依照完成時間的成本來分類主要有分兩種,一種是順手可以完成的,一種是需要一個不短的開發時段去完成的。

通常前者是可以在開發功能或修復缺陷時,順手完成。但是若遇到後者的情況,會建議先記錄在一個團隊都看得到的清單(可能是技術債清單、或是壞味道清單),並在每次規劃進度時,也挑一到數個(團隊與主管或客戶雙方都能接受的範圍)希望重構的項目,一起列入開發成本或待辦清單,透過這種方式逐步改善。

另外有一種例外是,這個專案是免洗專案,沒有要長期維護的打算,且沒有要重用裡面的程式碼,亦即重構不會對未來有太大幫助時,這時最好的作法就是忍痛不重構。

掌握重構時機,避免陷入重構的泥沼,保持「持續創造價值與改善程式碼」的平衡,我想就是今天我想要分享的。

當然,重構對象盡量要先有測試,避免重構時改變了既有的功能這件事也很重要,但和本文主旨無關,就不詳述了。


上一篇
前言
下一篇
如何導入 Code Review
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言