KISS原则：尽量保持简单
- Keep It Simple and Stupid.
- Keep It Short and Simple.
- Keep It Simple and Straightforward.
代码的可读性，可维护性是衡量代码质量非常重要的标准。
代码足够简单，就意味着容易读懂，bug比较难隐藏。
代码行数越少就越“简单”吗？
同一个功能，一段代码使用的复杂的技术，比如正则，代码量最少；一段代码使用简单的工具类代码量次之；一段代码自己实现逻辑代替工具类，代码量最多；
使用正则增加了代码的维护成本，同时写出没有bug的正则也不是一件容易的事。不是简单的代码
全部自己实现逻辑，可读性不高，不是简单的代码
使用简单的工具类，中等量的代码是简单的代码。
代码逻辑复杂就违背 KISS 原则吗？
对于复杂的问题，用复杂的方法解决，并不违背KISS原则。看是否符合KISS原则，是对具体问题而言。
如何写出满足 KISS 原则的代码？
- 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
- 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。
- 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。
在做开发的时候，一定不要过度设计，不要觉得简单的东西就没有技术含量。实际上，越是能用简单的方法解决复杂的问题，越能体现一个人的能力。
YAGNI原则，不要做过度设计
比如，我们的系统暂时只用 Redis 存储配置信息，以后可能会用到 ZooKeeper。根据 YAGNI 原则，在未用到 ZooKeeper 之前，我们没必要提前编写这部分代码。当然，这并不是说我们就不需要考虑代码的扩展性。我们还是要预留好扩展点，等到需要的时候，再去实现 ZooKeeper 存储配置信息这部分代码。
再比如，我们不要在项目中提前引入不需要依赖的开发包。对于 Java 程序员来说，我们经常使用 Maven 或者 Gradle 来管理依赖的类库（library）。我发现，有些同事为了避免开发中 library 包缺失而频繁地修改 Maven 或者 Gradle 配置文件，提前往项目里引入大量常用的 library 包。实际上，这样的做法也是违背 YAGNI 原则的。
从刚刚的分析我们可以看出，YAGNI 原则跟 KISS 原则并非一回事儿。KISS 原则讲的是“如何做”的问题（尽量保持简单），而 YAGNI 原则说的是“要不要做”的问题（当前不需要的就不要做）。