iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 30
1
Software Development

看到 code 寫成這樣我也是醉了,不如試試重構?系列 第 30

三十天總結

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

品質改善,不進則退

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

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

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

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

提高品質,積少成多

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

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

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

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

圖片來源: reddit

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

因此,今天還想偷懶嗎?

重構之路,步步艱辛

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

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

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

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

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

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

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

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

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

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

後記

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

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

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


上一篇
組合應用
系列文
看到 code 寫成這樣我也是醉了,不如試試重構?30

尚未有邦友留言

立即登入留言