在聊维护项目的时候我们在聊什么

48 阅读3分钟

在维护大型项目的时候,随着项目功能的迭代会出现委会的一些痛点,比如

  • 页面打包、开发启动过程慢,模块间逻辑冗余,模块间功能依赖导致牵一发而动全身
  • 项目规范难以实行,不同模块同学开发的代码理解成本大
  • 功能和逻辑共享问题 本文在以上问题的基础上,梳理自己对项目维护的一点思考

重新认识项目

不同的项目类型决定了项目不同的技术方案和业务发展模式,当前对项目维护上的一些决策是可以结合到当前的现状和未来的业务发展做提前规划的。比如在C端项目中会侧重于用户侧的性能和体验的探索,那么在技术方案上就会比较激进,要考虑好方案的回退等。在B端项目侧重于稳定性、功能流程的完善性,单个项目周期较长。长期项目和短期项目的思考点又有些不同。如果项目是作为服务模块提供给使用者,这个使用者可以是我们自身或者业务同事,那么就需要思考如何在不影响原有的架构模式上提供服务。

项目的组织方式

这里谈的是项目的拆分和聚合。可以通过monorepo的方式把依赖项目管理起来或者把不长维护的模块拆分出去。通用的模块拆出来进行维护,这里的拆可以是渐进的,先在项目维度进行拆分,防止过度拆分引起的后续维护问题.模块可以通过框架层面进行共享和注入。

模块之间的解耦(分层、共享)

代码不好维护有一定程度上跟模块的治理有关,模块间没有更好的做好分层,功能的拆分,就会导致业务逻辑分散,功能不聚合。 在前端应用中,要思考业务、数据逻辑与视图逻辑的拆分

项目的规范(项目中的人)

项目中的规范是比较难实行的,比如设计到代码书写方式上的问题,不同人的理解真的很大不同,对于这部分应该要认可人之间的不同,在项目中建工具化的规范,通过工具去限制人的行为。比如lint 规范、大文件拆分、核心代码注释,尽可能通过框架去限制不合理的代码操作,这里举个例子比如项目中涉及到静态图片的展示,大图对用户的代码和体验都有损失,那么就可以通过编译时脚本来检查图片资源目录,当出现大图文件时中断编译或者通知。

代码是与机器交互的语言,也是开发者之间交流的一种方式.之所以要提倡编写可维护的代码是希望在同一个团队中形成统一的方言.这种独特的方言要在一定程度上提高开发的效率(不好的方言有可能降低开发效率).也许团队这段时间会使用这种方言,过段时间会换另一种方言.自己的建议是多思考,多想想方言之间的不同,为什么这种模式会适应现在的场景,慢慢的你就会建立一种你自己的方言或者思考问题的方式.

参考

代码质量与规范,那些年你欠下的技术债
好的提高代码质量的方法有哪些
Goodbye, Clean Code