Bug管理的经验和实践(中).doc

Bug管理的经验和实践（中）发表在程序员杂志2005年第2期3842页的访谈文章未删节稿孟岩：刘振飞，你好。上一期文章里，我们谈到了Bug管理的理念和经验。按照我的体会，Bug的控制是一个管理与技术相结合的课题。做好Bug的管理，一方面需要有完善的管理体系和制度，另一方面更需要有一个坚实的基础平台来支撑。确切地说，就是要有一个比较完善适用的软件，充当Bug管理的中枢神经。显然你是很看重这个软件系统的。我想问你一个问题，如果没有这样的软件系统，而是单方面强化管理，比如制定完善的流程和制度来管理Bug，你看这样可行吗？刘振飞：从我的经验来讲，只靠制度而没有良好的Bug管理软件，根本无法确保Bug管理的有效性，因为仅靠这些规章制度很可能流于形式、走过场。正如源代码管理一样，如果没有类似CVS或VSS的工具，很难想象一个较大项目中的源代码仅仅靠公司的源代码管理制度和大家的自觉性，就可以让多个程序员之间的不同版本源程序保持同步、不冲突。光有制度是不行的，必须有配套工具来保证这些制度落到实处！还有，做好 Bug 的管理，应该是从高层领导到中间管理层再到基层人员，都从内心认同其重要性，然后根据自己公司的实际情况制定相关的管理体系和制度，切实执行并逐步形成自己的风格。要实用、不要随波逐流。不能今天一个ISO、明天一个CMM、后天又来个6西格码。工具是思想的载体，再好的管理思想还是要通过工具来实现。购买也好、自己开发也好，必须有个 Bug 管理工具作为基础支撑平台。孟岩：一个企业如果有意建立自己的“Bug管理神经系统”，大致可以有三种选择，一是购买成熟的商业产品，二是选择类似BugFree那样的开源软件，三是自己开发符合本公司现有架构的Bug管理软件。对于某些公司来说，最后一种模式应该是很有吸引力的。你主持了BugFree的开发，能否告诉我们，开发一个Bug管理系统难不难？刘振飞：应该说不难，想自己开发一个Bug管理系统的朋友，你首先要明确本公司真正的需求是什么，再就是根据你的需求做出来后一定要在实际产品研发中真正应用起来，根据大家的反馈不断去完善。像我们开发BugFree，从开始动手写代码到真正能够在公司里使用，前后也就两个月时间。为什么能够这么快做出来呢？最重要的原因是我把 BugFree的需求真正掌握了。我在微软天天使用Raid、时时刻刻和Bug管理打交道。我是站在微软这个巨人的肩上去深刻理解其20多年研发所总结出来的经验，所以四年下来，不让我熟悉Bug管理都难J 当我决定做 BugFree 的时候，脑子里很清楚为什么要做、做成什么模样、应该怎么做、做出来后大家怎么用，每个环节都考虑清楚了。这样真正实现的时候就很快了。当然仅仅做出来是不够的，还要在实际工作真正使用起来，并根据大家的实践去不断完善这个系统。之所以敢于把 BugFree 开源出来展示给更多的朋友，是因为经过我们近20人的团队10个多月的实际应用，大家一致觉得它是个难得的好工具、是日常工作的好帮手，大家工作都离不开了。不过，现在有不少成熟的Bug管理软件可以买的到，也有很多开源软件让你自由挑选。BugFree 是免费并且开发源代码的，你可以体验到微软的Bug管理精髓，按自己的需要自由地增加功能、修改代码而不用担心版权问题，为什么不试一试？实在不满意再动手自己造也不迟J 孟岩：那么去买一个成熟的商业产品如何？有什么比较好的选择吗？我听说科泰世纪公司在陈榕的领导下也开发了一个类似微软内部使用的Bug管理系统，你了解吗？还有开源社区里很流行的Bugzilla！，你怎么看？刘振飞：成熟的Bug管理商业产品应该有不少，比如，IBM提供的Rational ClearQuest、微软将在VS.NET 2005（Whidbey）中集成的Bug管理系统、上海微创提供的BMS、科泰世纪和欣软件工程管理工具套装软件中的Bug管理系统等等，都应该不错。开源社区中，你可以选择Bugzilla！、Mantis等Bug管理系统。老实讲，除了微软相关的Bug管理系统之外，其它的我都不熟悉。不过我认为不同的Bug管理系统之间功能上应该不会差别太大，因为大家都是从软件实践中总结出来的经验结晶，不会说某家有特别独到、别家根本想不到的地方。差别之处主要在于价格、安装配置、易用性、可定制、能修改源程序等方面。在我决定做 BugFree 之前，曾经考察过上面提到的开源社区Bug管理系统，但是简单研究之后，觉得和我在微软用的Raid差别太大、不习惯；陈榕在微软工作时间更长，他们做的系统也是借鉴微软、最接近我的使用习惯，但是得花钱购买（尽管比起其它商业化Bug管理系统而言，价格不算贵），而且不能根据我自己的要求随便更改，所以干脆自己做一个算了。不管怎么样，我觉得多样性是一件好事，给了大家更多的选择机会。每家公司、项目、人员的状况都不一样，都可以根据自己的具体情况挑选自己喜爱的Bug管理系统。顺便说一句，通过我自己做BugFree开源的经历，觉得自由软件的真正魅力不在于其零价格，而是其源代码的完全开放，你可以根据自己的具体情况自由的去修改、去定制，完整的控制整个系统。孟岩：如果有这么一家公司，它接受不了整套的Bug管理制度，打算自己开发一个Bug管理系统，以适应自己企业的需求，让你给参谋参谋，你觉得一个良好可用的Bug管理系统，需要有哪些基本功能？刘振飞：我觉得一个Bug管理系统需要具备以下外部特征：1可以完备的记录、跟踪Bug 的一生：从出生（创建新的Bug）、不断成长（记录相关人员寻找产生Bug的原因的讨论过程）、发育成熟（找到了一个处理办法）到最后死亡（关闭），同时也要允许Bug的复活（问题重现），继续其生长过程。2方便的查询功能，快速找到你关心的 Bug。比如：a). 最近N个指派给我的 Bugb). 最近N个由我创建的 Bugc). 各种自定义条件的查询3提供各种Bug统计信息。比如每个人头上有多少个Bug、到目前为止Bug总数的统计、最近一周Bug曲线图等等，视具体需要可以有很多种统计。4方便的项目和模块管理，可以有很多项目、每个项目有多个模块，要能够很方便的增加、删除、修改。5简单的用户管理。作为一个可独立使用的系统，需要能够增加、删除用户。当然最好的是直接使用公司已有的管理系统中的用户认证。比如在微软，只要你登录公司内部网（域）后，你就可以直接使用Raid了，它直接集成了公司的用户认证，不需要单独一套用户认证系统，那样对使用者就很不方便，管理起来也会比较混乱。孟岩：你结合BugFree具体谈谈，这些功能是如何协同的？开发者、测试工程师和PM在整个开发过程中，是如何围绕这个系统运转的？刘振飞：先从基础设施说起。首先BugFree有一个独立且简单的用户管理，可以方便的增删用户：然后是简单的项目/模块管理，管理员可以方便的增加新的项目、新的模块，或者更改已有项目/模块的显示名字：因为仅仅有管理员才可以进入后台管理，所以这两个后台功能做的比较简单。这样定义了项目/模块和用户后，BugFree的用户就可以进行Bug的跟踪处理了。举个虚拟的场景，林燕锋、你、我三个人在一家公司做网站，他是测试工程师（Tester）、你是开发工程师（Developer）、我是需求定义者（PM），我们三个负责公司网站的新闻频道：1. 林燕锋发现新闻频道的后台管理中“编辑”功能打开速度非常的缓慢，无法忍受。于是他新建一个Bug说明这个问题，然后指派给我；2. 我看到这个Bug后，赶快到新闻频道的后台试用一下，果然很慢。于是我把这个Bug指派给你，加上我的注释：“孟岩，这项功能使用很频繁，速度太慢直接影响了我们信息编辑的工作效率。请你研究一下这部分代码，看如何调整程序，以加快打开速度。”3. 你看到这个Bug后，作为这部分功能的实现者，去认真地研究了当时的代码，经过调试，发现是数据库查询方式的问题，采用不同的方式之后，新闻编辑功能的速度大大提高了，于是你解掉（Fixed）这个Bug，并把你发现的问题原因和解决方法做了描述：“不好意思，以前的查询方法有点笨，现在已经修改了数据库查询方式，加快了浏览速度，具体改动请参见附件EditNews.php。”因为问题被解决，这个Bug会被自动指派给创建者林燕锋头上。4. 林燕锋看到这个Bug被Fixed了，赶快去验证了一下，发现问题真的消失了，于是他关闭这个Bug，并加上注释：“太好了，刚才用了一下，速度确实快了很多。我代表信息编辑感谢你老兄的工作啊！:-)”你看这样做，BugFree就非常完整地记录了Bug的一生：如何发现（创建Bug）、不断讨论（编辑Bug）、找到原因（解决Bug）到最后关闭它。这样开发工程师、测试工程师和PM在整个开发过程中，都被一个个情况各异的Bug们牵着鼻子，密切配合，不断发现问题、研究可能的原因、找到处理办法、验证解决方法是否真的凑效。BugFree 让所有项目/产品的研发参与者围着它转，忠实的记录了所有被发现问题的讨论处理过程，即使时间过了很久、我们三个都离开了这家公司，但当时我们处理的思路被保留下来了，后面接手的同事可以完整无误的看到全部的讨论过程，就像有台录像机把这个过程录下来一样。孟岩：从内部来看，BugFree的架构是怎么样的？刘振飞：BugFree 是用 PHP+MySQL 写成的。首先我们定义了七个相关数据表：- BugProject:项目表- BugModule:项目中的模块表- BugInfo:Bug基本信息表- BugHistory:Bug处理过程的历史记录表- BugFile:Bug相关附件表- BugQuery:Bug查询条件表- BugUser:Bug的简单用户表程序代码也是按照前面介绍的Bug管理功能展开的，基本上一个功能对应一个PHP文件，比如： Bug的处理过程- AddBug.php:加入一个新Bug- EditBugForm.php:编辑一个Bug的信息- ResolveBug.php:解决一个Bug- ActivateBug.php:激活一个Bug- CloseBug.php:关闭一个Bug Bug的查询- QueryBug.php:查询符合条件的Bug- SaveQuery.php:保存用户定义的查询条件- DelQuery.php:删除一个用户定义的查询条件 Bug的统计自动通知- NoticeBug.php:发信通知每个用户的Bug情况- StatBug.php:发信给所有人告知当前Bug统计情况BugFree 中使用Smarty技术把PHP代码和HTML隔离开，每个涉及到界面的.php文件，都有一个对应的在Template目录下的.tpl文件，这样代码结构就非常清晰，很容易看懂、维护和添加新的功能。主要目录结构如下：- 根目录下主要存放上述Bug一生处理流程、查询等功能文件Admin- 后台管理对应的文件BugFile- 存放Bug中的附件Compile- 存放Smarty编译后的文件Document- BugFree 的各种说明文档Image- BugFree 中用到的各种图片Include-公用文件JS- 用到的JavaScript文件Shell-存放需要定时执行的文件Template- 所有界面模板文件（.tpl）除去ADO、Smarty等第三方文件，BugFree 自身也就是由30多个PHP文件组成。更详细的说明请参看DocumentFileList.txt (代码文件结构)。所以你看，BugFree 的架构其实非常简单，代码量也不大。想探个究竟的朋友，只要明白了表的结构，然后按图索骥，根据功能逐个查看对应的代码文件就可以了。PHP 程序的复杂度要远小于C/C+，很直观。我觉得一个中等水平的 PHP程序员就可以在12周内看懂所有的代码，然后就可以根据需要做相应的定制了。BugFree 仅仅是个小工具而已，没有什么神秘的。孟岩：看来BugFree的设计考虑是相当细致的。不过很多人都抱怨这个用PHP编写的软件不容易配置，尤其是在Windows环境下。你能否简单地给大家介绍一下BugFree的配置和部署方法？刘振飞：上一期文章发表后陆续收到一些网友的Email，反映的主要问题是 BugFree 在 Windows平台上的安装问题，而Linux平台上似乎很少人抱怨。这从一个侧面说明在Linux上大家已经习惯自己动手配置、有问题自己能找到解决办法J坦率的讲，因为时间、精力、资源有限，目前我们对 BugFree的安装配置这一块的测试做的很不够，所以还要请网友谅解。我也是通过这个软件，觉得做好开源项目真的很不容易，需要付出巨大的努力，因而很佩服那些为开源社区贡献优秀软件的人们。从反馈的情况来看，我想主要的原因有三个：1. 运行环境的版本问题，比如PHP、MySQL的版本2. 程序路径问题3. PHP 的配置参数 目前经过我们实际测试的工作环境有： PHP 4.3.8和MySQL 4.0.17(基于RedHat 9 + Apache 1.3.x) EasyPHP 1.7 (我自己在Windows上测试过)其他环境，如IIS、Apache2、PHP5等，还没有测试过。在Window上使用BugFree需要改动PHP.ini中的下述参数： allow_call_time_pass_reference = On error_reporting = E_ALL & E_NOTICE register_globals = On根据大家的意见，我特别写了一份文档“在 Windows 平台上安装 BugFree 的详细步骤”，公布在 /OpenSource，供大家参考。若有朋友成功尝试过其他版本的运行环境，欢迎你把详细步骤整理出来发送给我，这样我可以共享给所有网友。这就是开源的好处：和感兴趣的热心朋友们一起不断完善 BugFree。孟岩：我记得BugFree 1.0开发出来以后，你特别兴奋，跟我说这个系统已经达到了微软内部系统的水准。不过马上你就开始做2.0版。2.0有什么大的改进吗？是你的1.0版还不够完善，还是说你对于Bug管理有了新的认识？刘振飞：前面提过，BugFree 仅仅是个小小的Bug管理工具而已，所以第一版发布后我觉得从1.0计数有点不好意思，那么庞大的Apache才到2.0了嘛。所以我决定 BugFree 的版本从0.1计数，慢慢往上加JBugFree 0.1版是在2004-10-11正式公开的。在我们内部使用过程中，逐步累积了不少新的功能需求一直没有来得及添加，而且 Ver 0.1主要有两个不足：1.