小时候掉牙了的时候，总是用舌头去舔那个缺口，一直到牙齿完全长出来，似乎
想时刻确定它长到了什么程度。最有意思的是，家长告诉，不要去舔，会长歪
的；越是这样，我们越想确定，它歪了么？
我在芬兰有一次坐长途大巴，那个司机的头顶大半秃了。之所以能让我有这么深
刻的印象，是因为那几个小时里，他一直轮换着用一只手去摸头顶。似乎这样能
长出来，或者确定没长出来？
我们在构造物品，搭积木，或者盖房子的时候，无一不是如此。我们在每一个步
骤测试，确定产品（此处应作人工制品，但是这字太小资了）确实按我们计划开
发，这一个小部分，也符合我们的预期。
中间没有任何测试过程，期待直接完成，是愚蠢的。
治病的时候，医生也要不停地测试--抽血，验尿，然后才敢给你下药。我们的所
有行为，都依赖于对世界的观察。
谈恋爱的人们，小心翼翼地试探--今天气你一次，明天考验你一下。揪玫瑰花瓣
这种行为，大抵只能用于测试智商，或者投入程度了。
软件开发中，我们也需要在每个阶段，测试每个单元是否按我们预想的那样工作。
如果"是"，那么我们继续。如果"不是"，我们要做的不是继续突进，而是停下来
想想哪里出了毛病。这也是我们设计实验和写实验报告的不二法门。
遗憾的是，计算机系的似乎有把实验报告写得很糟烂的传统？那么一页半的代码
和结果，你是打算让我相信，你从头开始敲代码，敲到最后，然后编译就通过了
么。那么，你一定不知道，代码不是从上向下写的。从上向下写，就像画蒙娜丽
莎的时候，把这杰作分成1024行，然后一行一行从下向下扫描。写代码，也是先
写眼睛，再写耳朵，可能再改下眼睛...这样的顺序。即使很短的代码也是这样。
所以，在不断的修改中，我们需要始终保证我们的代码还是按我们预想的方式工
作的。这就需要测试。
说到这里，我总会回想起小时候做航模，没有耐心等到胶完全固化就想去测试机
翼和机身连接的强度。好在，软件从写出来到测试，快得多。
前两天写了500来行java，有如下体会，与测试和观察软件的行为有关。
在软件从第一行开始成长的过程中，我这样确定它，此刻，仍然符合我所想的。
1. log - 我要知道一切，用户能看到的，用户看不到的，你所想的。
这次我没有用log4j。上次用了，这次最初以为这样部署起来容易一些，现在后
悔了。最初在软件的规模就应该有个估计，这种规模对于我来说，就应该有log
了。
log4j与System.out.println()相比，一个明显的好处是，在发布的时候，只要把
输出信息的级别在配置文件中修改一下，就可以阻止所有的调试信息输出。而
System.out.println()一行行注释起来，就容易落了这个丢了那个。
即使你有那个精力，用在看碟打游戏上岂不是更好。自动化那些非创造性的工
作，始终都我们追求的一个目标。
log非常重要的另一个原因，我和典同学一样，很少使用dbg这类东西，也不用
IDE的messages，而是喜欢自己输出到控制台之类的。log4j的输出可以与正常的
用户会看到的输出分开。
2. 测试 - 不停地考验
就像搭积木一样，我们总是要在可能不稳固的地方设置一两个测试点，输出一些
东西，让我们确认，到这一层，还是稳妥的。
不要"相信"代码是正确的。如果它是正确的，那么，运行一下证实，这花不了多
少时间；如果它不正确，你需要第一时间知道真相。在错误的基础之上继续写，
接下来付出的代价，除了失败的经验以外，没有任何收益。Tom Hagen说："我的
代理人希望第一时间知道坏消息。"
放心地一遍遍测试吧，你的代码不会因此而认为你不相信它的--只有上帝（和女
人？）才有这个规定。
每当修改一小段代码，就应该测试一下。根据回归测试的原则，任何一处修改，
都可能让原来正确的东西变成错误的。所以，每个修改都应该测试。
仍然是那个原则，不要"相信"代码是正确的。下面这个例子，就是我犯的错误。
当时我想，这么简单的修改，就不必测了。直到十多分钟以后，发现这家伙的行
为不正常。可是这个醉汉已经又走出好远了。
错误的代码：
: while (i.hasNext())
: {
: String current = i.next();
: if(i.next()==null || value==null)
: {
: return false;
: }
: else if(eval(i.next()).equals(eval(value)) )
: {
: return true;
: }
: }
正确的代码：
: while (i.hasNext())
: {
: String current = i.next();
: if(current==null || value==null)
: {
: return false;
: }
: else if(eval(current).equals(eval(value)) )
: {
: return true;
: }
: }
如果我当时做了回归测试，就可以马上发现错误的代码中副作用-- i.next()不
仅取出了值，也移动了"指针"。这样的错误在C/C++中也常发生。
3. 一个小技巧
如果我们在回归测试中，不断地观察程序的输出，就需要集中注意力找"不同"。
如果输出是一大摊的话，那就更是麻烦，可能还要翻页才行。
这也可以自动化。
我们可以先把正确的输出写下来，文件名叫 expect.txt 吧。
然后我们把每次的输入写下来，文件名叫 input.txt 吧。
如果你有多组输入，多整几个文件。
然后我们这样运行我们的程序：
proc.exe < input.txt > output.txt
如果你有多组输入，就做个批处理，这样：
proc.exe < input1.txt > output.txt
proc.exe < input2.txt > output.txt
proc.exe < input3.txt > output.txt
现在，可以看看程序是否按我们期待的运行了，基本不需要眼睛：
diff output.txt expect.txt
如果啥输出也没有，那就是它俩完全相同。
这与自然科学研究的技术路线差不多。
先做实验，或者观察世界，得到expect.txt；
然后假说，得到proc.exe；
最后看看proc.exe运行的结果output.txt与实验结果expect.txt是否一样。
如果结果好，那么写论文；如果结果不好，有些人会假装没看到，或者...反正
修改实验结果是不行的，因为还有别人也会做实验。
4. 更好的东西
上述小技巧可以写成一个批处理，改会代码，编译，然后就跑一遍这个批处理。
最初每次期望与结果都是不一样的，也就是还不成。再改再改，后来，diff不出
声了。
大功告成。
这个批处理的路子早就被俺们这个学科的古人发现了，并且写成了工具，叫做
JUnit。
还有其他语言的版本 cppUnit 啥的。
牛人总是N多，所以，我们能想到，必然早就被牛人实现了。就像，剧毒之物五
步以内，必有解药。如果你嫌断肠草药性太烈呢，就自己去动手改进吧。
No comments:
Post a Comment