记一次项目重构

前言

本文主要记录，刚刚步入架构师岗位4个月的我，重构项目的一些经历。

项目重构的过程

重构项目这件事，最重要的实际上是心态，只要心态良好，这事儿十有八九能干成。

由于，咱们要面对困难，每每并不只仅是代码。好比，你在项目重构开始后，发现，重构项目组只剩你一我的。。。

01熟悉表结构

对于这一次重构的项目，我仍是比较陌生的，由于我也是刚刚介入该项目，而且赶在了项目交付期，虽然作了一些功能，但因为团队成员都很忙，个人工做也很急，因此我连数据库的表结构都很陌生。因此，当项目重构启动后，个人第一个任务就是熟悉表结构。

熟悉表结构，是我遇到的第一个难题，首先，通过调查，表结构的相关文档已通过时了，近一半的表结构都没有记录，其次，开发人员经历几轮换血，不少重要的表，你们都不敢给出笃定的描述。

但重构仍是要继续，因而，我就在这样的状况下，开始了一个陌生项目的重构之旅。

02从项目的Main函数打开突破口

当下的项目没有业务专家的，这意味着，我必须成为业务专家，否则的话，项目就必然没法重建，如何成为业务专家？很简单，重写代码；由于代码是最好的系统说明书，从Main函数开始，一个功能一个功能的重写。

每重写一个页面，我就对系统多了解一点，而后在拿着我掌握的信息，找现有的项目成员核对，一点一点，聚沙成塔。

固然了，重写项目页面，必需要保证速度，若是速度不够，那么代码之外的问题会越来多。

如何保证速度？很简单，首先把本身顺手的框架拿出来，封装好表格控件、图表控件等经常使用；搭建好CS客户端与服务的基础沟通，作好ORM，剩下的就是把业务模块一个一个的搬运过来。而后，边移植功能，边作文档描述；由于当下移植的功能极可能是错误的，当下的表结构极可能是错误的，因此，文档记录很是重要。

03基础功能与OA功能

经过坚持不懈的功能搬运，我终于彻底掌握了系统中重要的表，而后，我开始阅读历史项目的合同，和寻找面对面与客户沟通机会，将系统中无人使用的、非客户要求的、咱们自认为特点的冗余功能剔除。最后，我成功的将系统从新划分为基础功能和OA功能两大模块。

04领域驱动

由于有多年的领域驱动开发与设计经验，因此我深入的知道，领域驱动在分析业务时是一把利剑，但在代码实现时，是一把双刃剑；由于，项目毕竟不可能永远是我一我的开发，因此，我基于项目成员水平、学习意愿、客户需求修改频率等等因素，采用了半领域驱动设计模式，从新更新框架，其目的在于更快速、更高效，虽然不能伤敌一千，但也避免了自损八百的风险。

05重设计表

重构的过程当中，最痛苦的就是表歧义，好比班级类型表，实际存储的是学生分类信息。。。由于，入手该项目时，我是相对陌生的，因此，每当遇到有表歧义的功能时，我必须在脑海中先搭建一个映射，反复的确认后才能下手编码。若是歧义只有一两张表，那还好，若是歧义表不少，那真的，很痛苦。这也是我决心重设计表的主要缘由。固然了，优化表结构也很重要，不过，由于已经对业务进行了拆分，因此表结构优化已是水到渠成的事了，已经再也不是难题了。

06成员加入

至此，基建工做已经所有完成了，项目核心功能已经搭建完毕，项目重获新生，虽然还有剩余基础功能待扩展和部分OA功能待移植，但已经达到基础展现的水平了，因而，新项目替代了旧项目，正式为新客户服务，旧项目组成员也逐渐进入新项目组。

结语

一我的的重构项目和团队重构项目是彻底不一样的，一我的重构项目是否成功，和我的平时的积累密切相关，必须作到全程代码无开发，从ORM到UI控件乃至外部硬件设备协议封装都必须能搬运，若是有一项未积累到，须要查资料写Demo测试，那不只进度没法保证、自身状态也会被打乱，届时，外部因素一旦介入，可否成功重建就是个未知数了。

----------------------------------------------------------

注：此文章为原创，任何形式的转载都请联系做者得到受权并注明出处！
若您以为这篇文章还不错，请点击下方的【推荐】，很是感谢！

http://www.javashuo.com/article/p-zoershgx-mz.html