KISS原则

​

什么是KISS原则？

KISS原则是一种设计哲学，主张简单性是创建系统、产品和解决方案的核心价值。KISS是”Keep It Simple, Stupid”（保持简单，愚蠢）的首字母缩写（尽管变体包括”Keep It Simple and Stupid”或”Keep It Short and Simple”）。其基本前提看似简单却非常有力：简单的解决方案比复杂的解决方案更容易理解、实施、维护和调试。

“简单是终极的复杂。” — 列奥纳多·达·芬奇

这一原则源于多个领域的观察。在工程中，复杂的系统有更多的故障点，需要更多的维护，而且更难修改。在商业中，复杂的流程会造成瓶颈，使利益相关者感到困惑，并抵制变革。在软件开发中，过度设计的代码成为技术债务，多年来困扰着团队。KISS原则将这些观察结晶为一条可操作的准则：除非真正必要，否则始终优先选择简单。 一个常见的误解是KISS意味着”简化”或创建原始解决方案。实际上，实现简单往往比创建复杂需要更多的努力。简单的解决方案仍然必须是完整的、功能性的和优雅的——只是避免不必要的装饰，不服务于任何实际目的。

​

KISS原则的三层理解

• 入门: 在解决问题时，在添加功能之前先问”什么是最简单有效的解决方案？“避免猜测未来可能永远不会出现的需求的诱惑。
• 实践: 根据当前需求以最低可行复杂度设计系统。使用清晰、可读的代码，而不是巧妙的一行代码。记录为什么做出决策，而不只是记录实现了什么。
• 进阶: 认识到简单性是情境相关的——对专家简单的东西对新手来说可能不可能。通过构建可以组合成复杂行为的简单接口，在简单性和可扩展性之间取得平衡。

​

起源

KISS原则的确切起源有些模糊，有多个可信来源声称有不同的根源。最广为流传的起源故事将其追溯到1960年代的美国海军航空，当时飞机维护工程师使用”KISS”作为提醒，以保持飞机系统简单和可维护。该短语据报道出现在维护手册中，强调大多数飞机可以通过简单的程序保持运行。 该原则在1970年代和1980年代在软件工程中获得了更广泛的认可，因为开发人员努力应对日益复杂的软件系统。极限编程和测试驱动开发的先驱肯特·贝克（Kent Beck）将简单性作为影响几乎所有软件设计决策的核心价值。同样，传奇工程师艾达· Lovelace 经常被引用（虽然有时不正确）主张在计算机器中保持简单。 该原则得到了众多思想领袖的强化。阿尔伯特·爱因斯坦 famously 声明”一切都应尽可能简单，但不应过于简单”，捕捉到了简单性必须为功能服务的细微差别。在软件中，Unix”做一件事并做好它”的哲学在操作系统设计中回响着KISS。该原则的持久性源于其普遍适用性——简单性在几乎每个人类努力领域都能降低成本、错误和认知负担。

​

核心要点

​

应用场景

​

经典案例

在2000年代初期，谷歌的搜索基础设施 famously 体现了KISS原则。谷歌早期的工程师没有构建具有大量功能集的企业级复杂系统，而是构建了简单、可靠的组件，可以灵活组合。他们的分布式文件系统（GFS）和并行处理框架（MapReduce）在简单性方面很优雅——做好一件事，然后链接在一起解决复杂问题。这种简单性使谷歌的基础设施能够从服务数百万查询扩展到数十亿，与构建复杂得多的系统的竞争对手相比， 工程开销相对较小。教训：简单、专注的组件比复杂、功能丰富的组件更具可扩展性。

​

边界与失效场景

KISS原则虽然强大，但有重要的局限性。首先，过度简化可能牺牲必要的功能。并非所有复杂都是不必要的——有些问题确实需要复杂的解决方案。关键在于区分本质复杂性和偶然复杂性。 其次，对一个受众简单可能对另一个受众不简单。对专家简单的系统可能对新手难以理解。KISS原则需要考虑谁将维护和使用该系统。 第三，天真的简单性可能造成脆弱性。有时添加一层抽象（增加即时复杂性）可以防止以后更大的复杂性。该原则应该鼓励消除不必要的复杂性，而不是避免必要的复杂性。

​

常见误区

​

相关概念

​

一句话总结