前言
本文主要记录，刚刚步入架构师岗位4个月的我，重构项目的一些经历。
项目重构的过程
重构项目这件事，最重要的其实是心态，只有心态良好，这事儿十有八九能干成。
因为，我们要面对困难，往往并不仅仅是代码。比如，你在项目重构开始后，发现，重构项目组只剩你一个人。。。
01熟悉表结构
对于这一次重构的项目，我还是比较陌生的，因为我也是刚刚介入该项目，并且赶在了项目交付期，虽然做了一些功能，但由于团队成员都很忙，我的工作也很急，所以我连数据库的表结构都很陌生。所以，当项目重构启动后，我的第一个任务就是熟悉表结构。
熟悉表结构，是我遇到的第一个难题，首先，经过调查，表结构的相关文档已经过时了，近一半的表结构都没有记录，其次，开发人员经历几轮换血，很多重要的表，大家都不敢给出笃定的描述。
但重构还是要继续，于是，我就在这样的情况下，开始了一个陌生项目的重构之旅。
02从项目的Main函数打开突破口
当下的项目没有业务专家的，这意味着，我必须成为业务专家，不然的话，项目就必然无法重建，如果成为业务专家？很简单，重写代码；因为代码是最好的系统说明书，从Main函数开始，一个功能一个功能的重写。
每重写一个页面，我就对系统多了解一点，然后在拿着我掌握的信息，找现有的项目成员核对，一点一点，积少成多。
当然了，重写项目页面，必须要保证速度，如果速度不够，那么代码以外的问题会越来多。
如何保证速度？很简单，首先把自己顺手的框架拿出来，封装好表格控件、图表控件等常用；搭建好CS客户端与服务的基础沟通，做好ORM，剩下的就是把业务模块一个一个的搬运过来。然后，边移植功能，边做文档描述；因为当下移植的功能很可能是错误的，当下的表结构很可能是错误的，所以，文档记录非常重要。
03基础功能与OA功能
通过坚持不懈的功能搬运，我终于完全掌握了系统中重要的表，然后，我开始阅读历史项目的合同，和寻找面对面与客户沟通机会，将系统中无人使用的、非客户要求的、我们自认为特色的冗余功能剔除。最后，我成功的将系统重新划分为基础功能和OA功能两大模块。
04领域驱动
因为有多年的领域驱动开发与设计经验，所以我深刻的知道，领域驱动在分析业务时是一把利剑，但在代码实现时，是一把双刃剑；因为，项目毕竟不可能永远是我一个人开发，所以，我基于项目成员水平、学习意愿、客户需求修改频率等等因素，采用了半领域驱动设计模式，重新更新框架，其目的在于更快速、更高效，虽然不能伤敌一千，但也避免了自损八百的风险。
05重设计表
重构的过程中，最痛苦的就是表歧义，比如班级类型表，实际存储的是学生分类信息。。。因为，入手该项目时，我是相对陌生的，所以，每当遇到有表歧义的功能时，我必须在脑海中先搭建一个映射，反复的确认后才能下手编码。如果歧义只有一两张表，那还好，如果歧义表很多，那真的，很痛苦。这也是我决心重设计表的主要原因。当然了，优化表结构也很重要，不过，因为已经对业务进行了拆分，所以表结构优化已经是水到渠成的事了，已经不再是难题了。
06成员加入
至此，基建工作已经全部完成了，项目核心功能已经搭建完毕，项目重获新生，虽然还有剩余基础功能待扩展和部分OA功能待移植，但已经达到基础展示的水平了，于是，新项目替代了旧项目，正式为新客户服务，旧项目组成员也逐渐进入新项目组。
结语
一个人的重构项目和团队重构项目是完全不同的，一个人重构项目是否成功，和个人平时的积累密切相关，必须做到全程代码无开发，从ORM到UI控件乃至外部硬件设备协议封装都必须能搬运，如果有一项未积累到，需要查资料写Demo测试，那不仅进度无法保证、自身状态也会被打乱，届时，外部因素一旦介入，能否成功重建就是个未知数了。
本文作者：kiba518，全栈.Net软件工程师
声明：本文为 脚本之家专栏作者 投稿，未经允许请勿转载。
