敏捷中的架构设计之死

Source: Dev.to

二十年前，敏捷社区曾问过：设计已经死了吗？ 他们的答案是错误的。

我花了十五年时间观察团队使用“演化设计”构建系统。我看到他们庆祝速度，然后又看到这些系统在十八个月后崩溃。

误读

Martin Fowler 2004 年的文章有前提条件：熟练的开发者、完善的测试、小型系统、拥有重构权力的团队。
组织在忽视其他所有前提的情况下采用了“无前置设计”。结果并不是演化设计，而是意外的设计。

扩展问题

当你的系统很小，重构成本低。但系统不会一直保持小规模。

我曾为一家采用“自发架构”的金融科技公司提供咨询。两年快速交付后，他们尝试添加多币种支持。美元的假设遍布各处。一个原本预期一个月完成的功能最终用了八个月。

隐性债务的三类

• 结构耦合： 你的微服务变成了一个带有网络调用的分布式单体。
• 概念碎片化： “客户”在三个服务中代表三种不同的含义。
• 性能债务： 为一个功能执行了十七次数据库查询。

解决方案

在实现任何重要功能之前，先问：

• 这会引入哪些新概念？
• 我们在编码哪些假设？
• 哪些地方将来难以更改？
• 可能的扩展点在哪里？

一个团队在架构探索上多花了一天。六个月后，添加推送通知只用了三天，而不是三个冲刺。

让设计回归

敏捷宣言说“响应变化胜过遵循计划”。它并没有说“没有计划”。
没有选择性压力的演化会产生混乱。在软件领域，这种压力应当来自设计。

完整文章及案例研究、实现清单请访问 agilelie.com