系统
- 将系统的构造与使用分开，如依赖注入(DI)、控制反转(IoC)
- 保证系统良好的的扩容性，使用面向切面编程(AOP)方式编程
对于系统这章不能透彻理解，平时对于架构没有深入理解，系统应该是随着业务的变化而变化，没必要先做大设计而限制后续设计思路，保证大概可工作的最简单方案即最合适。
迭进
- 运行所有测试，可以导向类保持短小且单一
- 不可重复，尽量抽象如使用模板方法
- 表达程序员的意图，使用标准的命名法、斟酌好的名称
- 尽可能减少类和方法的数量，按照实际平衡忌教条
实践中很少能一蹴而就，在不断地迭代中改进是最好的方式，时常关注代码质量。
味道和启发
- 注释
- 不恰当的信息删除掉，只放描述有关代码和设计的技术性信息
- 废弃的注释尽快更新或删除
- 注释应提及代码自身未提及的信息
- 保持注释简洁
- 及时删除注释掉的代码
- 函数
- 避免过多参数，没有最佳，一个次之，尽量避免三个以上参数
- 避免输出参数
- 避免使用boolean型参数，使用多个函数优于想单个函数传递参数选择函数行为
- 删除未调用的函数
- 一般性问题
- 减少文件中额外语言的数量和范围
- 遵循“最小惊异原则”，命名和行为一致
- 了解边界，别依赖直觉
- 重视安全
- 消除重复
- 创建分离较高层级一般性概念和较低层级细节性的抽象模型
- 较高层级基类概念不依赖于较低层级派生类概念
- 保持接口紧凑，隐藏实现，减少耦合
- 及时检查删除死代码
- 垂直分隔
- 命名前后一致
- 保持文件整洁，良好的组织
- 代码尽可能的具有表达力
- 倾向使用非静态函数，如果使用确保没机会打算其有多态行为
- 使用解释性变量
- 函数名称应清晰表达其行为
- 将逻辑依赖改为物理依赖
- 用多态替代if/else和switch/case
- 用命名常量替代魔法数
- 结构甚于约定
- 分装条件
- 避免否定性条件
- 函数只做一件事
- 掩盖时序耦合
- 封装边界条件
- 函数应该只在一个抽象层级上
- 在较高层放置可配置资源
- 避免传递浏览
在实践过程中应该时刻注意这些问题，避免代码腐烂蔓延。让代码时刻保持清晰的意图，避免猜测。