建站
咨詢
售后
建站咨詢
新聞中心
最近參與了幾個(gè)需求開發(fā)，BUG很少，有些需求沒BUG，有些才一個(gè)BUG，搞的測(cè)試人員還發(fā)牢騷說：
目前創(chuàng)新互聯(lián)已為超過千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)站空間、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計(jì)、城區(qū)網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
大佬，你負(fù)責(zé)的項(xiàng)目，bug都少的可憐，叫俺怎么活？
哈哈，其實(shí)測(cè)試人員要感謝我才對(duì)，因?yàn)殚_發(fā)人員的代碼質(zhì)量高了，會(huì)極大的提升測(cè)試人員測(cè)試的速度，因?yàn)闇y(cè)試過程中非常順暢，沒啥阻礙的東西。
設(shè)想一下，如果提測(cè)后，代碼BUG滿天飛，測(cè)試人員不斷的提BUG單，開發(fā)人員不斷的修復(fù)，一不小心還可能修復(fù)出其他BUG來呢，中間還穿插各種各樣不必要的討論，這些都嚴(yán)重影響了測(cè)試進(jìn)度，當(dāng)然也嚴(yán)重影響了測(cè)試人員和開發(fā)人員的心情。
因此：
最好是在開發(fā)階段就認(rèn)真起來，把代碼寫好，以求后續(xù)流程的順暢性。
那么如何做到寫代碼的時(shí)候，盡量避免BUG呢？趁這個(gè)機(jī)會(huì)也跟大家分享一下我的做法。
與產(chǎn)品經(jīng)理和經(jīng)驗(yàn)豐富的測(cè)試人員多溝通
需求階段
產(chǎn)品經(jīng)理正式開需求會(huì)議之前，一般都會(huì)先把需求文檔發(fā)出來，這個(gè)時(shí)候，開發(fā)人員一定要認(rèn)真的看并仔細(xì)分析，每個(gè)細(xì)節(jié)都要多想想，有疑問的地方及時(shí)跟產(chǎn)品經(jīng)理溝通。
另外，看需求的時(shí)候，最好跟熟悉業(yè)務(wù)的測(cè)試人員多多溝通，測(cè)試人員是對(duì)以往需求最清楚的人，能看到其他人看不到的細(xì)節(jié)。像我自己就經(jīng)常從測(cè)試人員那里，聽到了一些要命的而我卻忽略掉的需求細(xì)節(jié)。
代碼設(shè)計(jì)階段
我一般想好方案后，第一時(shí)間就會(huì)去找技術(shù)老大和熟悉業(yè)務(wù)的測(cè)試人員。
能做到技術(shù)老大，他的思路一般都是比較廣的，多聽聽他的意見是沒錯(cuò)的。另外，也要去找測(cè)試人員，有些開發(fā)可能認(rèn)為，技術(shù)方案怎么會(huì)去找測(cè)試人員商量呢？
請(qǐng)不要忘記，部分測(cè)試人員是對(duì)整個(gè)公司的大部分應(yīng)用和需求和業(yè)務(wù)都了如指掌的人，能清楚的知道系統(tǒng)與系統(tǒng)之間如何交互，整個(gè)鏈路是怎么走的，整個(gè)上下文又是怎么樣的。
當(dāng)開發(fā)人員的設(shè)計(jì)方案出來后，表面上看起來，完美無瑕，其實(shí)可能存在影響上下游系統(tǒng)的隱患。而多與熟悉業(yè)務(wù)的測(cè)試人員溝通，則可以盡早把這些問題暴露出來，減少影響和損失。
代碼開發(fā)階段
必須寫單元測(cè)試
單元測(cè)試的重要性，無論怎么強(qiáng)調(diào)都不為過。它是用于測(cè)試自己寫的代碼是否符合預(yù)期的極好的手段。尤其是在創(chuàng)業(yè)公司，需求都非常多，經(jīng)常需要改代碼，如果沒有一套完整的單元測(cè)試來回歸驗(yàn)證代碼，分分鐘由于新寫了代碼而破壞了原有的代碼功能。
單元測(cè)試可以讓開發(fā)人員放心大膽的改代碼，無需擔(dān)心影響之前的功能。
但是單元測(cè)試一定要認(rèn)真負(fù)責(zé)的寫，盡量覆蓋主流程業(yè)務(wù)。那種隨便寫寫，隨便驗(yàn)證的單元測(cè)試，不寫也罷，沒啥意義，還浪費(fèi)時(shí)間。
寫單元測(cè)試經(jīng)常犯的另外一個(gè)錯(cuò)誤是，由于急著改bug，忘記同時(shí)改單元測(cè)試了，導(dǎo)致之前跑過的單元測(cè)試，后面又跑不過了，這個(gè)是絕對(duì)不允許的，單元測(cè)試也必須持續(xù)維護(hù)的。
另外有一個(gè)點(diǎn)就是，開發(fā)人員提測(cè)后，理論上就可以接另外一個(gè)開發(fā)任務(wù)了，如果開發(fā)階段BUG太多的話，則會(huì)影響下一個(gè)開發(fā)任務(wù)的進(jìn)度。這個(gè)是開發(fā)經(jīng)理不愿意看到的。
不斷的重復(fù)的看自己的代碼
代碼提測(cè)前，要多看幾次，有時(shí)候能看出一些隱藏的代碼BUG的，有時(shí)候也會(huì)覺得，昨天寫的代碼，真垃圾，還是有蠻多代碼要優(yōu)化的。
在看代碼的時(shí)候，最好順便做到下面幾點(diǎn)：
代碼收攏性要強(qiáng)，不要存在那種類似的代碼滿天飛，能封裝起來的就封裝；
業(yè)務(wù)代碼一定要有必要的準(zhǔn)確的注釋，千萬別信那套方法名命名好了就能解釋清楚的鬼話；
變量名要起好；Google 出品的 Java 編碼規(guī)范，這篇推薦你看下。
代碼抽象層次要一致，不要跳躍，例如，你的業(yè)務(wù)方法，操作其他模塊業(yè)務(wù)表的時(shí)候，都是調(diào)用Service類的，就不要突然冒出個(gè)直接使用xxxxxMapper去操作數(shù)據(jù)庫表了；
流程性比較強(qiáng)，最好用 //1、 //2、 //3、 標(biāo)注一下，這樣會(huì)更加清晰。
必須做開發(fā)聯(lián)調(diào)
當(dāng)你的業(yè)務(wù)接口開發(fā)完成后，一定要做開發(fā)者之間的聯(lián)調(diào)。聯(lián)調(diào)是端對(duì)端的，就算其中一方做的再好，沒有聯(lián)調(diào)，還是會(huì)出問題。
開發(fā)聯(lián)調(diào)通過后，建議叫產(chǎn)品過來提前驗(yàn)收
一般來說，功能測(cè)試通過后，上線前，會(huì)讓產(chǎn)品先驗(yàn)收一下。但是我則喜歡開發(fā)聯(lián)調(diào)完后，就先拉上產(chǎn)品經(jīng)理，先大概驗(yàn)收一下。不要小看這一步，經(jīng)常能提早發(fā)現(xiàn)一些問題的。
開發(fā)人員列出改動(dòng)了哪些已有接口
列出改動(dòng)細(xì)節(jié)有個(gè)好處：
讓測(cè)試人員更加有針對(duì)性的做回歸測(cè)試。雖說每次項(xiàng)目上線前，測(cè)試人員會(huì)做回歸測(cè)試，但是很難做到全面回歸，而沒有回歸到的場(chǎng)景，到線上可能就會(huì)造成bug。如果開發(fā)人員能列出改動(dòng)點(diǎn)，則測(cè)試人員可以重點(diǎn)且認(rèn)真的回歸。
已有接口已經(jīng)是在線上驗(yàn)證過的接口，如果改動(dòng)了，是一定要做兼容性測(cè)試的，既要保證新功能可用，也要保證不影響舊功能。
盡最大努力,保證開發(fā)提測(cè)不delay
對(duì)于那種上線日期已經(jīng)定了，一般會(huì)采用倒排的方式，推導(dǎo)出，開發(fā)哪個(gè)時(shí)間點(diǎn)提測(cè)，測(cè)試人員什么時(shí)候介入測(cè)試，測(cè)試多少天等，都會(huì)安排好。
如果開發(fā)提測(cè)delay了，留給測(cè)試人員的測(cè)試時(shí)間就縮短了，會(huì)給測(cè)試人員造成很大的壓力，壓力一大，則更容易出錯(cuò)，直接影響測(cè)試質(zhì)量，也就影響了上線質(zhì)量。
當(dāng)出現(xiàn)了提測(cè)delay的苗頭，開發(fā)人員一定要及時(shí)反饋出來，由組長或者經(jīng)理協(xié)調(diào)資源，進(jìn)行補(bǔ)救。
這里要重點(diǎn)強(qiáng)調(diào)的是，一個(gè)功能的提測(cè)，是涉及到前端、后端的，你想自己加班到深夜趕進(jìn)度也是沒用的，一定要以最快的速度，將問題暴露出來，由上級(jí)去協(xié)調(diào)一下，留下相關(guān)的人一起奮斗一下，盡量保證按時(shí)提測(cè)。
測(cè)試人員測(cè)試階段-看日志
不要以為提測(cè)后，就沒自己啥事了，最好還是抽少許時(shí)間，去測(cè)試機(jī)器上看看日志，觀察和分析一下入?yún)⒑统鰠⒌?，看看有沒有什么異常或者不合理的數(shù)據(jù)。
你們有什么好的想法？一起來分享一下，評(píng)論區(qū)見！
文章標(biāo)題：看看高手怎么做到寫出沒有bug的代碼
文章起源：http://fisionsoft.com.cn/article/gephep.html
