搜索引擎一直不收錄網(wǎng)站怎么辦 |
發(fā)布時(shí)間:2016-10-07 文章來源: 瀏覽次數(shù):2552 |
代碼審查(Code Review)是軟件開發(fā)中常用的手段,和QA測(cè)試比擬,它更輕易發(fā)現(xiàn)和架構(gòu)以及時(shí)序相關(guān)等較難發(fā)現(xiàn)的題目,還可以匡助團(tuán)隊(duì)成員進(jìn)步編程技能,同一編程風(fēng)格等。 1. 代碼審查要求團(tuán)隊(duì)有良好的文化 團(tuán)隊(duì)需要熟悉到代碼審查是為了進(jìn)步整個(gè)團(tuán)隊(duì)的能力,而不是針對(duì)個(gè)體設(shè)置的檢查“關(guān)卡”。 “A的代碼有個(gè)bug被B發(fā)現(xiàn),所以A能力不行,B能力更好”,這一類的陷阱很輕易被擴(kuò)散從而影響團(tuán)隊(duì)內(nèi)部的協(xié)作,因此需要避免。 另外,代碼審查本身可以進(jìn)步開發(fā)者的能力,讓其從自身犯過的錯(cuò)誤中學(xué)習(xí),從他人的思路中學(xué)習(xí)。假如開發(fā)者對(duì)這個(gè)流程有抵觸或者反感,這個(gè)目的就達(dá)不到。 2. 謹(jǐn)嚴(yán)的使用審查中題目的發(fā)現(xiàn)率作為考評(píng)尺度 高效代碼審查的十個(gè)經(jīng)驗(yàn) 在代碼審查中假如發(fā)現(xiàn)題目,對(duì)于題目的發(fā)現(xiàn)者來說這是好事,應(yīng)該予以鼓勵(lì)。但對(duì)于被發(fā)現(xiàn)者,我們不主張使用這個(gè)方式予以懲罰。軟件開發(fā)中bug在所難免,過度苛求本身有悖常理。更糟的是,假如造成介入者怕承擔(dān)責(zé)任,不愿意在審查中指出題目,代碼審查就沒有任何的價(jià)值和意義。 3. 控制每次審查的代碼數(shù)目 根據(jù)smartbear在思科所作的調(diào)查,每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多,發(fā)現(xiàn)題目的能力就會(huì)下降. 高效代碼審查的十個(gè)經(jīng)驗(yàn) 我們?cè)趯?shí)踐中發(fā)現(xiàn),跟著開發(fā)平臺(tái)和開發(fā)語言的不同,最優(yōu)的代碼審查量有所不同。但是限制每次審查的數(shù)目確實(shí)非常必要,由于這個(gè)過程是高強(qiáng)度的腦力密集型流動(dòng)。時(shí)間一長,代碼在審查者眼里只是字母,無任何邏輯聯(lián)系,天然不會(huì)有太多的產(chǎn)出。 4. 帶著題目去進(jìn)行審查 我們?cè)诿看未a審查中,要求審查者利用自身的經(jīng)驗(yàn)先思索可能會(huì)遇到的題目,然后通過審查工作驗(yàn)證這些題目是否已經(jīng)解決。一個(gè)竅門是,從用戶可見的功能出發(fā),假設(shè)一個(gè)比較復(fù)雜的使用場景,在代碼閱讀中驗(yàn)證這個(gè)使用場景是否能夠準(zhǔn)確工作。 使用這個(gè)技巧,可以讓審查者有代入感,真正的陶醉入代碼中,進(jìn)步效率。大家都知道看武俠小說不輕易瞌睡兒,而看專業(yè)書輕易瞌睡兒,原因就是武俠小說更輕易產(chǎn)生代入感。 有的研究建議每次樹立目標(biāo),控制單位時(shí)間內(nèi)審核的代碼數(shù)目。這個(gè)方法在我們的實(shí)踐中顯得很機(jī)械和流程化,不如上面的方法效果好。 5. 所有的題目和修改,必需由原作者進(jìn)行確認(rèn) 假如在審查中發(fā)現(xiàn)題目,務(wù)必由原作者進(jìn)行確認(rèn)。 這樣做有兩個(gè)目的: (1)確認(rèn)題目確實(shí)存在,保證題目被解決 (2)讓原作者了解題目和不足,匡助其成長 有些時(shí)候?yàn)榱俗非笮,有?jīng)驗(yàn)的審查者更傾向于直接修改代碼乃至重構(gòu)所有代碼,但這樣不利于進(jìn)步團(tuán)隊(duì)效率,并且會(huì)增加由于重構(gòu)引入新bug的幾率,通常情況下我們不予鼓勵(lì)。 6.利用代碼審查激活個(gè)體“能動(dòng)性" 即使項(xiàng)目進(jìn)度比較緊張,無法完全的進(jìn)行代碼審查,至少也要進(jìn)行部門代碼的審查,此時(shí)隨即抽取一些樞紐部門是個(gè)不錯(cuò)的辦法。 背后的邏輯是,軟件開發(fā)長短常有創(chuàng)造性的工作,開發(fā)者都有強(qiáng)烈的自我驅(qū)動(dòng)性和自我實(shí)現(xiàn)的要求。閃開發(fā)者知道他寫的任何代碼都可能被其他人閱讀和審察,可以促使開發(fā)者集中留意力,尤其是避免將質(zhì)量糟糕,乃至有初級(jí)錯(cuò)誤的代碼提交給同伴審查。開源軟件也很好的利用了這種心態(tài)來進(jìn)步代碼質(zhì)量。 7.在非正式,輕松的環(huán)境下進(jìn)行代碼審查 如前所述,代碼審查是一個(gè)腦力密集型的工作。介入者需要在比較輕松的環(huán)境下進(jìn)行該工作。因此,我們以為像某些實(shí)踐中建議的那樣,以會(huì)議的形式進(jìn)行代碼審查效果并不好,不僅由于長時(shí)間的會(huì)議輕易讓效率低下,更由于會(huì)議上可能泛起的爭議和思索不利于進(jìn)行如斯復(fù)雜的工作。 8.提交代碼前自我審查,添加對(duì)代碼的說明 所有團(tuán)隊(duì)成員在提交代碼給其他成員審查前,必需提高前輩行一次審查。這次自我修正形式的審查除了檢查代碼的準(zhǔn)確性以外,還可以完成如下的工作: (1)對(duì)代碼添加注釋,說明本次修改背后的原因,利便其他人進(jìn)行審查。 (2)修正編碼風(fēng)格,尤其是一些樞紐數(shù)據(jù)結(jié)構(gòu)和方法的命名,進(jìn)步代碼的可讀性。 (3)從全局審閱設(shè)計(jì),是否完整的考慮了所有情景。在實(shí)現(xiàn)之前做的設(shè)計(jì)假如存在考慮不周的情況,這個(gè)階段可以很好的進(jìn)行補(bǔ)救。 我們?cè)趯?shí)踐中發(fā)現(xiàn),即使只有原作者進(jìn)行代碼審查,仍舊可以很好的進(jìn)步代碼質(zhì)量。 9.實(shí)現(xiàn)中記實(shí)筆記可以很好的進(jìn)步題目發(fā)現(xiàn)率 成員在編碼的時(shí)候應(yīng)做隨手記實(shí),包括在代碼頂用注釋的方式表示,或者記實(shí)簡樸的個(gè)人文檔,這樣做有幾個(gè)好處: (1)避免漏掉。在編碼時(shí)將考慮到的任何題目都記實(shí)下來,在審查階段再次檢查這些題目都確認(rèn)解決。 (2)根據(jù)研究,每個(gè)人都習(xí)慣犯一些重復(fù)性的錯(cuò)誤。這類題目在編碼是記實(shí)下來,可以在審查的時(shí)候用作檢查的依據(jù)。 (3)在反復(fù)記實(shí)筆記并在審查中發(fā)現(xiàn)類似的題目后,該類題目泛起率會(huì)明顯下降 10. 使用好的工具進(jìn)行輕量級(jí)的代碼審查 “工欲善其事,必先利其器”。我們使用的是bitbucket提供的代碼托管服務(wù)。 每個(gè)團(tuán)隊(duì)成員獨(dú)立開發(fā)功能,然后利用Pull Request的形式將代碼提交給審查者。復(fù)審者可以很利便在網(wǎng)頁上閱讀代碼,添加評(píng)論等,然后原作者會(huì)自動(dòng)收到郵件提醒,對(duì)審視的意見進(jìn)行討論。 即使團(tuán)隊(duì)成員分布在天南海北,利用bitbucket提供的工具也能很好的進(jìn)行代碼審查。 |
|