按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 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） 来特别监视这
一部分的程序。
有一次我在审查一个利用一组庞大的数字矩阵来控制
的功能，其实用数字矩阵来执行这个功能是一个很好的主
意，但是我恐怕它容易出错，因为数字矩阵的内容可能根
本就是错的，这个程序恐怕经不起这种错误，所以我要求
程序设计师加入除错码来防止。程序设计师想也没想，脱
口而出道：“写除错码太浪费时间了。”
听到这句话的刹那间，我脑中警铃大响。。
因为这位程序设计�