大家好，我是树哥，好久不见啦。
作为一个工作了 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 的因素之外，肯定还有其他影响因素。
