软件设计有两种方式：一种是设计得极为简洁，没有看得到的缺陷；另一种是设计得极为复杂，有缺陷也看不出来。第一种方式的难度要大得多。

-- 《皇帝的旧衣》，CACM 1981 年 2 月 C.A.R. Hoare

引言

本文将介绍软件开发中的核心原则，这里与设计模式的七大原则不同。虽然众多的原则都早有耳闻，但是在开发过程中，却又常常忘记了这些原则，陷入开发的困境。本文再这里再将这些原则进行重新介绍一番，并带上自己的一些思考。

软件开发的核心原则

• 原则一：Don't Repeat Yourself

• 原则二：Keep it simple stupid

• 原则三：You Ain't Gonna Need It

• 原则四：Done is better than perfect

• 原则五：Choose the most suitable things

DRY 原则

Don't Repeat Yourself，简称 DRY 原则，即不要重复自身，这是软件开发的一个 基础原则 。很好理解，在软件开发中不要做重复性劳动。也就是经常说的“不要重复造轮子”。

任何一个知识点在系统内部都应当有一个 唯一、 明确、权威的表述。这个原则又被称为“真理的单点性（Single Point of Truth）” 或者 SPOT 原则 。

重复会导致前后矛盾、产生隐微问题的代码，原因是当你修改重复点时，往往只改变了一部分而并非全部。通常，这也说明我们在软件设计中的代码的组织没有想清楚。

对去重的思考

设计过程中：常量、表和元数据只应该声明和初始化一次，并导入其它地方。通过，可以通过 重构 去除重复代码，更改代码的组织而不更改核心算法。

如果遇到重复数据无法避免，可以思考如下问题：

• 函数封装：如果代码中含有重复数据是因为在两个不同的地方必须使用两个不同的表现形式，能否写个函数、工具或者代码生成程序，让其中一个由另一个生成，或两者都来来自同一个来源？

• 文档或其他形式：如果文档重复了代码中的知识点，能否从部分代码中生成部分文档，或者反之，或者两者都来自同一个更高级的表现形式？

• 头文件和接口：如果头文件和接口声明重复了实现代码中的知识点，是否可以找到一种方法，从代码中生成头文件和接口声明？

数据结构中也存在类似的 SPOT 原则：“ 无垃圾，无混淆 ”（No junk，no confusion）。

• “无垃圾”是说数据结构（模型）应该最小化，比如，不要让数据结构太通用，居然还能表示不可能存在的情况。

• “无混淆”是指在真实世界中绝对明确清晰的状态在模型中也应该同样明确清晰。

简言之，SPOT 原则就是提倡寻找一种数据结构，使得模型中的状态跟真实世界系统的状态能够一一对应。

KISS 原则

Keep it simple stupid，简称 KISS 原则。在做软件设计的工作中，很多时候都不要想得过于复杂， 也不要过度设计和过早优化 ，用最简单且行之有效的方案也就避免了复杂方案带来的各种额外成本。这样既有利与后续的维护，也有利于进一步的扩展。

思考：永远都不会知道用户会怎么操作，所以没有必要在软件开发中过度设计。

YAGNI 原则

You Ain't Gonna Need it：即 YAGNI 原则。只需要将应用程序必需的功能包含进来，而不要试图添加任何其他你认为可能需要的功能。因为在一个软件中，往往 80% 的请求都花费在 20% 的功能上。

思考：关注软件中的核心功能，功能越少，开发周期就会越短，才有更有立足于市场。

完成胜于完美

Done is better than perfect：在面对一个开发任务时，最佳的思路就是先把东西做出来，再去迭代优化。如果一开始就面面俱到，考虑各种细节，那么很容易钻牛角尖而延误项目进度。

这一点在工作中深有体会，每次拿到一个需求总是要能快速交付，给用户测试，能满足他们的需求比自己想到的完美更重要。

思考：“人无完人，金无足赤”，软件开发也是，先完成，再优化。

选择最合适的

Choose the most suitable things：这是在做方案选择、技术选型时候的一个很重要的原则。在面对许多技术方案、开源实现的时候，务必做到不能盲目求新，要选择最合适的而非被吹得天花乱坠的。

思考：技术层出不穷，日新月异，没有必要一味追求最前沿的技术，正确的事情就是针对特定的需求能够解决当前的问题。

链接: https://fly63.com/article/detial/11605