第10章 类
尽管讨论了这么多关于代码语句及由代码语言形成的函数的表达力，<br>但是，<b>除非我们将注意力放到代码组织的更高层面，否则始终不能得到整洁的代码</b>
类的组织
代码应该符合自上向下的原则，让程序读起来像一篇报纸文章
封装：尽可能的保持函数或变量的隐私；放松封装是下策
类应该短小
关于类的第一条规则时类应该短小，第二条规则是还要更短小
类只应有一个权责
类的名称应当描述其权责，类名越含糊，该类越有坑拥有过多的权责
系统应该由许多短小的类而不是少量巨大的类组成
类应该只有少数实体变量
隔离依赖
需求会改变，所以代码也会改变
依赖具体细节的类，当细节改变时就会有风险，可以借助接口和抽象类来改立这些细节带来的影响
第11章 系统
复杂要人命，它消磨开发者的生命，让产品难以规划、构建和测试
扩容
我们不能一开始就在小镇里修建一条六车道的公路
合理的利用资源，而不是浪费
优化决策
延迟决策至最后一刻也是好手段，这不是懒惰或不负责，而是让我们能够基于最有可能的信息做出选择
系统也应该是整洁的，侵害性架构会湮灭领域逻辑，冲击敏捷能力
最好的方案：大概可开展工作的最简单方案
第14章 逐步改进
要编写整洁代码，必须先写肮脏代码，然后再清理它
混乱是逐渐产生的
毁掉程序的最好方法之一就是以改进为名大动其结构
重构有点儿像解魔方，需要经过许多小步骤，才能达到较大目标，每一步都是下一步的基础
优秀的软件设计，大都关乎分割————创建合适的空间放置不同种类的代码。对关注面的分割让代码更易于理解和维护
保持代码整洁的方法是相对容易：早晨在模块中制造出一堆混乱，下午就能轻易清理掉
更好的情况是：5分钟之前制造出混乱，马上就能很容易地清理掉
第15章 JUnit内幕
遵循童子军军规，每个人都有责任把模块改进得比发现它时更整洁
第17章 味道与启发
注释
不恰当的信息
废弃的注释
冗余注释
糟糕的注释
注释掉的代码
环境
需要多步才能实现的构建
需要多步才能做到的测试
一般性问题
一个源文件中存在多种语言
明显的行为未被实现
不正确的边界行为
忽略安全
重复
在错误的抽象层级上的代码
基类依赖派生类
信息过多
死代码
垂直分隔
前后不一致
混淆视听
人为耦合
特性依恋
选择算子参数
晦涩的意图
位置错误的权责
不恰当的静态方法
函数方法应该表达其行为
理解算法
把逻辑依赖改为物理依赖
使用多态代替 if/Else 或 Switch/Case
遵循行业标准
使用命名常量替代魔术数
准确
结构基于约定
封装条件
避免否定性条件
函数只做一件事
掩蔽时序耦合
别随意
封装边界条件
函数应该只在一个抽象层级上
在较高层级放置可配置数据
避免传递浏览
Java
通过使用通配符避免过长的导入清单
不要继承常量
名称
采用描述性名称
名称应于抽象层级相符合
尽可能使用标准命名法
无歧义的名称
为较大作用范围选用较长名称
避免编码
名称应该说明副作用
测试
测试不足
使用覆盖率工具
别略过小测试
被忽略的测试就是对不确定事物的疑问
测试边界条件
全面测试相近的缺陷
测试失败的模式有启发性
测试覆盖率的模式有启发性
测试应该快速
