Clean Code 阅读笔记(2)

系统:

  • 将系统的构造与使用分开,如依赖注入(DI)、控制反转(IoC)
  • 保证系统良好的的扩容性,使用面向切面编程(AOP)方式编程

对于系统这章不能透彻理解,平时对于架构没有深入理解,系统应该是随着业务的变化而变化,没必要先做大设计而限制后续设计思路,保证大概可工作的最简单方案即最合适。

迭进

  • 运行所有测试,可以导向类保持短小且单一
  • 不可重复,尽量抽象如使用模板方法
  • 表达程序员的意图,使用标准的命名法、斟酌好的名称
  • 尽可能减少类和方法的数量,按照实际平衡忌教条

实践中很少能一蹴而就,在不断地迭代中改进是最好的方式,时常关注代码质量。

味道和启发

  • 注释
    • 不恰当的信息删除掉,只放描述有关代码和设计的技术性信息
    • 废弃的注释尽快更新或删除
    • 注释应提及代码自身未提及的信息
    • 保持注释简洁
    • 及时删除注释掉的代码
  • 函数
    • 避免过多参数,没有最佳,一个次之,尽量避免三个以上参数
    • 避免输出参数
    • 避免使用boolean型参数,使用多个函数优于想单个函数传递参数选择函数行为
    • 删除未调用的函数
  • 一般性问题
    • 减少文件中额外语言的数量和范围
    • 遵循“最小惊异原则”,命名和行为一致
    • 了解边界,别依赖直觉
    • 重视安全
    • 消除重复
    • 创建分离较高层级一般性概念和较低层级细节性的抽象模型
    • 较高层级基类概念不依赖于较低层级派生类概念
    • 保持接口紧凑,隐藏实现,减少耦合
    • 及时检查删除死代码
    • 垂直分隔
    • 命名前后一致
    • 保持文件整洁,良好的组织
    • 代码尽可能的具有表达力
    • 倾向使用非静态函数,如果使用确保没机会打算其有多态行为
    • 使用解释性变量
    • 函数名称应清晰表达其行为
    • 将逻辑依赖改为物理依赖
    • 用多态替代if/else和switch/case
    • 用命名常量替代魔法数
    • 结构甚于约定
    • 分装条件
    • 避免否定性条件
    • 函数只做一件事
    • 掩盖时序耦合
    • 封装边界条件
    • 函数应该只在一个抽象层级上
    • 在较高层放置可配置资源
    • 避免传递浏览

在实践过程中应该时刻注意这些问题,避免代码腐烂蔓延。让代码时刻保持清晰的意图,避免猜测。