少即是多如何抵制过度设计的诱惑在软件工程师的成长历程中几乎每个人都会经历一段“过度设计迷恋期”刚学了设计模式就恨不得在每一个类上套用工厂模式和观察者模式刚接触了领域驱动设计DDD就非要在一个简单的 CRUD 项目里搞聚合根、值对象和防腐层刚听说了微服务和云原生就急不可耐地把单体拆成十几个独立部署的微服务。这种对复杂度的虚荣心追求不仅没有提升系统的质量反而把原本简单直白的业务逻辑变成了难以阅读、难以调试、难以交付的“工程泥潭”。“少即是多Less is more”不仅是一句设计名言更是顶尖工程师最核心的工程自律。为什么工程师总是忍不住过度设计将“复杂度”误认为“技术深度”在技术汇报或晋升中工程师往往担心写简单的代码显得没有工作量于是通过堆砌复杂的中间件、抽象层和专业名词来增加技术光环对“虚构未来”的过度焦虑“万一以后业务增长 100 倍呢”、“万一以后要支持多云部署呢” 于是为了 1% 的潜在可能性付出了 99% 的过度开发和维护成本沉迷于搭积木的智力快感把原本 10 行能写完的代码拆成 5 个文件享受代码在 IDE 中跳转的仪式感却忽略了业务真正关心的交付效率与稳定性。抵制过度设计的三道“心智紧箍咒”每当你在键盘前想要新建一个抽象层、引入一个新框架或拆分一个服务时在心中默念三道紧箍咒紧箍咒一Rule of Three三次法则“事不过三不造轮子没有三个真实场景坚决不做抽象。”当同一段逻辑只在代码中出现一次或两次时直接复制粘贴或者适度硬编码是完全可以接受的。只有当它在三个完全不同的业务场景中被反复要求实现时才值得花时间去提炼抽象函数。紧箍咒二KISS 原则Keep It Simple, Stupid“能用单体解决的坚决不拆微服务能用单文件解决的坚决不分层能用 switch-case 解决的坚决不上状态机引擎。”永远把最直白、最浅显的实现作为第一方案。如果一个刚入行的初级工程师花 5 分钟看不懂你的代码说明这段代码大概率已经被过度设计了。紧箍咒三算清技术债的利息账单引入每一个新库、每一个抽象层都在透支未来的排障与升级成本。永远问自己“这个设计是在解决当下的真实痛点还是在满足我个人的技术虚荣心”极简主义的最终收益当你开始坚定不移地践行“少即是多”时奇妙的改变发生了代码库总行数急剧缩减代码读起来如同散文般通透流畅本地单测毫秒级全绿发版变得像呼吸一样自然系统的 Bug 率断崖式下跌团队终于有充裕的时间去思考产品与业务的真正价值。总结成熟的标志是学会克制。砍掉一切虚妄的枝节让代码回归纯粹与力量。少即是多实用为王。
