程序备忘录：之一－从B票到编码的回视（2004/06/30 11:30）

　　2004年4月下旬，项目后期人员进入开发现场，参加软件项目的收尾工作。从合作双方来说，要达到客户满意的要求，这是一个必经的阶段。而对于项目人员是一种难得的机会，但同时也是一种艰苦的考验。（背景省略100字。）
　　B票就是记录BUG的文档，既作为过程文档，又作为结果文档。从技术上说，是修正程序的依据；从管理上说，是计算工时的依据。当然，B票不是唯一的参考资料，但是它非常重要。
    一个月时间除休息日，共投入工作日25天，其中通霄5个，修改B票29个，总修改代码行约2500。因为BUG是随机出现的，所以对每日的工作范围不易掌握，一度比较疲劳，遇到休息日一般12点起床，不过还好，客户对编程质量比较满意，为引出观点，不妨回忆一下修改的几个BUG。
    在不做选择的情况下，列举几个编号，作一下基本的分析。
    Bug No.1:
    简介：一个数据表信息的编辑画面，用户可以在数个输入框中填写数据，也可以从已有的数据中通过点击按钮取到一些现有的数据再稍做修改，按钮旁边有一个下拉框，用于选择要拷贝的源数据名称。
    错误：下拉框中的文字包含单引号时，点击按钮出现系统错误。
    过程：首先再现此错误，发现并非单引号的问题，但是会有偶然的时候出现错误。这个问题困扰了两、三个小时，终于发现只要连续点两次按钮就出现错误。
    分析：这个错误值得总结的地方在于测试的目的不在于证明程序正确，而在于发现错误，而我们侧重于前者，对自己的程序不做过多的严格测试，或者说不愿意破坏性的测试。从编码上来看，注释不太够，但是逻辑清晰，版面整齐，两次对DB的写入用重复的主键(画面未迁移，使用上一次得到的ID)，造成BUG，仅仅反映了经验的不足，所以类似的错误在以后的项目中完全可以避免。
    Bug No.2:
    错误：HTML画面应该是2行2列，结果是第一行是3列，第二行是2列。
    分析：这样的BUG对于修改人员是很省事的，但仔细想想也是可以避免的，只要编程者知道最后的结果应该是什么，并且往浏览器上一放看一遍就可以避免了。
    Bug No.3:
    简介：画面1对应一个数据表的一条记录，上有一个按钮，对应打开与这条记录关联的多条记录。一条记录与关联记录的最新更新日期有前有后，要求分别比较并提示。
    错误：编码漏掉了此项内容。
    分析：编码期间可能花1个小时，这时却用了5.5个小时，结果是修改文件3个，代码23行。这种问题需要在浏览代码时检查出来。
    Bug No.4:
    简介：设计书漏掉的功能。
    分析：这种BUG考验代码的可维护性，经阅读源码，因为注释不够，多花了不少时间DEBUG和分析源码。因为大规模开发阶段已经过去，仅有几个人留在后期维护，必然接触到其他人完成的代码。源码注释量不够，好在层次较为清晰，而且需要增加的部分正好在一个方法内，这样其影响范围可以清楚的表现。增加这部分功能时，又写了数个小方法，然后在调用处增加两三行即可。这说明多写小方法是有利于程序维护的。但要注意，一定要定义常量和规范的注释，利于再次的修改完善。所以要编写可维护性强的代码。
    上面的BUG只反映了一小部分和编码有关的信息，从实际的情况看，可以在编码期间避免的错误占10%左右，有很大的提高空间。
    如何对待BUG？最简单的想法就是找到问题所在，查看其影响范围，修改完成。但项目里是如何对待的呢？如果该问题很通用，则调查所有具有相同特征的业务，列举出来。然后逐个对照，统一处理。这个问题其实我注意到了，但这些工作是否要做，首先要看这个BUG消除了没有，确保任务之进展，其次只能做到列举部分相关的共性提出可能的影响，而不会一板一眼的画出一张汇总表，这恐怕正是值得虚心学习的地方。