怎么样能让程序员少写BUG

编辑导语：作为一名产品经理，除了要关注你的产品需求和用户需求，还要参与到每一个步骤里；比如开发测试，参与到其中，才能更好的做到结合，完成项目的开发。本文作者介绍了在程序员写代码时如何避免出错。

有没有觉得，有时候程序员哥哥的脑回路不同凡响，能自己想出一套逻辑，甚至写一些让你哭笑不得的BUG。

那有没有思考过，怎么样让他们少些BUG呢？

其实，我为此是操碎了心，在公司之前各方面都不不成熟，且没有测试人员的时候，我是兼任测试的。

我在测试的时候，主要有以下三个问题。

1. 我们以为达成共识的公共组件，开发哥哥们很容易因为文档需求没有明确说明而进行自己新的一套东西；还美其名曰：我比你们产品想的多，我让我们系统更加完美。但其实是他们美好的yy，很多东西的实现效果让你觉得很反人类。
2. 需求理解不一致，未真正达成共识，各自在各自的频道，天马行空；你以为你跟他说清楚了，他以为自己理解了，实际上就是鸡同鸭讲，谁也没理解谁，最后导致开发出来的东西，用户根本不能用。
3. 粗心大意，考虑不全面，写出了真正的BUG；这类BUG要么很明显，要么就**藏得很深。

这三个问题，在我经历了许多项目开发后发现，其实是能够通过完善的文档和充足的软件设计去避免的。

第一个问题，其实不止是组件，还有很多文档中并不明确的东西，这些都是能够通过我们详细需求文档描述或者详细的原型设计去避免；如果是通用的东西，我们可以形成一套通用的规范说明，或者让开发形成一套公共功能库，通用或者公共的东西，不需要每次都单独写，只要按规范去做就好。

第二个问题，我们可以让书面的描述，落成更直观的逻辑图、流程图或是直接举例的数据计算过程，让程序员哥哥们可以多角度深刻的去理解；这样做，不仅可以让繁琐复杂的文字表述文档变成更通俗易懂的图形和数据，还可以检查需求和逻辑的完整性。

也就是说这两个问题，其实我们都可以通过详细的软件设计和规范的开发流程，尽量去避免。

那么第三个问题呢？

第三个问题，则要从测试上入手。

在《人月神话》一书中，曾提到过“易除BUG 的设计”。

这所谓的“易除BUG 的设计”其实是通过三块内容：测试规格说明、自下而上的设计和结构化编程。

一、测试规格说明

在编写代码之前提交测试规格说明，也就是我们常说的测试用例；以详细的检查和说明的完整性和明确性的文档，并组织项目组全体成员进行测试用例评审，以达到项目需求的真正共识。

这个过程中，也是对需求文档和原型的检查，其中不免**对原需求文档和原型进行进一步的需求细化和存疑点的修改。

这一点非常考验测试用例编写人员对业务理解的能力和逆向思维能力，测试想要覆盖全面，则需要深刻理解业务需求，且能对异常操作场景进行细化设计；数据类的测试，还需要数据用例去验证逻辑。

因此，测试人员编写测试用例只是第一步，想要测试用例覆盖全面，做到大家真正达成共识，则需要大家群策群力，一起去完善；这一过程，可能是系统开发正确最关键的一步。

二、自下而上的设计

将系统开发分为体系结构设计、设计实现和物理编码实现，即精化步骤、细化任务。

这一点，其实就是在开发上入手，让系统开发分步设计，这样做，则有以下优点：

• 清晰的结构和表达方式，更容易对需求和模块功能进行精确的描述；
• 模块分割和模块独立性，则避免系统级的BUG；
• 细节的抑制使结构上的缺陷更加容易识别；
• 设计在每个精化步骤上都是可以测试的，所以测试可以尽早开始，并且每个步骤的重点乐于放在合适的级别上。

三、结构化编程

将系统分为单元调试和集成调试。将相同的组件们作为某个单元，可以减少重复工作，也能控制变更；这样不仅能够方便测试，也可以阶段化的迭代。

四、总结

软件的开发是所有参与人员共同朝着一个目标前进，每一个人都在为项目辛勤付出，都希望项目做到有结果，所以每个人都要为项目的质量、结果进行负责。

过程中大家要各司其职，也要互相帮助，尽量避免走歪路和出错。

我们都要对整个软件开发过程负责，因此，我们产品经理不仅仅只是把需求做得完美，还要协助开发测试，更好的完成项目开发目标，达成真正可用的系统。

本文由 @阿虚 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 unsplash，基于 CC0 协议