查看原文
其他

记一次项目重构

kiba518 脚本之家 2022-05-10

  脚本之家

你与百万开发者在一起

作者 | kiba518
出品 | 脚本之家(ID:jb51net)



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



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

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

01熟悉表结构

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

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

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

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

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

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

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

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

03基础功能与OA功能

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

04领域驱动

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

05重设计表

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

06成员加入

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



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

本文作者:kiba518,全栈.Net软件工程师

声明:本文为 脚本之家专栏作者 投稿,未经允许请勿转载。

写的不错?赞赏一下


长按扫码赞赏我

●  积分兑换,来就“兑”了

●  人人都欠微软一个正版? 

●  软件开发“教父”的20年,重构开发模式,重塑开发者思维

● 这一顿神操作!我把 3000 行代码重构成 15 行!

 动态类型一时爽,代码重构火葬场?谈谈重构

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存