重构 uniapp 项目(0):相信自己


重构不是一个好活,需要对技术和业务的多重理解,重构又是一个好活,能够站在更加全然的高度,去俯视项目,给项目做手术。

前端重构

前端重构高度依赖 git 信息,人员变动,业务变动,会导致原有的项目结构出现各种变动,命名可能不再语义化,逻辑不再清晰,写法可能千姿百态。如果没有或者丢失 git 信息,那你将寸步难行。

挺羡慕后端,重构也不是什么大不了的事情,只要测试用例都过,基本是完成了 80%,后端的重构给人一种安全和确定感,前端的重构,有一种两眼一抹黑的感觉。

能不能不重构

这个问题很难去回答。开发过程中应该有意识的进行一部分重构,对于不好的写法,腐败的味道及时剔除,那这样的项目可能就不存在问题,因为重构已经是它的一部分。

而对于没有强力执行的项目,长期迭代,屎山堆积的项目,请慎重考虑重构。

重构中的压力

如果很幸运,领导也支持,那么推行重构过程中你还将面临一些压力。

项目无法运行。这几乎不可能,现代 IDE 提供很好的错误机制,这类错误可以很快的去定位到。

项目中各种黑魔法。比如我遇到 uniapp 中,没有引入注册子组件,但是它竟然可以正常使用,可能是它的父级或者兄弟组件使用,使得它这里也能正常使用。这种问题,一般能够在项目测试中发现。

无法实现优化目标。多套开发环境,需要手动去切换请求地址,开始没有什么思路,后续思考尝试了多种方式,最终通过 vue 环境变量的方式实现。如果某些功能,你确实无法实现,不要放弃,给自己一点时间,本次无法优化,可以放到后续,平时业务中去优化。

线上事故。即使你对自己的重构非常有信心,测试也尽心尽力,每一个地方都点了。但是你依然无法避免线上事故。因为有测试同事的介入,这个事故应该是不严重的,它不会阻塞你的主流程,也不会对你的业务造成实质性的影响。最坏最坏,提桶跑路咯,如果一个公司对于犯错 0 容忍,那这并不是你的问题,是这个机制的问题,它并没有给线上 0 事故提供一系列的制度保证。(其实,这也保证不了,google,apple,这种量级的公司每年都有线上事故,黑天鹅永远存在)

大胆重构,挥舞你的手术刀

梳理项目结构,非公共模块,不要放到公共目录中,该移动的移动,该合并的合并。

消灭黑魔法,用前端的视角,给项目注入新的生命力,不要再纠结项目怎么这样神奇的运行了,手起刀落,用最稳妥的方式,把黑魔法消灭。

更新项目依赖 package.json 。不要直接全部更新,项目中如果某些功能确实需要新的依赖支持,尝试单独去更新这部分依赖,比如我的 uniapp 项目不支持可选链,那我去更新它的 babel 依赖就可以了,尽量小的修改,避免引入过多的外界因素。

拦路虎,消灭或者绕过。我选择了消灭,比如 life-follow 这个组件,始终无法正常使用,我深入研究了 uniapp 的事件机制,给官方提交了 mr,推动了支付宝 life-follow 在 uniapp 中的正常使用。

信任 IDE。移动文件位置,优化导入,这些事情,请大胆放心的交给 IDE ,不要再去一个一个的写它的路径,IDE 非常擅长这些事情。

引入新思路。重构是对过去的一次修补,也是对未来的一种开拓和展望。尝试在重构中通过命令进行环境判断、装饰器模式进行埋点、非生产环境不上报 log 数据。这些本该是项目的一部分,然而,因为各种原因,需要靠一次重构去实现,这也许也是重构的价值,角度不一样,思路也不一样。

相信自己

大胆假设,小心求证,相信你一定可以把项目梳理的井井有条,自己和项目都能够快速成长。

参考

支付宝小程序使用花呗分期插件,⽆法监听到插件提供的onChange事件,报错为事件信息不存在。 · Issue #2410 · dcloudio/uni-app


 上一篇
重构 uniapp 项目(1):浅浅理解 uniapp 重构 uniapp 项目(1):浅浅理解 uniapp
uniapp 在业内名气口碑都挺不错的,选择这个框架,能够让开发者快速出活,依托 vue 的生态,相关开发者也多,企业也容易招聘。然而小程序和web毕竟还是有点区别,某些时候还是需要对uniapp 有一定的理解,才能够顺利的搬砖。本篇,
2021-07-20
下一篇 
ts 方法装饰器 ts 方法装饰器
装饰器在java中叫注解,体现了面向切面(AOP)的编程思想。 方法装饰器// 定义装饰器 export function logger(target: any, propertyKey: string, descriptor: Prop
2021-07-12
  目录