前言

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

项目重构的过程

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

因为,我们要面对困难,往往并不仅仅是代码。比如,你在项目重构开始后,发现,重构项目组只剩你一个人。。。

01熟悉结构

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

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

但重构还是要继续,于是,我就在这样的情况下,开始了一个陌生项目的重构之旅。

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

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

每重写一个页面,我就对系统多了解一点,然后在拿着我掌握的信息,找现有的项目成员核对,一点一点,积少成多。

当然了,重写项目页面,必须要保证速度,如果速度不够,那么代码以外的问题会越来多。

如何保证速度?很简单,首先把自己顺手的框架拿出来,封装好表格控件、图表控件等常用;搭建好CS客户端与服务的基础沟通,做好ORM,剩下的就是把业务模块一个一个的搬运过来。然后,边移植功能,边做文档描述;因为当下移植的功能很可能是错误的,当下的表结构很可能是错误的,所以,文档记录非常重要。

03基础功能与OA功能

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

04领域驱动

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

05重设计表

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

06成员加入

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

结语

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

———————————————————-

注:此文章为原创,任何形式的转载都请联系作者获得授权并注明出处!
若您觉得这篇文章还不错,请点击下方的推荐】,非常感谢!

https://www.cnblogs.com/kiba/p/13467704.html

 记一次项目重构插图

 

本站资源均源自网络,若涉及您的版权、知识产权或其他利益,请附上版权证明邮件告知。收到您的邮件后,我们将在72小时内删除。
若下载资源地址错误或链接跳转错误请联系站长。站长q:770044133。

» 记一次项目重构

发表评论

免登录下载网,提供全网最优质的资源集合!