本次阅读了4-6章内容。书抛出了这样一句话：你不可能写出完美的软件。短暂思考后发现确实如此，世上本来就没有完美的软件，在计算技术简短的历史中，没有一个人曾经写出过-个完美的软件。你也不大可能成为第一个。除非你把这作为事实接受下来，否则你最终会把时间和精力浪费在追逐不可能实现的梦想上。
这告诉了我一个道理——注重实效。我们知道编码的相似性相当明显。我们不断地与他人的代码接合可能不符合我们的高标准的代码-----并处理可能有效。也可能无效的输人。所以我们被教导说，要防卫性地编码如果有任何疑问， 我们就会验证给予我们的所有信息，我们使用断点检测坏数据.我们检查一致性，在数据库的列上施加约束，而且通常对自己感到相当满意。但注重实效的程序员会更进一步他们连自己也不信任。知道没有人能编写完美的代码，包括自己，所以注重实效的程序员针对自己的错误进行防卫性的编码。
同样重要的还有测试集。
即使是最好的测试集也不大可能找出所有的bug; 工作环境的潮湿、温暖的状况似乎能把它们从木制品中带出来。这就意味着，一且某个软件部署之后，你常常需要对其进行测试——在现实世界的数据正流过它的血脉时、与电路板或芯片不同，在软件中我们没有测试管脚。但我们可以提供模块的内部状态的各种视图，而又不使用调试器(在产品应用中这可能不方便，或是不可能)。含有跟踪消息的日志文件就是这样一种机制，日志消息的格式应该正规、一致。你也许想要自动解析它们，以推断程序所用的处理时间或逻辑路径、格式糟糕或不一致的诊断信息就像是一堆“呕吐物”——它们既难以阅读，也无法解析。了解运行中的代码的内部状况的另-种机制是“热键”序列按下特定的键组合。就会弹出一个诊断控制窗口。显示状态消息等信息，你通常不会想把这样的热键透露给最终用户，但这对于客户服务人员却非常方便。
你编写的所有软件都将进行测试一，如果不是由你和你们团队测试，那就要由最终用户测试，所以你最好计划好对其进行彻底的测试 一点预先的准备可以大大降低维护费用、减少客户服务电话。