项目总结

 

项目总结

 

财政会计项目在大家的共同努力下圆满的完成了任务。这个项目中我们大家有欢乐、有艰辛……

我很幸运的在项目开发初期便投入工作，随着项目一起成长，学到了很多东西，本文回顾整个项目的历程做一个总结。

 

1.1.需求 

在工作初期，我简单的认为需求只是跟需求文档编写人有关，程序员只需要对照详细设计把功能实现就可以了。然而在实际工作中发现，在人员紧缺的情况下，人员并非像软件工程中所述，呈金字塔型分布，而是呈直线分布，每个开发人员不仅要编写代码，还要参与详细设计和部分需求的修改，在这种情况下就必须对需求有非常充分的了解。

作为程序员，我总是习惯于早早的开始编码，原因很简单，我认为双眼对着文档发直远不如写代码来的有趣。事实给了我很深刻的教训，在项目中期我负责维护老程序员留下的一部分代码，对这部分的业务理解也仅仅是从代码的功能上。这些代码所描述的并非一个复杂的流程，工作流上的图形也清晰地描述了所有过程，用户和第三方经过多次测试也没有对此流程提出认可异议，所以我从未怀疑过程序的正确性并从未看过需求文档。直到项目后期的测试时，测试人员对照需求文档对所有模块进行测试，发现此流程竟然少了一个节点！此刻我才重新打开需求文档，发现工作流的确画错了。于是在时间紧张的日子里我不得不加班修改全国32个省市自治区的工作流模版。

教训是：如果你对需求分析理解的不是很好，那么，停止继续工作，重新返回到需求分析阶段。当然，这样会使人觉得你已经落后了。但是，如果你在开车从沈阳到吉林的途中，发现自己到了北京槐树岭，那么停下车来看一下地图是浪费时间吗？当然不是。因此，如果你发现方向不对，赶紧停下来检查你的方向，并且最好在你准备去旅行时先看好地图。

另外，UML图的使用至关重要，讨论时，把一个简单的图形画出来远比大家大嗓门争论强的多，而且我觉得把那些小人和圆圈的连线复制到需求文档里会使文档看起来更好看并且页码更多。

1.2.设计

套用<<代码大全重>>的一段话：

“程序员处于软件开发食物链的最后一环。结构设计吃掉需求分析；详细设计者以结构设计者为食，而他自己又成为编码者的食物。比较软件食物链和真正的食物链，我们会发现如下事实，在一个正常的生态系统中，海鸥以沙丁鱼为食，沙丁鱼吃鲜鱼，鲜鱼吃水虱，其结果会形成一个正常的食物链。

“在编程工作中，如果软件食物链的每一级都可以吃到健康的食物，其结果是由一群快乐的程序员写出的正确代码。

在一个被污染了的环境中，水虱在受到核沾染的水中游泳，鲫鱼体内积聚了滴滴涕，而沙丁鱼生活的水域又遭受了石油污染，那么，不幸的海鸥由于处在食物链的最后一环，因此，它吃的不仅仅是沙丁鱼体内的石油，还有鲜鱼体内的滴滴涕和水虱体内的核废料。在程序设计中，如果需求定义遭受了污染，那么这又会影响结构设计，而这将最终影响创建活动。这将导致程序员们脾气暴躁而营养不良，同时生产出遭受严重污染而充满缺陷的软件。”

很遗憾，我们的合作伙伴并没有给我们提供一个无污染的绿色设计。今后的工作中，在编码之前我们应该先看看设计是否合理，如果合理，那么它是否能够自如的应付一些需求的变更，这么做虽然比较无趣，但是可以避免在项目中、后期没命的加班，这正像你去超市购买沙丁鱼罐头时要看看保质期一样。

1.3.规范

其实我们有一个很好的规范文档，里面规定了各种界面标签的样式，变量方法的命名规范以及代码的风格等等，如果按照规范去做，那么我们的代码看起来会更像一个团队。真是可惜呀，我们的规范并没有及时更新，更可惜的是，我们直到今天才注意到那个规范文档的重要，我们代码的每一行都印满了个性签名，到处充斥着汉语拼音与英文结合的又臭又长的名字（好像我是最严重的）。

小看规范的直接问题就是到了后期不得不花费大量的时间去做一些毫无技术含量的体力劳动，这无疑是令人沮丧的。一个记忆犹新的实例是关于查询的回显问题，正确的做法是只有点击查询按钮时，查询框中的条件才会随用户输入的改变而改变，统计的结果是整个系统竟有上百个页面需要修改，在时间紧张的日子里我真想花钱顾人帮我完成这个工作。

及时更新规范并通知组内的所有人是性价比极高的事情。

1.4.编码

作为开发人员，最在意的就是编码，这也是相对于需求和设计比较有趣的工作，但是到了项目后期，面对大量的需求变更和测试人员引以为傲的bug清单时，貌似有趣的工作突然撕掉了面具，露出一副狰狞的面孔。

怨谁呢？测试人员吗？肯定不会，那等于说自己写的东西是垃圾。那么怨一下乱改需求的客户吧，这是个发泄的途径，而且屡试不爽。但是静下心来想想吧，客户并不是专家，在系统没有以实实在在的东西展现在眼前之前，他们并不知道系统和澳大利亚袋鼠有什么区别，到底符不符合他们的需求，于是便有了这样的场面：

客户：这个东西不符合我们的工作习惯，实际工作中我们并不是这样做的，需要改一下。

开发人员：我们是严格按照需求做的，如果改动，将会牵扯很多的东西。

客户：但是我们工作不是像系统中这样做的，你们必须改。

那么好吧，为了不和客户闹僵，为了使系统真正符合需求，我们答应了修改，此后，在某天凌晨，我们怨气冲天的抱怨客户，因为那些需要修改的东西确实牵扯了大量的模块，我们震惊的发现，系统的耦合度竟如此之高，为了赶进度而写出的那些上千行的类在此时的缺陷暴露无疑。

这是实实在在发生过的事。

怎么办呢？需求并不会像照赵州桥那样千年长存，根据 IBM 的调查，对于一个典型的有一百万字的需求分析，大约25%的内容在开发过程中要进行变动。我突然明白了算法书上为什么把所有的数据类型和基本方法都提取出来，即使是一个比较操作也要单独写一个方法，这样做可以应对多变的客户程序而不必大肆改动，无论结构是矩阵还是邻接表。

面向对象并不是嘴上说说好听，OOP的思想应该渗透到代码的自里行间。对于一个多次用过的验证，应该考虑把它单独抽取出来，与其重复使用if(age == null && age.empty(“”)) 不如使用isEmpty(age)来的容易。

一个应对需求变更的好方法是重构，及时重构。搭建一个临时窝棚只需要几块木板和几个水泥罐，然而有一天，我突然发现这个临时窝棚达到了数十米高，里面还住满了自以为安全的用户，于是我的衬衫有些湿了，每移动一块木板就可能导致窝棚的坍塌，更严重的是有人因此而丧命。重构吧，在面对新一轮的需求变更之前重构，用钢筋混凝土隔开每一间屋子。

我的结论是：在动手编码之前就设计一个优秀的代码结构，预见可能发生变动的地方，尽量把大多数地方写活，在程序中写死一个代表全国大区的数组queryArea[6]，不如在方法中传递一个代表大区数量的变量，因为我并不知道台湾是否有一天会单独成为一个地区。还有，别忘了重构。

1.5.测试

测试的重要性不用多说了，在提交测试组之前我至少应该检查一下错字，因为“事物所”而增加了一个bug是不值得的。

1.6.技术

总结了一些关于技术经验，有些解决了，有些没有得到很好的解决办法：

1)        功能操作完成后，鼠标右键点击所在页面，选择弹出菜单的刷新功能，容易出现重复提交问题；功能操作完成后，通过浏览器的后退键进行重复操作，容易出现重复提交问题；某功能键反应时间延迟时，在短时间内重复点击该功能键，容易出现重复提交问题；某些用户习惯双击按钮，某些用户错误地点了两次按钮，某些鼠标出现故障，导致单击变成双击，结果发生重复提交。如果不加限制，这些请求都会被服务器处理，从而导致错误的结果

2)        校验问题，同时实现客户端和服务器端校验。

3)        如何在两个操作之间传递大量数据，尤其是非存储的动态数据，如何快速传递。

4)        加入时间戳避免浏览器缓存问题。

5)        怎样把特殊参数在不提交页面的情况下传递到模态对话框。

6)        怎样有效处理百万级的数据查询。

7)        在页面使用标签做类似比较的操作时，避免比较值使用中文。

8)        在处理分组的sql时一定要加入order by。

9)        如何提高开发效率。

1.7.沟通与团队合作

沟通作用不必多说了，围成一圈讨论处罚功能否应该加入对非执业会员的处罚，不如打个电话问问客户来的容易；遇到疑难问题问问身边的人是否已经有了解决方法也远比在百度上漫无边际的搜索来的快捷。我突然发现当木匠的老爹是最懂得沟通的，干活时一些环节必须要雇主在旁边才行，他通常提出多种设计方案让雇主选择，最终敲定后还会提出多种建议。降低床的高度很容易，但是要增加床的宽度呢？

对于团队合作，就一句话：太重要了！如果不信，打电话问问齐达内好了。

 

1.8.结束语

财政会计项目在大家的共同努力下完成了任务，学到的经验将会另我终身受益，尽管这些经验在IT技术的阳光中如同指尖淡淡的温度一样微弱，但正是这微弱的温度让我化开车窗上的寒霜，透过小小的圆圈看到外面广阔的世界。

 

 

 

2006-12-5

 

幽弓