单据影像系统项目总结

我坐在球面显示器前，旁边是半杯喝剩的咖啡和散发着噪音的塞扬366卡匣式CPU，此时是凌晨两点，我聚精会神地用JCreator调试一个纸牌游戏，最后一个bug终于排除了，我伸了个懒腰。上床休息前我突然想到一个有趣的问题，如果我运气不好输给了电脑，应该经过一点小小的刺激后再重新开始：当漂亮的艺术字“GAME OVER”消失后会出现一个可恶的白色乒乓球，它在800×600的古老屏幕中来回乱窜，碰到墙壁后快速反弹，我需要用鼠标准确地点中它才可以开始新一轮游戏。重新画图计算公式……当我实现这个功能时已经是次日中午。

那是五年前的一天，当时我还在大学学习，第一次接触到面向对象并乐在其中。

不久前的一个周末，我坐在宽敞的办公室，双眼发直地看着ThinkPad中标注了红灯的进度列表。

“A要完蛋了，三天时间对他来说太少了。”

“B要完蛋了，凭他一个人完成这个功能至少要五个月。”

“C更要完蛋了，等他做出这个功能就得下辈子见了。”

 ……

以上只是一个小小的故事，我几乎忘了讲这个故事的初衷。但是进入正题前我还要再讲一个。

 在我职业生涯的开始，开发人员递交给我一些Excel表格，我的任务是将这些表格中的数据分类整理，重新美化Excel的样式。这并不是个轻松的工作，表格中充斥着大量杂乱无章的字体，各种类型的数据被混杂在一起，Excel复杂的特性被乱用了一遍又一遍……就这样耗去了我21天，最后换来的仅仅是一声谢谢。这个场景我们是不是似曾相识？就发生在阅读别人代码的时候。

东方有线单据影像项目暂时告一段落，按照惯例，我将做一个简要的回顾。

似乎很久以前就开始着手准备这个项目，项目评审早在08年11月就已经通过，但是由于客户和我们都在忙于发票稽核模块，这个项目暂时被遗忘在角落。

牛年伊始，我们终于见到了盼望已久的需求文档。让人郁闷的是，短短十几页的文档中有五页以上的八股文，可以提取的有效信息极少，我们要做的是为空中楼阁搭建一些地基。值得一提的是，这个项目分为C/S采集和B/S展现两部分，在我主要负责的B/S部分一筹莫展时，C/S已经接近尾声，提交客户正式试用。

正像开发人员的不良传统一样，我对需求文档向来缺乏重视，于是这个空中楼阁一直悬在半空，每次开会都是无疾而终，其他开发人员似乎比我还不善于阅读文档，匮乏的想象力让我们画不出有效的界面图例。

 就这样一瘸一拐地走了大约两周，这段时间每个人都极其懒散，理由也似乎很充分：这种文档怎么做？需求是需要不断完善的，遗憾的是我们并没有意识到这一点。直到有一天，忍耐许久以至近乎发疯的测试人员终于集中火力向我开炮，他们抱怨文档的东西太少，无法有效写出测试用例……我这才意识到我们做的简直差到了极点。既然知道了自己的无知就要勇于改正，我自问不缺少这份勇气，于是我用了大约一周时间细化需求文档，在这个过程中加深了对问题的理解，也发现了一些与C/S部分存在的焊接点问题，这些问题被转换成列表一一记录在案。

上个项目中我们在需求文档上吃了大亏，大量的需求变更碎片无人整理，我们甚至无法有效确定客户新发的变更是否是需求反复。单据影像项目中，我们计划将需求以版本号的形式升级，保留以前的版本以便随时对照，实际上我们正是这么做的。

 有了细化的文档，我们终于打下了第一根地基，由于B/S部分功能相对简单，设计部分耗时较少。

很快迎来了编码工作，大量的问题也在这时集中暴露出来。

先来看一下代码统计结果：

 

1W行左右的代码说明这仅仅是个小模块，如果去掉我加入的部分单元测试代码，总数将更少。与之相对的是一份缺陷统计图：

 

 

严重性高的bug占了总数的41.56%，这是个极其丢脸的统计结果。

 我和测试人员的对话多少可以反应这个结果：

“以前没做过软件吗？”

“当然做过。”

“提交测试组前做了测试吗？”

“做了，但是显然还不太充分。”

“为什么会出现这样的结果？”

 “……（天晓得）”

 我自信自己的代码做了足够的测试，即使出现一些问题我也仍然较为自信，其他人呢？连续四版冒烟测试不通过令我极为恼火，大家似乎懒于为自己的代码做测试，或者说并未掌握测试的基本技术，这对于软件质量或许是致命的，因为我看到了大量由于缺少校验而引起的异常，我过滤的其中的大部分，发布版本时仍不免有漏网之鱼。我将几个主要问题总结如下：

1.         缺少文本域长度校验导致的异常（为什么这种错误百般强调仍一再发生？）；

2.         正则表达式导致的校验错误（有一次我发现了一个奇怪的错误，剖开代码发现其中的正则表达式根本不贴边？是何种力量驱使这名程序员写出了它？）；

3.         SQL语句不熟练导致的异常（不对SQL语句有一定的了解是做不了企业级应用的，基础中的基础）；

4.         基础不扎实导致的错误；

5.         缺少问题转换的方法，人为导致问题复杂化从而引起不易修复的错误；

6.         缺乏自测导致的错误（尤为严重的一点）。

 

我们也不幸遇到了技术风险：一个图片预览功能需要调用webService接口，这段代码在tomcat和weblogic10上可以顺利运行，但是客户不巧用到了weblogic9.2。负责此功能的程序员花了大量时间尝试不同的方法，依然没有结果。当我们得到正确结果时又发现修改的范围大到了需要修改整个系统。由于其他人也需要调用这段程序，于是测试人员不断地崔问，我每次都试图转移话题。这是个黑洞问题，没法预测解决问题的时间，或许有一天我们灵感突发解决了它，但是无法预测这一天发生在什么时候。最后，我们改变了设计方案，用古老的共享目录方式暂时解决了这个问题。

版本发布计是重中之重，能否按时并有效地发布直接反应了计划的合理性和程序完成情况。上个项目的版本控制极为混乱，很幸运我们即时吸取了教训（仍然感谢测试组的提醒，否则我一无是处）。从V0.02版开始我编写了详细的版本计划并即时予以更改，在文档中注明了每个版本对应的需求、设计、增加的功能、修正的bug等。这份计划让我对进度有了更好的把握。下图是版本发布统计：

 

Bug的递增是可以预见的，随着功能的增加逐渐递增，在所有功能基本完成时逐渐递减，从V0.07开始主要修改bug。重新打开的bug大幅度减少，较之上个项目有了大幅度提高，下图是重新打开缺陷统计：

 

 

单据模块终于可以提交客户试用，我们可以稍微松一口气。这个项目中有提高也有不足，也让我第一次认真思考自己适合做软件，再次感谢测试组对我的帮助。

最后，我想以一句看了三年但仍未真正理解的话结尾：“软件是一种态度”。