關與代碼重構那些事
- 2019 年 12 月 30 日
- 筆記
摘要： 重構有時候可能費力不討好。
首先拋出觀點：重構既有代碼並不是一件討好的事情，甚至是一件無功有過的事。
說個我朋友的事（我的一個朋友系列）。這個人頗有些強迫症。他在入職某家公司一段時間後，實在受不了負責模塊那些祖傳代碼的組織方式，就用工作之餘的的時間徹底重構了部分內容。也算幸運，他的重構工作沒有影響生產業務。在年底進行績效評估的時候，他將代碼重構作為績效的一部分彙報，卻沒有得到領導的認可。為什麼呢？因為即使沒有重構，以前的代碼也能滿足業務需求，而且重構後的代碼並沒有性能上的顯著提升，他的工作被視為是可有可無的。
對於朋友的做法，我現在說不上不認可；對於當時他的領導的做法，我也能夠理解。如果對代碼進行重構的肇始是緣於潔癖或強迫症，那麼最好三思三思三思而後行，至少也不要一開始就全面重構。因為既有的祖傳代碼雖然可能比較糟糕，但還是經過了生產業務的考驗的。而修改後的代碼必須得經過充分的測試才能投入生產。而這種測試我不認為是開發一個人進行自測就能充分覆蓋完全的，項目組需要為這些改動多投入一些成本。
但是重構就是完全不能進行了么？我也沒這麼說。我只是強調了要優先保證生產環境的穩定性，並且需要顧及到團隊投入的成本。重構還是要做的，但是要掌握好契機。
比如有新需求來的時候，如果繼續用過往的代碼適配新的業務邏輯會消耗太多的時間。這些時間甚至超過了重構的時間。那麼此時優先選擇重構。
再比如發現引入新的技術方案可以顯著提升當前系統的性能，改善系統的短板。那麼經過團隊討論後，可以在引入新方案的時候順手實現代碼的重構。
充分利用這些機會，就可以在不會過多佔用團隊資源的前提下，重構既有代碼。
如果沒有理想的機會的時候也可以小範圍的進行調整，或者拉一個新的分支在不影響生產系統的前提下實現對既有代碼的改造。這樣在真正需要大面積改造的時候也就有了足夠的基礎。
版權聲明
轉載時請註明作者 Fundebug以及本文地址： https://blog.fundebug.com/2019/04/03/about-code-refactoring/
您的用戶遇到BUG了嗎？
.copyright *{box-sizing:border-box}
