按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
或是“编译器根本就不应该对语法正确的程序代码发出警
告”。如果您看到这些程序设计师对我的建议所表现出的
态度，您真会觉得我是在劝他们扔掉P C，回头去使用打
孔卡片的古董计算机来写程序呢。
这就是程序设计师面对错虫的态度问题了。以我个人
来说，因为我使用编译器的预警功能已经成为习惯，我并
不觉得警告讯息会困扰我，除非我不小心留了错虫在程序
里，编译器也不会用警告讯息来烦我，因为我写程序的习
200
微软研发
致胜策略下载
惯不会使用if （ch = readkeyboard（）） 这样的方式。对我来
说，只要能找到程序中的错误，程序风格上的修改是微不
足道的小事。在我看起来，那些拒绝使用预警功能的程序
设计师关心个人的表现远甚于程序的正确性，如果他们连
这一点小小的改变都不肯，又怎能期望他们做到重大的改
变呢？如果全部门或全公司从现在起规定新的命名原则，
或是固定的程序风格，怎能期望他们遵循呢？他们能不能
放弃自己喜欢、但容易出错的程序风格？他们会肯用除错
工具来一步步地追踪程序的执行步骤，以期及早发现错误
吗？
是的，撰写“零错误”程序的确需要下功夫，而程序
设计师大都不愿下这些功夫，除非程序设计师有正确的态
度：没有任何理由，有错虫就是不行。在我的项目中，我
会仔细追查错虫清单上的每一个错虫，看看这个错虫是不
是应该早在单元测试（unit test） 阶段就应该发现，或是在
用除错工具追踪时就该被找出来。如果是程序设计师粗心，
让这个早在开发时期就能发现的错虫留到整个系统建置完
毕时才被发现，我就会认为他的工作质量不及格，应该再
重新训练。
有些比较笨蛋的程序设计师会太早认为自己已经完成
201
微软研发·致胜策略
态度问题下载
工作，觉得编译能够过就表示没问题了，因为他们的基本
态度还没有认识到错虫是多么严重，程序无论如何就是不
能有错虫。他们会说：
我认为程序已经完成，因为编译都没有任
何错误，而且执行起来似乎蛮正确的。
笨蛋程序设计师会有这种态度，因为他们没有被各
种难缠的错虫搞得七荤八素过—溢出（overflow &
underflow） 错误、有号型别与无号型别（signed data type &
unsigned data type） 错误、一般性错误、运算子优先级的
错误、逻辑的错误以及特殊状况的错误。有太多种“地
雷”，笨蛋们还不懂得如何把它们嗅出来，也不懂得它的
可怕。
除错要趁早
我严格要求程序中绝对不允许有错虫：要程序设计师
在写程序的当时，就必须用除错工具一步步地追踪程序的
执行步骤、确实执行单位测试，因为如果让任何一个错虫
留到整体测试时才被发现，那不知道要花多少倍的时间才
能找到它并清除它。
202
微软研发
致胜策略下载
一旦错虫进了产品，不只是伤害产品的质量，还会赔
上大量的人力和时间。负责除错的程序设计师一时不能投
入开发工作，要追踪到错虫的藏身之处、加以修正、重新
测试（找错的话再重来） 。。测试结果正确之后，报告错
虫已经清除，再做一次整体测试，确定清除错虫的动作没
有伤害到其他正常的程序代码，然后再来一次回归测试
（regression test），回归测试是不能自动化的，必须由人工
执行并核对所有的功能，完全正确才算真正过关。清除错
虫是多么浩大的工程！
比较起来，在写程序的时候就确定没有任何一个小错
虫，已经是相当单纯的事了。如果程序设计师认真使用除
错工具、如果在严格的单元测试之后，才把程序置入系统，
我上面所说的浩大工程都可以避免。所以，怎么说都是愈
早除错愈划算。
凡是经验丰富、甚少出错的程序设计师都知道，那怕
赌注再高，他们也不敢赌自己的程序毫无错虫。和笨蛋不
同的是，他们绝对不会觉得自己的程序没有错虫了，即使
再熟练，他们还是要经过测试才相信程序的质量，他们会
认为：
203
微软研发·致胜策略
态度问题下载
除非我已经完全测试过，没有错虫了，否
则程序不能算完工。
有这种态度的程序设计师会不会测试过度？我从来没
见过这种事发生，因为是自己写的程序，一定知道什么样
的测试是不必要的。能当程序设计师的人，一定聪明到知
道什么样的行动是浪费时间，但常常没有聪明到知道什么
样的测试才够彻底。其实，不做重复的测试，这很容易，
反而是要保证测试工作毫无疏漏、每一种情况都测到，颇
为困难。
要让每一位程序设计师都明白，写出零错误程序
是很不容易的，所以应该多花功夫用各种方法做
最彻底的测试。
不愿下功夫
每当我审核产品设计和原始程序代码时，我总是自问：
“这个设计或程序出错的机率有多少？”我找出缺点，并
试着评估修改的代价有多大，一旦发现缺点，要么修正它，
204
微软研发
致胜策略下载
要么就是在程序中加入除错码（debug code） 来特别监视这
一部分的程序。
有一次我在审查一个利用一组庞大的数字矩阵来控制
的功能，其实用数字矩阵来执行这个功能是一个很好的主
意，但是我恐怕它容易出错，因为数字矩阵的内容可能根
本就是错的，这个程序恐怕经不起这种错误，所以我要求
程序设计师加入除错码来防止。程序设计师想也没想，脱
口而出道：“写除错码太浪费时间了。”
听到这句话的刹那间，我脑中警铃大响。。
因为这位程序设计师完全没有想到“写除错码的要求
是否合理”，也没有想到“这样做能否符合项目的目标及
工作的优先级”，而只想到要花太多时间，或者是他要付
出多少辛苦。
等这位程序设计师冷静下来后，我告诉他我反对他这
种态度，并解释我的理由，然后请他依次以下列问题来评
估我的要求：
◆ 在程序中加入除错码有没有道理？
◆ 如果有，增加除错码是否符合项目的目标与工作的
优先级？
205
微软研发·致胜策略
态度问题下载
◆ 最后，增加除错码的重要性是否值得花时间去做？
在我们依序讨论过这三个问题后，程序设计师同意加
入除错码，不过还是不太情愿。
3 0分钟后，他拿着加了除错码的程序到我办公室来，
给我看被除错码突显出来的三个潜在的错虫，其中两个很
明显是程序的错虫，只是没有除错码的话看不太出来，第
三个则令人一头雾水，我们两人都看不出来怎么会有这个
错虫。一开始我们猜测也许是除错码本身错了，使得除错
码产生的错误报告也不正确，但如果是这样，那前面两个
错虫就无法解释了，错误的除错码怎么能正确地找出错虫
来呢？我们研究了半天，终于发现原来是数字矩阵中的资
料有错，这个错虫实在太难找了！如果不是利用除错码，
我们几乎不可能找到它。
这位程序设计师学到了宝贵的一课：第一，即使您已
经觉得程序不可能有错，还是值得加上除错码，第二，对
于加上除错码这件事，永远不能认为“太花时间”或是
“太困难了”，这都是借口。
206
微软研发
致胜策略下载
纠正程序设计师以为加除错码会花太多时间的观
念，应该训练程序设计师第一个反应是考虑加上
除错码是否有道理，第二是考虑加除错码是否符
合项目的目标与工作的优先级。
凡事不能的态度
我和很多程序设计师、程序设计师的小组长、项目经
理共事过，他们甚少想出新点子或尝试新的开发策略，因
为他们的想像力在还没开始以前就先封闭了。您有没有看
过那种可怜虫，提出一个新点子但是遭到众人们的重炮攻
击：行不通、上级不会同意，甚至直叱道：“你不能这么
做！从来没有人这么做过！”
这就是“凡是不能的态度”—对于解决问题与创造
力是极大的伤害，我总是尽一切的可能消灭这种消极的态
度。我的部门里有一个不成文规矩，所有的人都不准说
“某件事不可能做到”，他们可以说很难或很花时间，但是
不准说“不能做到”，我的理由是：
207
微软研发·致胜策略
态度问题下载
当某人说“某件事不可能做到”时，他往
往是错的。
很久以前我就学会了不去管别人说什么“不可能做到”
之类的话，说这种话的人大都没仔细想过究竟可能不可能。
当然，您可以举出各种千奇百怪的“做不到”：明天中午
以前修正2704 个错虫。。之类。但是一般人说“做不到”
时，说的通常是正常的事情，千奇百怪的事情不会有人当
问题来问吧？
当您听到别人说“某件事不可能做到”时，请注意他
有没有仔细思考过您的问题，如果他有，考虑一下现在的
状况是否和他所想像的不同，因为世界在变，尤其是软件
产业的世界，也许去年做不到的事情现在只要动几下手就
行了─特别是在内存空间和速度方面，变化更是惊人。
几年前也许有人会认为图形界面行不通，因为太占内存，
会拖垮整个执行速度，在过去这话是对的，但现在早已完
全被推翻了。
有的时候会有政策上或管理上的规则是您“不可能”
打破的。微软的管理者一定会告诉您，不可能有人连续升
级或加薪超过最大限度，但是两项我都例外地做到了，当
208
微软研发
致胜策略下载
然非常不容易，我必须能够证明我的要求是为了公司的最
大利益；因为我的要求合理，所以公司的规则才能为我例
外。这并不是“不可能”，只不过“很困难”罢了。
我认为，人们之所以会说“某件事不可能做到”，只
是由于这件事超出了他们的经验范围。
在1 9 8 8年�