🗓️ 2025-09-05 🏷️ #工程化#

问题1

通用三维功能的代码分散在不同项目中,没有形成稳定的基线版,一直在为某个项目的个性化而改来改去,在项目A改一点,又在项目B改一点,这时新来一个项目C,Ta们直接把原A或者B的代码复制到C里,为了C的个性需求,又一通乱改,最后改的“六亲不认”。同一个功能,下意识就会想到复用代码,但是有些项目时间很紧迫,连同着UI组件,很冗余,来不及修改,而且没时间写测试,所以在A,B,C中会出现专属于自己的幽灵bug(还有共同的),修复之后没有在另外的项目中合并更新,以至于出现“同一个bug,重复修改”的奇观。

问题2

业务无关的通用性功能的代码和GIS框架,JS框架互相耦合,剪不断理还乱,彷佛一次性代码,写完即弃,无法在新项目中快速复用。记得当初接触到系统部开发的一个系统,前端仓库代码每个文件动辄几千行代码,所有逻辑都写在Vue2组件里(选项式),这简直就是噩梦。

解决方案

上述问题自我加入公司之后就存在了,一直没人解决,虽然项目都能正常跑,但是开发过程挺难受的,便上书领导尝试去解决。

我的解决方案是直接将通用性功能从业务中剥离,使用MonoRepo + Rollup + Pnpm 构建一个业务无关的SDK(即NPM包),每一个功能对应一个子包,可按需安装子包或完整的主包,接着使用Verdaccio搭建NPM私服,在项目中直接npm install 一把梭哈。

好处如下:

  • 代码共享和复用更简单:多个项目可以轻松共享组件、库而无需跨仓库复制。减少重复工作,并便于维护一致性。
  • 集中测试:在包中引入统一的测试框架,集中编写单元/集成测试,项目中不再单独进行重复测试。
  • 文档自动化:使用如JSDoc或TSDoc自动生成详细的API及示例文档,便于跨团队/项目合作,降低沟通成本。
  • 保护代码:可通过构建工具对产物进行混淆,加密,防止逆向或提高逆向难度,保护代码资产。
  • 精细化提交和变更:跨项目的修改可以作为一个提交处理,例如当为某项目个性化而更新SDK时,同时调整依赖它的应用,确保一致性和减少错误;自动生成ChangeLog,功能迭代变更一目了然。
graph TD
SDK --> a[项目A]
SDK --> b[项目b]
SDK --> c[项目...]

从业务开发的角度看待,就是1.以后项目开发的速度更快(目前基本以项目为主,开发速度对成本控制至关重要),系统基本是各个互相独立的模块的按需组合;2.可以将业务中一些通用的功能沉淀下来,慢慢打磨成一个通用性的产品级系统(模板)或者打造一套类似element-plus的组件库,以便更进一步提高开发速度。

graph TD
SDK --> ui[组件库]
ui --> a[项目a]
ui --> b[项目b]
ui --> c[项目...]

以前我总是犹豫不决,觉得有些问题不属于自己的工作内容和职责,就想着去逃避它,将解决的希望寄托在别人身上,即使问题已经压到我脸上,因此走了很多弯路,今后不管是谁的问题,只要是阻碍我的问题,我都要解决,千方百计去解决它,我要自己救自己。