代码整洁（4）：边界、单元测试、类

《代码整洁之道》Clean Code A Handbook of Agile Software Craftsmanship 读书笔记

边界

• 边界上的代码需要清晰的分割和定义了期望的测试。应该避免我们的代码过多地了解第三方代码中的特定信息。依靠你能控制的东西，好过依靠你控制不了的东西，免得日后受它控制。

单元测试

• TDD三定律
  • 1）在编写不能通过的单元测试前，不可编写生成代码
  • 2）只可编写刚好无法通过的单元测试，不能编译也算不通过
  • 3）只可编写刚好通过当前失败测试的生产代码
• 保持测试整洁
  • 测试代码和生产代码一样重要。它可不是二等公民。它需要被思考、被设计和被照料，它该像生产代码一般保持整洁。
  • 没有了测试，你就会失去保证生产代码可扩展的一切要素。（现在除了真正的大项目很少做单元测试了，需求都加班搞，没有时间编写代码量不低的测试代码。特别是一些不懂技术的项目经理，只要看到功能就OK，才不管你是怎么实现的）
• 整洁的测试
  • 在单元测试中，可读性甚至比在生产代码中还重要。测试如何才能做到可读？和其他代码中一样：明确，简介，还有足够的表达力。在测试中，你要以尽可能少的文字表达大量内容。
• 面向特定领域的测试语言
• 双重标准
  • 测试代码应当简单、精悍、足具表达力，但它该和生产代码一般有效。毕竟它是在测试环境而非生产环境中运行，这两种环境有着截然不同的需求。
• 每个测试一个断言
  • （很是头大的要求...）
• F.I.R.S.T.
  • 快速（Fast） 测试应该够快。
  • 独立（Independent） 测试应该相互独立。某个测试不应为下一个测试设定条件。
  • 可重复（Repeatable） 测试应当可在任何环境中重复通过。
  • 自足验证（Self-Validating） 测试应该有布尔值输出。无论是通过或失败，你不应该查看日志文件来确认测试是否通过。
  • 及时（Timely） 测试应及时编写。单元测试应该恰好在使其通过的生产

类

• 类的组织
  • 遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。
  • 公共函数应跟在变量列表之后。我们喜欢把由某个公共函数调用的私有工具函数紧随在该公共函数后面。这符合了自顶向下原则，让程序读起来就像一片报纸文章。
• 类应该短小
  • 关于类的第一条规则是类应该短小。第二条规则是还要更短小。
  • 类的名称应当描述其权责。实际上，命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类越有可能拥有过多权责。
• 单一权责原则
  • 类或模块应有且只有一条加以修改的理由。该原则既给出了权责的定义，又是关于类的长度的指导方针。类应有一个权责——只有一条修改的理由。
  • 系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
• 内聚
  • 类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。
• 保持内聚性就会得到许多短小的类
  • 当类丧失了内聚性，就拆分它！
• 为了修改而组织
  • 对于多数系统，修改将一直持续。每处修改都让我们冒着系统其他部分不能如期望般工作的风险。在整洁的系统中，我们对类加以组织，以降低修改的风险。