重构不是一个好活，需要对技术和业务的多重理解，重构又是一个好活，能够站在更加全然的高度，去俯视项目，给项目做手术。
前端重构
前端重构高度依赖 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