偷懒的代价

在正式测试之前，给开发制定各种模板和规范的时候，曾经想过给开发制定一份统计规范，但最终因为那段时间事情太多，偷懒少写了一份统计规范文档，抱着侥幸的心理以为这本身应该是开发的设计工作，他们在实现功能之前应该会自己先编写一份规范或在头脑里形成一个清晰的思路。

可是，在IAGW-M部分的代码提交统计部分的测试时，发现统计的实现比较乱，很多功能的统计或错误或不合理，给开发报bug之后，同一个问题反反复复修改了好几次， 而问题的修改也没有在类似的流程中进行更正，或者是问题的修改又引进了新的问题。结果，在测试的时候感觉很郁闷，原计划打算使用2天的时间进行的统计测试，却用了4天，多了一倍的时间，而且开发他自己也修改得很烦。

造成这样的结果，因为没有明确的规范，开发实现代码的质量就看他个人的责任心和对业务的理解程度了，这就变成了一种不可控的行为了。在我们的team，目前的管理、设计还没有形成一个规范的过程，本来，这些东西，本身应该在设计阶段由项目经理做好的工作，但是一直以来都是一项空白，虽然这样给开发人员和测试人员提供了一个非常大的自由发挥空间，但是，如果开发或测试的水平不够或责任心不强，那产品的质量就难以保证了。

不过，作为开发个体，在代码实现之前，应该自己对如何实现统计有一个清晰的思路，这是每个开发人员应该具备的素质。就正如，测试在测试的之前，会首先设计测试案例，每个功能应该如何实现，测试点是什么检查结果该怎样，自己的脑子非常清楚；在测试的时候，发现某种业务流程会出现某些问题，很自然也会去检查类似的业务流程是否存在类似的问题。我想，作为开发，在代码的实现之前，应该通盘考虑，每个动作或业务该会怎样处理该产生怎样的结果；在修改一个bug的时候，也应该自己动脑思考，这样的问题是否也存在于别的业务流程，这个修改是否会引进新的问题；对问题修改之后，自己应该先验证是否已经把问题给解决了，而不是把代码修改完没经过任何的测试验证就扔给测试。开发实现代码之后不经过全面的单元测试就提交，bug修复只是简单地修改就完事，当然，对于开发来说，会相对比较轻松省事，但是对于测试来说无疑增加了很多工作量，对于整个项目来说成本肯定是增加了。这些，我一直跟开发强调，但是，因为没有形成制度，执行的力度很弱，执行的结果也完全取决于开发的责任心和自觉性。

该如何去改进，怎样可以让大家不觉烦琐的前提下保质保量，怎样可以避免一些本应该及早发现的问题，怎样可以消除一些本不应该出现的问题，我想，确实是值得管理层甚至是团队中每个人好好地去思考了。