我在文章《 TiDB in 2023 - 一次简单的回顾 》 中提到了一个我一直以来面临的问题：每次 TiDB 发布新版本后，我如何能够非常自信地告诉客户，这个版本的质量很好，大家可以放心使用呢？

坦白地说， 这个问题并不容易回答 。 我计划通过一系列文章来分享我对产品质量的思考，这是其中的第一篇，主要讲讲我对质量的基本理解。

需要说明的是，这些都是我个人的理解，并不绝对正确。我会不断吸收和更新迭代自己对质量的认知。另外，我提到的产品主要是 TiDB 等基础架构软件产品，不一定适用于其他产品。

高质量的产品是用出来的

『高质量的产品是用出来的』，其实这句话还有后半句，完整来说就是『高质量的产品是用出来的，而不仅仅只是测出来的』。 这是我近年来的一个深刻认识。一开始就提出这样的观点，可能会让人觉得我在为无法直接发布高质量产品找借口，甚至会让用户产生不必要的焦虑，觉得自己会被当成小白鼠来测试产品。

为什么我会有这样的认知，可以看下面这幅因果回路图：

关于因果回路图，我后面会写文章专门介绍，大家也可以先看看 Wiki - Causal loop diagram

以上是一个增强回路，我们从 Quality Product 这个点开始，整体的回路逻辑如下：

● 当我们有一个高质量的产品时，我们就 会获得更多客户。 具体的 客户获取 可以通过销售努力、客户自我推荐、 品 牌传播等方式 ，这里我们不做 详细 讨论。

● 当我们有更多的客户之后，产品就会面临更多的业务场景，承接更多的负载。

● 更多的业务场景、负载，更容易突破产品的边界能力，从而让我们发现更多的 Bug 和缺陷。

● 我们就会投入更多的努力去修复这些质量问题， 从而提高产品质量。 而产品质量的提高将进一步吸引更多客户。

我在上面的回路图中是 从 "Quality Product" 这个点开始讨论，这也意味着我们需要有一个质量还不错的产品。 如果我们的产品质量不行，由于这是一个增强回路，我们将会失去更多客户，同时也无法 继 续 打磨产品

那么，如何发布一个质量还不错的产品呢？其中一个重要工作是测试，因此测试非常关键。但我们需要清醒地认识到，测试只是我们对客户业务系统的一种抽象，是我们自己对于我们自己产品系统能力的理解。而我们自己的认知是不可能覆盖到真实世界所有情况的，所以我们也需要在各种各样的现实场景中打磨我们的产品，让产品质量变得越来越好。

这里在回应一下上面『小白鼠』的观点，我认为，不仅 TiDB，市场上大多数软件产品都是如此。我们通常会先找一部分样板客户去打磨产品，打磨好之后才会推广到更多的客户。而更多客户的使用也将帮助我们发现更多问题，从而继续完善产品。这其实也符合前面的因果回路图 。

更多的功能，更多的 bug

继续上面的因果回路，我们可以扩展另一个增强回路。当我们承接了客户更多的场景和负载之后，客户对我们提出了更多的要求，也就是会给我们提更多的功能需求。在这种情况下，我们就需要投入到新功能的开发当中。 新 功能做的越多 ，我们的产品在更多的维度上就更有竞争力，自然就会吸引更多的客户去使用。

这个外面的增强回路，看起来非常美好，不过这里有两个点需要特别注意：

● 新功能的开发， 从最初的设计到最终发布，再到客户真正开始使用这些新功能 ，是需要很长时间的，这个时间通常以季度来计算。 因此，产品竞争力的提升会存在一定的延迟。 这也是我在新功能到产品竞争力之间加了一个延迟标记的原因。 尽管在其他方面也存在延迟，但我在这里想要重点强调这一点。

● 更重要的是，研发的带宽是一个物理约束，公司不可能无限制的增加研发资源。当我们投入更多的研发带宽去研发新的功能时候，自然会挤占质量改进的带宽，所以无论是新的功能引入的 bug，还是累积的未修复的 bug，都会降低产品的质量。

注意：上面我在 Feature Development Efforts 到 Quality Improvement Efforts 之间，画了一条负反馈连接。虽然形成了一个调节回路，不过因为调节回路都需要收敛到一个目标，这个图其实画的并不完善，这里先就这样将就吧……

这里就有我的第二个认知，『更多的功能，更多的 bug』。

这其实也是我的教训。在之前的 TiDB 版本里面，我们有时候太放飞自我，做了太多的功能，而功能越多的版本，质量在一开始就是不稳定，所以我们耗费了大量的精力去提升质量。注意，这里其实也有另一个平衡回路。当我们投入更多资源到质量改进时，自然也会影响新功能的开发。新功能减少会影响后续产品的竞争力。这也是为什么我们从 7.5 版本开始，在控制新功能数量的同时，努力寻找竞争力和质量之间的平衡点。

另外一个现实需要面对的，就是任何功能的开发，甚至包括 bug 修复，都会涉及到代码的调整。在一个极度复杂的产品里面，做任何的代码调整，都可能引入新的 bug。我相信研发都不愿意写有 bug 的代码，不过这个不会以研发的意志为转移。

当然我们可以通过非常多的手段来提升我们开发新功能的产品质量，或者修复 bug 的速度，这些我将在后面的文章中详细说明。我想强调的是，上述认知是我对现实的理解。只有接受了这一点，我们才能更好地做出取舍，更好地打造出有竞争力、高质量的产品 。

小结

当我写下上面几点我的认知时，我感到非常吃惊。我承认，如果回到 10 年前，我绝对不会有这样的认知。当然，我也不指望我的认知是正确的，也可能不久之后，我的认知又会刷新。我也会在文章中做相关的更新。

写到这里，不由得让我想到一个语言的梗，据传来自 C++ 之父 Bjarne Stroustrup - 『世界上只有两种语言，一种饱受诟病，一种没有人用。』产品也是如此。一个好的产品必须要有大量的用户，用的多了，骂的自然也多了，当然最终的结果是越变越好，这可能就是产品成长的必然经历吧 。

更新

● 一个很有意思的事情，在我当天 2024-02-24 发布这篇文章的时候，Hacker News 上也有一篇讨论软件质量的帖子上了首页， How to think about software quality (2022) | Hacker News ，看来不只是我，大概率全球的开发者也在头疼这个问题吧。

● 另外也找到了一篇非常早的关于 MySQL 质量的帖子，里面的一些观点跟我不谋而合， 7 Reasons why MySQL Quality will never be the same ( https://www.percona.com/blog/7-reasons-mysql-quality-will-never-be-the-same/ )