问题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
一把梭哈。
好处如下:
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[项目...]
以前我总是犹豫不决,觉得有些问题不属于自己的工作内容和职责,就想着去逃避它,将解决的希望寄托在别人身上,即使问题已经压到我脸上,因此走了很多弯路,今后不管是谁的问题,只要是阻碍我的问题,我都要解决,千方百计去解决它,我要自己救自己。