摘要：在编程过程中，调试和诊断如影相随，以确保程序的完美运行，这就像是一门艺术。本文详述了调试和诊断的五大规则，包括编程前后的不同事项。分享给各位程序员，希望能对你们有用。

导读：Micheal Shallop是一位资深的Web开发者，软件工程师。6月21号在DZone上发表文章The Top 5 Debugging and Diagnostic Rules for Programming，分享自己多年的工作经验。下面是编译内容。

在我的职业生涯中，不管是系统开发、系统设计、还是系统调试，我都是这些方面的专家。对于我的成就，我很自豪。后来我大部分时间都花在系统检查上。“系统崩溃了”是我经常听到的话。

在一个进行了三年的项目里，我没有任何假期，甚至没有脱产培训，外出都是带着笔记本电脑，以便于每天早上可以检查头天晚上的运行结果。这种紧张而有序的工作情况恐怕不是所有人都能想象得到的。花在技术支持上的时间可以帮我磨练诊断技术——想想看，您正在安装一个你根本看不到的系统，还要和远程专家进行交流。时间久了，技术就是这样慢慢积累起来的。

还是来说说重点吧，在这些年的工作当中我已经学到了很多编程调试很诊断的东西。我目前的任务是编写一个后端数据系统，100%的可伸缩，水平和垂直方向的，使用的是开源服务项目，例如mongo，mysql，rabbitmq和memcache，框架是由我编写的100%PHP。当别人看着我设计出来的系统的时候，我能从他的眼里看出羡慕的眼神——这是知识的力量。可是你有没有发现，现在的高校仍然缺乏在软件/系统调试和诊断方面的综合性专业。

调试的方法主要是目标访问、运行控制以及实时跟踪。调试问题贯穿多种多样的系统，集成开源系统，或者在你自己的代码之间，这就像是一门艺术。在过去的几十年里，我编译了关于诊断技术的非正式列表，很荣幸与你分享。

Rule 1—最后的更改可能会让整个项目前功尽弃

在我做电话技术支持（Pre-Web）的时候，我学到一件事情，如果你花足够长的时间去聆听客户的话，那你就知道怎样解决客户的问题。在大部分情况下，如果系统或软件突然停止工作，原因可能是你在运行环境里做了一些改变，不论是配置还是代码，都会对系统的稳定性有很大的冲击。

一旦你取消改变的项目，重新运行，恢复旧的数据库，撤销程序包，看看系统/软件是否继续工作？如果继续工作，那就能知道是什么导致系统漏洞，同时还可以找到系统崩溃的切入点。

你可能会很惊讶，经验丰富的程序员或管理员会不会经常忽略这条规律？其实，如今的软件是很稳定的，基本上不会自行变动。一旦它突然停止，就必须判断原因是什么，为什么会出现这样的问题。有可能是你作了一些变动。如果没有，就询问团队是谁安装了最后一段程序或谁意外的改动了文件权限等等。

最后要检查的，就是你最先修改的东西。

Rule 2—复制问题

针对软件开发，如果要诊断一个问题，那首要任务是重新把这个问题制造出来，才能从根本上了解并解决问题。有可能需要你真正参与进来：让终端用户确定他们所做的事件的确切顺序，以便能够产生同样的错误。

作为一个软件工程师，在不知道具体问题的时候修复代码的确很难。所以说，在这种情况下，你就不得不重新制造同样的问题。

如果同样的动作产生不一致的结果，比如说，工作第一次，第二次就不工作了，接着第三次第四次第五次都工作，但第六次又不工作了。问题可能出现在数据上，并且需要检查运行时间配置选项、有效载荷、输入和结果。代码不是关键问题，因为代码每次都是以同样的方式执行的。

当然啦，通常情况下也会有特例，不过这些年特例变得越来越罕见了，因为电脑都已经配备了保护内存的功能。数十年前，我讲过一堂内核崩溃分析的课程。稳定就是点动鼠标的一系列顺序，给鼠标驱动程序重新编码，通过内存分配将接收到的顺序输入打印机驱动程序，当发布一个打印命令的时候——核心转储！

如果你能连贯地复制问题，那你就有能力处理代码问题。

Rule 3—找出原因，而不是症状

因为系统都是互相联系的，沿着错误的道路诊断问题是最常见的错误，这被称之为“连锁反应”，软件或系统里的问题能够体现在不同的区域，挽回软件的质量只是问题的表面。当问题露出水面的时候，需要仔细想一想：我是要处理问题呢，还是处理看到的症状呢？

当处理一个问题的时候，你只是在问题上兜圈子，你必须停止您的心理过程，只需简单地确定你所处理的问题是表面症状还是有因果关系的。

Rule 4—要有信心

我曾经教过非传统的学生如何开始编程，他们当中的一些人认为电脑是智能的，恶毒的，有密谋的，诡计多端的，阴险狡猾的，看上去就像是一个充满恶作剧的盒子。

电影Short-Circuit（霹雳五号）里有段台词：

它只是一个机器，施罗德。它不会生气，没有快乐，不知道难过，不会嘲笑你的笑话...它只会运行程序！

人们往往忘记了这一点，在软件完美运行第一次之后，只要提供相同的数据和稳定的运行环境，那它就能一直完美无缺的运行下去。如果在两个对话窗口完成了测试，却在第三个窗口上失败了，其实不要浪费时间检查代码，因为问题不在软件上，而在第三个对话窗口的环境配置上，或者是输入的数据有问题。

不幸的是，能够发现基于软件问题的技术精英实在是很少，因为他们知道这方面几乎所有的问题。

“服务器有问题。”

“软件有问题。”

有些看上去深入的观点其实并没有经过分析。你千万不要因为别人这样的评论而分心，不能被别人误导，更不能动摇自己的立场。尤其当你是负责调试/编写系统或软件的带头人/开发者/管理员的时候。你必须有信心，坚信你的代码、平台和数据库在给出一致的输入和稳定环境的条件下，每次都能在相同的时间内完成运行。

当然，从表面上看，软件或系统可能是“有问题的”，但这并不表明只需简简单单的处理代码块——而是要分析问题范围，了解前置条件，数据源的完整性和输出质量。如果所有的项目都如设计的那样保持一致性，那你就应该看看对话框以外的地方，说不定问题根源就在那里。

Rule 5—记录，记录，再记录

记录在一个开发环境不能被滥用。通过记录,当然,我指的是诊断或提示性信息嵌入到代码库的输出,提供一个初步的问题确定性。要有频率、长时间的记录。

记录信息不仅仅提供洞察代码的问题区域，还给你提供自信——一切都按计划执行/处理/计算，一切都在监控中。记录工作同样可以告诉你这个查询、计算和方法都是成功的。

就我个人而言,我总是硬编码两个级别的登录作为代码的子程序。我经常在每个方法的入口点编写跟踪输出的代码，而且以关键决策点的出现作为条件编写调试代码，然后可以使用我的记录输出手段跟踪程序流，同时关注临界值。因为这些都是运行时方法，系统配置里单独的Boolean可以控制所有的跟踪，所以在非开发环境中信息发送功能是受限制的。

此外，拿记录PHP为例，有一个全域常数：__文件__，__线性__，__方法__和__功能__，这为你提供一个信息记录模板，还有一些其他模板：

随着开发的继续，你的硬编码行数将迅速变得毫无意义,除了搜索键还有点用。编写记录代码要用到所有的信息和有效代码相关的东西。

如果你想知道不同的记录等级之间有什么区别，那我建议你阅读文章10-Commandments of Logging。你可能并不赞同文章里的观点，但我保证你肯定会下决心改变之前的记录方法。

奖励制度

和二十年前我们普遍使用的工具相比起来，今天年轻的程序员使用的先进工具是经过我们不懈的努力创造出来的，这段美好的回忆将是在这个相对年轻领域里奋斗过的前辈们最好的礼物。我的第一个调试工具是printf()和(sh)，然而当打印机被广泛使用的时候，转存一个50000-line C-code列表到折叠式记录纸上，一个红色的毡笔头和大量的走廊空间成了我的调试器。

现代调试器是你的朋友,你的得力助手，能够向你的老板证明你简直就是个天才——它允许你在开发阶段分步调试代码和发现问题。不但能分步调试，附加变量监控，还能跳回堆栈，一切都是那么简单，听起来有点不可思议！

总之，如果你不想开发使用调试器，那建议你抽时间给你的IDE安装并配置一个调试程序包。用过你就会很惊讶，如果没有调试器，你该怎么编码？

总结

调试是一个习得的技能，所有的要点都已经在上面提到了，但这也不一定对你有帮助——如果你不知道你的系统，不了解你的应用程序或者是不懂电脑科学的基本规律。

英国科幻作家Arthur C. Clarke说过：任何非常先进的技术,初看都与魔法无异。

对于那些才疏学浅的人来说，观看优秀的开发人员或系统管理员解决复杂程序问题简直就像是玩魔术！真希望那种感觉会激励你努力学习必要的技能来加入到魔法行列。