设计模式之美 - 20
怎么理解 KISS 原则中“简单”两个字？什么样的代码才算“简单”？怎样的代码才算“复杂”？如何才能写出“简单”的代码？YAGNI 原则跟 KISS 原则说的是一回事吗？只要两段代码长得一样，那就是违反 DRY 原则了吗？
一、KISS 原则 Keep It Short and Simple 翻译成中文就是：尽量保持简单
不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。
二、YAGNI 原则 You Ain’t Gonna Need It 翻譯過來的意思就是：不要去设计当前用不到的功能；
这条原则的核心思想就是：不要做过度设计
三、DRY原则 Don’t Repeat Yourself。翻譯過來的意思就是：不要寫重複的代碼。
1、实现逻辑重复
在判断是否要合并相同的实现逻辑，需要同时考虑到 “单一职责原则” 和 “接口隔离原则”
例如：目前isValidUserName() 和 isValidPassword() 两个方法，如果判断逻辑完全相同，那么我可以为isValidUserNameOrPassword()方法吗？单从名字上看，我们就能发现，合并之后的 isValidUserNameOrPassword() 函数，负责两件事情：验证用户名和验证密码，违反了“单一职责原则”和“接口隔离原则”。如果之后还修改密码的判断逻辑，那么这个方法修改起来就会不变得负责、
2、功能语义重复
不要存在功能相同的两种方法。日后会不知道用哪个，迭代功能，也需要改多个。
3、代码执行重复
减少相同的IO操作。
四、代码的可复用性方法：
减少代码耦合满足单一职责原则模块化业务与非业务逻辑分离通用代码下沉：从分层的角度来看，越底层的代码越通用、会被越多的模块调用，越应该设计得足够可复用。继承、多态、抽象、封装应用模板等设计模式
