5月iOS設備好評榜：iPhone 14僅排第43？
來到新的一月，安兔兔的各個榜單又重新匯總了數據，像安卓陣營的榜單都有著比較大的變動，不過iOS由于設備的更新換代并沒有那么快，所以相對來說變化并不大，特別是iOS好評榜，老款設
大家好，我是樹哥，好久不見啦。
作為一個工作了 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 的因素之外，肯定還有其他影響因素。
本文鏈接：http://m.www897cc.com/showinfo-26-76489-0.html業務開發做到零 bug 有多難？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Go 包循環引用及對策，你學會了嗎？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號