概述
最近參與了幾個需求開發，BUG很少，有些需求沒BUG，有些才一個BUG，搞的測試人員還發牢騷說，
大佬，你負責的項目，bug都少的可憐，叫俺怎麼活？
哈哈，其實測試人員要感謝我纔對，因爲開發人員的代碼質量高了，會極大的提升測試人員測試的速度，因爲測試過程中非常順暢，沒啥阻礙的東西。設想一下，如果提測後，代碼BUG滿天飛，測試人員不斷的提BUG單，開發人員不斷的修復，一不小心還可能修復出其他BUG來呢，中間還穿插各種各樣不必要的討論，這些都嚴重影響了測試進度，當然也嚴重影響了測試人員和開發人員的心情。因此：
最好是在開發階段就認真起來，把代碼寫好，以求後續流程的順暢性。
那麼如何做到寫代碼的時候，儘量避免BUG呢？趁這個機會也跟大家分享一下我的做法。
儘量避免bug的手法
與產品經理和經驗豐富的測試人員多溝通
需求階段
產品經理正式開需求會議之前，一般都會先把需求文檔發出來，這個時候，開發人員一定要認真的看並仔細分析，每個細節都要多想想，有疑問的地方及時跟產品經理溝通。另外，看需求的時候，最好跟熟悉業務的測試人員多多溝通，測試人員是對以往需求最清楚的人，能看到其他人看不到的細節。像我自己就經常從測試人員那裏，聽到了一些要命的而我卻忽略掉的需求細節。
代碼設計階段
我一般想好方案後，第一時間就會去找技術老大和熟悉業務的測試人員。能做到技術老大，他的思路一般都是比較廣的，多聽聽他的意見是沒錯的。另外，也要去找測試人員，有些開發可能認爲，技術方案怎麼會去找測試人員商量呢？請不要忘記，部分測試人員是對整個公司的大部分應用和需求和業務都瞭如指掌的人，能清楚的知道系統與系統之間如何交互，整個鏈路是怎麼走的，整個上下文又是怎麼樣的。當開發人員的設計方案出來後，表面上看起來，完美無瑕，其實可能存在影響上下游系統的隱患。而多與熟悉業務的測試人員溝通，則可以儘早把這些問題暴露出來，減少影響和損失。
代碼開發階段
必須寫單元測試
單元測試的重要性，無論怎麼強調都不爲過。它是用於測試自己寫的代碼是否符合預期的極好的手段。尤其是在創業公司，需求都非常多，經常需要改代碼，如果沒有一套完整的單元測試來回歸驗證代碼，分分鐘由於新寫了代碼而破壞了原有的代碼功能。單元測試可以讓開發人員放心大膽的改代碼，無需擔心影響之前的功能。
但是單元測試一定要認真負責的寫，儘量覆蓋主流程業務。那種隨便寫寫，隨便驗證的單元測試，不寫也罷，沒啥意義，還浪費時間。
另外有一個點就是，開發人員提測後，理論上就可以接另外一個開發任務了，如果開發階段BUG太多的話，則會影響下一個開發任務的進度。這個是開發經理不願意看到的。
不斷的重複的看自己的代碼
代碼提測前，要多看幾次，有時候能看出一些隱藏的代碼BUG的，有時候也會覺得，昨天寫的代碼，真垃圾，還是有蠻多代碼要優化的。
在看代碼的時候，最好順便做到下面幾點：
- 代碼收攏性要強，不要存在那種類似的代碼滿天飛，能封裝起來的就封裝；
- 業務代碼一定要有必要的準確的註釋，千萬別信那套方法名命名好了就能解釋清楚的鬼話；
- 變量名要起好；
- 代碼抽象層次要一致，不要跳躍，例如，你的業務方法，操作其他模塊業務表的時候，都是調用
Service類的，就不要突然冒出個直接使用xxxxxMapper去操作數據庫表了； - 流程性比較強，最好用 //1、 //2、 //3、 標註一下，這樣會更加清晰。
必須做開發聯調
當你的業務接口開發完成後，一定要做開發者之間的聯調。聯調是端對端的，就算其中一方做的再好，沒有聯調，還是會出問題。
開發聯調通過後，建議叫產品過來提前驗收
一般來說，功能測試通過後，上線前，會讓產品先驗收一下。但是我則喜歡開發聯調完後，就先拉上產品經理，先大概驗收一下。不要小看這一步，經常能提早發現一些問題的。
測試人員測試階段-看日誌
不要以爲提測後，就沒自己啥事了，最好還是抽少許時間，去測試機器上看看日誌，觀察和分析一下入參和出參等，看看有沒有什麼異常或者不合理的數據。