最近參與了幾個需求開發，BUG很少，有些需求沒BUG，有些才一個BUG，搞的測試人員還發牢騷說：

“

大佬，你負責的項目，bug都少的可憐，叫俺怎么活？

哈哈，其實測試人員要感謝我才對，因為開發人員的代碼質量高了，會極大的提升測試人員測試的速度，因為測試過程中非常順暢，沒啥阻礙的東西。

設想一下，如果提測后，代碼BUG滿天飛，測試人員不斷的提BUG單，開發人員不斷的修復，一不小心還可能修復出其他BUG來呢，中間還穿插各種各樣不必要的討論，這些都嚴重影響了測試進度，當然也嚴重影響了測試人員和開發人員的心情。

因此：

最好是在開發階段就認真起來，把代碼寫好，以求后續流程的順暢性。

那么如何做到寫代碼的時候，盡量避免BUG呢？趁這個機會也跟大家分享一下我的做法。

與產品經理和經驗豐富的測試人員多溝通

需求階段

產品經理正式開需求會議之前，一般都會先把需求文檔發出來，這個時候，開發人員一定要認真的看并仔細分析，每個細節都要多想想，有疑問的地方及時跟產品經理溝通。

另外，看需求的時候，最好跟熟悉業務的測試人員多多溝通，測試人員是對以往需求最清楚的人，能看到其他人看不到的細節。像我自己就經常從測試人員那里，聽到了一些要命的而我卻忽略掉的需求細節。

代碼設計階段

我一般想好方案后，第一時間就會去找技術老大和熟悉業務的測試人員。

能做到技術老大，他的思路一般都是比較廣的，多聽聽他的意見是沒錯的。另外，也要去找測試人員，有些開發可能認為，技術方案怎么會去找測試人員商量呢？

請不要忘記，部分測試人員是對整個公司的大部分應用和需求和業務都了如指掌的人，能清楚的知道系統與系統之間如何交互，整個鏈路是怎么走的，整個上下文又是怎么樣的。

當開發人員的設計方案出來后，表面上看起來，完美無瑕，其實可能存在影響上下游系統的隱患。而多與熟悉業務的測試人員溝通，則可以盡早把這些問題暴露出來，減少影響和損失。

代碼開發階段

必須寫單元測試

單元測試的重要性，無論怎么強調都不為過。它是用于測試自己寫的代碼是否符合預期的極好的手段。尤其是在創業公司，需求都非常多，經常需要改代碼，如果沒有一套完整的單元測試來回歸驗證代碼，分分鐘由于新寫了代碼而破壞了原有的代碼功能。

單元測試可以讓開發人員放心大膽的改代碼，無需擔心影響之前的功能。

但是單元測試一定要認真負責的寫，盡量覆蓋主流程業務。那種隨便寫寫，隨便驗證的單元測試，不寫也罷，沒啥意義，還浪費時間。

寫單元測試經常犯的另外一個錯誤是，由于急著改bug，忘記同時改單元測試了，導致之前跑過的單元測試，后面又跑不過了，這個是絕對不允許的，單元測試也必須持續維護的。

另外有一個點就是，開發人員提測后，理論上就可以接另外一個開發任務了，如果開發階段BUG太多的話，則會影響下一個開發任務的進度。這個是開發經理不愿意看到的。

不斷的重復的看自己的代碼

代碼提測前，要多看幾次，有時候能看出一些隱藏的代碼BUG的，有時候也會覺得，昨天寫的代碼，真垃圾，還是有蠻多代碼要優化的。

在看代碼的時候，最好順便做到下面幾點：

代碼收攏性要強，不要存在那種類似的代碼滿天飛，能封裝起來的就封裝；

業務代碼一定要有必要的準確的注釋，千萬別信那套方法名命名好了就能解釋清楚的鬼話；

代碼抽象層次要一致，不要跳躍，例如，你的業務方法，操作其他模塊業務表的時候，都是調用Service類的，就不要突然冒出個直接使用xxxxxMapper去操作數據庫表了；

流程性比較強，最好用 //1、 ?//2、 ?//3、 標注一下，這樣會更加清晰。

必須做開發聯調

當你的業務接口開發完成后，一定要做開發者之間的聯調。聯調是端對端的，就算其中一方做的再好，沒有聯調，還是會出問題。

開發聯調通過后，建議叫產品過來提前驗收

一般來說，功能測試通過后，上線前，會讓產品先驗收一下。但是我則喜歡開發聯調完后，就先拉上產品經理，先大概驗收一下。不要小看這一步，經常能提早發現一些問題的。

開發人員列出改動了哪些已有接口

列出改動細節有個好處：

讓測試人員更加有針對性的做回歸測試。雖說每次項目上線前，測試人員會做回歸測試，但是很難做到全面回歸，而沒有回歸到的場景，到線上可能就會造成bug。如果開發人員能列出改動點，則測試人員可以重點且認真的回歸。

已有接口已經是在線上驗證過的接口，如果改動了，是一定要做兼容性測試的，既要保證新功能可用，也要保證不影響舊功能。

盡最大努力,保證開發提測不delay

對于那種上線日期已經定了，一般會采用倒排的方式，推導出，開發哪個時間點提測，測試人員什么時候介入測試，測試多少天等，都會安排好。

如果開發提測delay了，留給測試人員的測試時間就縮短了，會給測試人員造成很大的壓力，壓力一大，則更容易出錯，直接影響測試質量，也就影響了上線質量。

當出現了提測delay的苗頭，開發人員一定要及時反饋出來，由組長或者經理協調資源，進行補救。

這里要重點強調的是，一個功能的提測，是涉及到前端、后端的，你想自己加班到深夜趕進度也是沒用的，一定要以最快的速度，將問題暴露出來，由上級去協調一下，留下相關的人一起奮斗一下，盡量保證按時提測。

測試人員測試階段-看日志

不要以為提測后，就沒自己啥事了，最好還是抽少許時間，去測試機器上看看日志，觀察和分析一下入參和出參等，看看有沒有什么異常或者不合理的數據。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的硬核！尽量避免 BUG 手法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。