審查指南 最新版本

by Assaf Elovic

通過阿薩夫·埃洛維奇

代碼審查-最終指南 (Code Review — The Ultimate Guide)

構(gòu)建團(tuán)隊(duì)代碼審查流程的終極指南 (The ultimate guide for building your team’s code review process)

After conducting hundreds of code reviews, leading R&D teams and pushing several unintentional bugs myself, I’ve decided to share my conclusions for building the ultimate code review process for your team.

在進(jìn)行了數(shù)百次代碼審查，領(lǐng)導(dǎo)研發(fā)團(tuán)隊(duì)并親自解決了一些無意的錯(cuò)誤之后，我決定分享我的結(jié)論，以為您的團(tuán)隊(duì)構(gòu)建最終的代碼審查流程。

This article assumes you know what a code review is. So if you don’t, click here for a great intro.

本文假設(shè)您知道什么是代碼審查。 因此，如果您不這樣做， 請(qǐng)單擊此處獲取出色的介紹。

Let’s quickly state some straightforward reasons as to why you should do code reviews:

讓我們快速說明為什么要進(jìn)行代碼審查的一些直接原因：

Can help reduce bugs in code.

可以幫助減少代碼中的錯(cuò)誤。

Validate that all coding requirements have been filled.

驗(yàn)證是否已滿足所有編碼要求。

An effective way to learn from peers and get familiar with the code base.

向同齡人學(xué)習(xí)并熟悉代碼庫的有效方法。

Helps maintain code styling across the team.

幫助維護(hù)整個(gè)團(tuán)隊(duì)的代碼樣式。

Team cohesion — encourage developers to talk to each other on best practices and coding standards.

團(tuán)隊(duì)凝聚力-鼓勵(lì)開發(fā)人員就最佳實(shí)踐和編碼標(biāo)準(zhǔn)相互交流。

Improves overall code quality due to peer pressure.

由于同伴的壓力，提高了整體代碼質(zhì)量。

However, code reviews can be one of the most difficult and time-consuming parts of the software development process.

但是，代碼審查可能是軟件開發(fā)過程中最困難，最耗時(shí)的部分之一。

We’ve all been there. You might have waited days until your code was reviewed. Once it was reviewed you started a ping pong with the reviewer of resubmitting your pull request. All the sudden you’re spending weeks going back and forth. You are context switching between new features and old commits that still need polishing.

我們都去過那里。 您可能已經(jīng)等了幾天，直到代碼被審查。 一經(jīng)審核，您就可以與審核員開始乒乓球，重新提交您的拉取請(qǐng)求。 突然之間，您要花費(fèi)數(shù)周的時(shí)間來回移動(dòng)。 您正在新功能和仍需要完善的舊提交之間進(jìn)行上下文切換。

If the code review process is not planned right, it could have more cost than value.如果沒有正確計(jì)劃代碼審查流程，那么成本可能會(huì)超過價(jià)值。

This is why it’s extremely important to structure and build a well-defined process for code reviews within your engineering team.

這就是為什么在您的工程團(tuán)隊(duì)中構(gòu)造和建立定義良好的代碼審查流程極為重要的原因。

In general, you’ll need to have in place well-defined guidelines for both the reviewer and reviewee, prior to creating a pull request and while it’s being reviewed. More specifically:

通常，在創(chuàng)建拉取請(qǐng)求之前和正在審閱期間，您都需要為審閱者和受審者都制定明確的準(zhǔn)則。 進(jìn)一步來說：

定義用于創(chuàng)建拉取請(qǐng)求的條件。 (Define perquisites for creating pull requests.)

I’ve found that the following greatly reduces friction:

我發(fā)現(xiàn)以下可以大大減少摩擦：

Make sure code compiles successfully.

確保代碼成功編譯。

Read and annotate your code.

閱讀并注釋您的代碼。

Build and run tests that validate the scope of your code.

建立并運(yùn)行測(cè)試以驗(yàn)證代碼范圍。

All code in codebase should be tested.

代碼庫中的所有代碼都應(yīng)經(jīng)過測(cè)試。

Link relevant tickets/items in your task management tool (JIRA for example) to your pull request.

將任務(wù)管理工具(例如JIRA)中的相關(guān)票證/項(xiàng)目鏈接到您的請(qǐng)求請(qǐng)求。

Do not assign a reviewer until you’ve finalized the above.

在完成上述工作之前，請(qǐng)勿分配審閱者。

定義受審者職責(zé) (Define reviewee responsibilities)

While the reviewer is last in the chain of merging your PR, the better it’s handed over by the reviewee, the fewer risks you’ll run into in the long term. Here are some guidelines that can greatly help:

雖然審閱者在合并您的PR鏈中處于最后一位，但審閱者交出的越好，從長遠(yuǎn)來看，您遇到的風(fēng)險(xiǎn)就越少。 以下是一些可以大大幫助您的準(zhǔn)則：

Communicate with your reviewer — Give your reviewers background about your task. Since most of us pull request authors have likely been reviewers already, simply put yourself in the shoes of the reviewer and ask, “How could this be easier for me?”

與您的審閱者交流 —為您的審閱者提供有關(guān)您任務(wù)的背景。 由于我們大多數(shù)人的拉動(dòng)請(qǐng)求作者可能已經(jīng)是審稿人，所以只需將自己放在審稿人的面前，然后問：“這對(duì)我來說會(huì)更容易嗎？”

Make smaller pull requests — Making smaller pull requests is the best way to speed up your review time. Keep your pull requests small so that you can iterate more quickly and accurately. In general, smaller code changes are also easier to test and verify as stable. When a pull request is small, it’s easier for the reviewers to understand the context and reason with the logic.

提出較小的提取請(qǐng)求 - 提出較小的提取請(qǐng)求是縮短審核時(shí)間的最佳方法。 保持拉取請(qǐng)求較小，以便可以更快，更準(zhǔn)確地進(jìn)行迭代。 通常，較小的代碼更改也更易于測(cè)試和驗(yàn)證是否穩(wěn)定。 當(dāng)拉取請(qǐng)求較小時(shí)，審閱者更容易理解邏輯的上下文和原因。

Avoid changes during the code review — Major changes in the middle of code review basically resets the entire review process. If you need to make major changes after submitting a review, you may want to ship your existing review and follow-up with additional changes. If you need to make major changes after starting the code review process, make sure to communicate this to the reviewer as early in the process as possible.

避免在代碼檢查期間進(jìn)行更改 - 代碼檢查過程中的主要更改基本上會(huì)重置整個(gè)檢查過程。 如果您在提交評(píng)論后需要進(jìn)行重大更改，則可能需要發(fā)送現(xiàn)有的評(píng)論并進(jìn)行其他更改。 如果您需要在開始代碼審查過程之后進(jìn)行重大更改，請(qǐng)確保在過程中盡早將此信息告知審查者。

Respond to all actionable code review feedback — Even if you don’t implement their feedback, respond to it and explain your reasoning. If there’s something you don’t understand, ask questions inside or outside the code review.

響應(yīng)所有可操作的代碼審閱反饋 -即使您不執(zhí)行他們的反饋，也要對(duì)其進(jìn)行答復(fù)并解釋您的推理。 如果您不了解某些內(nèi)容，請(qǐng)?jiān)诖a審查的內(nèi)部或外部提出問題。

Code reviews are discussions, not dictation — You can think of most code review feedback as a suggestion more than an order. It’s fine to disagree with a reviewer’s feedback but you need to explain why and give them an opportunity to respond.

代碼審查是討論，而不是聽寫 -您可以將大多數(shù)代碼審查反饋視為建議，而不是命令。 可以不同意審閱者的反饋，但您需要解釋原因并給予他們回應(yīng)的機(jī)會(huì)。

定義審閱者職責(zé) (Define reviewer responsibilities)

Since the reviewer is last in the chain before merging the code, a great part of the responsibility is on him for reducing errors. The reviewer should:

由于審閱者在合并代碼之前是鏈中的最后一員，因此減少錯(cuò)誤的責(zé)任很大。 審稿人應(yīng)：

Be aware to the task description and requirements.

注意任務(wù)說明和要求。

Make sure to completely understand the code.

確保完全理解代碼。

Evaluate all the architecture tradeoffs.

評(píng)估所有架構(gòu)權(quán)衡。

Divide your comments into 3 categories: Critical, Optional and Positive. The first are comments that the developer must accept to change, and the latter being comments that let the developer know your appreciation for nice pieces of code.

將您的評(píng)論分為3類：關(guān)鍵，可選和肯定。 第一個(gè)是開發(fā)人員必須接受才能更改的注釋，第二個(gè)是使開發(fā)人員知道您對(duì)精美代碼的贊賞的注釋。

Also, avoid many comments and use Github review instead (see example below).

另外，請(qǐng)避免使用大量評(píng)論，而應(yīng)使用Github評(píng)論(請(qǐng)參見下面的示例)。

When you have several comments, you should use the review option in Github, instead of comment each of them separately, and notify the developer (PR owner) when you’re done.

當(dāng)您有多條評(píng)論時(shí)，應(yīng)使用Github中的review選項(xiàng)，而不是分別評(píng)論每條評(píng)論，并在完成后通知開發(fā)人員(公關(guān)所有者)。

Finally, I’ve found that asking the following questions is a great tool for an overall better and easier reviewing process:

最后，我發(fā)現(xiàn)提出以下問題對(duì)于整體上更好，更輕松地進(jìn)行審核是一個(gè)很好的工具：

• Am I having difficulty in understanding this code?
  我在理解此代碼時(shí)有困難嗎？
• Is there any complexity in the code which could be reduced by refactoring?
  代碼中是否存在可以通過重構(gòu)減少的復(fù)雜性？
• Is the code well organized in a package structure which makes sense?
  代碼是否合理地以有意義的包結(jié)構(gòu)進(jìn)行了組織？
• Are the class names intuitive and is it obvious what they do?
  類名是直觀的，并且它們的作用很明顯嗎？
• Are there any classes which are notably large?
  有沒有特別大的課程？
• Are there any particularly long methods?
  有沒有特別長的方法？
• Do all the method names seem clear and intuitive?
  所有方法名稱看起來清晰直觀嗎？
• Is the code well documented?
  該代碼是否有據(jù)可查？
• Is the code well tested?
  代碼是否經(jīng)過良好測(cè)試？
• Are there ways in which this code could be made more efficient?
  有什么方法可以使此代碼更有效？
• Does the code meet our teams styling standards?
  該代碼是否符合我們團(tuán)隊(duì)的樣式標(biāo)準(zhǔn)？

There are various effective and different code review practices that vary based on team’s needs. So assume this is my personal opinion and that there are other ways that might work for your team. In the end, building such a sensitive process should be subjective to your companies goals, team’s culture and overall R&D structure.

有多種有效且不同的代碼檢查實(shí)踐，具體取決于團(tuán)隊(duì)的需求。 因此，假設(shè)這是我的個(gè)人觀點(diǎn)，并且還有其他一些方法可以為您的團(tuán)隊(duì)工作。 最后，建立這樣一個(gè)敏感的流程應(yīng)該取決于您公司的目標(biāo)，團(tuán)隊(duì)的文化和整體研發(fā)結(jié)構(gòu)。

If you have any questions or feedback for improving these guidelines, please feel free to add a comment below!

如果您對(duì)改善這些準(zhǔn)則有任何疑問或反饋，請(qǐng)隨時(shí)在下面添加評(píng)論！

翻譯自: https://www.freecodecamp.org/news/code-review-the-ultimate-guide-aa45c358bbf5/

審查指南 最新版本

總結(jié)

以上是生活随笔為你收集整理的审查指南 最新版本_代码审查-最终指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。