今天总结的是程序员修炼之道第五部分的内容：
Chap6 当你编码时
编码过程中应该遵循的原则。
靠巧合编程：不可靠。不要使模块可能依赖特定的输入数据、语境，否则模块的正常工作可能只是偶然。积极地查找可能的问题并修改。
为了避免这个问题，编码过程中要依靠可靠的、了解的东西，而不要碰巧拼凑一些代码，希望它能成功。比如如果不会使用某个第三方库，应该去学习而非随意堆积代码，试图得到希望得到的结果。为模块编写文档有利于发现隐藏的假设和巧合。
不要让自己成为过去的代码的奴隶，尤其是在开发阶段。对于模棱两可、可能出问题的代码，要积极地进行检查与重构。
算法速率：这里讲到了对算法运行时间进行O( )的估算，即数据结构课程中提到的时间复杂度。算法速率的估算可以通过常识估算。如果算法有多重循环，达到了O(n2)甚至O(n3)的时间复杂度，就要试着用分治法等方法将时间复杂度降低。不过算法速率的估算是理论的极端情况，实际的算法速率要通过测试来获取。可以使用code profiler这一工具获得算法中不同步骤的执行次数。
不过快的算法速率并不一定是好的。有时数据集很小，O(n)与O(ln n)级的算法差别很小，算法速率反而受常数影响更大。这时花过多的时间构想一个高效的算法是没有实际意义的，根据实用主义的原则不必这么做。当然如果随着系统的增加该算法成了效率瓶颈，进行优化就很有必要。
重构：重写、重做及重新架构代码。在出现这些情况时需要重构：代码有自重复、功能不正交、性能不够、内容过时。重构可能是痛苦的，但不要为了一时的痛苦放弃重构，因为有问题的代码可能带来更多问题。重构是将原本能够工作的代码进行修改，所以很可能是危险的。重构要遵循以下原则：不能加入新功能。保持有一系列良好的测试，这样出现任何问题时都可以快速发现。将重构拆分成许多个短小的重构，并在进行每个小改动之后进行测试，以发现可能的错误。
易于测试的代码：进行模块的组装前，对模块进行单元测试，检查其在各种情况下的行为非常重要。对于有依赖关系的模块，从最小的模块向上层层单元测试可以更容易定位错误。建议根据合约对代码进行测试，利用合约的前条件、后条件和不变量设置可以很容易确定测试内容。
编写代码的同时就应该编写代码的单元测试。
编写大型项目时，为了方便单元测试，应该使用测试装备以动态构建测试。比如可以编写一个类，负责测试的常用功能。测试装备有必要提供以下功能：用以指定设置测试条件与清理测试现场的方法，用以选择个别或全部测试的方法，分析输出是否是预期结果的方法，生成标准化错误输出的方法。测试应该是可组合的。
在编写代码的过程中，常会加入一些即兴调试，如printf语句。不要抛弃这些调试语句，将它们加入单元测试。编码过程中出现过问题的部分在运行中可能会再出问题。
代码部署好之后也不要忘记测试。要构建运行日志以方便记录运行状态，日志应该风格良好以方便解析。要构建可用于诊断运行状态的服务。
邪恶的向导：依靠开发环境提供的“向导”进行编码是依靠巧合而编程。可以使用封装良好的第三方库，但在不理解gui生成的“向导代码”时不要使用它，因为它会变成代码有机的一部分，并随时可能带来问题。