大家好，我是樹哥，好久不見啦。
作爲一個工作了 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 的因素之外，肯定還有其他影響因素。
你能想到什麼影響業務開發零 bug 的因素嗎？歡迎在評論區留言與大家分享。
好了，今天的分享就到此爲止，希望大家都能做到業務開發零 bug，業務開發代碼一把過！
如果你覺得今天的文章對你有幫助，歡迎點贊轉發評論，你的轉發對於我很重要，感謝大家！