IAGW统计报表的设计

关于周一下班前设计的统计报表，周二听到了不同的声音，有同事提出了新的建议和疑问，这样的讨论，其实应该在设计阶段完成的，在数据库设计review的时候我没有全面考虑清楚应该如何呈现，没有及时提供建议和组织讨论，的确是我做得不好的地方，早上在我回复建议的末尾，很诚恳地向我的同事道歉。虽然现在的讨论有那么一点点晚了，但是late better than never，而且，如果是在上线之后客户才提出来，那么修改的成本就更加大了。

对于需要呈现的数据，在原来的基础上做了调整，也就是将原来在一个流量统计报表中呈现的数据拆分为两个小的流量统计表，这个改动不错，当初在设计的时候我也考虑过这种方案。不过对于数据库表要设计成怎样，与开发负责人存在不一致的看法。开发负责人坚持不修改数据库表结构，而是呈现的时候采取了我的建议。目前不太规范的数据库设计，让我有点担心以后的扩展，我心里在犯愁自己该继续坚持他们重新设计，还是应该接受目前的设计呢？在项目组中，包括项目经理，都倾向于我的设计，也倾向于修改数据库表结构，但是因为模块负责人的坚持不改，在一翻讨论之后，大家都默认接受了现有的数据库设计。

在回去的路上，我仔细思考了很多，发现自己还是过不了自己这一关，不能心安理得地接受目前的设计，我必须要对我所负责测试的产品负责。首先，目前的设计与我们之前制定的设计规范不一致，一个团队中，每个人都有自己的特色，如果大家都不遵循规则，那一个产品的代码和设计风格就五花八门了，对以后的维护和产品的整理架构非常不利。其次，从业务流程上，目前的数据库设计很难理解，既然是业务的统计，那么数据库表的设计也要体现出业务的特征。最后一点，也是最重要的一点，因为目前设计的不规范，导致与之相配合的模块都需要修改，不是说别的模块修改不了或改动量很大，而是说某个新增模块的设计不应该导致成熟的架构也要跟着修改，而这个修改本来就是可以不需要的。

周三的早上，我很早就来到了公司，凭借着我对业务的透彻理解，我将自己的建议和看法重新在邮件中阐述，并发送给相关的开发人员，这是一个非常漫长的讨论过程，因为大家的意见不一致，并且各自有各自充足的理由。后来，我把我的建议由文字转换成完整的数据库表设计描述出来，并且跟旧的进行了对比，项目经理在最后的关头出来说话肯定了我的设计。在大家意见存在严重分歧的情况下，的确需要有一个角色来做最后的定夺，否则这个讨论就得不到更好的解决。感谢项目经理对我的工作的肯定，我在上面花的心血没有白费，最终被采用了，有些合理的东西的确是应该坚持。这就是我们现在这个团队非常好的地方，什么问题都可以拿出来自由讨论，任何问题，都会在这个free talking中得到一个比较满意的解决，只要是合理的建议一般都会被采用，让枯燥的测试变得非常有意思。

                                                                Writtren by smilings on July 26 2006 in Guangzhou