看看高手怎么做到寫出沒有bug的代碼

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

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

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

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

因此：

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

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

與產品經(jīng)理和經(jīng)驗豐富的測試人員多溝通

需求階段

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

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

代碼設計階段

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

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

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

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

代碼開發(fā)階段

必須寫單元測試

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

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

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

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

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

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

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

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

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

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

變量名要起好；Google 出品的 Java 編碼規(guī)范，這篇推薦你看下。

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

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

必須做開發(fā)聯(lián)調

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

開發(fā)聯(lián)調通過后，建議叫產品過來提前驗收

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

開發(fā)人員列出改動了哪些已有接口

列出改動細節(jié)有個好處：

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

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

盡最大努力,保證開發(fā)提測不delay

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

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

當出現(xiàn)了提測delay的苗頭，開發(fā)人員一定要及時反饋出來，由組長或者經(jīng)理協(xié)調資源，進行補救。

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

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

不要以為提測后，就沒自己啥事了，最好還是抽少許時間，去測試機器上看看日志，觀察和分析一下入?yún)⒑统鰠⒌?，看看有沒有什么異常或者不合理的數(shù)據(jù)。

你們有什么好的想法？一起來分享一下，評論區(qū)見！