《程序员修炼之道：从小工到专家》读后感(第四篇)

第21节 按合约设计1、注重实效的程序员会不信任自己，所以他们针对自己的错误行为进行防卫性编码。2、按合约设计（Design By Contract，简写DBC）是 Bertrand Meyer 为 Eiffel 语言发展的概念。它的核心是用文档记载模块的权利与责任，并进行校验。它的目的是对函数做一些前置检查和后置保证，结合编译器的支持，我们能够尽早的发现代码问题。3、DBC 有三个概念。前条件：为了调用例程必须为真的条件。后条件：例程保证会做的事情，其完成时的状态。类不变项：其确保从调用者的视角来看，该条件总是为真。4、Java 中的 iContract 框架是专为 DBC 设计的，它通过注释里的 @pre、@post、@invariant 声明这三个概念。它会读取注释并生成包含断言逻辑的源文件。Eiffel 则是通过 require、ensure、is 三个值表示对应概念。但是支持 DBC 的语言真的很少。第22节：死程序不说谎1、对待程序我们通常会有“它不会发生”的心理状态，这会导致我们忽视一些问题。对于注重实效的程序员来说，如果我们忽略了一个错误，将是非常糟糕的事情。2、我们一些异常情况，我们应该及早崩溃，用于强调问题的存在。3、引起崩溃的时候不要造成破坏，比如申请的资源还没有释放等情况。4、死程序带来的额危害通常比有隐患的程序要小得多。第23节 断言式编程1、如果它不可能发生，用断言确保它不会发生。assert(string != NULL)断言里写的为真的条件，当不为真时触发断言，程序退出。2、断言检查的是决不应该发生的事情，而不是错误处理。3、断言应该一直开着，不要在线上环境关掉它。断言对应的是一种强提示，它迫使我们必须遵守。像是单元测试，我们通常都使用断言的形式进行检查。第24节 何时使用异常1、异常很少应作为程序的正常流程的一部分使用，异常应该保留给意外情况。如果移除了所有的异常处理器，代码就无法运行，那说明异常正在被用于非异常情况中。2、是否应该使用异常取决于实际情况。比如打开文件，文件不存在，是否应该发生异常？如果文件应该在那里，那么异常就有正当理由。如果不确定文件是否在那里，返回错误就可以了。第25节 怎样配平资源1、对于资源（内存、事务、现成、文件、定时器等）的管理要有始有终，你分配了对应的资源，就需要考虑对应的解除逻辑。要有始有终。2、嵌套的资源分配，应该使用与分配次序相反的顺序进行解除。3、异常的配平需要避免违反 DRY 原则。例如文件打开的异常情况，会导致 try..catch 有两条路径，那如何避免在正常流程和 catch 流程都处理 error 情况呢？C++ 可以依赖对象自动析构的特性，Java 可以依赖 finally子句。4、当无法配平资源时，需要设定一个规则，决定谁为某个聚集数据结构中的数据负责，以及如何负责。这里有点类似引用计数方案，无引用时释放。5、自动化检查资源配平状态，可以依赖一些三方工具。