转:乱想1/2

项目在launch的前一小时发现了Bug！

嗯，活见鬼了。但是事实摆在眼前，并且不止一次。实事求是地说，谁也不可能保证项目100%没有bug，但是，在项目发布前后的这一当口发现bug 绝对是不正常的，这说明之前的测试环节有严重的问题。在我为时并不算长的几年项目经验中，这种现象时常出现，并且频率有变高的趋势。为什么？这里我想总结 一个典型但不完整的原因列表和大家共勉：

1、开发环境、测试环境和生产环境的不一致。

在《程序员修炼之道》中，作者特别就这一条做了详尽的讨论，字字都是血的教训，而我在比较了供职过的两个team的经验之后对此也有深刻的体会。之 前供职的A公司是一家日企（我反感日企的工作氛围，但是佩服日企对工作的态度），有专门的系统团队负责建设和维护项目的测试环境和生产环境，对他们的要求 是：在这两种环境中，从操作系统的内核到服务器上安装的应用软件，其版本和配置都必须保持严格的一致，并且有详尽的文档记录服务器上软件版本的每一次更 新。所以开发人员和测试人员都对通过测试的项目很放心，因为不管在哪种环境下，程序的行为表现都是高度一致的。至于开发环境，程序员完全主动的向测试环境 靠拢并保持一致，因为大家都明白环境差异的最小化会使项目质量变高，继而他们自己的日子也好过得多。而现在供职的项目在这一点上做得较差，生产环境用的是 CentOS4，测试环境用的是一个老版本的Fedora，PHP和Mysql的版本也不一样，我清楚的记得有一次项目发布到生产服务器上后马上就地瘫 痪，在线苦苦调试了一个多小时没能找到原因，无奈被迫下线，事后又经过两个小时的排查，发现是因为PHP版本差异造成Json函数的行为不同。事后我在邮 件中总结了问题原因并提请系统管理员注意，管理员先生很诚恳的跟我解释说他早就意识到了这个风险并且也有同步两个环境的打算，但是经过和高层的沟通后他们 决定半年后再动手（还记得那个关于把箱子从IBM一楼搬到六楼的故事么，那是真事儿），现在，一年半过去了，毛都没同步过…… 而就在几个小时前，最新的一次release再次因为配置差异造成了30分钟停顿。

2、开发环境、测试环境的代码被污染。

之前（大概也就两个月之前吧），项目的所有成员还都是在主干上进行开发的，想象一下，5个程序员同时在主干上开发10个功能，代码互相缠绕在一起， 在开发过程中就开始互相污染了，其中更不乏有的developer有意无意的将未测试的代码提交进cvs，继而影响其他人的开发工作。而如果其中一个功能 因为某种原因被从release列表中拿掉的话，剩余的九个功能也因为频繁的交错commit而与之错骨连筋、无法划清界限。后来经过讨论，我们使用了每 个task一个分支的做法。这种方法保证了程序员各自工作在干净的working copy上，提交的代码也不会受其他程序员的影响——至少在代码合并、集成测试之前不受别人的影响，而且发布时的可选择性也变大了，没通过测试或者有问题 的task可以不合并到主干上，主干上保存的永远是稳定的、生产用的代码。

测试环境的代码污染问题稍微复杂一点。当使用cvs update -j对代码进行合并的时候，出现冲突是很常见的一件事。这个时候程序员会手工解决冲突，这里就隐藏着潜在的污染威胁——如果不了解其他人的代码逻辑，合并 就可能出错，更要命的是，有些程序员直接就会在集成测试环境上进行调试！各种echo、printr、var_dump、die，最后调试虽然可能成功 了，但是代码已经面目全非！根本没法指望他们能把集成测试的代码恢复原样，因为根本记不清debug过多少个地方，也不知道当前测试的代码是从哪些个 branch上merge进来的。退一步讲，就算他们什么都知道，人多手杂，你敢保证一点错误都没有么？很少有程序员真正了解别人的代码逻辑，也没道理要 求他们去这样做。所以合并代码不应该是程序员做的事儿，集成测试环境更不应该让程序员染指。要像保护生产环境一样保护测试环境！那么如果有的程序员就是怀 疑集成测试的代码出现了“灵异现象”，需要调试以检查错误怎么办？很简单，把集成测试的代码copy给他们一份，或者干脆为每个程序员在测试服务器上建立 一个集成调试环境，让他们在里面爱怎么折腾怎么折腾吧，绝对不会影响其他人，更不会干扰正常测试。

同样的问题也会出现在测试用的数据上。如果测试所用的数据库是被各个instance共享的，同样会造成“灵异事件”，有的程序员会抱怨说“数据不知被谁改了，乱七八糟的根本没法调试！”那么好，给每个人制作一个干净的数据拷贝，让他们自己维护，防止别人染指。

3、不完善的分工和不严格的实践。

还是那句话，测试能保证100%的覆盖率么？或许unit test可以，但是即使单元测试全部通过，没不能说明程序是完全按照客户的需求在工作。很可能代码逻辑没问题，但是客户要的是A，程序却在干着B，也就是 说业务逻辑上有问题。这就需要test case的制作要既详细又严格，当然，对需求的正确理解也是一个前提。你没办法完全保证程序员完全理解了需求，但是你可以保证test case跟solution文档的一致！不然要solution干嘛？好，现在权责分明了：

1、正确的理解需求是BA或者PM的责任

2、正确的提供solution是Tech leader或者架构师的责任

3、正确的实现solution是Developer的责任

4、正确的编写和测试test case的是测试人员的责任

如果每个角色都能严格的履行职责，那么项目的可靠性就会很高，不要以人手不够或时间有限做借口来干扰分工，一个人身兼数职也不是问题，问题是，每一 项工作都要认真的分配、可靠的完成，如果dead line确实很紧，那么，宁可牺牲功能，也不要牺牲质量。“不要允许破窗户的出现”，这一原则不仅适用于程序代码，也适用于项目管理，“破窗户”是会传染 的，一个步骤的疏忽或者不负责任，带来的可能是整个team的心烦意乱、步调不统一，对项目的影响也可能像蝴蝶效应一样难以估量。

所谓宽容与理解。

对工作的严格不等于对人的严厉。我就不喜欢别人对我很严厉，在A公司供职的时候那个PM就很严厉，尽管我非常敬佩他对工作的严格要求，但仍不免反 感。不要用教官对待新兵蛋子的态度对待同事或者下属。把解决问题的方法上升到制度层面，而不要降低到员工的自身修养或者素质层面，这是区分好 Manager和差Manager的一个标准，（插播一下，我觉得我党之所以把国家治理成这个鸟样，就是因为法制不足，人治有余）你怎么知道下一个招进来 是什么样的员工？你打算把每个员工都修理成你觉得满意的样子？对team成员的个性和习惯宽容，对制度的执行认真并严格。当然，我也不想因为对制度的严格 遵守而被别人误解为对人的严厉。没人喜欢矛盾，但是矛盾不会因为大家讨厌就不出现，任何时候，开放的讨论是最好的解决方式，抱怨和责备解决不了问题。但是 如果你不小心触犯了“天条”，给别人造成了麻烦，眼睁睁看着人家给你擦屁股的时候，适当的表现一下愧疚吧，毕竟大家都是成年人，是吧……

 

转自 http://www.fidy.net/?p=198