关于后端展示层的思考

背景

  19年末重构的项目在经历半年的业务迭代后web层的代码已经开始混乱,没有秩序,可读性下降,由此引发一些的思考.

序

  在一次同事相互CodeReview中发现,业务中负责对接App接口的Web项目在半年的业务迭代中,代码的可读性,扩展性已经出现坏味道,在原有代码上开发的效率已经开始下降,代码的业务含义也不再清晰,为了解决或避免这类问题,我们需要思考并总结.

问题出现的原因

  Web层代码现象到底是如何出现,并发展的?这是要考虑和研究清楚的.只有发现问题出现的规则,才能从底层解决不在复现

1. App的版本升级
      App在业务迭代中不断升级,展示层不断改变,Web层接口为了适应App的展示改动,势必会导致Web层出现多个版本的代码纠缠和粘合的现象.
2. 业务迭代没有重构时间
     在每一次的业务迭代的资源分配中,业务方没有给与技术迭代的时间和资源,在一次次迭代后技术债务堆积,没有时间处理和消化.
3. 惰性和责任
     还有一部分原因是人本身的惰性导致,懒于去优化,去重构,去添加注释和日志,去提高代码的质量和优雅性.对于一些勤奋且对代码有要求的同事,承担代码重构导致的后果和责任是另一方面顾虑,在没有完备的自动化测试和充足的黑盒测试资源下,贸然改动老旧代码导致线上事故,并背负批评和责备是非常可怕的.

是否有解决方案

  上面的问题中,2和3是开发的共性问题,就不在这里详细论述,我们专注于问题1.
  App的版本升级导致的问题,我认为是有解决方案的,并且可以在代码维度从根本上解决这类问题.

解决方案

  这类接口版本兼容导致的代码腐烂和坏味道等问题,其实都可以通过模板方法结合工厂方法实现良好的扩展性和可读性.
  思想就是通过模板方法实现代码复用和扩展性,利用工厂方法实现接口版本和实现的关联.

文末

  具体的代码就不贴出来了,实现起来没有什么难度,真正困难的是能够在项目启动时候,就架构出一套可扩展的方案,或是项目迭代中,有魄力去重构代码,化腐朽为神奇.
  写代码能力很容易通过短时间工作达到90分的,而架构能力需要不断的去思考和总结,去逐渐提升,共勉!