業(yè)務(wù)開發(fā)做到零 bug 有多難？
大家好，我是樹哥，好久不見啦。
作為一個(gè)工作了 10 多年的開發(fā)，寫業(yè)務(wù)代碼總是寫了不少的。但你想過做到零 bug 嗎？我可是想過的，畢竟我還是有點(diǎn)追求的。不然每天都是渾渾噩噩地過，多沒意思啊。
大概在一年多前，我給自己立下一個(gè)目標(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)過一段時(shí)間的思考與摸索，我自己總結(jié)出一些影響因素，分別是：
- 產(chǎn)品需求文檔的清晰程度
- 需求的復(fù)雜程度
- 開發(fā)人員的細(xì)心程度
- 開發(fā)人員是否詳細(xì)自測(cè)過
- 開發(fā)人員對(duì)項(xiàng)目的熟悉程度
- 開發(fā)人員開發(fā)時(shí)間是否充足
針對(duì)上面說到的影響因素，我們一個(gè)個(gè)詳細(xì)聊聊。
需求文檔清晰程度
對(duì)于研發(fā)、測(cè)試人員來說，他們獲取信息的源頭就是產(chǎn)品的 PRD 文檔。因此，需求文檔是否寫得清晰、明確，就顯得非常重要。
如果產(chǎn)品自己對(duì)功能都不了解，那么輸出的需求文檔肯定「缺斤少兩」，到時(shí)候就是邊開發(fā)邊補(bǔ)充需求，甚至是在測(cè)試過程中補(bǔ)充需求。遇到這種情況，想要做到零 bug 真的非常難。
因此，清晰明確的需求文檔，是我們實(shí)現(xiàn)業(yè)務(wù)開發(fā)零 bug 的重要前提。如果這個(gè)前提保證不了，那要做到零 bug 真的很難。畢竟想做成啥樣都不知道，程序員又不是神仙，咋能猜出你想要什么。但這塊內(nèi)容，更多是對(duì)于產(chǎn)品人員專業(yè)能力的要求，開發(fā)人員無法控制。
在一些公司，會(huì)再需求評(píng)審之前先對(duì)需求文檔進(jìn)行一次初審，篩除那些有明顯重大問題的需求，這樣可以減少一部分劣質(zhì)需求。
但初審的作用還是有限的，它沒辦法對(duì)功能的細(xì)節(jié)做較多的判斷。很多時(shí)候恰恰就是一些功能細(xì)節(jié)的缺失，導(dǎo)致了一些 bug 的誕生。
需求的復(fù)雜程度
需求的復(fù)雜程度，對(duì)于實(shí)現(xiàn)業(yè)務(wù)開發(fā)零 bug 也有很大的影響。舉個(gè)簡單地例子：一個(gè)改文案的需求，和一個(gè)完全重新做的功能。
這樣的兩個(gè)需求，其復(fù)雜程度差別很大，肯定是改文案的需求實(shí)現(xiàn)業(yè)務(wù)開發(fā)零 bug 的難度低很多。對(duì)于一個(gè)完全重新做的功能，要做到完全零 bug，對(duì)于開發(fā)人員的要求非常高。
對(duì)于越復(fù)雜的項(xiàng)目，零 bug 的可能性就越低。因此，很多項(xiàng)目為了追求產(chǎn)出功能的高質(zhì)量，會(huì)采用將功能點(diǎn)拆得非常細(xì)的方式，來減少單個(gè)需求的復(fù)雜度。
筆者公司在去年做過這個(gè)嘗試，確實(shí)是可以較大地提高產(chǎn)出功能的質(zhì)量。
細(xì)心程度
前面說到需求文檔的清晰程度很重要，這取決于產(chǎn)品人員對(duì)于業(yè)務(wù)的理解程度，以及對(duì)于對(duì)于功能的熟悉程度。開發(fā)人員的細(xì)心，就像是一個(gè)質(zhì)檢關(guān)卡一樣，在開發(fā)之前就對(duì)產(chǎn)品的需求內(nèi)容進(jìn)行詳盡的思考與提問。
對(duì)于粗心的開發(fā)人員來說，其可能不看需求文檔就直接參加需求評(píng)審，等到開發(fā)的時(shí)候邊寫代碼邊看需求文檔，其寫得代碼也是一邊熟悉需求一邊改。這樣寫出來的系統(tǒng)功能是比較差的，沒有一個(gè)統(tǒng)一、全局的設(shè)計(jì)與思考，很容易在細(xì)節(jié)處發(fā)生問題。
一個(gè)細(xì)心的開發(fā)人員，其會(huì)在評(píng)審之前就詳細(xì)閱讀需求文檔，甚至?xí)扒昂蠛蠓喓脦状?。他甚至?xí)鹱种鹁涞亻喿x，弄懂每個(gè)文字、句子的意思，甚至有時(shí)候會(huì)讓你覺得他是在玩文字游戲（但不得不說，確實(shí)有必要細(xì)致一些）。
最后會(huì)聯(lián)系上下文思考功能的合理性。如果發(fā)現(xiàn)一些不合理的地方，他會(huì)積極與產(chǎn)品溝通反饋，以確保其對(duì)于需求的理解，與產(chǎn)品經(jīng)理對(duì)于需求的理解是一致的。
通過對(duì)比，我們知道細(xì)心的開發(fā)人員對(duì)于產(chǎn)品經(jīng)理來說，是一個(gè)莫大的幫助，可以幫助他查漏補(bǔ)缺，讓其對(duì)于功能的考慮更加細(xì)致、嚴(yán)謹(jǐn)。
這里的開發(fā)人員不僅僅指的是后端開發(fā)人員，也包括前端開發(fā)、移動(dòng)端開發(fā)，他們都會(huì)從不同角度提出問題。
對(duì)于后端開發(fā)人員來說，他們可能會(huì)提出性能問題。對(duì)于前端開發(fā)以及移動(dòng)端開發(fā)同學(xué)，他們可能會(huì)提出交互問題、樣式統(tǒng)一等問題。
簡單地說，細(xì)心的開發(fā)人員可以彌補(bǔ)需求文檔的缺陷，從而讓大家對(duì)于需求的理解更趨于一致，從而減少 bug 的發(fā)生。因此，開發(fā)人員的細(xì)心程度也是決定業(yè)務(wù)開發(fā)能否實(shí)現(xiàn)零 bug 的關(guān)鍵因素！
是否詳細(xì)自測(cè)過
即使寫過 10 多年代碼的開發(fā)人員，刷 Leetcode 也不敢說 bug free 一把過，對(duì)于更加復(fù)雜的業(yè)務(wù)代碼更是如此。因此，要做到業(yè)務(wù)開發(fā)零 bug，其中一個(gè)很重要的操作便是 —— 自測(cè)。
自測(cè)可以幫你再次檢查可能出現(xiàn)的問題，從而提高零 bug 的概率。對(duì)于我而言，我習(xí)慣性在自測(cè)的時(shí)候再次對(duì)照一遍需求文檔，從而避免自己遺漏一些功能的細(xì)節(jié)點(diǎn)。
對(duì)于自測(cè)而言，業(yè)界有很多種自測(cè)方法，包括：單測(cè)、集成測(cè)試、功能測(cè)試。一般情況，建議自己選擇適合自己的自測(cè)方法。
很多時(shí)候，功能測(cè)試是相對(duì)來說性價(jià)比較高的方式。除此之外，自測(cè)的詳細(xì)程度也根據(jù)實(shí)際情況有所不同，例如有些人只會(huì)測(cè)試正常情況，但有些老手會(huì)測(cè)試一些邊界情況、異常情況。
毫無疑問，你越能像測(cè)試人員一樣測(cè)試，你的提測(cè)質(zhì)量肯定就越高，bug 當(dāng)然也就越少。
對(duì)項(xiàng)目的熟悉程度
這里說的項(xiàng)目熟悉程度，既指技術(shù)層面的熟悉程度，也指業(yè)務(wù)功能層面的熟悉程度。
技術(shù)層面的熟悉程度，指的是項(xiàng)目之間是用什么技術(shù)棧搭建的，你對(duì)這些技術(shù)是否都熟悉。舉個(gè)很簡單的例子，項(xiàng)目中采用了微服務(wù)的方式進(jìn)行調(diào)用，那么你是否清楚是什么微服務(wù)調(diào)用？
如果采用了 ElasticSearch 進(jìn)行搜索，那么你是否對(duì) ElasticSearch 有一些了解，知道一些基本使用及最佳實(shí)踐？等等。
這些算是技術(shù)層面的熟悉程度，你對(duì)這些越熟悉，你在技術(shù)層面發(fā)生問題的可能性就越小。
業(yè)務(wù)功能層面的熟悉程度，指的是你對(duì)項(xiàng)目其他模塊的業(yè)務(wù)是否熟悉。例如你經(jīng)常負(fù)責(zé) A 模塊的功能，你對(duì) A 模塊肯定很熟悉。
但下個(gè)迭代你就要去做 B 迭代的需求了，這時(shí)候你肯定不是很熟，相對(duì)來說出錯(cuò)的可能性就更大一些。
無論是技術(shù)層面，還是業(yè)務(wù)層面的熟悉程度，都會(huì)隨著你做了更多的需求，變得更加熟悉。到了后面某個(gè)階段，你基本上就不存在踩坑的問題了，也為你業(yè)務(wù)開發(fā)零 bug 奠定了基礎(chǔ)。如果你是一個(gè)剛剛進(jìn)入公司的新手，那么做到零 bug 還是很難的。
開發(fā)時(shí)間是否充足
開發(fā)時(shí)間是否充足，決定了你是否有充足的時(shí)間去熟悉需求，去和產(chǎn)品經(jīng)理確定細(xì)節(jié)。有了充足的時(shí)間，你也才能有一定時(shí)間去進(jìn)行更詳細(xì)的自測(cè)。更為關(guān)鍵的一點(diǎn)，有充足的時(shí)間，你寫代碼才能寫得更好。因此，開發(fā)時(shí)間是否充足是很重要的。
在實(shí)際的開發(fā)過程中，會(huì)因?yàn)楦鞣N各樣的原因，其實(shí)并沒有辦法給你留出特別理想的開發(fā)時(shí)間。這時(shí)候該怎么辦？有些人選擇接受，去壓縮自己的時(shí)間。
有些人則會(huì)選擇去溝通，或者協(xié)調(diào)資源，保證自己有充足的時(shí)間。其實(shí)，正確的做法還是第二種，這樣會(huì)更好一些。
這需要開發(fā)人員有更強(qiáng)的綜合能力（溝通、協(xié)調(diào)能力），但并不是每個(gè)開發(fā)人員都具備的。關(guān)于這點(diǎn)，又是可以聊的一個(gè)話題 —— 當(dāng)你的需求被壓縮工時(shí)的時(shí)候，你應(yīng)該怎么做？這里暫不展開，后續(xù)有時(shí)間可以聊聊。
簡單來說，開發(fā)時(shí)間是基礎(chǔ)，沒有合理、充足的時(shí)間保障的話，要做到業(yè)務(wù)開發(fā)零 bug 是不可能的事情。
總結(jié)
要做到業(yè)務(wù)開發(fā)零 bug，其實(shí)就是要消除功能開發(fā)過程中的所有不確定性，包括：需求功能的不確定性、自己寫錯(cuò)代碼的不確定性等等。而發(fā)生這些不確定性的地方，可能就有：
- 產(chǎn)品需求文檔的清晰程度
- 需求的復(fù)雜程度
- 開發(fā)人員的細(xì)心程度
- 開發(fā)人員是否詳細(xì)自測(cè)過
- 開發(fā)人員對(duì)項(xiàng)目的熟悉程度
- 開發(fā)人員開發(fā)時(shí)間是否充足
除了上面說到的 6 個(gè)影響業(yè)務(wù)開發(fā)零 bug 的因素之外，肯定還有其他影響因素。
