前因

刚刚来到一个大厂，加入的项目组之前的前端是两个外包的同学，现在招了我（正式）和另一个外包同学

来的时候聊得是因为之前对前端不太重视，很多东西比较对付，希望招聘一个正式员工，把前端这块全局负责了解一下。

来了之后，发现对前端确实不重视，技术负责人是后端的同学，对前端的理解就是拿数据切图作页面，够用就行，一切以后端为主导，之前招聘的leader也没有太多想改进的意思

具体到代码，我花了一些时间看了一下，主要是Vue的PC端项目，一个管理后台，本身架构不太复杂，但是前端代码确实很应付，目前就是出于能用的状态，性能、可维护性之类的根本没有考虑

我推测，之前的同学完成业务需求，就是不断的加代码，根本没有考虑过可维护性之类的东西。代码格式乱七八糟，无数的重复但是有细微区别的逻辑和代码

举个例子，一个筛选组件，筛选条件比较复杂，可能分为多组，一个组里面又会有二次的筛选（点击一组的某个筛选条件会弹框再次筛选）

大改有10组左右的筛选条件，每个条件都有单独的筛选方法，筛选的选项是从后端取，没有任何缓存，没进入一个新的页面要发一堆的请求重新获取

本来想把这个组件整理重构一下，提取一些公共的逻辑，引入Vuex把数据做个缓存，但是仔细读了之后我的焦虑感一下max，template部分大概500行，就这一个组件5000行

这还只是一个组件，各个具体的业务组件，差不多都是这种状态，我随便打开pages下面的一个目录，基本都在1000行左右

我有点绝望，我对自己的能力也没有太多的自信，靠自己的能力，想把这个项目变的更好可能吗？是继续在这个屎山上拉屎，还是硬着头皮，先把5000行的代码重构？

如何处理这种困境

在一个不重视代码质量，但又极其在乎kpi，按时交付，控制bug率的公司，重构是不可能重构的。

1.老代码存量巨大。要彻底完美重构，必须重新设计整个架构，重新管理引用的第三方库，甚至更换整个底层框架。即使你有这个能力，即使让你全职做这件事，恐怕也要花12人月，甚至更大的代价。哪个领导愿意让你做这些，表面上没有任何收益的事?

顶多做一下局部重构。但遇到更烂的代码，没有模块化的概念，耦合严重，局部重构也是个极其费力的事情。

2.这样的项目，别说单元测试了，就是业务文档也不可能有精准的。所有业务逻辑，只能一点点去看代码理清，一个个的请教相关人员。有些时候看代码，经常会发现有问题，可你搞不懂到底是代码的问题，还是产品设计的问题。你去问产品，发现他也不懂，他那边也是前人留下的坑。为什么有这样的业务逻辑，为什么要这样设计，现在已经无人知晓，于是你也根本不敢动这块代码。与后端接口的交互也经常有这样深坑。

3.公司的压榨，不可能让你闲的。你一来，恐怕接手的代码都还不熟悉，业务也还没理清，甚至接口人都还没认完，几个需求，或n个bug单就甩你头上了。还特么天天催。思绪刚准备好，写了没几行代码，一个会议就来了，让你帮定位问题。

4.写出bug一般到还不会向你问责，但，回归不通过，哼哼，那就惨了。因为代码烂，没单元测试，模块耦合严重，修改这样的代码谁都不敢保证不会引入新问题。嗯，修改引入了新问题。。。一般漏到生产环境的bug由测试兄弟们背锅，算漏测，修改引入的嘛，当然就由你自己背了。

在这些制度下，别说重构了，就是修改都只能小心翼翼。

5.除非是领导指派的，否则你重构不会受所有人待见。领导觉得你是工作不饱和，并且也不敢用你的重构代码(你能保证100%没bug吗)。以前的代码再烂，好歹也是经过了层层测试验证。要么用之前也必须要测试兄弟测一下。嗯，你又给测试兄弟增加了工作量。

建议

我给你的建议是，改！

但是，怎么改就是个技巧了。

1. 改之前，先去看看《重构》：第一版就行，第二版更好。你需要知道什么是 bad code ， 什么是的 good code。
2. 先做单测，再改代码：免得改坏了你都不知道，先写好单元测试，再去改代码，避免你把业务搞坏了，那你就玩完了。
3. 优先解决性能问题：代码里的 code smell 有很多类型，有的是可维护性问题，有的是代码的性能问题。你需要先去解决性能问题，然后做出重构前后性能对比，让你的老板认可你对于项目的改造。这样后续你对于代码可维护性的修改才更容易得到他的支持。如果上来就改可维护性问题，老板会认为你没有产生效益，不再允许你在使用工作时间解决问题。
4. 先完成本职工作，再解决 bad code：企业支付你工资首先想要你完成应尽职责，然后才是代码可维护性等问题。