代码被恢复到之前的版本，时间来到了BJ时间上午11点，眼瞅就到了用膳的时间了，可是估计我这午膳是要被搅黄了。国内的项目组立刻开会大家开始审查各自代码看看到底哪出了问题，结果非常庆幸的是大家的代码似乎都没有问题。排除了自己人，那么非常自然的大家都想到了新来的阿三程序猿，难道他开始写代码了么？
　　于是乎大家开始翻看代码的记录，记录显示他确实写了代码了，不过实际上他也不太可能写出什么问题，因为这位老兄写了很多很多的代码，但他们都是注释，说白了就是在代码里加了好多英文的解释，解释别人的代码都干了什么，那么怎么会出问题呢，大家于是建议只把阿三的代码踢出去再测试一下，于是1个小时候，代码在剔除了阿三的几百行注释后真的跑通了，而且简单的测试后没有发现任何问题，所以大家又把目光拉回了阿三的代码，经过仔细的阅读发现阿三的一个多行注释的代码被换行混进了正式的代码里面，导致整个代码崩盘了。那么问题就非常清楚了，这个锅被一脚踢回了大洋彼岸，唐经理不失礼貌的把阿三代码导致整体代码崩盘的问题告到了美国大客户那里，时间来到了BJ时间下午两点。唐经理回完邮件宣布大家一起去吃饭，中午，准确的说是下午，唐经理请大家吃了顿饭，算是弥补大家加班加点审查代码的辛苦工作。唐经理请大家吃饭，主要是代码问题没有出现在中方项目组，否则免不了又要被大洋彼岸的印度人告状。这回把锅题给大洋彼岸，不管结果如何，总不至于被撕咬了。
　　而且这个时间美国人都睡觉去了，大家可以等着明天早上看好戏了。
　　下午五点半，中国项目组准时下班。
　　第二天一大早，我好奇的打开邮件看看战况如何。
　　我想阿三程序猿这回又要大伤元气了吧，至少能消停几个月了，打开邮件我的感觉真是印度人是欧亨利的祖师爷啊，阿三他大哥，就是远在大洋彼岸的印度项目经理，我们索性叫他S吧，项目经理S在邮件中这样总结了这次失败，失败的原因主要是我们项目的自动化测试工作不足导致的，项目应该抓紧提升自动化测试的比例，而且每次有人提交代码都应该运行全部自动化测试用例，从而保证随时提交代码随时测试。所以接下来的时间，中方的项目组应该第一时间完成自动化测试用例的编写工作和自动化测试环境的搭建工作。
　　而且还提到每个程序猿的代码必须有单元测试用例，覆盖度超过98%才能提交。提交代码必须要通过集成测试用例的自动化测试才能提交。经理S在涛涛不绝的论述了中方项目在测试方面的不专业之后，不忘鼓励中方项目再接再厉，为了项目的高质量高效率，严格要求自己，积极主动的学习先进的软件工程知识。
　　可以这么说吧，阿三程序猿的个人失误导致的一次代码上线失败，最后淹没在S经理涛涛不绝的辞藻中，最后完全变成了整个中方项目组的测试流程不专业，不但完美的甩锅，而且合情合理的增加了程序猿的工作量。
　　我只能说他说的一点都没错，这套东西是个程序猿都知道，但是现实的项目中为了效率，有几个程序猿会这样做呢，写一个覆盖率98%的单元测试代码比写出源代码花的时间可能还要多。基本相当于工作量原地翻倍。关键这个事的起因居然是为了给阿三程序猿甩锅！
　　我震惊到了怀疑人生的地步，然而唐经理也表示束手无策，但是坚韧不拔的唐经理最终还是和远在大洋彼岸的经理S撕吧了几个回合，把单元测试的覆盖率砍到了60%。唐经理说单元测试的覆盖度当然越高越好，但前提是我们还要满足项目的时间节点。如果因为单元测试覆盖度过高，影响了最终的项目交付周期，那么谁来承担这个责任？换句话说如果非要保证98%的覆盖度，那么工作量翻倍，是不是要给中方项目组增加人员和经费？经理S当然不愿意承担项目延期的大锅，也没有那个意愿去帮中方申请更多的项目经费，这件事起因本来就是帮他的阿三小弟擦屁股，现在屁股擦的香喷喷的了，这个单元测试的覆盖率本来就不重要，索性就卖了唐经理一个人情，不过经理S还是不忘埋了一个雷，他告诉唐经理为了项目的进度单元测试覆盖率可以暂时保持在60%，但是随着大家单元测试的经验越来越丰富，效率也越来越高，以后应该逐步提高测试覆盖率……
　　看到这个结果我感觉整个人都不好了，大家赶紧收拾收拾写代码，写完代码还得写莫名奇妙的单元测试代码。这一局，完败！