我在文章《 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/ )