文章分享自公眾號(hào)： DevOps云學(xué)堂
如何在代碼審查方面表現(xiàn)出色
在本文中，我們將簡(jiǎn)要介紹13種代碼審查標(biāo)準(zhǔn)，這些標(biāo)準(zhǔn)可以極大地幫助改善軟件的運(yùn)行狀況并保持開發(fā)人員滿意。
顧名思義，代碼審查是一個(gè)過程，其中一個(gè)或多個(gè)開發(fā)人員審查或篩選另一位開發(fā)者（作者）編寫的代碼，以確保：
- 代碼沒有任何錯(cuò)誤或問題。
- 符合所有質(zhì)量要求和標(biāo)準(zhǔn)。
- 代碼執(zhí)行了預(yù)期的測(cè)試。
- 合并后，它將使代碼庫(kù)的運(yùn)行狀況保持更好。
這就是為什么代碼審查是軟件開發(fā)的關(guān)鍵部分的原因。代碼審閱者充當(dāng)代碼庫(kù)管理員，負(fù)責(zé)確定代碼是否處于要成為代碼庫(kù)的一部分并進(jìn)入生產(chǎn)的狀態(tài)。
Google以其卓越的技術(shù)而著稱，它們具有有效的代碼審查標(biāo)準(zhǔn)，這些標(biāo)準(zhǔn)似乎突出了審查代碼時(shí)要記住的一些要點(diǎn)。在Google，代碼審查的主要目的是確保Google代碼庫(kù)的整體代碼運(yùn)行狀況隨著時(shí)間的推移而不斷改善。
這是您在查看更改列表時(shí)要記住的事項(xiàng)列表。
審查標(biāo)準(zhǔn)
1.該代碼改善了系統(tǒng)的整體運(yùn)行狀況
每個(gè)更改列表（Pull Request）都會(huì)改善系統(tǒng)的整體運(yùn)行狀況。想法是，由于進(jìn)行了如此小的改進(jìn)，每次合并后，軟件或代碼庫(kù)的運(yùn)行狀況都會(huì)得到改善。
2.快速的代碼審查，響應(yīng)和反饋
首先，不要延遲推送（合并）更好的代碼。不要指望代碼是完美的。如果它的狀況可以改善系統(tǒng)的整體運(yùn)行狀況，則請(qǐng)推送。
“這里的關(guān)鍵是沒有'完美'的代碼，只有更好的代碼?！?/p>
如果您不在一項(xiàng)重點(diǎn)任務(wù)的中間，那么請(qǐng)?jiān)诖a完成后立即進(jìn)行檢查；但是，一個(gè)工作日是響應(yīng)拉取請(qǐng)求所需的最長(zhǎng)時(shí)間。預(yù)計(jì)變更列表將在一天之內(nèi)獲得多輪的部分/完整代碼審查。
3.在代碼審查期間進(jìn)行教育和啟發(fā)
通過盡可能共享知識(shí)和經(jīng)驗(yàn)，在代碼審查期間提供指導(dǎo)。
4.審查代碼時(shí)遵循標(biāo)準(zhǔn)
始終牢記，編碼標(biāo)準(zhǔn)此類文檔是代碼審查期間的絕對(duì)權(quán)威。例如，要在制表符和空格之間保持一致性，可以引用編碼約定。
5.解決代碼審查沖突
通過遵循樣式指南和編碼標(biāo)準(zhǔn)文檔中商定的最佳實(shí)踐，并尋求其他在產(chǎn)品領(lǐng)域具有更多知識(shí)和經(jīng)驗(yàn)的人的建議，來解決沖突。根據(jù)嚴(yán)重性，處理沖突有所不同。
如果您的評(píng)論是可選的或次要的，請(qǐng)?jiān)谠u(píng)論中進(jìn)行說明，然后由作者決定是解決還是忽略它們。作為代碼審閱者，您至少可以建議在沒有樣式指南或編碼標(biāo)準(zhǔn)的情況下，更改列表（請(qǐng)求）與其余代碼庫(kù)保持一致。
6.演示UI更改是代碼審查的一部分
如果更改列表（Pull Request）更改了用戶界面，則除了代碼查看之外，還必須進(jìn)行演示以確保外觀上的所有外觀均符合預(yù)期并與模擬匹配。
對(duì)于前端變更列表（Pull Request），始終建議進(jìn)行演示/演練，或確保變更列表還包括必要的UI自動(dòng)化測(cè)試，以驗(yàn)證添加/更新的功能。
7.確保代碼審查伴隨所有測(cè)試
除非緊急情況，否則拉取請(qǐng)求（更改列表）應(yīng)伴隨所有必要的測(cè)試，例如單元，集成，端到端等。
緊急情況可能是需要盡快修復(fù)的錯(cuò)誤或安全漏洞，以后可以添加測(cè)試。在這種情況下，請(qǐng)確保創(chuàng)建了適當(dāng)?shù)膯栴}，并確保有人在完成熱修復(fù)或部署后立即擁有所有權(quán)才能完成。
沒有足夠的理由跳過測(cè)試。如果由于時(shí)間限制，某些目標(biāo)有無法實(shí)現(xiàn)的風(fēng)險(xiǎn)，那么解決方案不是跳過測(cè)試，而是要對(duì)可交付成果進(jìn)行范圍界定。
8.專注時(shí)，不要打擾自己進(jìn)行代碼審查
如果您正處于重點(diǎn)工作中，請(qǐng)不要打擾自己，因?yàn)檫@可能需要很長(zhǎng)時(shí)間才能恢復(fù)正常。換句話說，打斷專注的開發(fā)人員所付出的代價(jià)比讓開發(fā)人員等待代碼審查要高得多。在計(jì)劃的休息時(shí)間（例如午餐，咖啡等）之后進(jìn)行代碼檢查。
期望并非總是在同一天完成并合并整個(gè)代碼審查過程。重要的是迅速給作者一些反饋。例如，您可能無法進(jìn)行完整的檢查，但是您可以快速指出一些可以研究的內(nèi)容。這將極大地減少代碼審查期間的挫敗感。
9.復(fù)習(xí)一切，不要做任何假設(shè)
查看分配給您檢查的每一行代碼。不要對(duì)人工編寫的類和方法做任何假設(shè)，并且應(yīng)該確保您了解代碼在做什么。
確保了解您正在檢查的代碼。如果沒有，請(qǐng)進(jìn)行澄清或要求代碼演練/解釋。如果您有部分代碼不具備審閱的資格，請(qǐng)確保還有其他合格的開發(fā)人員可以審閱代碼的那些部分。
10.回顧代碼時(shí)要顧全大局
從更廣泛的背景來看變化通常是有幫助的。例如，更改了文件，并添加了四行代碼。不要只查看四行代碼；相反，請(qǐng)考慮查看整個(gè)文件并檢查新添加的內(nèi)容。它們會(huì)降低現(xiàn)有代碼的質(zhì)量，還是會(huì)使現(xiàn)有功能成為重構(gòu)的候選對(duì)象？
如果不在函數(shù)/方法或類的上下文中檢查此類簡(jiǎn)單的添加項(xiàng)，則隨著時(shí)間的流逝，您將繼承一個(gè)類，該類是不可維護(hù)的，超級(jí)復(fù)雜的，難以測(cè)試的，無法完成的所有工作，并且難以擴(kuò)展或重構(gòu)。
請(qǐng)記住，隨著時(shí)間的推移，很少的改進(jìn)加起來就可以產(chǎn)生具有最少數(shù)量缺陷的優(yōu)質(zhì)產(chǎn)品，同樣，隨著時(shí)間的流逝，輕微的代碼降級(jí)或技術(shù)負(fù)擔(dān)也會(huì)加重并導(dǎo)致產(chǎn)品難以維護(hù)和擴(kuò)展。
11.認(rèn)可并鼓勵(lì)代碼評(píng)審期間的良好工作
如果您在變更列表中看到了一些不錯(cuò)的東西，請(qǐng)別忘了喊出作者的出色作品并鼓勵(lì)他們。這是我個(gè)人以前從未做過的事情。代碼審查的目的不僅應(yīng)該是發(fā)現(xiàn)錯(cuò)誤，還應(yīng)該鼓勵(lì)和指導(dǎo)開發(fā)人員所做的出色工作。
12.在代碼審查中要謹(jǐn)慎，尊重，友善和清晰
至關(guān)重要的是，在代碼審閱期間，您要善良，清晰，禮貌和尊重，同時(shí)也要對(duì)作者非常清楚和樂于助人。查看代碼時(shí)，請(qǐng)確保對(duì)代碼而不是開發(fā)人員做出評(píng)論。
13.解釋您的代碼審查注釋，并牢記范圍
每當(dāng)代碼審閱意見提出替代方法或進(jìn)行標(biāo)記時(shí)，至關(guān)重要的是要解釋原因并根據(jù)您的知識(shí)和經(jīng)驗(yàn)提供示例，以幫助開發(fā)人員了解您的建議將如何幫助提高代碼質(zhì)量。
當(dāng)建議修復(fù)或更改時(shí)，請(qǐng)?jiān)谌绾沃笇?dǎo)作者修復(fù)代碼方面找到適當(dāng)?shù)钠胶?。例如，我很欣賞指導(dǎo)，解釋，一些提示或建議，而不是整個(gè)解決方案。
以上就是W3Cschool編程獅關(guān)于Google鼓勵(lì)的13條代碼審查標(biāo)準(zhǔn)的相關(guān)介紹了，希望對(duì)大家有所幫助。
