程序是调试出来的吗?

转载请标明出处：blog.csdn.net/zhangxingping

        前些天听到有人无意中说到写程序就是要慢慢调试，看其表情，听其语气很有程序就是要慢慢调试才能写好的意思。当时心里楞了一下，不过由于事情比较多，也没有过多留意。事后有空想起这件事情让我感觉到有必要思考一下这么几个问题：程序是调试出来的吗？程序应该是调试出来的吗？好的程序应该是调试出来的吗？

        还是先从自己从业的经历来说起，来思考这几个问题吧。大学毕业后，从事商用软件开发也不下5年的时间了，如果算上在校研究生期间跟导师做项目的话，编程的年龄已超过10年了。还记得上大学期间学习C语言的时候，老师布置一个用链表实现简单的学生信息管理的小程序。链表操作中大量使用到了指针，当时自己整整花费了4个小时在学校的机房里面调试程序中对链表的操作。那情形真可谓是“屡战屡败，屡败屡战”！最终在吃晚饭前把程序调试出来了。也就是经过那次4个多小时的调试，让我深深理解到了C语言中指针操作常常会出现哪些问题，以及应该如何避免这些常见的问题。也是那次调试深深理解到了有人说的“指针才是C的精华”这句话的含义。以至于后来在工作中，自己每次使用指针的时候都是小心翼翼。在编写和指针相关的代码的时候头脑中总是迸出一下的几个问题：这个指针如何初始化？是指向已有空间的地址还是需要新申请空间？如果是指向已有空间的地址，那该空间是否需要由自己编写的模块负责释放？如果是需要自己新申请空间，那么这些空间中的初始值是什么？这些空间应该由自己的模块负责释放还是别的模块赋值释放？这些空间应该在何时被释放？申请和释放使用的函数是否匹配（malloc，free，new ，delete），甚至是delete p; ，还是delete  []p;都要在脑子里面思考一下，并在代码或者相关文档中查找相关的证据证明应该这样做而不是那样做。人就是这样，吃一堑，长一智。

        还记得大学毕业的时候，老师们组织对毕业生的设计做检查，轮到检查我的时候，有一个老师问我到：“你做的这个软件有需求说明书吗？”。自己楞了几秒，然后低声说到没有。庆幸的是由于毕业设计做的那个小软件功能还算可以，也就顺利毕业了。但是那个老师的问题我依然没有忘记。回忆在学校做的毕业设计大部分都来自于老师的项目，我们只是跟着老师干活，具体就是编程了。软件需要实现那些功能也都是由导师口头表述给我们。需求说明书的概念只有在软件工程的课堂上听过。说实话当时连正式的软件说明书张什么样子都不是特别清楚。

        毕业后有幸在一家国内一流的通信设备制造商那里从事交换机主机软件的开发。该公司当时是遵循SW－CMM的要求来对软件开发过程进行管理，以确保软件的质量。初次接受这样的管理过程很不适应，在学校里面基本上不用写什么需求分析，概要设计，详细设计等文档，写的代码也不作什么单元测试，集成测试等。老师口述要做什么，自己直接就编码，基本调试通过就给老师看看结果，老师说OK就OK了，不OK则继续修改或调试。在学校那些小程序真的是调试出来的，没有设计可以言。程序都是流水账，写到那儿算那儿。更谈不上复用性，维护性，可读性等。工作了，一切都不一样了！有了严格的开发过程保证，甚至这些过程文档还要经过评审，评审的意见还有很多“率”的要求。每个开发阶段都有很多的指标要求，达到这些指标了方能进行下一个阶段的开发。所以当时心里那是个抵触呀！不过抵触归抵触，该干的事情还是得干。当时加班加点已经是家常便饭。一两年下来，也做了两三个项目，这些项目有的做的还不错，也的也不是很理想。后来自己作项目也就自然按照公司的规范要求去做了，只是后面的几个项目做的就要比前面轻松多了。现在回顾起来，为什么后面越做越轻松了？也许是真正体会到了那些个严格过程的最终目的，以及理解了这些过程是怎样保证了能够达到这个最终目的的，因此自己就自然的顺应了这样的开发过程了吧。这段时间个人感觉是我进步最大的一段时间了，工作虽然辛苦，但是很充实。感觉比在大学期间学习的东西还多。

        再后来，由于个人的原因离开这家公司。先后在两三家国内比较有名的公司从事软件开发工作，但都是感觉不自然，直到现在从事的这份工作吧。想想为什么后来的这几家公司让我感觉到不自然了，主要原因都是有种强烈的回到了学校的那种开发过程的感觉。

        这里说说曾经去某大型公司面试的经历吧。该公司是一家国际知名的IT企业。技术面试的时候有一位面试官的问题几乎都是围绕这代码的调试这个主题进行的。面试完毕，我就感觉恐怕不能去这家公司了。因为从面试官的问题可以看出至少这位面试官对软件开发的和我的认识大相径庭。

        也许正是我的这种认识让我在听到了文中开始那位开发人员的话的时候楞了一下。也许正是这种认识让促使我思考文中开始的那几个问题。程序的调试是软件开发过程中的一个必然的步骤。世界上恐怕不存在高人的程序不需要调试就能完美运行并满足要求的。但是调试真的足以重要到会影响真个程序的运行以至于不得不说程序是调试出来的吗？

        也许现实中，有些程序基本上就是靠开发人员的不断调试和修正最终才运行起来的。自己在上大学期间的程序基本上也都是靠着这种调试才出来的。但是，为什么会这样呢？我想主要原因就是在开发前没有精密的设计和慎重的思考。正是由于没有这种思考，而直接上机器进行编程，才导致需要花费大量的时间来对程序进行调试和修改。实际上这种调试和修改都是针对之前没有进行缜密思考和设计的补偿，或者说大量的调试工作都是因为之前没有进行良好的设计和缜密思考的后果。正是在这种情况下，调试才显得非常重要。试想，如果在编码之前，进行了神秘的分析和良好的设计，并在编码的时候严格按照设计时的想法进行，稍有编程功底的人恐怕都不会再调试上花费太多的精力就能使自己的程序快速并良好的运转起来。也许小程序可以不需要编码前的思考和分析，完全可以在编码的过程中进行分析和思考，并通过大量的调试来弥补思考和分析不足带来的缺陷。但是，软件开发可决不能，也不应该是这样的。一个小程序往往都是自己一个人的事情，至于你浪费了多少时间进行调试，恐怕出来自己没有别人会关系。现在软件开发往往都是大型的，代码量上万，甚至十几万，几十万行的，也往往是团队协作开发的。此时，浪费的时间和精力往往会成为影响开发成本的一个主要因素。

        开发人员往往都有这样的体会：调试时候的一个问题常常需要花费较多的时间来进行定位，分析，有的甚至需要数天的时间才能定位出问题的原因，而且这种时间上的花费往往是不可预期的。时而还会出现问题定位后，才发现修改是个大麻烦，因为可能涉及到程序的整个框架。但是如果先前有过良好的设计和缜密的分析，这种问题就在开发的前期被避免了。程序员要做的恐怕就是按照详细设计文档写好自己的代码，进行编译，消除编译时的告警和错误就可以了。但是由于前期良好的设计和分析避免了后期问题的出现所带来的成本降低往往是隐形的，不易被察觉的。因为没有出现问题，大家都认为这完全是理所当然的。很少有人会意识到这是前期缜密分析和良好设计的结果。实际中还有这样的情况：一个项目组在开发过程中经常加班加点，最后软件交付前还有一堆问题亟待解决。而有的项目组在整个开发过程中都很轻松没，交付时软件质量也很好。当然这样局面的出现可能有很多的原因，比如后者的开发人员经验丰富等。但是我想至少有一条就是后者在开发前期分析透彻，设计良好。正如成功需要一万个努力，而失败只要一个理由就够了。当然，前期的透彻分析和良好设计不是谁都能做到的，需要经验积累，需要耐心分析。因此，我们需要在工作中对造成目前不好的局面进行分析，为什么会这样？思考如何在下次避免这种情况的发生。按照PDCA循环来说，一开始做某件或者某种事情的时候，可能由于没有经验，P做的不是很好。此时只能依靠D和C来检验这种方法做事的结果。也就是说一开始我们编写程序（软件）的时候可能由于经验不足，分析和设计做得不好，甚至没有分析和设计，只能依靠调试来弥补这种缺失。但是，随着每次在PDC之后的A的进行，我们的经验在不断得到累计，对事物的认识也在不断深入，这样一来，我们就有能力在后续做同类事情的时候进行缜密的分析和良好的设计，以确保D本身就是按照正确的方式进行的，此时C的工作量也就小了很多。具体到程序（软件）的开发上来，有了相关的经验以后，我们就有能力在编码前对需求进行缜密的分析，给出良好详细的设计方案，那么在编码的时候就会轻松很多，调试也会变得简单很多。实际中有些开发人员之所以认为调试是相当重要的，以至于感觉到程序是调试出来的，就是因为前期没有做好分析和设计，导致所以问题都累积到了编码和调试阶段，此时不进行加班加点的调试就无法按时交付。个人认为PCDA中A的作用就是为了避免以后出现类似的问题，尽量把问题消灭在萌芽状态，消灭在开发过程的早期，这样不经能降低开发成本，也能保证交付良好的软件。

        但愿所有的开发人员都不在加班加点进行调试。

        PDCA：http://baike.baidu.com/view/529300.htm