背景
??19年末重構的項目在經歷半年的業務迭代后web層的代碼已經開始混亂,沒有秩序,可讀性下降,由此引發一些的思考.
序
??在一次同事相互CodeReview中發現,業務中負責對接App接口的Web項目在半年的業務迭代中,代碼的可讀性,擴展性已經出現壞味道,在原有代碼上開發的效率已經開始下降,代碼的業務含義也不再清晰,為了解決或避免這類問題,我們需要思考并總結.
問題出現的原因
??Web層代碼現象到底是如何出現,并發展的?這是要考慮和研究清楚的.只有發現問題出現的規則,才能從底層解決不在復現
- App的版本升級
?? App在業務迭代中不斷升級,展示層不斷改變,Web層接口為了適應App的展示改動,勢必會導致Web層出現多個版本的代碼糾纏和粘合的現象. - 業務迭代沒有重構時間
??在每一次的業務迭代的資源分配中,業務方沒有給與技術迭代的時間和資源,在一次次迭代后技術債務堆積,沒有時間處理和消化. - 惰性和責任
??還有一部分原因是人本身的惰性導致,懶于去優化,去重構,去添加注釋和日志,去提高代碼的質量和優雅性.對于一些勤奮且對代碼有要求的同事,承擔代碼重構導致的后果和責任是另一方面顧慮,在沒有完備的自動化測試和充足的黑盒測試資源下,貿然改動老舊代碼導致線上事故,并背負批評和責備是非常可怕的.
是否有解決方案
??上面的問題中,2和3是開發的共性問題,就不在這里詳細論述,我們專注于問題1.
??App的版本升級導致的問題,我認為是有解決方案的,并且可以在代碼維度從根本上解決這類問題.
解決方案
??這類接口版本兼容導致的代碼腐爛和壞味道等問題,其實都可以通過模板方法結合工廠方法實現良好的擴展性和可讀性.
??思想就是通過模板方法實現代碼復用和擴展性,利用工廠方法實現接口版本和實現的關聯.
文末
??具體的代碼就不貼出來了,實現起來沒有什么難度,真正困難的是能夠在項目啟動時候,就架構出一套可擴展的方案,或是項目迭代中,有魄力去重構代碼,化腐朽為神奇.
??寫代碼能力很容易通過短時間工作達到90分的,而架構能力需要不斷的去思考和總結,去逐漸提升,共勉!
