把不愿写文档的程序员赶出你的团队

最近碰到一个很狗血的事情，也让我颇为抑郁了一番。经我手开发的一个银联卡支付项目，系统运维阶段集中爆发了一些问题。虽然最终都得到了解决，但是反思问题的出现及深层次的原因，对于项目管理的技巧和团队规则的建立有了更深层此的感触。暴发出来的问题主要包括以下几个：

1.本行卡境外交易失败。

2.本行卡境外交易部分国家失败：有的国家成功，有的国家失败。

3.境外卡行内交易失败。

4.他代本交易，非规范报文数据库表插入出现错误。

5.预授权交易处理失败。

　　由于该项目是一个移植项目，大部分源程序来源于公司另外的一个项目，按照XX以及XXXX的说法，配置上就能用，说的好是轻松，就好像3天就可以上线，五天就可以完活似得。而我也竟然放松了警惕，轻信了这些说法，结果可想而知。

第一、项目没有文档：扔过来一个文件包，包括代码、定制、数据库表一团。这就是所有，你自己看吧，鬼知道我该拿这些东东做个球用啊。对比，用对工具对比，自己去找差异，看来我真有病，谁有药呢？

第二、变更没有说明：

　　核心变了，没有记录；前置变了，也没有记录。处理到用户认证和预授权类交易时，悲剧了，核心返回的错误码，不符合银联的规范，每次报文送上去，都会被拒。没办法，拿着银联规范一个个核对，最后发现核心使用的错误码时2.0版本，验证规则是2.0版本。拿着规则找核心的人去理论，核心不敢改，告诉我：XX地就是这么处理的，这里也该这么处理，肯定没问题。我的亲娘四舅奶奶，到底是业务决定设计还是经验决定设计呢。没辙啊，纠结啊。后来找所谓的XX地要了最新版本，才发现，对方早已经变更过了，而我们还不知道。更悲剧的事情还要，不过我不能说。耶稣啊。谁来拯救你呢！

第三、Bug没有记录

　　前人种树,后人乘凉。Bug管理系统的核心价值就在于此，可惜悲剧的是，前人种树，种完了又挖走了，就留下一个树坑，我还要从头开始种。上述本行卡境外交易失败的原因就在于缺少了一个国别代码域，悲催啊。境内交易一切OK，境外交易，直接Over。对比啊，测试啊，终于找到问题所在，用户脸也开始绿了。

第四、未经测试即发布

　　未经测试的程序，直接发布，你敢吗？不管你敢不敢，反正我是不敢，可是不敢的我却这么做了。然后，挂了，然后再来。不是哥不想测试，是没环境，没有加密机，很狗血的一个理由吧，我感觉也是，别告诉我用仿真，别告诉我绕过去，可能是我真的很笨。强势的用户，无理的要求，被践踏的流程。见过胆子肥的，没见过这么肥的。耶稣啊，你先在坑里呆着吧！