業(yè)務(wù)開發(fā)做到零 bug 有多難？

作者：陳樹義 2024-03-18 08:03:32

開發(fā)時間是否充足，決定了你是否有充足的時間去熟悉需求，去和產(chǎn)品經(jīng)理確定細(xì)節(jié)。有了充足的時間，你也才能有一定時間去進(jìn)行更詳細(xì)的自測。更為關(guān)鍵的一點(diǎn)，有充足的時間，你寫代碼才能寫得更好。因此，開發(fā)時間是否充足是很重要的。

大家好，我是樹哥，好久不見啦。

作為一個工作了 10 多年的開發(fā)，寫業(yè)務(wù)代碼總是寫了不少的。但你想過做到零 bug 嗎？我可是想過的，畢竟我還是有點(diǎn)追求的。不然每天都是渾渾噩噩地過，多沒意思啊。

大概在一年多前，我給自己立下一個目標(biāo) —— 盡量將自己經(jīng)手的業(yè)務(wù)需求做到零 bug。不試不知道，一試嚇一跳，原來零 bug 還真的還不容易。今天，樹哥就跟大家分享關(guān)于「業(yè)務(wù)開發(fā)零 bug」的一些思考。

要做到業(yè)務(wù)開發(fā)零 bug，其實(shí)挺難的。這涉及到非常多方面，有些方面可能還不只是你能控制的，例如：產(chǎn)品 PRD 詳盡程度，產(chǎn)研組織的穩(wěn)定性等等。經(jīng)過一段時間的思考與摸索，我自己總結(jié)出一些影響因素，分別是：

產(chǎn)品需求文檔的清晰程度
需求的復(fù)雜程度
開發(fā)人員的細(xì)心程度
開發(fā)人員是否詳細(xì)自測過
開發(fā)人員對項目的熟悉程度
開發(fā)人員開發(fā)時間是否充足

針對上面說到的影響因素，我們一個個詳細(xì)聊聊。

需求文檔清晰程度

對于研發(fā)、測試人員來說，他們獲取信息的源頭就是產(chǎn)品的 PRD 文檔。因此，需求文檔是否寫得清晰、明確，就顯得非常重要。

如果產(chǎn)品自己對功能都不了解，那么輸出的需求文檔肯定「缺斤少兩」，到時候就是邊開發(fā)邊補(bǔ)充需求，甚至是在測試過程中補(bǔ)充需求。遇到這種情況，想要做到零 bug 真的非常難。

因此，清晰明確的需求文檔，是我們實(shí)現(xiàn)業(yè)務(wù)開發(fā)零 bug 的重要前提。如果這個前提保證不了，那要做到零 bug 真的很難。畢竟想做成啥樣都不知道，程序員又不是神仙，咋能猜出你想要什么。但這塊內(nèi)容，更多是對于產(chǎn)品人員專業(yè)能力的要求，開發(fā)人員無法控制。

在一些公司，會再需求評審之前先對需求文檔進(jìn)行一次初審，篩除那些有明顯重大問題的需求，這樣可以減少一部分劣質(zhì)需求。

但初審的作用還是有限的，它沒辦法對功能的細(xì)節(jié)做較多的判斷。很多時候恰恰就是一些功能細(xì)節(jié)的缺失，導(dǎo)致了一些 bug 的誕生。

需求的復(fù)雜程度

需求的復(fù)雜程度，對于實(shí)現(xiàn)業(yè)務(wù)開發(fā)零 bug 也有很大的影響。舉個簡單地例子：一個改文案的需求，和一個完全重新做的功能。

這樣的兩個需求，其復(fù)雜程度差別很大，肯定是改文案的需求實(shí)現(xiàn)業(yè)務(wù)開發(fā)零 bug 的難度低很多。對于一個完全重新做的功能，要做到完全零 bug，對于開發(fā)人員的要求非常高。

對于越復(fù)雜的項目，零 bug 的可能性就越低。因此，很多項目為了追求產(chǎn)出功能的高質(zhì)量，會采用將功能點(diǎn)拆得非常細(xì)的方式，來減少單個需求的復(fù)雜度。

筆者公司在去年做過這個嘗試，確實(shí)是可以較大地提高產(chǎn)出功能的質(zhì)量。

細(xì)心程度

前面說到需求文檔的清晰程度很重要，這取決于產(chǎn)品人員對于業(yè)務(wù)的理解程度，以及對于對于功能的熟悉程度。開發(fā)人員的細(xì)心，就像是一個質(zhì)檢關(guān)卡一樣，在開發(fā)之前就對產(chǎn)品的需求內(nèi)容進(jìn)行詳盡的思考與提問。

對于粗心的開發(fā)人員來說，其可能不看需求文檔就直接參加需求評審，等到開發(fā)的時候邊寫代碼邊看需求文檔，其寫得代碼也是一邊熟悉需求一邊改。這樣寫出來的系統(tǒng)功能是比較差的，沒有一個統(tǒng)一、全局的設(shè)計與思考，很容易在細(xì)節(jié)處發(fā)生問題。

一個細(xì)心的開發(fā)人員，其會在評審之前就詳細(xì)閱讀需求文檔，甚至?xí)扒昂蠛蠓喓脦状巍Ｋ踔習(xí)鹱种鹁涞亻喿x，弄懂每個文字、句子的意思，甚至有時候會讓你覺得他是在玩文字游戲（但不得不說，確實(shí)有必要細(xì)致一些）。

最后會聯(lián)系上下文思考功能的合理性。如果發(fā)現(xiàn)一些不合理的地方，他會積極與產(chǎn)品溝通反饋，以確保其對于需求的理解，與產(chǎn)品經(jīng)理對于需求的理解是一致的。

通過對比，我們知道細(xì)心的開發(fā)人員對于產(chǎn)品經(jīng)理來說，是一個莫大的幫助，可以幫助他查漏補(bǔ)缺，讓其對于功能的考慮更加細(xì)致、嚴(yán)謹(jǐn)。

這里的開發(fā)人員不僅僅指的是后端開發(fā)人員，也包括前端開發(fā)、移動端開發(fā)，他們都會從不同角度提出問題。

對于后端開發(fā)人員來說，他們可能會提出性能問題。對于前端開發(fā)以及移動端開發(fā)同學(xué)，他們可能會提出交互問題、樣式統(tǒng)一等問題。

簡單地說，細(xì)心的開發(fā)人員可以彌補(bǔ)需求文檔的缺陷，從而讓大家對于需求的理解更趨于一致，從而減少 bug 的發(fā)生。因此，開發(fā)人員的細(xì)心程度也是決定業(yè)務(wù)開發(fā)能否實(shí)現(xiàn)零 bug 的關(guān)鍵因素！

是否詳細(xì)自測過

即使寫過 10 多年代碼的開發(fā)人員，刷 Leetcode 也不敢說 bug free 一把過，對于更加復(fù)雜的業(yè)務(wù)代碼更是如此。因此，要做到業(yè)務(wù)開發(fā)零 bug，其中一個很重要的操作便是 —— 自測。

自測可以幫你再次檢查可能出現(xiàn)的問題，從而提高零 bug 的概率。對于我而言，我習(xí)慣性在自測的時候再次對照一遍需求文檔，從而避免自己遺漏一些功能的細(xì)節(jié)點(diǎn)。

對于自測而言，業(yè)界有很多種自測方法，包括：單測、集成測試、功能測試。一般情況，建議自己選擇適合自己的自測方法。

很多時候，功能測試是相對來說性價比較高的方式。除此之外，自測的詳細(xì)程度也根據(jù)實(shí)際情況有所不同，例如有些人只會測試正常情況，但有些老手會測試一些邊界情況、異常情況。

毫無疑問，你越能像測試人員一樣測試，你的提測質(zhì)量肯定就越高，bug 當(dāng)然也就越少。

對項目的熟悉程度

這里說的項目熟悉程度，既指技術(shù)層面的熟悉程度，也指業(yè)務(wù)功能層面的熟悉程度。

技術(shù)層面的熟悉程度，指的是項目之間是用什么技術(shù)棧搭建的，你對這些技術(shù)是否都熟悉。舉個很簡單的例子，項目中采用了微服務(wù)的方式進(jìn)行調(diào)用，那么你是否清楚是什么微服務(wù)調(diào)用？

如果采用了 ElasticSearch 進(jìn)行搜索，那么你是否對 ElasticSearch 有一些了解，知道一些基本使用及最佳實(shí)踐？等等。

這些算是技術(shù)層面的熟悉程度，你對這些越熟悉，你在技術(shù)層面發(fā)生問題的可能性就越小。

業(yè)務(wù)功能層面的熟悉程度，指的是你對項目其他模塊的業(yè)務(wù)是否熟悉。例如你經(jīng)常負(fù)責(zé) A 模塊的功能，你對 A 模塊肯定很熟悉。

但下個迭代你就要去做 B 迭代的需求了，這時候你肯定不是很熟，相對來說出錯的可能性就更大一些。

無論是技術(shù)層面，還是業(yè)務(wù)層面的熟悉程度，都會隨著你做了更多的需求，變得更加熟悉。到了后面某個階段，你基本上就不存在踩坑的問題了，也為你業(yè)務(wù)開發(fā)零 bug 奠定了基礎(chǔ)。如果你是一個剛剛進(jìn)入公司的新手，那么做到零 bug 還是很難的。

開發(fā)時間是否充足

在實(shí)際的開發(fā)過程中，會因為各種各樣的原因，其實(shí)并沒有辦法給你留出特別理想的開發(fā)時間。這時候該怎么辦？有些人選擇接受，去壓縮自己的時間。

有些人則會選擇去溝通，或者協(xié)調(diào)資源，保證自己有充足的時間。其實(shí)，正確的做法還是第二種，這樣會更好一些。

這需要開發(fā)人員有更強(qiáng)的綜合能力（溝通、協(xié)調(diào)能力），但并不是每個開發(fā)人員都具備的。關(guān)于這點(diǎn)，又是可以聊的一個話題 —— 當(dāng)你的需求被壓縮工時的時候，你應(yīng)該怎么做？這里暫不展開，后續(xù)有時間可以聊聊。

簡單來說，開發(fā)時間是基礎(chǔ)，沒有合理、充足的時間保障的話，要做到業(yè)務(wù)開發(fā)零 bug 是不可能的事情。