Uber架构重构的十二条军规.docxVIP

Uber架构重构的十二条军规 崔康 2021-01-17 对于开发者来说，架构设计是软件研发过程中最重要的一环，所谓没有图纸，就建不了房子。在遍地App的互联网时代，架构设计有了一些比较成熟的模式，开发者和架构师也可以经常自创。 但是，随着应用的不断进展，最后的架构往往面临着各种问题，比如无法满足客户的需求、无法实现应用的扩展、无法实现新的特性等等。在这种情况下，我们如何避开一些坑，尽量比较成功地实现架构的重构，是很多开发者和架构师亟需处理的问题。 在这里，跟大家共享一下Uber的工程主管Raffi Krikorian的12条规章，并附上一些解读，期望对大家有所启发。 看起来这个法规有些多余，但是请不要忽视。每一次架构的重构都是“伤筋动骨”，就像做手术一样，即便再成功，也会伤元气，所以决策者们首先要分析架构重构的理由和其他备选方案，明确重构的目的是为了满足业务需求，并且是不得不做的最佳方案，然后再考虑其他问题。 有时候，经过分析就会发觉，或许还有其他处理方案，比如添加计算资源，或者重构的目的不是为了业务需求，那就没有必要做了。 检查清单： 架构重构的缘由是什么，是为了满足业务的需要还是只是觉得架构不好看？ 除了架构重构之外，还有其他备选方案吗？能否都分析过这些方案的利弊？ 假如确定要重构，那么要把目标明确下来，也就是重构的边界条件，怎样才算是 “完成”了重构，目标要有数据量化，或者有能够测试的方法。这也是一个需求分析的过程，假如需求不明确，那么规格说明书没法写清楚，担任重构的团队也没有明确的目标，不能以重构的时间或者客观的推断为结束的依据。前几天和一伴侣谈天，他最近在担任系统的功能优化，也要做一些重构的事情，开头的时候团队的目标不明确，大家不晓得优化到什么程度，所以不敢下手。假如目标是提高10%，那么可以从细节处着手；假如是提高50%，那可能要搞大动作才能实现了。后来目标明确之后，团队才找到合适的方法。 检查清单： 重构的目标可以量化，或者说可以测试吗？ 重构完成的标准是什么？得到业务部门或者领导的认可了吗？ 现在软件研发最流行的就是快速迭代、持续交付、尽早反馈。这同样可以用在架构的重构上，重构过程的难度不亚于构建一个新产品，所以在设计重构的时候，要引入持续交付的流程，每一个重构步骤或者模块都要快速部署并得到反馈，以便评估重构的效果，准时作出策略调整。有的读者会说，我们的架构重构是釜底抽薪型的，没法渐进，只能一蹴而就。假如是这种情况，可以考虑在另外一套拷贝的系统中做重构，经过谨慎测试之后，将数据和业务迁移过去。 检查清单： 能否把重构过程分成小的迭代，每一次改进都能尽快得到反馈？ 重构过程中的效果能够定期呈现给业务部门或者领导吗？ 在启动重构之前，团队要对当前的架构形态有清楚的了解，也就是设定好基准，以便评估重构的效果。据我的阅历，担任重构的架构师或者开发者，往往还没 有搞清楚现有的架构设计，就开头重构了，结果经常消灭这样的情况：重构到某个阶段，发觉行不通，然后一拍脑袋说，哦，原来这块的架构是这个样的，是为了达 到某某业务需求啊，这块不能动，得想别的方法。类似的例子在研发团队中时有发生，也提示我们要慎重当心。记得有位哲人说过，了解别人很简约，了解本人很 难。 检查清单： 你了解当前的架构设计吗？它的设计初衷和之前的选型方案晓得吗？ 你能给架构设定一个基准形态吗？ 数据的重要性不言而喻，业务都是以数据流为载体的，所以架构重构的本质就是对于数据流的重构。数据对重构的重要性次要体现在两个方面：在重构设计时，需要考虑业务数据的需求，重构之后的系统对于数据的存储、处理、分析等功能能否有影响；在重构过程中，考虑依靠数据甚至是实际的数据来验证重构的效果，供应评估的支持。 检查清单： 业务数据的需求在重构设计中有体现吗？ 重构过程中能否通过实际数据来验证效果？ 技术债务在平常的软件研发过程中也是比较突出的问题，现在单独拿出来强调是期望提示开发者们：架构重构往往是为了偿还技术债务，所以请不要在偿还技术债务的过程中制造技术债务了。技术债务就像信誉卡一样，会有很高的利息率，就犹如给团队留下了大量的帐务开销。组织应当培育一种保证设计质量的文化。应当鼓舞重构、同时也应当鼓舞持续设计以及其它有关代码质量的实践。在开发时间中应当特地抽出一部分以处理技术债务。假如没有合适的照料，那么真实世界中的代码会变得越来越简单难懂。 检查清单： 团队对技术债务有跟踪和备忘录机制吗？还是开发人员可以任凭的产生债务？ 针对技术债务有定期的培训、回顾机制吗？ Java后端架构，关注猎取更多技术共享 欢迎加入 联系QQ：517894513 QQ群号码：217023887