简单设计中的四条原则就是设计的全部了吗？

在设计决策中，提到了4个原则应对4种要求（需求充分、可理解性、可修改性、简单），但设计还有其他要求，简单设计为什么没有考虑将怎么应对这些要求的方法纳入进自己的原则体系？

在TDD训练营或重构训练营中，我都会将简单设计作为必讲的知识点。我觉得这四条原则非常朴素，也较为容易理解。并且背后支撑了考量软件的核心的四个维度：

1. 需求充分，编写的软件要满足客户需求的，这个毋庸置疑，没什么可讨论的。
2. 可理解性，编写的软件要易于理解，这个是广大开发人员也不会反对的事实。
3. 可修改性，编写的软件要易于修改，这个也是广大开发人员不会反对的实施。
4. 简单，编写的软件要简单，如非必要，不要加多余的元素，但看这个点，很多人也不会反对，但很多人不知道怎么把我。

可能你会说，软件设计远远不止这些，还有好多，比如：

1. 高内聚，低耦合
2. 面向抽象编程
3. 组合优于继承
4. SOLID
5. 好莱坞原则
6. DRY
7. KISS
8. 设计模式
9. 分层架构（洋葱架构、整洁架构）
10. 中台
11. ......

仔细想想，这些名字光鲜华丽的原则，哪个能逃脱的了上述四个维度？无一例外！

在当下的软件开发的上下文，所有的软件设计理念和原则，都是在满足需求的前提下，为了提高软件的可维护性，而可维护性就体现在：容易理解，容易修改，简单。

基于对良好软件本质的思考，Kent Beck提出了简单设计的四条原则：

1. 通过测试。广义上满足客户需求
2. 揭示意图。讲业务语言，软件模型跟业务模型一致。
3. 消除重复。消除重复代码（当然，还有很多其他导致难以修改的问题）。
4. 最少元素。不要增加没必要的元素。

没有华丽的辞藻，用词朴素，容易被人理解。这个框架，即便初学者也能立马用起来，他扮演了一个智者一直在对你提问，促进你去思考：

1. 你写的软件满足了需求了吗？（嘿，跑偏了，PO没说要实现这个功能...）
2. 你这个代码表达业务意图了吗？（嘿，这个东西在业务上不是这么叫的...）
3. 你的代码容易修改吗？有没有重复？（嘿，这段逻辑重复了，真讨厌...）
4. 这个元素对真的有用吗？（嘿，这个字段没用上，去掉也没有任何影响...）

初学者就可以从最基本的代码命名、重复代码、冗余方面去思考自己实现软件的过程，从很小的命名习惯（也是最重要的习惯之一）开始培养自己的编码Sense，避免花里胡哨的炫技，做一个接地气的简约开发者。

掌握了简单设计原则的标志是：你对四条原则的优先级的理解和冲突场景下的决策。这个在简单设计一文中有介绍。

简单设计只是一个开始，它代表不了软件设计的全部，它让初学者更容易的开始。要具备软件设计的敏锐的嗅觉，还需要日积月累对上文提到的设计理念（不限于上述几条）有深刻的理解。不然，即便掌握简单设计，甚至TDD和重构，也会很快到达瓶颈期。