阅读《代码整洁之道》
cuixiaorui opened this issue · 0 comments
代码整洁之道
函数
- 大师级别的程序员把系统当做故事来讲
- 写函数要注意抽象的层级
- 高级抽象层级 - 封装了中级的操作
- 中级 - 封装了低级的操作
- 低级 - 比较底层的操作
- 尽量保持函数的参数最多不超过2个
- 先写然后通过重构的手段来打磨代码
注释
- 尽量用函数和变量来表达 - 可读的代码
- 可以简单的描述下意图 - 如果在代码命名上不能表达的
- 不写废话注释
边界
- 使用第三方代码的时候建议包装一层 - 防腐层
- 影响范围最小
- 改动方便
- 可控制
- 编写学习型测试
- 编写测试来理解第三方代码·
- 不要在生产代码中试验新东西
- 学习难，整合第三方库也很难，所有不要同时处理
- 不会影响其他工作的途径
- 是一种精确试验，帮助我们对 api 的理解
- 当第三方更新时，我们只需要跑下测试就能知道 api 是否有变动
测试
TDD 三定律
- 在编写不能通过的单元测试前，不可编写生产代码
- 只可编写刚好无法通过的单元测试，不能编译也算不通过
- 只可编写刚好足以通过当前失败测试的生产代码
保持测试整洁
- 测试代码和生产代码一样重要
- 单元测试可以让你的代码可扩展、可维护、可复用
- 测试越脏，代码就会变得越脏，最终将会丢失测试，代码开始腐坏
整洁的测试
三要素
- 可读
- 可读
- 还是可读
三个环节
- 构造测试数据 （given）
- 操作测试数据（when）
- 检验操作是否得到期望的结果（then）
双重标准
测试坏境和生产坏境是可以有不同的标准的
单个测试中的断言数量应该最小化
遵循一个测试一个概念
FIRST
快速（Fast）：测试应该能快速运行
独立（Independent ：测试应该相互独立，不可以互相依赖
可重复（Repeatable）：测试应当可在任何坏境中重复通过
自足验证（Self-Validating）：测试应该有布尔值输出
及时（Timely）：测试应该及时编写（TDD）
总结
要想代码可复用、可读、可扩展 ，那么就需要测试
而怎么写好测试，让测试覆盖率高呢？ 用 TDD
先写测试后写实现会很容易的写出可测试的代码
所以 TDD 是值得每一个有追求的程序员去学习的
类
类的组织
-
static public variable
-
static pirivate variable
-
public variable
-
private variable
-
public method
-
被 public method 调用的私有函数
类应该短小
衡量方法：类的权责
原则
- 单一职责就是只有一条加以修改的理由
- 具体类实现细节，抽象类呈现概念
- 借助接口和抽象类来隔离这些细节带来的影响
- 通过降低连接度，我们的类就遵循了依赖倒置原则（依赖抽象带来的收益）
- 让代码能工作和让代码保持整洁是两种截然不同的工作！！！
系统
分离
将系统的构造与使用分开
初始化和运行时分开
方法
- 工厂
- 依赖注入
- 扩容
简单原则
无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案
测试驱动系统架构
没必要先做大设计
系统的架构应该是跟随着业务需求慢慢演化的
我们只需要保证架构在演进的过程中不会被破坏
如何保证不被破坏，只能是拥有足够的测试
延迟决策
延迟决策至最后一刻也是好手段
即拥有了大量信息
设计原则
DIP
依赖倒转原则
细节应当依赖于抽象，抽象不应当依赖于细节
SRP
单一职责原则
它规定一个类应该只有一个发生变化的原因
就是只有一条加以修改的理由
代码保持简单整洁的原则
需要遵循几个点就可以保持简单原则
-
测试 - 可以驱动出简单的设计，还可以消除重构代码会破坏代码的恐惧
-
不可重复 - 重复代码是拥有良好设计系统的大敌
-
表达力 - 良好的命名 类和函数越小越容易命名
-
类和方法应该竟可能的少（优先级最低，这是为了防止教条式。来制约 第三条原则的）
一句话
- 编程是一种技艺甚于科学的东西，要编写整洁代码，必须先写肮脏代码，然后再清理它（手艺人）
- 满足于仅仅让代码能工作的程序员不够专业
- 不要依赖直觉编程（我们应该要有测试来保证验证我们的逻辑）
- 让代码能工作和让代码保持整洁是两种截然不同的工作！！！