开发人员做代码变动需要得到批准

开发人员做代码变动需要得到批准

从理论上来讲，开发和测试是平等的，这个大家也都能接受，只有平等才能进行有效监督嘛。可是，“泥巴怎么捏”的权利在开发人员手里，他在大家都不知情的情况下对代码做改动，你能怎么样?还能找他打-一架?

在项目后期，不管开发人员出于好意还是出于对技术或者完美性的追求所做的代码变动，实际上都是项目的一个风险。很有可能他的改动中包含错误，也有可能他的改动会对其他模块带来不利影响，他不可能考虑得那么全面，所以，我们需要控制这种改动。从配置管理的角度来说，对变更的控制是项目的一个关键。项目必须在控制之中，而不能被某一个开发人员的“心血来潮”拖入泥潭。

微软这方面做得很好。到了项目后期，每一个代码的变动都需要经过评审小组的批准，没有得到批准而对代码做变动会被公开批评。在一个专业的小组中，被公开批评是一个很大的负面评价。这个评审小组的成员包括开发组长、测试组长、需求组长等人，他们每天开会来决定当前有哪些变动可以被批准。所以，你会看到，开发人员会小心地陈述理由以争取变动获得批准，他们的“随意修改”的权利已经被剥夺了。有的时候，当的确是因为编程.上的错误导致了一个软件错误时，开发人员想修正自己的错误，在争取批准的时候就会比较着急，生怕得不到批准。

这个制度巩固了开发和测试的平等关系，避免了产品质量的动荡，值得学习。

认真考虑用户的真实使用场景

我在项目组内的工作之一就是测试Toast，我是这个功能的Owner（负责人）。当你使用MSN的时候，你的朋友发消息给你，你会在屏幕的右下方看到一个小窗口，这就是Toast。我们的产品虽然不是MSN，但是是类似产品。

Toast虽小，可是我不敢含糊。从Toast的种类、触发条件、·显示内容、UI效果等出发，我编写了多个测试用例。几轮测试下来，自我感觉还不错。

可是在测试后期Beta用户报告的一个问题却让我有些惭愧,这个问题是这样的，的确，每次有联系人登录或者收到次对话的第条消息的时候，用户都希望看到Toast，这样用户能得到明确的提示。但是，从另外-个方面来讲，用户也不希望当前的.L