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

标签: 架构 重构 | 发表时间:2015-04-24 18:29 | 作者:
出处:http://kb.cnblogs.com/

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

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

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

   确定重构的目的和必要性

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

  检查清单:

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

   定义“重构完成”的界限

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

  检查清单:

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

   渐进式重构

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

  检查清单:

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

   确定当前的架构状态

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

  检查清单:

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

   不要忽略数据

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

  检查清单:

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

   管理好技术债务

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

  检查清单:

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

相关 [架构 重构] 推荐:

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

- - 博客园_知识库
  对于开发者来说,架构设计是软件研发过程中最重要的一环,所谓没有图纸,就建不了房子. 在遍地App的互联网时代,架构设计有了一些比较成熟的模式,开发者和架构师也可以经常借鉴.   但是,随着应用的不断发展,最初的架构往往面临着各种问题,比如无法满足客户的需求、无法实现应用的扩展、无法实现新的特性等等.

唯品会11.11:频繁黑匣架构背景下,看唯品会的革命性重构

- - IT瘾-geek
eBay和唯品会的电商文化缩影. eBay是一个老牌的互联网公司,是曾经全球最大的交易平台. 我有幸在eBay中国研发中心工作接近10年,曾经在支付平台、电商平台、云平台等不同开发部门工作过. eBay电商系统设计非常复杂,将系统划分为一个个小模块,每个团队和其中每个人负责一个产品的一个小模块. 这种系统结构经过长期演练已经非常严谨、成熟和稳定.

代码重构

- - ITeye博客
随着程序的演化,我们有必要重新思考早先的决策,并重写部分代码. 代码需要演化;它不是静态的事物. 重写、重做和重新架构代码合起来,称为重构.    当你遇到绊脚石  ---  代码不在合适,你注意到有两样东西其实应该合并或是其他任何对你来说是"错误"的东西  -------- . 如果代码具备以下特征,你都应该考虑重构代码:.

Sunny谈重构

- - CSDN博客架构设计推荐文章
       按照软件工程大神Martin Fowler的定义, 重构就是在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,进而提高软件的可扩展性和可维护性. 这是重构的定义,简单来说就是不改变软件的功能,优化软件设计和代码,让软件更易于扩展和维护,当然也包括易于复用.

信息架构

- Michael - Tony-懒得设计
写几篇关于信息架构的文章,系统地输出我理解的信息架构. 发了一篇关于招信息架构实习生的博客,收到不少简历. 但谈起信息架构,多数不了解,稍微了解的扯了很多很偏的东西. 随手搜索了一下,我发现了原因:. 1 《web信息架构》这本书太概念,太学术. 2 有人绑架了“信息架构”这个词,拿出去唬人,内容都是皮毛或者是根本和信息架构不沾边的东西.

CSS架构

- - 博客 - 伯乐在线
英文原文: CSS Architecture,编译: CSDN-张红月. Philip Walton 在AppFolio担任前端工程师,他在Santa Barbara on Rails的聚会上提出了CSS架构和一些最佳实践,并且在工作中一直沿用. 擅长CSS的Web开发人员不仅可以从视觉上复制实物原型,还可以用代码进行完美的呈现.

Linux的架构

- - 博客园_首页
作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明. 我们以下图为基础,说明Linux的架构(architecture). (该图参考《 Advanced Programming in Unix Environment》). 最内层是我们的硬件,最外层是我们常用的各种应用,比如说使用firefox浏览器,打开evolution查看邮件,运行一个计算流体模型等等.

LMAX架构(转)

- - 企业架构 - ITeye博客
LMAX是一种新型零售金融交易平台,它能够以很低的延迟(latency)产生大量交易(吞吐量). 这个系统是建立在JVM平台上,核心是一个业务逻辑处理器,它能够在一个线程里每秒处理6百万订单. 业务逻辑处理器完全是运行在内存中(in-memory),使用事件源驱动方式(event sourcing).

软件架构

- - 研发管理 - ITeye博客
    对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的.     1、为大规模开发提供基础和规范,并提供可重用的资产,软件系统的大规模开发,必须要有一定的基础和遵循一定的规范,这既是软件工程本身的要求,也是客户的要求. 架构设计的过程中可以将一些公共部分抽象提取出来,形成公共类和工具类,以达到重用的目的.