大型项目如何做?
第一,先了解业务再重构。 先把业务了解清楚,再去重构,不然这次重构很大可能是失败的,并且会导致你提桶跑路。
第二,小步快跑。 无论如何,还是要保持小步快跑的方式,每次改动较少的地方,然后完成上线。而不要一次性改动太多的地方。
第三,注重沟通。 积极与领导沟通,让他明白你当前的进度,必要时咨询他的意见。切忌自己闷头搞开发,最后别人都不知道你在做什么。
第四,给出自己的方案。 要有自己的思考,能给出自己的方案。对于领导不切实际的方案,要懂得提出自己的意见,引导领导按照自己的思路去做,从而按自己的节奏走。
第五,做好充分的测试。 单元测试是最基本的内容,一定要做好单元测试。对于无法做单元测试的,一定要让测试同学做充分的功能测试。
下面是别人的经验分析:
博主个人独立站点开通啦!欢迎点击访问:https://shuyi.tech
蓦然回首,我已经工作七年了。在这七年的时间里,做过了无数个项目,但要说大的重构,只有三个。第一个是在我工作三年时,重构公司的聊天 IM 系统。第二个是我在现在的这个公司,重构了整个业务线的业务架构。第三个是现在我正在做的,重构消息中台的技术架构。
IM 系统重构
2017 年的我,毕业三年了,但是从来没有重构过一个系统,就连一个模块也没有。而刚好就在这个时候,公司考虑到原有聊天功能不太友好,决定对原有聊天功能进行重构。于是组件了一个项目组,有两个架构师再加上我去做这个事情。
由于当时的我并不清楚如何设计一个 IM 系统,所以我分配到的是业务逻辑代码梳理,而其他两位同学则是进行架构设计,以及 IM 通信层面的代码编写。正是由于这样的分工,让我后面越做越难受。
这是一个积累了十年的功能系统,沉积了无数的业务逻辑,而且很多业务逻辑很多人也不清楚。当然了,单元测试肯定也是没有的,测试用例肯定也是没有的。在这样的情况下,我只能自己厚着脸皮一点点地去撸代码弄清楚业务逻辑。
后面回头来看,这种方式真的是最低效率的方法。如果不到万不得已,千万别这么做。最好的方法是找一个人捋清整体思路,之后再一点点弄清细节。另外,最好的重构方式不是一开始就重写,而是一个功能一个能地重写,这样才更加稳妥。
另外一个重要的点是向上沟通。很多时候我们都是按照上级的指令行事,但是却不提出自己的想法和方案。但对于重构这件事情来讲,如果不做好沟通,很可能会出大事。像这种大系统,功能众多、细节复杂,一开始就应该和领导打上预防针,并且争取分阶段、分模块开发,降低自己的风险。一般情况下,领导考虑到开发的风险,都会同意按照你的方案去做。如果领导执意要一次性做完,那你也尽到了自己的责任,后续出问题做不完,也不全是你一个人的问题了。
这个项目最终做一个多月才做完上线,主要的时间是在梳理业务逻辑上。在这过程中自己也一度快做不下去了,甚至做到后期有点抑郁了。现在回想来看,就是自己重构经验不足,心态又不好导致的。
文章首发于公众号「陈树义」及个人博客 shuyi.tech,欢迎关注访问。
业务线重构
熟悉的朋友都知道,我从唯品会出来后,就去了现在的公司。当时这块业务是从别的部门交接过来的,我们算是从零开始去熟悉这块业务。对比起上次的系统重构,这次的规模更大,直接是整个 CRM 业务线的重构。我作为技术 leader 则是参与组建了整个技术团队,并主导设计、推动落地了整个 CRM 的系统架构。
CRM 系统看起来就是一个 B 端系统,一个管理后台有什么好做的嘛。一开始我也这么觉得,但慢慢深入了解之后发现:这个东西还是不简单。经过一段时间的了解,我发现原有系统存在一些问题,例如:系统功能混在在一起,功能模块之间没有清晰的的划分;后台模块耦合在一个项目中,没有做合理的模块拆分;等等。
经过一段时间对业务的深入了解,结合对业界公司解决方案的对比,我设计出了全新的业务架构图。整个业务架构图将系统功能分为了三大系统:消息管理平台(MMP)、营销发送平台(MSP)、营销分析平台(MAP)。
经过与技术总监、产品总监沟通,他们对这个方案感到很满意,决定后续按照这个方案去推动。在整体产品、开发、测试团队的一起努力下,我们经过了半年的时间,将原有的 PHP 与 Java 系统共存的业务项目,成功改造完成了上面所说的三大系统。
对比起两年前的那次重构,这次重构是更大意义上的、业务架构层面的架构。 也是这次成功的系统重构经验,让我学会了如何从零开始去做一个业务,如何从零开始去重构一整个业务系统。后面有机会,我再写一写这块的文章。
文章首发于公众号「陈树义」及个人博客 shuyi.tech,欢迎关注访问。
消息中台重构
还记得前面说到的消息管理平台吗?其实这个就是消息中台的前身。在这之前,消息管理平台只是负责发送小批量的消息(100条以下)。但随着业务的发展,我们发现有很多系统也需要发送几十万、甚至几百万的数据。而在这之前,这个需求只有我们这块业务有。而这块业务实现则是我们单独放在营销发送平台实现,并没有抽离出来作为中台服务。
经过与小伙伴们的讨论,以及对未来业务发展的考虑,我们发现后续应该会有越来越多的系统需要用到这个功能,于是我们决定将原本在营销发送平台的功能抽离出来,放入消息管理平台。而消息管理平台则作为消息中台,掌管所有与用户通信的渠道,包括:邮件、短信、Push 等等。
虽然做架构决策很快,但是怎么去做调整,项目之间的众多细节如何处理,却是一个非常苦恼的问题。对于我来说,我擅长与抽象总结归纳,因此对于整体架构上游刃有余。但重构的具体实现,如何设计得更有扩展性,则更考验程序员的代码实现基本功。
目前这块内容的重构还在进行,等到做得差不多之时,我再分享关于这块内容的重构经验。
总结
这篇文章分享了我工作七年来的三次重大重构经验,也算是对我职业生涯里有关重构的一个总结。每一次重大的重构经验,都让我从中汲取养分,在下次重构时做得更好,让我更加游刃有余。经历过这么几次重大的重构,我也发现了不少重构的经验,这里简单总结下。
第一,先了解业务再重构。 先把业务了解清楚,再去重构,不然这次重构很大可能是失败的,并且会导致你提桶跑路。
第二,小步快跑。 无论如何,还是要保持小步快跑的方式,每次改动较少的地方,然后完成上线。而不要一次性改动太多的地方。
第三,注重沟通。 积极与领导沟通,让他明白你当前的进度,必要时咨询他的意见。切忌自己闷头搞开发,最后别人都不知道你在做什么。
第四,给出自己的方案。 要有自己的思考,能给出自己的方案。对于领导不切实际的方案,要懂得提出自己的意见,引导领导按照自己的思路去做,从而按自己的节奏走。
第五,做好充分的测试。 单元测试是最基本的内容,一定要做好单元测试。对于无法做单元测试的,一定要让测试同学做充分的功能测试。
好了,关于重构的分享,今天就聊到这儿。
参考:
[七年三次大重构,聊聊我的重构成长史 - 陈树义 - 博客园](https://www.cnblogs.com/chanshuyi/p/my-refactor-experiment.html )]