回顾超强加班的一周

2007年4月9日 星期一 08时54分

按上次会议的安排，周一应该把系统交给客户试运行了。周五和客户讨论后的得到结果是周一演示给使用系统的各个部门看，然后各个部门提需求。看起来比试运行的压力小一点。不过为了这个演示也依然加班了一周。
为什么每个项目都是到后期紧的要死？现在觉得主要还是前期太放松了。
项目开始后把开发任务分成三块：流程、页面，计分模型，etl。这样做倒是很正确，但是现在看来这么分配是不平衡的，但是对于刚开始开发来说也难以准确的估计。现在来看流程页面模块需要做的事情最多，细节的东西也最多，需要测试的地方也最多。etl模块负责提供数据，任务应该是最紧迫的，因为如果没有真实的数据，计分模块很难测试。计分模型因为使用了以前项目从来没有用过的jboss rules，可能会发生无法预料的问题，应该及早尽可能多的测试。
针对三个模块不同的特点，项目都没有采用适当的措施来避免问题。
计分模型是我设计开发的，采用了jboss rules，但是以前项目从来没有使用过，也不知道会有什么问题，其实需要在真是环境中好好测试他，但是一直苦于没有数据测试。手工写了几笔记录草草测试之后我也觉得这个模块完成的差不多了。后面被客户召唤去修改维护他们的旧系统也分了不少心，也就没有详细追究问题了，基本完工之后自己也一直处于一种放松状态，完全没有紧迫感，因为根本没有明确要做的任务安排。到4月15日etl模块终于把数据导入进去之后，一运行这个评分规则引擎才知道有些不妙。运行效率非常糟糕，直到现在还没有时间去解决这个问题。
流程和页面模块交给david开发后，完全由他一个人在开发，开发进度也只是口头确认，没有通过实际运行系统或者check代码来确认开发的进度和质量。直到开发团队杀到客户这边来才开始测试，这个时候为时已晚了，N多NullPointException搞得挺郁闷，流程也和需求有些差异，特别是有一个流程根本没有开发，流程的细节也经不起推敲，有些边角的逻辑判断根本没有。造成这个局面就是因为没有确认，只是口头上问问做完了没有，然后开发人员随口回答：差不多了。
etl，应该在最早完成工作，却在最后才交出一个根本没有测试过的alpha代码。4月15日，hy才把数据导入到应用表中，当天晚上还发现有N个字段有空格，比如卡号。随后加班，搞到很晚终于把空格削除，现在看来，削除空格的工作仅仅是用trim之后忽悠动作。前几天经过一行行代码的核对后才发现有一个存储过程运行非常慢，但是他交给我的时候是很洒脱的把那段注释掉了，导致账户表只有一个月的数据。另外还有可疑交易、准贷记卡欠款次数几个指标根本没有计算，月薪指标也完全是0，额度使用率、年剔除消费累计等等指标计算都有问题。一句话总结：就是一个烂摊子。真是让我很气愤。做为交接，没有告诉我存在哪些问题需要我去处理，没有告诉我解决了哪些问题。前者比较重要，比如明确告诉我可疑交易指标没有计算，我就会有针对性去解决这个问题。
关于交接，自己也犯了大错，没有及早地把代码拿过来去写些sql测试，虽然sql没有单元测试，不过拿些数据去测试不难的，虽然靠手工核对，但是感觉直观性比junit也不差太多。一直对交给自己的代码保有相信的态度，及早的怀疑就不会导致自己得把所有代码接手下来。
留下几点教训就是：
[b]1.使用jira安排好任务，保持所有开发人员的适当紧迫感
2.至少要运行声称完成的系统，下一个项目完全可测试显得很有必要。
3.如果有交接，及早的交流，及时去测试，必须留下一份问题清单。[/b]


当然经过这一周的加班发现激励团队的成员一起奋战很重要，这周多亏david和我一样积极去解决各种bug，对客户提出的各种修改丝毫没有抵触情绪。
[b]关于激励，很重要的一点就是给开发人员适当的挑战，让他们做一些不同平常工作的事情。[/b] 周一的演示就是安排david去讲的，面对的是客户各个部门的领导，所以他在准备演示前干劲特足，主动在周末呆在家中拼命测试自己的模块，这和他以前的风格大不相同啊。因为他是一个NullPointException大户。 :D