BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

架构之重构的12条军规(上)

| 作者 崔康 关注 0 他的粉丝 发布于 2015年4月27日. 估计阅读时间: 5 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

对于开发者来说,架构设计是软件研发过程中最重要的一环,所谓没有图纸,就建不了房子。在遍地App的互联网时代,架构设计有了一些比较成熟的模式,开发者和架构师也可以经常借鉴。

但是,随着应用的不断发展,最初的架构往往面临着各种问题,比如无法满足客户的需求、无法实现应用的扩展、无法实现新的特性等等。在这种情况下,我们如何避免一些坑,尽量比较成功地实现架构的重构,是很多开发者和架构师亟需解决的问题。

在这里,跟大家分享一下Uber的工程主管Raffi Krikorian的12条规则,并附上一些解读,希望对大家有所启发。

确定重构的目的和必要性

看起来这个规矩有些多余,但是请不要忽略。每一次架构的重构都是“伤筋动骨”,就像做手术一样,即使再成功,也会伤元气,所以决策者们首先要分析架构重构的理由和其他备选方案,明确重构的目的是为了满足业务需求,并且是不得不做的最佳方案,然后再考虑其他问题。 有时候,经过分析就会发现,也许还有其他解决方案,比如增加计算资源,或者重构的目的不是为了业务需求,那就没有必要做了。

检查清单:

  • 架构重构的原因是什么,是为了满足业务的需要还是只是觉得架构不好看?
  • 除了架构重构之外,还有其他备选方案吗?是否都分析过这些方案的利弊?

定义“重构完成”的界限

如果确定要重构,那么要把目标明确下来,也就是重构的边界条件,怎么才算是“完成”了重构,目标要有数据量化,或者有能够测试的办法。这也是一个需求分析的过程,如果需求不明确,那么规格说明书没法写清楚,负责重构的团队也没有明确的目标,不能以重构的时间或者主观的判断为结束的依据。前几天和一朋友聊天,他最近在负责系统的性能优化,也要做一些重构的事情,开始的时候团队的目标不明确,大家不知道优化到什么程度,所以不敢下手。如果目标是提高10%,那么可以从细节处着手;如果是提高50%,那可能要搞大动作才能实现了。后来目标明确之后,团队才找到合适的办法。

检查清单:

  • 重构的目标可以量化,或者说可以测试吗?
  • 重构完成的标准是什么?得到业务部门或者领导的认可了吗?

渐进式重构

现在软件研发最流行的就是快速迭代、持续交付、尽早反馈。这同样可以用在架构的重构上,重构过程的难度不亚于构建一个新产品,所以在设计重构的时候,要引入持续交付的流程,每一个重构步骤或者模块都要快速部署并得到反馈,以便评估重构的效果,及时作出策略调整。有的读者会说,我们的架构重构是釜底抽薪型的,没法渐进,只能一蹴而就。如果是这种情况,可以考虑在另外一套拷贝的系统中做重构,经过谨慎测试之后,将数据和业务迁移过去。

检查清单:

  • 能否把重构过程分成小的迭代,每一次改进都能尽快得到反馈?
  • 重构过程中的效果能够定期展示给业务部门或者领导吗?

确定当前的架构状态

在启动重构之前,团队要对当前的架构状态有清晰的了解,也就是设定好基准,以便评估重构的效果。据我的经验,负责重构的架构师或者开发者,往往还没有搞清楚现有的架构设计,就开始重构了,结果经常出现这样的情况:重构到某个阶段,发现行不通,然后一拍脑袋说,哦,原来这块的架构是这个样的,是为了达到某某业务需求啊,这块不能动,得想别的办法。类似的例子在研发团队中时有发生,也提醒我们要慎重小心。记得有位哲人说过,了解别人很容易,了解自己很难。

检查清单:

  • 你了解当前的架构设计吗?它的设计初衷和之前的选型方案知道吗?
  • 你能给架构设定一个基准状态吗?

不要忽略数据

数据的重要性不言而喻,业务都是以数据流为载体的,所以架构重构的本质就是对于数据流的重构。数据对重构的重要性主要体现在两个方面:在重构设计时,需要考虑业务数据的需求,重构之后的系统对于数据的存储、处理、分析等功能是否有影响;在重构过程中,考虑依靠数据甚至是实际的数据来验证重构的效果,提供评估的支持。

检查清单:

  • 业务数据的需求在重构设计中有体现吗?
  • 重构过程中能否通过实际数据来验证效果?

管理好技术债务

技术债务在平常的软件研发过程中也是比较突出的问题,现在单独拿出来强调是希望提醒开发者们:架构重构往往是为了偿还技术债务,所以请不要在偿还技术债务的过程中制造技术债务了。技术债务就像信用卡一样,会有很高的利息率,就如同给团队留下了大量的帐务开销。组织应该培养一种保证设计质量的文化。应当鼓励重构、同时也应当鼓励持续设计以及其它有关代码质量的实践。在开发时间中应当专门抽出一部分以解决技术债务。如果没有合适的照料,那么真实世界中的代码会变得越来越复杂难懂。

检查清单:

  • 团队对技术债务有跟踪和备忘录机制吗?还是开发人员可以随意的产生债务?
  • 针对技术债务有定期的培训、回顾机制吗?

作者的微信公众号“技术风向标”,关注IT趋势,承载前沿、深入、有温度的内容。感兴趣的读者可以搜索ID:jishuqushi,或者扫描下方二维码加关注。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

架构之重构的12条军规(下) by JIN Jerry

你好,目前我正要对现在的系统进行重构,请问,剩余的一般军规是什么?

Re: 架构之重构的12条军规(下) by 崔 康

剩下军规的描述见第一个图,具体的分析文章会在5月份发布,感谢支持!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT