前言
已经一年没写过文章了，但是公司这次安排的项目重构需求，让我非常想记录一下，主要是这次重构的心路历程，以及一些感想和自我反思。
因为这个过程太艰难，我认为好好复盘是有必要的！
废话不想多说，只说我认为有价值的。
关于项目的历史
这是一个有着十多年历史的老项目，最开始是用jsp开发的，之前也经历过一次重构，那次重构也是我做的，重构历程我写过一篇《把jsp重构成vue》的文章。
重构之后不久，公司想着能节约成本，要把各种产品都融合到一个大的网站平台统一管理，其中就包括我们刚重构完成的vue项目，于是该项目作为子产品无缝衔接的直接从1.0进入到了2.0重构。
1.0重构版本只上线了3个月就下线了，虽然2.0版本代码还没有1.0的质量高，但是高层的领导们考虑问题并不把代码质量看成重点，对于开发来说，这是无奈又改变不了的事实。
重构的经过
这次重构的过程非常的乱，一部分是我本人的原因，一部分是项目本身的问题。
至于具体的情况，在重构完成后我也总结了一下，主要有以下几点：
一.大平台的代码乱
这次重构的项目要接入到其他平台的代码，就要在它们平台的前端架构基础上新建页面，使用它们平台的架构思路，共用它们的一些基础代码。
本来以为这一步非常简单，但却难的超乎我的想象。
前任连vue-router都不会用，所有功能放在一个大组件中，代码写的也是非常乱，接手后非常不适应，特别是我对编码还有点洁癖，非常看不惯差的实现方式，刚接手该项目，就有了干不了撂挑子的想法。
二.业务乱
组内没有一个业务大佬掌控进度，整个过程都是盲目的进行着。
UX设计师一点业务都不了解，UX高保真图漏洞百出，和业务功能无法契合，前期虽然修改了很多版，还是无法指导开发；
测试员水平差，因为是之前测试1.0功能的老人，为了省事，他们用1.0的测试用例来测2.0的功能，对2.0的业务不做深入了解，提单的时候都是凭借自己的思维和使用的习惯来，而且还把不符合1.0测试用例的位置就视为bug(这点非常无语，明明是重构，实现方式有不同也应该是很正常的，况且从结果上看并不影响客户使用)，有些功能明明是对1.0的优化，他们还固执的提单了。无数次沟通无果后，最后还是要通过写代码，给他们的低认知买单。我也明白，测试是最怕担责的，又要体现自己的工作量，所以提一些莫名其妙的bug，但实在受不了，因为太恶心开发了。
三.编码乱
编码阶段没有计划性，没有把混乱的逻辑连成一条线，没有踏实的思考与产出，因为时间紧而扰乱了内心的秩序感，一开始就在忙碌的瞎做，结尾的时候也只想着赶紧交差。
重构完之后我非常的后悔，没有一开始就深思熟虑，列好计划，一步一步踏实的解决问题，而是怀着抱怨的心情去编码，这让我在本次重构中能得到的收获也大打折扣。
重构的结果
历经两个月，重构工作基本完成，上线后的网站能够使用，过程中一共处理了150个bug，还有20个降级处理的bug将在后续迭代进行处理。
自我的反思
如果满分是10分的话，我给本次重构打6分！很艰难的完成了，但完成的不太漂亮。
如果让我重新做一次，以下几点是必须要改进的：
1. 认真分析需求、UI设计图、测试用例，不要遗漏任何细节，因为这些漏掉的细节最后都会变成你要解决的bug。
2. 请教前任，特别是他的一些架构思想，不懂的都问清楚，不要碍于面子不问，重构路上分分钟被折磨。
3. 要列清楚计划，有哪些事情，每天处理哪些事情，一步一步去实现，磨刀不误砍柴功。
总结
乱导致事情难且多，继而情绪差，继而效率低，继而延期，继而被追责，继而情绪更差，最后绷不住开始抱怨，然后影响和同事的关系，然后沟通不畅导致更难，更乱......
进入到一个消极的循环后，就很难取到一个满意的结果。
最好的方式其实是接受那些困难的、不公的现实，让自己不急不躁，稳定的发挥出自己的能力。