架构技术债的五种表现形式与支付案例

架构技术债是技术债的一种，开发人员在架构层面做出的技术妥协就像一笔债务——眼前能得到好处，但必须在未来偿还，软件工程师要么持续付出额外时间精力修复之前妥协造成的问题及副作用，要么重构把架构实现改善为最佳实现方式；相比最优架构，它是一种为完成组织或企业短期特定业务目标而选择的次优解决方案。架构技术债常见有五种表现形式。依赖违背：上下文特定的架构中（如不同组件层之间）存在被明确禁止的架构依赖。模式和策略的不一致性：贯穿整个系统，架构（和架构师）定义的模式和策略未能保持一致，例如系统某部分采用的命名约定在另一部分没被采用，或同一功能在不同组件间使用了不同的交互模式实现。代码重复（非重用）：系统不同部分（特别是不同产品之间）存在极其相似甚至相同、却没有被分组成一个可重用组件的代码。相互依存资源的时序属性：多个组件访问同一资源时，某组件与资源交互的方式可能改变其他组件与该资源的交互方式，这与时序有关（如两个组件改变数据库状态或访问顺序可能改变系统行为），需要设计特定调度模式来确保组件正确交互。非功能需求的次优机制：可扩展性、性能、可靠性等非功能需求，本该在开发过程之前或早期就被识别并测试，若被拖延处理就会形成架构层面的技术债。书中给出一个商场支付系统的具体案例：用户按有无等级和能否用积分分成三种类型，函数getBill()对不同类型用户做判断、返回应付金额——这个结构能应付简单需求，是架构设计师在没有足够时间选出更好方案、但当前方案能满足客户需求时的常见选择，短期不会产生不良影响；但随着支付系统扩展（如需按不同支付方式提供不同优惠政策），若不偿还这笔债务、继续沿用原设计，就必须修改大量分支代码。解决方案是用策略模式重构Payment类，把客户端代码与实际算法分离——重构后需要修改或增加支付细节时可以直接在服务器端进行，客户端修改量很小，比重构前的结构更有利于后续开发维护。这个案例精确演示了架构技术债最典型的偿还路径：识别出”判断逻辑与业务对象耦合”这个次优设计的具体位置，用一个成熟设计模式（策略模式）替换它，把原本会随需求增长而线性膨胀的分支代码，转化成可以独立扩展的策略对象集合。