数十年来，软件行业一直重复着KISS的箴言：保持简单，傻瓜（Keep It Simple, Stupid）。但在某个时候，我们停止践行它了。
如今，我们设计的系统远比它们试图解决的问题复杂得多。我们在层层叠加抽象、嵌套层级之后，甚至在业务方尚不清楚自己需要什么之前，就把系统拆分成数十个微服务。接着我们便困惑：为何软件难以修改、维护成本高昂且抗拒调整。
本文提出一个令人不安却重要的观点：
现代软件工程已偏离了简单性——而我们付出的代价是适应性。
让我们重新聚焦KISS，不是作为怀旧的口号，而是作为构建弹性、可维护系统的实用策略。
1. 简单性是设计目标——而非事后补救
KISS并非不惜一切代价避免复杂性。
而是要最小化意外复杂性——那种不提供商业价值却增加一切成本（理解、调试、上手、测试、重构、调整）的复杂性。
简单性并非没有功能，而是刻意消除阻碍。
这需要纪律：拒绝不必要的泛化、不必要的抽象和不必要的层级。
真正的简单是有意为之。
2. 简单性是成本节约策略
每位工程师都凭直觉知道：复杂系统成本更高。
但在实践中，团队往往优化“工程优雅性”，而非总拥有成本。
长期成本被隐藏起来——直到它不再隐藏。
复杂性会增加：
故障点数量
集成面
测试负担
运营开销
每位未来开发者的认知负荷
而最危险的是：
复杂系统会变得僵化。它们抗拒改变，因为每次改变都感觉充满风险。
简单性不仅是品味好，更是经济之道。
3. 唯一确定的是需求会变
这是软件工程中最大的盲点之一：
软件在构建前几乎从未被完全理解。
需求不理解，业务规则不理解，工作流程不理解，支撑它们的技术结构更不理解。
为何如此？因为大部分知识是在开发过程中通过探索浮现的：
利益相关者在看到系统使用时完善想法
自动化揭示瓶颈与新机遇
业务优先级转移
环境变化
约束只有在事后才变得可见
“我们能预先设计一切”的想法只是虚构。
如果变化不可避免，那么简单性就成了一种保险政策：
系统中硬编码的假设更少
架构僵化程度更低
重构更容易
团队对齐更快
调整时风险更低
简单性让系统保持可变性。
4. 服务层陷阱：一堆无上下文的逻辑
如今许多应用严重依赖“服务层”——满是业务操作的程序类。
但这种风格有隐藏成本：服务类是脱离上下文的区域。
它们不代表业务概念，不拥有不变式，不封装行为，只编排操作。
因此，业务规则失去了归属地。
这必然导致：
逻辑重复
验证不一致
工作流脆弱
程序大杂烩
无论团队多么努力保持纪律，重度服务架构都保证业务规则会散落在代码库中。
为何？因为没有归属地的规则会在需要时随处被重新发明。
简单性要求业务规则的本地化——通常通过丰富的领域模型或其他形式的上下文封装实现。
5. 微服务让重复成为必然
许多组织发现得太晚的残酷事实是：
微服务并未消除复杂性——它们将其倍增并分散。
而且它们保证了逻辑的重复。
不是因为团队协调不力，而是因为分布式系统迫使重复。
如果业务规则涉及多个领域（它们总是如此），那么将这些领域拆分为独立服务意味着：
每个服务必须强制执行规则的自己那部分
每个服务必须存储自己的相关数据
每个服务必须独立验证
规则变更必须在多处应用
这不是可选的，而是架构固有的。
分布式系统若不破坏独立性就无法集中业务逻辑——而这违背了微服务的初衷。
因此，微服务造成：
协调开销
规则的不同解读
部署流水线延迟
每次跨域变更的阻碍
可观测性帮你看到复杂性，却无法减少它。
微服务是对成熟、稳定领域的优化——而非新兴或演进中的领域。
6. 过早分布扼杀适应性
团队常早期采用微服务以“为扩展做准备”或“获得更好监督”。
但这里有个悖论：微服务让理解整个系统变得更难。
你增加了：
运营开销
部署复杂性
同步要求
部分故障
版本问题
调试难度
同时，你减少了：
连贯性
一致性
正确性
适应性
这不是简单性，而是伪装成现代性的架构债。
最简单的架构通常是：
单体式
内部模块化良好
领域建模丰富
为变化而设计
在真正必要时能演化为微服务
并非因为单体式固有优越——而是在探索阶段，内聚性优于碎片化。
7. 简单性=适应性
结合以上所有观点，信息变得清晰：
简单性减少意外复杂性→减少的复杂性降低变更成本→更低的变更成本提升适应性。
适应性是任何长寿软件系统最重要的属性。
目标不是完全避免复杂性——而是仅在领域需要时引入，且仅在它明显值得的地方引入。
这就是现代工程中KISS的精髓。
8. 将KISS带回实践
要将简单性重新锚定在我们的工程文化中，我们需要秉持几个明确原则：
不要实现当下不需要的功能。通过推测性抽象实现“未来证明”是个陷阱。
显式建模业务概念，而非程序化。给业务规则一个归属地。
在领域稳定前，优先选择模块化单体式而非微服务。分布并非免费。
推迟不可逆的决策。选择灵活性而非过早的结构。
优先优化清晰度。理解系统的团队能安全地改进它。
若如此，系统将更易使用而非更难。工程也将更专注于解决实际问题，而非管理我们自己制造的复杂性。
结论：带回KISS
软件工程并非有意抛弃KISS。我们只是让它淹没在承诺可扩展性和优雅性、却带来复杂性和脆弱性的工具、模式和架构趋势中。
是时候回归基础了。
简单性并非天真，并非初级，并非缺乏野心。
简单性是战略，是可持续，是让软件存活的根本。
因为归根结底：
复杂系统会崩溃，简单系统会适应。
而适应性才是软件真正的力量。
