业务开发做到零 bug 有多难？

大家好，我是树哥，好久不见啦。

作为一个工作了 10 多年的开发，写业务代码总是写了不少的。但你想过做到零 bug 吗？我可是想过的，毕竟我还是有点追求的。不然每天都是浑浑噩噩地过，多没意思啊。

大概在一年多前，我给自己立下一个目标 —— 尽量将自己经手的业务需求做到零 bug。不试不知道，一试吓一跳，原来零 bug 还真的还不容易。今天，树哥就跟大家分享关于「业务开发零 bug」的一些思考。

要做到业务开发零 bug，其实挺难的。这涉及到非常多方面，有些方面可能还不只是你能控制的，例如：产品 PRD 详尽程度，产研组织的稳定性等等。经过一段时间的思考与摸索，我自己总结出一些影响因素，分别是：

产品需求文档的清晰程度
需求的复杂程度
开发人员的细心程度
开发人员是否详细自测过
开发人员对项目的熟悉程度
开发人员开发时间是否充足

针对上面说到的影响因素，我们一个个详细聊聊。

需求文档清晰程度

对于研发、测试人员来说，他们获取信息的源头就是产品的 PRD 文档。因此，需求文档是否写得清晰、明确，就显得非常重要。

如果产品自己对功能都不了解，那么输出的需求文档肯定「缺斤少两」，到时候就是边开发边补充需求，甚至是在测试过程中补充需求。遇到这种情况，想要做到零 bug 真的非常难。

因此，清晰明确的需求文档，是我们实现业务开发零 bug 的重要前提。如果这个前提保证不了，那要做到零 bug 真的很难。毕竟想做成啥样都不知道，程序员又不是神仙，咋能猜出你想要什么。但这块内容，更多是对于产品人员专业能力的要求，开发人员无法控制。

在一些公司，会再需求评审之前先对需求文档进行一次初审，筛除那些有明显重大问题的需求，这样可以减少一部分劣质需求。

但初审的作用还是有限的，它没办法对功能的细节做较多的判断。很多时候恰恰就是一些功能细节的缺失，导致了一些 bug 的诞生。

需求的复杂程度

需求的复杂程度，对于实现业务开发零 bug 也有很大的影响。举个简单地例子：一个改文案的需求，和一个完全重新做的功能。

这样的两个需求，其复杂程度差别很大，肯定是改文案的需求实现业务开发零 bug 的难度低很多。对于一个完全重新做的功能，要做到完全零 bug，对于开发人员的要求非常高。

对于越复杂的项目，零 bug 的可能性就越低。因此，很多项目为了追求产出功能的高质量，会采用将功能点拆得非常细的方式，来减少单个需求的复杂度。

笔者公司在去年做过这个尝试，确实是可以较大地提高产出功能的质量。

细心程度

前面说到需求文档的清晰程度很重要，这取决于产品人员对于业务的理解程度，以及对于对于功能的熟悉程度。开发人员的细心，就像是一个质检关卡一样，在开发之前就对产品的需求内容进行详尽的思考与提问。

对于粗心的开发人员来说，其可能不看需求文档就直接参加需求评审，等到开发的时候边写代码边看需求文档，其写得代码也是一边熟悉需求一边改。这样写出来的系统功能是比较差的，没有一个统一、全局的设计与思考，很容易在细节处发生问题。

一个细心的开发人员，其会在评审之前就详细阅读需求文档，甚至会前前后后翻阅好几次。他甚至会逐字逐句地阅读，弄懂每个文字、句子的意思，甚至有时候会让你觉得他是在玩文字游戏（但不得不说，确实有必要细致一些）。

最后会联系上下文思考功能的合理性。如果发现一些不合理的地方，他会积极与产品沟通反馈，以确保其对于需求的理解，与产品经理对于需求的理解是一致的。

通过对比，我们知道细心的开发人员对于产品经理来说，是一个莫大的帮助，可以帮助他查漏补缺，让其对于功能的考虑更加细致、严谨。

这里的开发人员不仅仅指的是后端开发人员，也包括前端开发、移动端开发，他们都会从不同角度提出问题。

对于后端开发人员来说，他们可能会提出性能问题。对于前端开发以及移动端开发同学，他们可能会提出交互问题、样式统一等问题。

简单地说，细心的开发人员可以弥补需求文档的缺陷，从而让大家对于需求的理解更趋于一致，从而减少 bug 的发生。因此，开发人员的细心程度也是决定业务开发能否实现零 bug 的关键因素！

是否详细自测过

即使写过 10 多年代码的开发人员，刷 Leetcode 也不敢说 bug free 一把过，对于更加复杂的业务代码更是如此。因此，要做到业务开发零 bug，其中一个很重要的操作便是 —— 自测。

自测可以帮你再次检查可能出现的问题，从而提高零 bug 的概率。对于我而言，我习惯性在自测的时候再次对照一遍需求文档，从而避免自己遗漏一些功能的细节点。

对于自测而言，业界有很多种自测方法，包括：单测、集成测试、功能测试。一般情况，建议自己选择适合自己的自测方法。

很多时候，功能测试是相对来说性价比较高的方式。除此之外，自测的详细程度也根据实际情况有所不同，例如有些人只会测试正常情况，但有些老手会测试一些边界情况、异常情况。

毫无疑问，你越能像测试人员一样测试，你的提测质量肯定就越高，bug 当然也就越少。

对项目的熟悉程度

这里说的项目熟悉程度，既指技术层面的熟悉程度，也指业务功能层面的熟悉程度。

技术层面的熟悉程度，指的是项目之间是用什么技术栈搭建的，你对这些技术是否都熟悉。举个很简单的例子，项目中采用了微服务的方式进行调用，那么你是否清楚是什么微服务调用？

如果采用了 ElasticSearch 进行搜索，那么你是否对 ElasticSearch 有一些了解，知道一些基本使用及最佳实践？等等。

这些算是技术层面的熟悉程度，你对这些越熟悉，你在技术层面发生问题的可能性就越小。

业务功能层面的熟悉程度，指的是你对项目其他模块的业务是否熟悉。例如你经常负责 A 模块的功能，你对 A 模块肯定很熟悉。

但下个迭代你就要去做 B 迭代的需求了，这时候你肯定不是很熟，相对来说出错的可能性就更大一些。

无论是技术层面，还是业务层面的熟悉程度，都会随着你做了更多的需求，变得更加熟悉。到了后面某个阶段，你基本上就不存在踩坑的问题了，也为你业务开发零 bug 奠定了基础。如果你是一个刚刚进入公司的新手，那么做到零 bug 还是很难的。

开发时间是否充足

开发时间是否充足，决定了你是否有充足的时间去熟悉需求，去和产品经理确定细节。有了充足的时间，你也才能有一定时间去进行更详细的自测。更为关键的一点，有充足的时间，你写代码才能写得更好。因此，开发时间是否充足是很重要的。

在实际的开发过程中，会因为各种各样的原因，其实并没有办法给你留出特别理想的开发时间。这时候该怎么办？有些人选择接受，去压缩自己的时间。

有些人则会选择去沟通，或者协调资源，保证自己有充足的时间。其实，正确的做法还是第二种，这样会更好一些。

这需要开发人员有更强的综合能力（沟通、协调能力），但并不是每个开发人员都具备的。关于这点，又是可以聊的一个话题 —— 当你的需求被压缩工时的时候，你应该怎么做？这里暂不展开，后续有时间可以聊聊。

简单来说，开发时间是基础，没有合理、充足的时间保障的话，要做到业务开发零 bug 是不可能的事情。

总结

要做到业务开发零 bug，其实就是要消除功能开发过程中的所有不确定性，包括：需求功能的不确定性、自己写错代码的不确定性等等。而发生这些不确定性的地方，可能就有：

产品需求文档的清晰程度
需求的复杂程度
开发人员的细心程度
开发人员是否详细自测过
开发人员对项目的熟悉程度
开发人员开发时间是否充足

除了上面说到的 6 个影响业务开发零 bug 的因素之外，肯定还有其他影响因素。

你能想到什么影响业务开发零 bug 的因素吗？欢迎在评论区留言与大家分享。

好了，今天的分享就到此为止，希望大家都能做到业务开发零 bug，业务开发代码一把过！

如果你觉得今天的文章对你有帮助，欢迎点赞转发评论，你的转发对于我很重要，感谢大家！