软件设计师手记：好设计，让变化只改一小块代码

软件设计师常被误解为“写代码更久的人”。其实，软件设计师的核心价值不在于写更多代码，而在于判断哪些代码值得写、哪些边界必须划、哪些变化应该被隔离。代码只是设计的结果，不是设计的全部。

举个简单的例子。订单结算需要支持不同折扣：普通用户原价，VIP 打九折，SVIP 打八折。最初，很多人会这样写：

if (user.isVip()) {
    total = total.multiply(0.9);
} else if (user.isSvip()) {
    total = total.multiply(0.8);
}

它能运行，也足够直观。但问题在于：每新增一种折扣，结算流程都要被修改。今天加“新用户首单减 20”，明天加“节日活动满减”，这段逻辑会迅速膨胀成一座分支迷宫。软件设计师看到的不只是代码，而是变化的方向：折扣规则会变，结算流程相对稳定。

于是，软件设计师会尝试把变化关进一个边界里。代码可以很少，比如只定义一个接口：

public interface DiscountPolicy {
    Money apply(Money total);
}

这个接口本身不解决任何业务问题，但它划出了一条契约：结算服务只依赖 DiscountPolicy，不关心具体折扣怎么算。新增规则时，新增一个实现类即可，不必修改结算主流程。这就是“对扩展开放，对修改关闭”的朴素落地。

但软件设计师不会因此走向另一个极端：逢 if 必设计模式，逢变化必加抽象层。如果只有两种折扣，且半年都不会变，直接写 if-else 反而更诚实。设计模式不是目标，管理复杂度才是。过度设计会带来类爆炸、调用链变长、新人理解成本上升，它和欠设计一样，都是负债。

所以，软件设计师真正做的，是在代码之外做权衡：

• 哪些概念是稳定的，哪些是易变的？
• 依赖应该指向谁，接口应该由谁定义？
• 性能、安全、可测试性、可观测性，哪些是硬约束？
• 团队能否理解并维护这套抽象？
• 未来半年最可能发生的变化是什么？

这些问题，比多写几个类更重要。软件设计师还要把设计写成文档、画成图、讲成共识。因为架构不是某个人脑子里的蓝图，而是团队共同遵守的边界。

好的设计，往往在代码里看不见。它不炫耀技巧，不堆砌模式，而是让每个模块只承担该承担的职责，让每次需求变更只影响一小块代码。软件设计师的价值，不是写更多代码，而是让团队少写、写对、敢改。

真正的好设计，会在下一次需求到来时显现：别人忙着改十处，你只需要加一个实现。