前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >如何做系统重构

如何做系统重构

作者头像
Java架构
发布2018-05-04 14:32:56
1.3K0
发布2018-05-04 14:32:56
举报
文章被收录于专栏:Java架构师学习

重构,是任何一个技术团队都无法绕过和回避的话题。记得10年前,我第一份正式工作,就经历了项目持续的重构历程,为了写好代码,当时还反复读了Martin Flower的《Refactoring》, 时到今日,这本书里的很多点,还给了我很多启示。回顾这10多年来经历的各类项目,还是有很多值得分享的点,准备分两篇文章,来过一下这些想法,抛砖引玉,期待有更多好的想法能冒出来。

1. 明确本次重构的目的

我的第一个观点,重构是有代价的,带来业务的不稳定(引入新的bug)和人力资源的投入(大家需要暂时放下业务的推进)。所以在我们动手之前,一定要明确我们本次重构的原因是什么?,是为了满足业务的需要或只是觉得架构有缺陷?每一次架构的重构都是“伤筋动骨”,就像做手术一样,即使再成功,也会伤元气。重构的首要目的一定是为了更好的满足业务需求,然后再考虑其他问题,这就意味着,如果本次重构对未来业务承接的促进很小的话(比如仅是引入新的框架和技术),那么本次重构需要慎重或者暂缓。同时,需要认真比较重构的各种方案的利弊,想清楚后再开始,任何时候都需要有方案B。

2. 明确当前系统的状态

决定要执行重构后,首要做的任务,并不是立刻动手执行重构,而是对当前的架构状态有清晰的了解,如果开发当前系统的同事还在本公司,一定要拉着同事好好的讨论一下,作者给大家讲讲当时的思路,比我们闷头看代码理解还是要强不少的,能清楚理解当前系统的设计初衷。除此之外,通过研究当前系统,才能记录目前系统的性能基准,为未来评估重构的效果做准备。过去,我遇到不少同学,还没吃透当前系统的设计和代码,就开始大刀阔斧的开始重构了,最终的结果很可能是引入regression BUG, 或者是执行过程中,发现重构不下去了,原来这块的架构是为了达到某某业务需求啊,这块不能动,得想别的办法。所以不吃透代码和架构,直接进行重构是很危险的,慎行。

3. 重构的目标必要被量化

如果确定要重构,那么要把目标明确下来,也就是重构的边界条件,明确列出本次重构需要完成的要点,目标要有数据量化(比如代码行数降为过去的一半,代码执行时间缩短为过去的百分之30等等),同时,重构后的代码能够被有效的测试。重构之前,需要有一个需求分析的过程,如果需求不明确,重构PRD不能写清楚,负责重构的团队也就很难有明确的目标。特别是重构工作被一个团队来执行的时候,所有的成员对重构的目标必须要达成一致,开发成员内部,还是开发和测试之间,谨防重构不到位或者过度重构。

4. 重构中必须建立或者维护业务数据流

大家有任何想法和建议,请加我的JAVA架构进阶群:554355695

现在任何一个后台系统,都会通过日志系统建立必要的业务流转记录,比如,我这几年前后带的几支团队,都会建立各类业务埋点。本质上的原因在于,业务都是以数据流为载体的,架构重构的本质就是让数据流更通畅。所以在重构过程中,我们务必保证以下两点,1. 重构后的系统,对于数据的存储、处理、分析等功能是否有影响;2. 在重构过程中或者重构后,我们能用数据来验证重构的效果,能不断的对系统进行优化。

5. 采用“迭代式”重构

做过重构的小伙伴都知道,做重构的复杂度并不亚于做一个全新的产品,和自己的小伙伴私下沟通下来,都愿意重新做,而不是在老的代码上改。在这里说这个话的意思在于重构并不是一个一蹴而就的事情,既然如此,那么我们就需要考虑将一次重构拆分为多次“迭代”行为,然后每一个重构步骤能快速部署上线并得到反馈,以便评估重构的效果,及时作出调整。从项目风险的角度来说,通过将重构分成多个迭代,能有效的控制迭代的风险,每一个步骤,重构团队(开发和测试)都能集中一点吃透,并进行充分的测试。如果直接将重构1,2个月后的版本,一下丢给测试同学去验证,效果可见一斑。

另外一方面,重构过程对bug的容忍性比新产品的研发更低,上一次重构迭代的结果,决定了下一次重构迭代的执行。不论团队多忙,一定要保证代码提交之前,是经过其他成员审核过的,短期来看会占用团队的时间,长期来看是事半功倍的好事。

至于如何来拆分重构,并没有一个统一的标准,但是我个人的看法,每次重构的工作量,不应该超过1个正常的迭代(2周时间)。

6. 重构首选团队熟悉的技术

在我们制定重构方案过程中,第三方技术框架的选择至关重要,这关系到重构最终的成败,毕竟最后判断重构成功与否的是上线正常运行,所以是选择最新流行的技术还是发展成熟的技术其实并不重要,重要的是我们团队能否驾驭这门技术,是否有对应的人才储备,我们是否清楚该技术里面的“坑”,是否可以找到对应的技术社区帮助我们应对执行过程中产生的问题,在这里可以和大家讲一个我自己经历的惨痛的教训,2年前,我们在缓存方案上选择了我们并不是特别熟悉redis cluster,  而不是常规的redis 2.x版本,或者阿里云的KVStore,上线后,踩了各种坑,每次都只能事后来修复,充分暴露了如果对该技术没有吃透,就将它推向生产线,那就有很大的潜在风险,当然,如果现在上Redis Cluster, 我是很有信心的,因为我已经掌握了 :) 。对技术的选择上,我们需要反复确认各种技术方案对系统重构的影响和效果,必须要有前置的技术调研,并拿到对应的调研数据,根据数据和经验来做决策。

7. 重构前务必和业务方沟通

很多技术团队认为,重构的事情就是技术团队内部的事情,但是从我过去共事过的多个团队看,这个想法过于天真了,重构的最终目的就是改进业务和更好的承接业务,所以如果不和业务方做充分的沟通,甚至不了解业务就开始做重构,结果就是很可能没有抓到重点,例如,我们需要知道哪些关键业务的架构是不能轻易碰的,哪些业务之间是互相关联的。所以,我自己的技术团队在执行重构前,会和产品团队,运营团队做充分的沟通。

与业务方沟通的目的有2点:

了解业务方的述求,并把这些点放入到重构过程中,梳理清楚代码中,各类业务的运行情况,清楚每一项业务的重要程度。

寻求业务方的支持和帮助,重构过程中,需要和业务保持积极的沟通,确保重构不会对业务产生影响。 反过来说,通过沟通,才能获得业务团队对技术团队做重构的支持和理解,重构过程中才不会碰到非技术层面上的障碍。

8. 重视重构中的非技术问题

这一点是我过去1年,理清楚的一些问题,趁这个机会分享一下:

舒缓团队的压力,给予团队更多的鼓励。说白了,重构对个人或者团队来说通常是一件费力不讨好的事情。和做一个新产品或者新功能,能够取得老板或各业务方的掌声相比,重构的成绩往往不受老板重视,而且出了问题还要承担很大的责任。 因此,重构之前,我会提前给团队做好心理准备,打预防针,帮助大家舒缓压力,并且将重构的成果量化和业务的变化关联起来,定期向各方同步状态,得到大家的理解和支持。

做好重构过程中各种非技术沟通,任何一次较大的技术重构,都会遇到一些非技术因素,而这些因素往往不是我们所能掌控的。我们能做的就是与相关利益方进行有效的沟通,坦诚地和他们交流,非技术因素的影响是客观存在的,从公司层面来说也是合理的,对于技术人来说要学会适应。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2017.11.16 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 Redis
腾讯云数据库 Redis(TencentDB for Redis)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档