读书-代码整洁之道7-9章

异常处理

• 错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法。
• try代码就像是事务，catch代码块将程序维持在一种持续状态。在编写可能抛出异常的代码时，最好先写出try-catch-finally 语句。
• 可控异常的代价师违反开放/闭合原则。如果你在编写一套关键代码库，则可控异常有时也会有用，你必须捕获异常。但对于一般的应用开放，其依赖成本要高于收益。
• 定义异常时，最重要的考虑是如何捕获它们。
• 别返回null值，别传递null值。除非API要求传递null值，否则就要尽可能避免传递null值。

边界

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

单元测试

• TDD三定律
  • 第一定律：在编写不能通过的单元测试前，不能编写生产代码；
  • 第二定律：只可编写刚好无法通过的单元测试，不能编译也算不通过；
  • 第三定律：只可编写刚好足以通过当当前失败的测试的生产代码；
• 测试代码和生产代码一样重要，它可不是二等公民，它需要被思考、被设计和北照料。它该像生产代码一样保持整洁
• 整洁测试三要素：可读性、可读性和可读性。
• 测试还应遵守以下5条规则。
  1. 快速。测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。
  2. 独立。测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。
  3. 可重复。测试应该可以在任何环境中重复通过。
  4. 自足验证。测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认
  5. 及时。单元测试应该恰好在使其通过的生产代码之前编写。