三十天總結

不管軟體或硬體，產品的外在品質都是讓客戶滿意的重要指標；但產品好不好維護，是要看內在品質的。

品質改善，不進則退

既有程式碼的技術債，如果沒有開發者察覺的話，就不容易改善。隨著軟體迭代過程，新功能不斷的開發，技術債的雪球也就會越滾越大。

但客戶的滿意度也是，不提高外在品質，滿意度就會「不進則退」。維運產品，除了內在品質要改善，客戶也要顧好。

重構無法改善外在品質，它是件會讓顧客不開心的任務。但開發者容易因不自覺寫下技術債，或是被逼迫寫下技術債（時程壓力等因素），而讓內在品質低落，產品就會難以維護。

因此如何同時重構與開發功能，才是開發團隊最大的挑戰。除了開發者要努力外，非開發者也必須一同參戰，多體會開發者的感受，這才是目前正夯的 DevOps 精神啊！

提高品質，積少成多

「羅馬不是一天造成的」，高品質的軟體也是。

即使拿到的程式碼很糟，我們還是能有不同面向可以提高程式碼品質。不管再怎麼爛，還是能開始動手寫文件，或是試試看能不能寫測試等。相反地，如果運氣很好，拿到高品質的程式碼，也不能因此怠慢而寫出劣質的程式。

不管是好的程式或壞的程式，都會隨著時間過去，成等比級數的成長。

如果平常一天能寫出 100% 有價值的程式碼，每天多努力 1%，一年後品質將會是原本的 1.01 ^ 365 ≅ 37.8 倍；相反地，每天偷懶 1%，一年後的品質則會變成原本的 0.99 ^ 365 ≅ 0.03 倍！

圖片來源：reddit

品質會直接影響程式碼的可維護性。換句話說，多努力一點，系統就會好維護 30 倍；多偷懶就會難維護 30 倍。

因此，今天還想偷懶嗎？

重構之路，步步艱辛

重構一個充滿技術債的舊系統，除了要了解它之外，還要了解實際的業務邏輯，接著想出合適的設計，才能開始把舊有程式轉換到新設計上。

一點一點還，總有一天能還完。但，這是一份苦差事。除了舊系統難以了解外，還得面對非開發人員的時程壓力，甚至是偷懶開發者的冷言冷語。

努力了許久，成功還完債後的功勞，也許還會是其他人的：

「寫了三個月才好，看那新來的接手你的程式，三天就做出來了！」

抑或是重構還沒完成，被逼去開發新功能，這怎麼會快呢：

「寫了三個月都寫不好，看那新來的，雖然 bug 一堆，改一改也是三個禮拜就生出來了！」

重構過程會遇到很多挫折與挑戰，但換個角度想，重構完全是為了未來的自己。

如果挑戰成功，未來開發就會輕鬆許多；而不管成功或失敗，也會發現自己對程式設計更有想法，不會再用以前的複製貼上解決問題，寫出來的程式碼也更有品質－－因為重構已經看過一堆爛程式了－－；能寫出有品質的程式，維護的問題就會更少，不管怎麼看都是對自己有利的。

除此之外，開發者職責是要提升產品的品質，並為提交的程式碼負責，重構也是個學習的好方法。

最後，看到程式碼先別醉了，不如試試重構吧！

後記

這次鐵人賽，原本想花更多時間在說明重構過程，不過礙於時間因素就只好留下了文章債－－為了快速交卷而寫出架構簡單的文章，未來也不大會有時間回來重構了。

希望這三十天的重構分享能幫助到大家，祝大家

快快樂樂 重構
平平安安 上線