（1）症状和根源可能相隔很远。也就是说，症状可能在某一个程序单元中出现，而根源实际上在很远的另一个地方。高度耦合的程序结构加剧了这种情况。 （2）症状可能在另一个错误被纠正后暂时性消失。
（3）症状可能并不是由某个程序错误直接引发的，如误差累积。 （4）症状可能是由不太容易跟踪的人工错误引起的。 （5）症状可能时隐时现，如内存泄漏。
（6）很难重新产生完全一样的输入条件，难以恢复“错误的现场”。 （7）症状可能分布在许多不同的任务中，难以跟踪。
改错的最大忌讳是“急躁蛮干”。人们常说“急中生智”，我不信。我认为大多数人着急了就会蛮干，早把“智”丢到脑后。不仅人如此，动物也如此。
我们经常看到，蜜蜂或者苍蝇想从玻璃窗中飞出，它们会顶着玻璃折腾几个小时，却不晓得从旁边轻轻松松地飞走。我原以为蜜蜂和苍蝇长得太小，视野有限，以致看不见近在咫尺的逃生之窗，所以只好蛮干。可是有一天夜里，有只麻雀飞进我的房间，它的逃生方式竟然与蜜蜂一模一样。我用灯光照着那扇打开的窗户为其引路，并向它打手势，对它说话，均无济于事。它是到天亮后才飞走的，这一宿我和它都没有休息好。
我们把寻找错误根源的过程称为调试（Debugging）。调试的基本方法是“粗分细找”。对于隐藏得很深的Bug，我们应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。如果没有调试工具，那么只好用“土办法”：在程序中插入打印语句如printf(…)，观看屏幕的输出。
有些时候，世界上最好的调试工具恐怕是那些有经验的人。我们经常会长时间地追踪某个Bug，苦恼万分。恰好有高手路过，被他一语“道破天机”。顿时沮丧的阴云就被驱散，你不得不说“I服了You”。
修改代码错误时的注意事项：
? 找到错误时，不要急于修改，先思考一下：修改此代码会不会引发其它问题？
如果没有问题，则可以放心修改。如果有问题，那么可能要改动程序结构，而不止一行代码。
? 有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起
的）。好不容易逮住一个，应当乘胜追击，全部歼灭。
? 在改错之后一定要马上进行回归测试，以免引入新的错误。有人在马路上捡到
钱包后得意忘形，不料自己却被汽车撞倒。改了一个程序错误固然是喜事，但要防止乐极生悲。更加严格的要求是：不论原有程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的），都要进行回归测试。
? 上述事情做完后，应当好好反思：我为什么会犯这样的错误？怎么能够防止下
次不犯相似的错误？最好能写下心得体会，与他人共享经验教训。
10
1.6 关于软件开发的一些常识和思考
1.6.1 有最好的编程语言吗
作者的观点：程序员在最初学习Basic、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好，不免有喜新厌旧之举。而如今的Visual Basic、Delphi、Visual C++、Java等语言各有所长，真的难分优劣。能很好地解决问题的编程语言就是好语言。开发人员应该根据实际情况，选择业界推荐的并且是自己擅长的编程语言来开发软件，才能保证有较好的质量与生产率。
编程是件自由与快乐的事情，不要发誓忠于某某语言而自寻烦恼。
1.6.2 编程是一门艺术吗
作者的观点：水平高到一定程度后，干啥事都能感受到“艺术”，编程也不例外。但
在技术行业，人们通常认为“艺术”是随心所欲、不可把握的东西。如果程序员都把编程当成“艺术”来看待，准会把公司老板吓昏过去。
大部分人开发软件是为了满足客户的需求，而不是为了自己享受。本书提倡规范化编程。规范化能够提高质量与生产率，最具实用价值，尽管它在一定程度上压抑了“艺术”。编程艺术是人们对高水平程序创作的一种感受，但只可意会，不可言传，不能成为软件公司的一个指导方针。
1.6.3 编程时应该多使用技巧吗
作者的观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中使用太多的技巧，可能会留下错误隐患，别人也难以理解程序。鉴于一个局部的优点对整个系统而言是微小的，而一个错误则可能对整个系统是致命的。我建议用自然的方式编程，不要滥用技巧。我们有时的确不知道自己的得意之举究竟是锦上添花，还是画蛇添足。就象蒸出一笼馒头，在上面插一朵鲜花，本想弄点诗情画意，却让人误以为那是一堆热气腾腾的牛粪。
小时候读的《狼三则》故事启示我们，失败的技巧被讽刺为“技俩”。当我们在编程时无法判断是用了技巧还是用了技俩，那就少用。《卖油翁》的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，而不是卖弄出来的。卖油翁的绝技是可到中央电视台表演的，而他老人家却谦虚地说：“没啥没啥，用熟了而已”。
11
1.6.4 换更快的计算机还是换更快的算法
如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？ 作者的观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，则需谨慎考虑。若换一台更快的计算机能解决问题，则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度，但可能引入错误以及延误进度。
技术狂毫无疑问会选择后者，因为他们觉得放弃任何可以优化的机会就等于犯罪。类似的争议还有：是买现成的程序，还是彻底由自己开发？技术人员和商业人士常常会有不同的决策。
1.6.5 错误是否应该分等级
微软的一些开发小组将错误分成四个等级[Cusumano, 1995, p354-p355]： ? 一级严重：错误导致软件崩溃。
? 二级严重：错误导致一个特性不能运行并且没有替代方案。 ? 三级严重：错误导致一个特性不能运行但有替代方案。 ? 四级严重：错误是表面化的或是微小的。
作者的观点：将错误分等级的好处是便于统计分析。但上述分类带有较重的技术倾向，并不是普适的。假设某个财务软件有两个错误：错误A使该软件死掉，错误B导致工资计算错误。按上述分类，错误A属一级严重，错误B属二级严重。但事实上B要比A严重。工资算多了或者算少了，将会使老板或员工遭受经济损失。而错误A只是使操作员感到厌烦，并没有造成经济损失。再例如操作手册写错了，按上述分类则属四级严重，但这种错误可能导致机毁人亡，难道还算微小吗？
开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。只有这样才能少犯错误。
1.6.6 一些错误的观念
错误观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。
作者的观点：好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍，这是因为：
（1） 在现实中，由于工作条件千差万别，即使是相当成熟的软件工程规范，也常
常无法套用。
（2） 软件技术日新月异，没有哪一种标准能长盛不衰。祖传秘方在某些领域很吃
香，而在软件领域可能意味着落后。
12
错误观念之二：我们拥有充足的资源和经费，可以买最好的设备，一定能做出优秀的软件产品。
作者的观点：大公司经常有这样夜郎自大的心态。良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境的是一群庸人或者是一群勾心斗角的聪明人，难保他们不干出南辕北辙的事情。
错误观念之三：如果我们落后于计划，可以增加更多的程序员来解决问题。 作者的观点：软件开发不同于传统的农业生产，人多不见得力量大。如果给落后于计划的项目增添新手，可能会更加延误项目。因为：
（1） 新手会产生很多新的错误，给项目添麻烦。
（2） 老手向新手解释工作以及交流思想都要花费时间，使实际开发时间更少。 所以精确地制定项目计划很重要，不在乎计划中的进度看起来有多么快，计划要恰如其分。如果用“大跃进”的方式干活，只会产生倒退的后果。
错误观念之一：只要干活小心点，就能提高软件的质量。
作者的观点：软件开发是一种智力创作活动，世上最小心翼翼、最老实巴脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量属性素），一定要先搞清楚怎样才能提高质量，才可以在进行需求开发、系统设计、编程、测试时将高质量内建其中。
13