Linux 之父出席、干货分享、圆桌讨论,精彩尽在 OpenCloudOS 社区开放日,报名戳 了解详情
写点什么

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

  • 2015 年 4 月 26 日
  • 本文字数:1938 字

    阅读完需:约 6 分钟

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

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

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

确定重构的目的和必要性

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

检查清单:

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

定义“重构完成”的界限

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

检查清单:

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

渐进式重构

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

检查清单:

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

确定当前的架构状态

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

检查清单:

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

不要忽略数据

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

检查清单:

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

管理好技术债务

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

检查清单:

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

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

2015 年 4 月 26 日 02:147931
用户头像

发布了 501 篇内容, 共 227.7 次阅读, 收获喜欢 51 次。

关注

评论

发布
暂无评论
发现更多内容

盘点 2021|自己一个人扛起了公司的半边天

liuzhen007

技术人生 盘点2021 盘点 2021

Golang中文件的基本操作

liuzhen007

Go 28天写作 Go 语言 12月日更

Prometheus Exporter (三十四)JSON Exporter

耳东@Erdong

json Prometheus 28天写作 exporter 12月日更

架构实战营模块四作业

Poplar

#架构实战营

作业

AUV

「架构实战营」

模块三-学生管理系统详细架构设计

圈圈gor

架构实战 「架构实战营」

040022-week8-design

InfoQ_70156470130f

《PyTorch 深度学习实战》项目复习3

IT蜗壳-Tango

28天写作 12月日更

如何设计贴合业务的高性能高可用中间件系统

天天向上

架构实战营

架构模块三作业

holdzhu

「架构实战营」

外包学生管理系统架构设计文档

李晓笛

「架构实战营」

成都成都-01

wood

成都 28天写作

netty系列之:请netty再爱UDT一次

程序那些事

Netty 程序那些事 12月日更 UDT

一个cpp协程库的前世今生(一)缘起

SkyFire

协程 cpp cocpp

Java 数据持久化系列之池化技术

程序员历小冰

MySQL 持久化 28天写作 池化技术 12月日更

谈谈MemoryCache原生插值方式

喵叔

28天写作 12月日更

Kafka往事——Kafka的诞生

Kafka中文社区

架构实战营第三模块作业

马英杰

元宇宙100讲-0x011

hackstoic

元宇宙

作业:架构实战营模块 3

Poplar89

「架构实战营」

“学生管理系统”架构文档

CH

#架构实战营

模块三作业

novoer

「架构实战营」

瞰见 | 开源,会不会变成开源创业的焦油坑?

OpenTEKr

狄安瞰源

架构实战营模块三作业

lchx08

「架构实战营」

ALC北京发起人 姜宁:通过开放与协作,我们可以实现一个人想都不敢想的事情 I OpenTEKr 大话开源 Vol.6

OpenTEKr

大话开源

瞰见 | 初创1个月就融到3亿美金,ClickHouse 你凭什么?

OpenTEKr

狄安瞰源

外包学生管理系统详细设计文档

guodongq

「架构实战营」

模块三作业——学生管理系统详情设计

马志峰

架构实战营

第三模块学习总结

努力的静静

#架构实战营

「架构实战营」模块三《如何保证设计出合理的架构》作业

DaiChen

作业 模块三 「架构实战营」

Apache 海豚调度 PMC 郭炜:开源,不是天才的甜点,而是执着者的盛宴 I OpenTEKr 大话开源 Vol.7

OpenTEKr

大话开源

GPU容器虚拟化:用户态和内核态的技术和实践详解

GPU容器虚拟化:用户态和内核态的技术和实践详解

架构之重构的12条军规(上)_重构_崔康_InfoQ精选文章