按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
得创造学习的压力和气氛，不论是由您亲自教授，还是让
组员去上课、读书或参加研讨会，都是非常好的学习方式。
193
微软研发·致胜策略
学无止境下载
只要学习是持续的，让组员保持不断的进步，您就会逐渐
提升公司内“一般程序设计师”的技术水准，就像冬季奥
运会的花样滑冰选手一样，不断挑战极限、突破极限。这
样的话，不管是对您的组员、项目或是公司，都是极大的
好处，最后，您的顾客也是赢家之一。
重点提示
绝对不要让组员一直做同样的工作，这样
是限制了他的学习，使他停滞在原来的领
域。一旦程序设计师精通了某一个领域，
就让他换别的领域做做看，永远让他们学
习新的技术。
各种技术的用途范围有所不同，有的技术
在一般的项目都用得上，有的技术只有在
特定性质的项目才用得上。当您训练您的
组员时，必须让他们的技术能在公司发挥
最大的用处，最好的办法就是，把应用范
围最广的技术放在训练的最前期，应用范
围最小的技术放在最后训练。
194
微软研发
致胜策略下载
优秀的程序设计师是项目经理最需要的，
所以经理们通常舍不得让自己手下功力最
强的人到别组去，但是如果这位第一高手
在本组内再也没有新东西可学时，经理就
应该让他到别的项目去，一方面他个人可
以重新开始另一次的成长，一方面让接替
他的人学着承担重要的工作，最后公司的
平均程序技术水准因而提升，对大家都很
有好处。
为了确保每位程序设计师的技术都在稳定
地进步，一定要让每个人有个努力的目标，
最好的方法是把个人的成长和项目每两个
月的阶段性目标相结合，这样一年就有至
少六次的进步了。假定一位组员在公司待
了五年，那么他就学了3 0种新技术、或是
读了3 0本好书、或是1 5项技术加1 5本书，
对他的工作能力影响多大啊。
最好的成长目标是出于当时的需要。如果
您发现有位组员工作缺乏效率，或总是在
195
微软研发·致胜策略
学无止境下载
犯同样的错误，最好抓住机会立即为他立
一个目标，并且要求他立刻开始改进。这
种当时设立的目标让人印象深刻，又是马
上寻求改善，效果通常会非常好。比起年
终考评那种模模糊糊的建议，更能引起程
序设计师的重视。
196
微软研发
致胜策略下载
下载
第7 章
态度问题
7
Chapter Seven
在第6章中，我主要在强调学习的重要性，组员的
技术和知识应该精益求精。让组员接触他没做过
的新工作会促使他学习，鼓励他多看书、养成良好的程序
习惯会有更好的结果，但是还有一种最深度的改善，发自
程序设计师内心的，就是开发软件产品的良好态度。
错误的态度
我在第1章中提到过一个基本概念，就是专业的程序
设计师应该在合理的时间内，开发出有价值，而且零错误
（bug…free） 的程序代码。但是很不幸的是，要写“零错误”
的程序实在很难，否则每个人都能写程序了，何必要专
业。
在软件业有一个公认的观念，就是错虫是无法避免的，
而且除了发现错误时把它清除之外，没有什么好的对策。
虽然这个观念如此普遍，却是大错特错。零错误程序是可
以达到的目标，只不过需要额外的努力，而通常程序设计
师不愿意为这个理想付出，除非他们真正了解“零错误”
对软件产品开发的重要性。
有一个非常简单的方法，我经常用，就是在编译程序
时，选择预警功能（warning option），也就是让编译器来帮
198
微软研发
致胜策略下载
您找到比较明显的错误，编译器会警告您这里可能有错虫，
并且把原始程序代码列出给您参考。例如很多C 语言的
编译器都抓得到这种错虫：
if （ ch = tab_char ） /* 注意这是单等号，应该是
才是比较的意思*/
虽然这一句指令是完全符合C 的语法，但却隐含了
一个错误，程序设计师的本意是比较这两者，结果却变成
把ch 的内容设定为tab_char 的值。正确的写法应该是：
if （ ch tab_char ） /* 注意现在已改成双等号*/
让编译器来替您做初步的纠错，显然是很方便的做
法，但是我就看过很多程序设计师拒绝使用这个功能，
他们觉得这些警告的信息看起来很恼人，会干扰自己的
思路，因为有时候就是要在if 条件式中放单等号，编译
器也会不分青红皂白地当作警告列出来。例如这样的i f
条件式：
if （ ch = readkeyboard（） ）
｛。。｝
这段程序代码有两个作用，一是执行r e a d k e y b o a r d （ ），
把传回值留给ch 变量，一是若传回null 字符，则if 条件
不成立。它是正确的，但编译器却会给程序设计师警告，
199
微软研发·致胜策略
态度问题下载
看起来有点烦人，于是就得改成这样：
ch = readkeyboard（）；
if （ ch ！= nul_char ） 。。
或是更简洁的：
if （ （ ch = readkeyboard（） ） ！= nul_char ） 。。
这两种方式都会编译出一样大小的可执行码，差别只
是在明显表示ch 与nul_char 的比较关系，或是隐含表示
二者的比较关系。对于大部分的程序设计师而言，这几种
写法都一样容易理解，而如果要快速浏览程序的话，又以
第三种（只有一行） 最快。
话虽如此，就是有顽固派的程序设计师不肯使用编译
器的预警功能，而认为“我要怎么写程序，是我的自由”
或是“编译器根本就不应该对语法正确的程序代码发出警
告”。如果您看到这些程序设计师对我的建议所表现出的
态度，您真会觉得我是在劝他们扔掉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年，我们即将完成Macintosh 版的M i c r o s o f t
Excel 1。5 产品时，高层管理者已经在计划2。0 版了，他们
的目标是凡是Windows 版Excel 能做到的，Macintosh 的
Excel 2。0 版也要完全做到，尽可能沿用Windows 版的程
序代码，不能抓来用的就另外写，但是要看起来都一样。
已经在Excel 项目做过两年的我并不害怕这个任务，我只
是觉得这个计划本身有很多问题。除了外观上的相似性之
外，Windows 的Excel 和Macintosh 的Excel 基本上是完
全不同的软件，同时我也觉得Macintosh 的Excel 其实比
不上Windows 家族的软件，当然后者的团队也比较庞大，
增加的功能也比较多。
微软的Macintosh 版软件还有一个很严重的问题，就
是它无法利用1MB 以上的内存，这是由于最初在设计时
的一项决策所致。因此，软件必须加载到最前面1MB 的
内存才能正常运作，使用者非常抱怨，我明明还有7 M B
209
微软研发·致胜策略
态度问题下载
的内存，为什么它偏偏只肯用最前面那1 M B？这算哪门
子道理嘛！
苹果计算机公司的程序设计师在开发名叫
MultiFinder 的多任务操作系统时，发现Excel 只认得那最
前面1MB （低地址） 的内存。当时的苹果计算机操作系统
对于软件的加载是采用从高地址到低地