优质C程序秘诀---第 8 篇 - 剩下来的就是态度问题.doc

第8章 剩下来的就是态度问题 本书中讨论的方法可以用来检查错误和防止错误，但是这些技术并不能保证肯定可以写出无错代码，就象一个熟练的球队不可能是常胜军一样。重要的是养成好的习惯和正确的态度。 如果一个球队成天在嘴上讨论如何训练，这个球队可能有取胜的机会吗？如果这个球队的队员不断地因为工资低而牢骚满腹，或时刻耽心被换下场或裁减掉，那又会怎么样呢？虽然这些问题与球赛没有直接关系，但是却影响了球员水平的发挥。 同样读音可以使用本书的所有建议，但是，如果你持疑虑的态度或者使用错误的编码习惯，那么要写出无错的代码将是很困难的。因此，你要有必胜的信心和良好的习惯，同样，你同级的同事如果没有必胜信心和良好习惯也会遇到同样的问题。 因此在本章中将指出一些编写无错代码的主要障碍。只要能意识到这些障碍，改正就很容易了。 错误不出现，我还有一招 当向程序员询问有关他们修改错误的情况时，有多少次听到他们这样的回答：“唉呀！错误消失了。”多年以前，我就曾经向我的第一个经理说过这样的话，当时,我们正在研制Apple Ⅱ数据库产品，经理问我若已经设法找到错误项目能否就此收尾，我说：“唉呀！错误消失了。”经理停顿了片刻，然后邀请我到他的办公室坐坐。 “你说‘错误消失了’，是什么意思？” “哎呀！你知道，我一步步地仔细查看了错误报告。错误没再出现。” 经理在椅子上向后仰了一下问：“你认为错误到哪儿去了？” “我不知道。”我说，“我想它已被改正了吧。” “你并不知道谁改的，是吧？” “是的，我是不知道。”我坦诚地回答。 “好，那你不认为你应该查明到底真正发生了什么吗？”他说。“毕竟你是在和计算机打交道，错误不会自我改正。” 然后，经理进一步解释说，错误消失有三个原因：一是错误报告不对；二是错误已被别的程序员改正了；三是这个错误依然存在但没有表现出来。也就是说，作为一个专业程序员，其职责之一就是要确定错误的消失究竟属于以上三种情况中的哪一种，从而采取相应的行动，但是决不能因为错误不出现就简单地忽略了它，就万事大吉了。 在我第一次听到这个忠告的时候，也就是在CP/M和Apple Ⅱ的时代，这个忠告很有价值。实际上，在这之前的几十年里，它就很有价值，而且至今它仍然很有价值。但是，直到我自己成为项目负责人，并且发现程序员普遍乐于接受测试员搞错了或有某个程序员已经为其排除了这个错误，这时我才认识到这个忠告多么有意义。 错误消失经常是因为程序员和测试员使用了不同的程序版本。如果在程序员使用的代码中错误没有出现，就采用测试员使用的程序版本，如果错误仍未出现，就可通知测试组。但是，如果错误确实出现了，就要追踪到它早些的源程序版本，并决定如何修改它，然后再查看一下为什么在当前的源程序版本中，错误会不见了。通常错误仍然存在，只是环境有了更改从而掩盖了错误。无论什么原因，为了采取适宜的步骤来改正错误，必须弄明白为什么错误消失了。 浪费精力？ 当我要求程序员在老版本源程序上寻找所报告的错误时，他们经常要发牢骚，这样做似乎象是浪费时间。要是你也这么认为的话，你要明白这样做并不是要你恢复老版本源程序，而不过要你查看一下这些源程序，为你提供查错的良机，而且这也是找到错误最有效的方法。 即使你发现错误已被改正了，那些老版本源代码中将错误分离出来也是值得的。是将错误以“改正了”终结好呢？还是给错误标以“不会再产生了”并送还给测试组好呢？测试人员将怎样做呢？他们肯定不会认为这个错误已经更正了，他们只有两种选择，一种是花时间来试图提出另一组能再产生错误的用例；另一种是丢下这个错误，将其标以“不会再产生了”并希望错误已被改正。与在老版本源代码中找到了错误并以“改正了”而终结比较起来。后两种选择都不好。 及时纠正，事半功倍 我第一次参加Excel小组的时候，我们把所有的错误改正工作都推迟到项目的最后。这并不是说有人用枪顶着我们的脊骨说：“直到所有的特征都实现了再去改正错误”，但总有保持进度和实现特征的压力，而在修改错误方面却一点压力也没有。我曾经说过：“除非错误使系统瘫痪了或使测试组停工，否则别急着更改它，完成进度要求的各特征之后，我们有的是时间来修改错误。”简而言之，改正错误没放在优先地位。 我相信现在的Microsoft程序员听到上面所讲的肯定感到很逆耳，因为项目不再以这种方式研制了。这种方法存在的问题太多，最坏的是不能预言产品什么时候能够完成。你怎样估计修改1742个错误的时间？当然，不仅仅有1742个错误需要修改，因为在程序员修改旧错误时又会引起新错误。更密切相关的是，修改一个错误可能暴露其它的潜在错误，由于第一个错误的障碍，测试组未能发现这些潜在错误。 但这还不是唯一的问题。 由于没有改正错误就完成了所要求的特征，产品看上去比它实际进展情况要提前了许多。公司的重要人物测试使用内部发行版本，发