缺牙的时候,我们不停地试探;软件开发,也应如此

缺牙的时候,我们不停地试探;软件开发,也应如此小时候掉牙了的时候,总是用舌头去舔那个缺口,一直到牙齿完全长出来,似乎
想时刻确定它长到了什么程度。最有意思的是,家长告诉,不要去舔,会长歪
的;越是这样,我们越想确定,它歪了么?我在芬兰有一次坐长途大巴,那个司机的头顶大半秃了。之所以能让我有这么深
刻的印象,是因为那几个小时里,他一直轮换着用一只手去摸头顶。似乎这样能
长出来,或者确定没长出来?我们在构造物品,搭积木,或者盖房子的时候,无一不是如此。我们在每一个步
骤测试,确定产品(此处应作人工制品,但是这字太小资了)确实按我们计划开
发,这一个小部分,也符合我们的预期。中间没有任何测试过程,期待直接完成,是愚蠢的。治病的时候,医生也要不停地测试–抽血,验尿,然后才敢给你下药。我们的所
有行为,都依赖于对世界的观察。谈恋爱的人们,小心翼翼地试探–今天气你一次,明天考验你一下。揪玫瑰花瓣
这种行为,大抵只能用于测试智商,或者投入程度了。软件开发中,我们也需要在每个阶段,测试每个单元是否按我们预想的那样工作。
如果"是",那么我们继续。如果"不是",我们要做的不是继续突进,而是停下来
想想哪里出了毛病。这也是我们设计实验和写实验报告的不二法门。遗憾的是,计算机系的似乎有把实验报告写得很糟烂的传统?那么一页半的代码
和结果,你是打算让我相信,你从头开始敲代码,敲到最后,然后编译就通过了
么。那么,你一定不知道,代码不是从上向下写的。从上向下写,就像画蒙娜丽
莎的时候,把这杰作分成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多,所以,我们能想到,必然早就被牛人实现了。就像,剧毒之物五
步以内,必有解药。如果你嫌断肠草药性太烈呢,就自己去动手改进吧。

Leave a Reply