程序员修炼之道---从小工到专家（第6章）

当你编码时

31, 靠巧合编程

怎样靠巧合编程：

一开始就不知道它为什么能工作。

实现的偶然：

因为代码现在的编写方式才得以发生的事情。最后会依靠没有记入文档的错误或是边界条件。

理由：

它也许不是真的能工作--它也许只是看起来能工作。
你依靠的边界条件也许只是一个偶然。
没有记入文档的行为可能会随着库的下一次发布而变化。
多余的和不必要的调用会使你的代码变慢。
多余的调用还会增加引入它们自己的新bug的风险。
结论？

对于你编写给别人调用的代码，良好的模块化以及把实现隐藏再撰写了良好文档的小接口之后，这样一些基本原则都能对你有帮助。
对于你调用的例程，要只依靠记入了文档的行为。如果出于任何原因你无法做到这一点，那就充分地把你的各种假定记入文档。
语境的偶然：

只是你现在为GUI环境编写代码，该模块就必须依靠给你的GUI吗？你是否依靠说英语的用户？有文化的用户？你还依靠别的什么没有保证的东西？

隐含的假定：

巧合可以在所有层面让人误入歧途--从生产需求知道测试。特别是测试，充满了虚假的因果关系和巧合的输出。不要假定，要证明。

Don't Program by Coincidence

怎么深思熟虑地编程

总是意识到你在做什么。
不要盲目地编程。
按照计划行事
依靠可靠的事物，不要依靠巧合或假定。
为你的假定建立文档。
不要只是测试你的代码，还要测试你的假定。断言
为你的工作划分优先级。把时间花在重要的方面，很可能也是最难的地方。如果基础设施不正确，再好的口哨都没用。
不要做历史的奴隶。准备好进行重构。
所以下次有什么东西看起来能工作，而你却不知道为什么，要确认它不是巧合。

32, 算法速率

我们说估算算法是什么意思？

只要我们编写的是含有循环或递归调用的程序，我们就会下意识地检查运行时间和内存需求。
O()表示法：

1：常量型，访问数组元素，简单语句

lg(n): 对数型，二分查找

n：线性型，顺序查找
nlg(n)：比线性差，但不会差很多（快速排序，堆排序）
n的平方，平方律型（选择和插入排序）
n的立方，立方型，2n×n 矩阵相乘。

Cn，指数型，旅行商问题，集合划分。
常识估算：

简单循环，从1循环到n，很可能是O(n)
嵌套循环，O(m*n) -> O(n的平方）

二分法，O(ln(n))
分而治之，O(nln(n))

组合，常常用启发式方法来优化。
实践中的算法速率：

时间和空间的权衡。

估算你的算法的阶，只需要几个点就可以确定。
测试你的估算。
最好的并非总是最好的：

最快的算法未必是最合适的。有时候追求简单，快速。

33,重构

重写，重做和重新架构代码合并起来，成为重构，refactor

你应在何时进行重构：

不要对改动犹豫不决

重复，非正交的设计，过时的知识，性能。
现实世界的复杂情况：

重构就像是切除肿瘤，需要停止花时间修复。否则。。。

早重构，常重构。

如果不能立刻重构，将其加入计划。

怎样进行重构：

重构就是重新设计，新的事实、新的理解、新的需求等。
重构要慎重、深思熟虑、小心进行的活动。
1, 不要试图在重构的同时增加新的功能。

2, 在开始重构之前，确保你拥有良好的测试。尽可能经常运行这些测试。这样，如果你改坏了，你也会知道。

3, 采取短小、深思熟虑的步骤。在每个步骤后测试。

修改了代码，也要修改依赖代码的地方。最好一劳永逸地修正它，不要容忍破窗户。

34, 易于测试的代码

单元测试：

软件的单元测试是对模块进行演练的代码，建立某种人工环境，然后调用被测试的模块中的例程。然后不同的测试值，对返回值进行检查。

针对合约进行测试：

代码是否符合合约，以及合约的含义是否与我们所认为的一样。边界，前后条件等。

这种风格的测试要求你首先测试模块的自组件。这样容易得知哪里出了错误。

为测试而设计。

早发现问题比解决问题更好。

编写单元测试：

将它们放在方便的地方。
这个给开发者带来无价的资源：

1, 一些例子，说明怎样使用你的模块的所有功能。

2, 用于构建回归测试、以验证未来对代码的任何改动是否正确的一种手段。

可以用#ifdef在编译的时候跳过单元测试的代码。

也可以借助shell脚本。

使用测试设备：

可以是GUI驱动，也可以是makefile与perl脚本组合
测试装备都应该有以下功能：
用以指定设置与清理的标准途径。
用以选择个别或所有可用测试的方法。
分析输出是否是预期结果的手段。
标准化的故障报告形式。
可以通过子组件来构成一个系统，达到任意深度。
即兴测试，临时测试，print，或者交互。可能需要将它正式化。
构建测试窗口：
含有跟踪消息的日志文件就是一种机制，格式要正规一致。
使用不为普通用户所知的热键，来打开诊断调试窗口。
更大的程序，可以使用web服务器。
测试文化：
测试是技术，更是文化。
测试你的软件，否则你的用户就得测试。
35，邪恶的向导
谨慎使用wizard，向导为你写好的代码你可能不清楚。如果你不清楚，可能就是在靠巧合编程。
不要使用你不理解的向导代码。