这几年微服务架构和中台架构的兴起，有许多传统企业所使用的系统还是十几年前的单体架构，功能通常聚集在一个系统上，功能繁杂混乱，导致新功能开发上受到限制。

　　有幸这几年我参加过几个旧系统的重构，有的项目从头到尾跟进负责，有的项目是中途才加入，项目有大有小。

　　接下来通过几篇文章来分享一下重构路上的经验和反思，主要以内部系统的重构为主，希望对大家有所帮助。

　　重构，也就是重做。这对于产品研发团队，甚至运营，各个系统的用户来说简直是噩梦，这相当于所有的东西都需要重头开始。

　　1）旧系统的开发语言或框架不再维护和更新，一些由底层技术或框架引起的问题无法修复，特别是影响到核心功能。

　　新业务或功能通过旧系统的技术和框架无法实现，或者开发起来难度较高，耗费时间较长。如果继续在旧系统开发可能无法达到预期，并且投入的成本会较高。

　　像电商系统，当做促销活动时，如618、双十一等活动，并发量较大，超出了平时的流量甚至翻倍，那就可能导致系统无法承载。

　　这时候只能通过增加服务器来临时解决。要把问题从根源上解决除非能优化现有的代码，不然就只能通过重构来解决。

　　为了尽快投入使用，追求快速、简单、高效的落地，经常在收到一个业务方需求的时候只是简单判断就开始设计并开发落地。

　　为了追求速度，没有在前期做好充足的准备，导致产品缺少足够的可扩展性，当用户需求在未来升级迭代的时候，现有的底层设计就没有办法跟上业务的发展。

　　最终导致重构的出现。这也是许多小公司不断做大后无法避免的，毕竟互联网时代都是小步快跑，在一开始无法面面俱到。

　　其实总结起来主要是旧系统的技术和框架阻碍了业务的发展，特别是影响到业务部门的销售额、产能和工作效率等的因素。

　　所以这时候我们就需要通过重构，重新整理各个系统的功能和职责，用适合公司的新技术来搭建新的系统。

　　虽然我们已经知道重构是势在必行，但也不能老板一拍板就立马去干，我们需要做足充分的准备和整体的规划，这样重构之路才会走得更顺畅。

　　但这时候我们需要按住老板激昂的情绪，因为在开工前还有许多东西需要考虑清楚和准备，不能盲目开工。

　　首先我们需要明确重构的系统，梳理清楚到底有多少个系统需要进行重构，因为系统的多少将直接影响到整个重构项目需要的时间和人力。

　　公司在不断发展的同时，业务也在不断拓展，有些新系统是最近才开发完成的，在开发语言和技术框架上可能已经用上了最新、最流行的东西，那这些系统就可以考虑不用再去重构。

　　但有可能在重构的过程中，这些系统同样需要对接口、数据库等改动，所以对应的开发人员也要有这个准备，去配合整个重构的项目。

　　明确了需要重构的系统后我们就要与相关系统的用户表达重构后的愿景，这是非常重要的一步，因为他们是重构后的受益者。

　　不管是可以给他们提高工作效率，还是提高他们的销售额、提高他们的业绩，都要给他们一个美好的愿景。

　　这样做的目的是让他们有一个共识，公司或部门将要做的事情，大家一起朝着同一个目标去努力，这样他们才会在后续的工作中更愿意帮助我们，更好的开展后续的工作。

　　产品可以与开发、测试先将各个系统里面的功能都清晰罗列出来，可以通过excel或者思维导图列出，然后找对应系统的用户去统计整理哪些功能正在使用，哪些功能已经不用了。

　　这一步将是漫长的过程，要看系统包括的功能多少，还有涉及不同岗位的用户有多少，对于每个功能都要有一个初步的了解。

　　而是在特定的时候或场景才会使用，这些功能在重构的时候也是需要去完成，所以这些功能也不可缺少。

　　如果需要重构的系统和功能比较多的时候，在原型设计杏彩体育、开发和测试的工作量就会相应较多，所使用的时间也会较长，最后导致的就是系统迟迟不能上线使用。

　　为了重构后的新系统能够尽快上线，我们需要对功能进行优先级排列，哪些功能可以延后开发，哪些功能可以砍掉或者放在后续版本迭代时完成的，我们把重要紧急的先完成。

　　这就要通过组织主要干系人进行讨论，这时候可以继续细化我们的excel或者思维导图，一起对所列出的功能标记重要性和优先级。

　　对于一个比较大的系统进行重构的时候不同岗位的用户都会想着把自己的功能能够做到尽善尽美，但因为涉及的时间和人力比较多，就需要对系统的功能进行优先级划分，这样我们才能根据优先级来进行排期开发。虽然我们不能满足所有用户的需求，但我们在做每一步的时候都需要衡量不同岗位的需求，做出一个平衡，不能偏向于某一个岗位的用户。

　　到这里我们可以总结出一份需要重构的系统和功能细分的文档了，这时候我们就需要与用户达成共识，一起去维护这份文档，最好是能够做成内部的共享文件，当有什么变动时大家都能知道，也能避免重构后用户验收时发现某个功能没有了的问题。

　　在系统和功能点都明确下来后，我们就可以给开发一个初步的重构方案，让他们可以评估出一个时间和需要的人力。因为涉及多个系统的重构，负责开发的人员有所不同，需要他们彼此之间协作开发，什么时候可以完成对应的功能，之后进行系统间的对接、联调，这些都需要一定的开发时间杏彩体育，评估时需要一并加入。

　　对于旧系统的重构最好由原开发团队成员来牵头，因为里面的一些功能和流程由他们负责开发，他们比较熟悉里面的业务和流程，开发起来会更加顺畅，能够节省一定时间。

　　因为需求文档、原型、UI界面等还没输出，所以这时候的评估都只是基于旧功能来进行。但我们可以通过评估给领导们一个大概时间，让他们心里有个底，如果在项目进行中需要增加人员，可以快速进行内部的人员调整或者启动招聘工作。

　　在软件开发的过程中，有变动是在所难免的，毕竟一开始不可能把所有东西都想得清楚，需要在项目不断推进的过程中去优化、杏彩体育平台注册完善。

　　但我们在重构开始前就要明确大的方向，尽可能在项目启动后避免大功能的改动，不然开发到一半或接近完成的功能被喊停，这将打击许多人的信心。

　　如我们之前确定重构的功能，不能因为项目的时间紧迫而不经过讨论就砍掉某个功能。因为这有可能对使用该功能的用户无法开展工作，或者需要用其他方法去操作，这有可能不仅没有提高效率，反而降低效率。

　　当我们对所列出的功能优先级列表有变动时，需要与对应用户进行沟通，再深入分析该功能的作用，涉及的业务流程。是否有简化的可能，能否有其他替代方案。

　　所以要提前订立一个改动的机制和流程，下达到每个人员，当出现变动时需要怎么操作，通知到相关人员。

　　在项目启动前需要制定一系列的流程，每一步到哪里需要进行些什么需要知会哪些人、哪个人负责、怎么进行汇报，这些流程的制定都是非常重要的。

　　如每天的早会、每周、每个月的定期汇报，这样能让全部人员都知道当前项目的进度，自己的责任，同事间遇到哪些问题需要帮忙，有什么难题大家可以一起配合解决的。

　　重构对于企业内部是一个较大的项目，特别涉及多个系统，会有不同的开发团队、不同岗位的人员参与。