- 怎么理解 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操作。
四、代码的可复用性方法:
- 减少代码耦合
- 满足单一职责原则
- 模块化
- 业务与非业务逻辑分离
- 通用代码下沉:从分层的角度来看,越底层的代码越通用、会被越多的模块调用,越应该设计得足够可复用。
- 继承、多态、抽象、封装
- 应用模板等设计模式