王争《设计模式之美》学习笔记
如何理解“KISS 原则”?
- KISS 原则的英文描述有好几个版本,比如:Keep It Simple and Stupid,翻译成中文就是:尽量保持简单。
- 代码的可读性和可维护性是衡量代码质量非常重要的两个标准。而KISS 原则就是保持代码可读和可维护的重要手段。
代码行数越少就越“简单”吗?
- 文中举例,检查输入的字符串是否是合法的IP地址。
- 第一种实现方式: 使用正则表达式。
- 代码行数最少,只有三行代码
- 但并不是最符合KISS原则的
- 因为使用正则表达式本身就比较复杂,bug率高
- 并不是每个程序员都精通正则表达式,会导致代码的可读性和可维护性变差
- 第二种实现方式: 使用现成的工具类,实现方式更加“简单”,更加符合 KISS 原则。
- 第三种实现方式: 不使用任何工具类
- 代码行数和第二种差不多
- 比第二种有难度,容易出bug
- 可读性差
- 完全是自己操作底层字符,没有多余函数调用和不必要的处理逻辑,性能更高些
- 但除非第二种方法调用的工具类成为性能瓶颈代码,第三种实际上是一种过度优化,牺牲了代码的可读性和实现难度,投入产出比不高
代码逻辑复杂就违背 KISS 原则吗?
- 文中举例,KMP 字符串匹配算法,是一个查找字符串匹配的算法,具体什么法没看懂
- KMP 算法本身具有逻辑复杂、实现难度大、可读性差的特点。本身就复杂的问题,用复杂的方法解决,并不违背 KISS 原则。
- 不过,平时的项目开发中涉及的字符串匹配问题,大部分都是针对比较小的文本,直接调用编程语言提供的现成的字符串匹配函数就足够了,如果非得用复杂的KMP算法,那真的违背KISS原则了
如何写出满足 KISS 原则的代码?
- 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式,还有一些编程语言中过于高级的语法等。
- 不要重复造轮子,要善于使用已经有的工具类库。经验证明,自己去实现这些类库,出 bug 的概率会更高,维护的成本也比较高。
- 不要过度优化。不要过度使用一些奇技淫巧(比如,位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等)来优化代码,牺牲代码的可读性。
- 评判代码是否简单,还有一个很有效的间接方法,那就是 code review。
- 一定不要过度设计,不要觉得简单的东西就没有技术含量。
YAGNI 跟 KISS 说的是一回事吗?
- YAGNI 原则的英文全称是:You Ain’t Gonna Need It。直译就是:你不会需要它。
- 这条原则的核心思想就是:不要做过度设计。
- 比如,我们的系统暂时只用 Redis 存储配置信息,以后可能会用到 ZooKeeper。根据 YAGNI 原则,在未用到 ZooKeeper 之前,我们没必要提前编写这部分代码。当然,这并不是说我们就不需要考虑代码的扩展性。
- 再比如,我们不要在项目中提前引入不需要依赖的开发包。
- KISS 原则讲的是“如何做”的问题(尽量保持简单),而 YAGNI 原则说的是“要不要做”的问题(当前不需要的就不要做)。