如何避免新代码变包袱？阿里通用方法来了！

阿里妹导读：什么是设计？什么是架构？从零开始创建一个新的系统，新写的每行代码均可能成为明天的历史包袱？如何能有效的在遗留代码上工做？今天，阿里资深技术专家辉子为咱们带来NBF框架下软件工程架构设计通用方法论，值得细细品读。

Note：本文讨论的是基于服务化前提下的通用软件工程架构方法论，并未涉及到微观设计或架构的具体细节。

前言

即便代码多年的人都会对这两个问题有点蒙圈：什么是设计？什么是架构？

从单词上看：设计是Software Design，架构是Software Architecture；分别对应的做者是：Designer和Architect：

• Architect都是Designer，但Designer未必是Architect。正如全部的架构设计都是设计，但设计未必是架构设计；
• Design关注微观代码(inside component)，Architecture关注宏观软件结构(between components)；
• Architect应该都是从Designer成长起来的。毕业了用code编写软件；成长了用ppt设计软件；
• 只会用ppt设计，但代码写得很差的Architect都是假的Architect；
• Architecture里听到比较多的词语：Serverless、FAAS、Microservice、multi-layer、Event driven、OSGI、NBF......
• Design里听到比较多的词语：SOLID、 DDD、正交设计、Design Pattern；
• 搞不清SOLID，也不可能把软件的层次分好，也没法理解什么是OSGI的价值；
• 好的Designer是通往好的Architect的必经之路。

服务化架构的基本原则

New System

从零开始创建一个新的系统，有几个特征：

• 历史包袱小
• 上下文简单
• 设计的约束小
• 新写的每行代码均可能成为明天的历史包袱

因为调用方尚未，新系统能够比较完美的执行咱们预想的架构设计，可是切记，最后那行才是最重要的那行：不要让今天的代码成为明天的历史包袱，新的每行代码都在书写历史。

上图的1，2，3，4表明新建系统的顺序：

1. 由“相”抽象出“心”：先思考，那么多的业务场景下“相”，共同的特征“心”是什么。并反向用更多的相去验证心。
2. 将“心”具象成领域模型：关注领域模型(Domain Model)，解耦数据模型(Persistence Model)：将TUNNEL SPI化。
3. 将领域模型中的依赖SPI化：解耦对外部系统的依赖，反转依赖控制权。
4. Mock全部spi实现，确保“心”领域模型包裹的单元测试彻底经过
5. 实现TUNNEL BUNDLE：设计数据模型（Persistence Model），关注“存”，“取”不关注领域模型。
6. 实现依赖SPI适配BUNDLE：链接真实依赖服务。
7. 包装domain service：模型相关，业务无关。
8. 根据业务需求组合/编排domain service成为scenario bundle或者业务SOP。

Working on legacy

对于一个软件工程师来说，写代码最痛苦的事情莫过于coding on legacy，但同时又给了咱们各类说辞：

• 这些代码太烂了，改起来太费劲【须要更多人】
• 这事作不到，由于之前系统架构问题致使的【责任不在我】
• 通过个人修改，如今已经好不少了，工单数量大批降低【我功劳显著】
• 知不知道：接手你代码的人其实也在重复说上述3件事情

如何能有效的在遗留代码上工做，业内有本很是不错的书，叫"Working Effectively with Legacy Code",值得精读：

因此我这里的标题可能不许确，我要讨论的更可能是"遗留代码的重构"，何时咱们开始讨论须要把现有系统重构：

• 代码确实腐化到没法正常维护，或者新加一个需求代价很大；
• 目前代码的技术架构知足不了下一步业务的发展；
• 不少特性已经下线做废，却跟有用的代码藕断丝连；
• 业务逻辑随着发展分散到不一样的应用里，界限不清；
• 专家级的未雨绸缪，着眼将来的规划和新技术的应用；
• 换老大了，须要立新的flag。

架构的基本原则依然是上面那幅图。但上下文的不一样，咱们的发力点和优先级有明显的区别。阿里整个体系里的依赖关系错综复杂，要对阿里环境下的系统作重构是件绝对谨小慎微的事情。为了完成在这么复杂体系下的架构及代码重构，咱们必须有条不紊的分离关注点以及一如既往的坚持软件卓越。

聚焦与收敛上游调用

解耦下游依赖

以服务为单位切换

老系统下线

通过一步一步的分解，legacy系统已经彻底被重构，而且具有随时切换的准备。这里我给几个建议：

1. 先把老实现做为API的默认实现，新的实现做为老的实现的降级实现，并使用策略分流一部分流量（具体比例跟团队信心相关）；
2. 对于有业务需求变动的部分应尽快实如今新的实现里，并将新实现做为API的默认实现，老实现做为新实现的降级实现，策略应该是即时降级，也就是新实现出现问题马上降级到老实现；
3. 运行一段时间没有问题后，讲全部默认实现切换为新实现，并将老实现做为新实现的降级实现；
4. 其实这时就算全部切换完毕：老实现能够永远做为新实现的降级实现，也就是只要我升级一次服务，上一次成功版本就能够做为此次的降级实现，这样，线上问题回滚就是秒级的。

总结

本文基于借助NBF提供的远程多态，服务编排等能力下基础资料，商品，组网等系统新建，重构的经验及方法论总结。仅供遇到架构重构，解耦等问题困扰的技术团队参考。

Note：本文全部图形出自玉简

---

本文做者：辉子

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。