代碼走查和代碼審查

什么是代碼審查？ (What are Code Reviews?)

A Code Review is essentially what it sounds like: a review of code before it is approved/accepted into the codebase. The general flow goes like this; an engineer writes some code in order to fix a bug/address some item of work. The engineer sends out a Code Review/Pull Request, basically asking for their changes to be accepted into the main body of project. One or more other engineers review the code changes, leaving comments/feedback, and either approves or rejects the changes. Rejection is often a temporary state asking for the comments/feedback to be addressed and the updated changes submitted again for approval.

本質上，代碼審查聽起來像是：在批準/接受代碼庫之前對代碼進行審查。 總體流程如下： 工程師編寫一些代碼來修復錯誤/解決某些工作。 工程師發出一個“代碼審查/拉取請求”，基本上是要求他們的更改被接受到項目主體中。 一個或多個其他工程師檢查代碼更改，留下評論/反饋，然后批準或拒絕更改。 拒絕通常是一種臨時狀態，要求處理評論/反饋，并再次提交更新的更改以供批準。

The idea of this flow is to ensure that code entering the project meets a variety of expectations and standards, enforced by everyone on the team. The requirements being enforced often include coding style standards, unit/other testing, and general code quality. This process also provides an opportunity to spot check the code for any potential bugs, logic issues or other problems. It is common for this approval gate to require at least two other engineer’s approval before the code changes are allowed to move forward. But all parts of this process vary significantly team by team.

該流程的目的是確保進入項目的代碼滿足團隊中每個人都執行的各種期望和標準。 強制執行的要求通常包括編碼樣式標準，單元/其他測試以及常規代碼質量。 此過程還提供了機會來檢查代碼是否存在任何潛在的錯誤，邏輯問題或其他問題。 通常，在允許更改代碼進行之前，此批準門通常需要至少兩個其他工程師的批準。 但是此過程的各個部分在團隊之間差異很大。

Code Reviews should not be the place where feature/implementation design feedback is discussed. This should happen long before code starts to be written.

代碼評審不應成為討論功能/實現設計反饋的地方。 這應該早在開始編寫代碼之前發生。

他們還提供什么其他好處？ (What Other Benefits Do They Offer?)

As outlined above, Code Reviews provide a number of quality gate, process, and standardization benefits. But there are many more, often less appreciated, potential benefits to the team, the resulting code, and the project as a whole. These are just my top three.

如上所述，代碼審查提供了許多質量控制，過程和標準化方面的好處。 但是，對于團隊，所產生的代碼以及整個項目而言，還有很多(通常是很少被人們所理解的)潛在利益。 這些只是我的前三名。

分享項目知識 (Sharing project knowledge)

Code Reviews are a great way to broadcast detailed knowledge about what changes are happening on a project. Having knowledge shared through the team versus locked up in silos (worst case in silos of one), has a very tangible impact on a project’s momentum and future. For those on the team actively participating in the Code Reviews, it acts as a ‘news beat’ or a pulse of the changes flowing into the codebase. This enables engineers to both stay up to date on how things work, but also allows them to plan their current and future work by taking these changes into account. For example, seeing an area of code is changing can help avoid conflicts if another engineer is about to make changes in the same area. Additionally, it may influence the implementation details of their next task if there is overlap.

代碼審查是一種傳播有關項目中正在發生的更改的詳細知識的好方法。 通過團隊共享知識，而不是陷入孤島( 最壞的情況是一個孤島 )，對項目的發展勢頭和未來產生了非常明顯的影響。 對于那些積極參與代碼審查的團隊而言，它就像是“新聞快訊”或流向代碼庫的變更脈動。 這使工程師不僅可以隨時了解工作原理，還可以通過考慮這些變化來計劃當前和將來的工作。 例如，如果另一個工程師要在同一區域進行更改，那么查看代碼區域是否正在更改可以幫助避免沖突。 此外，如果有重疊，可能會影響其下一個任務的實現細節。

On top of all of this, if your project involves an element of on-call rotation for handling live site issues/incidents, then Code Reviews provide a heads up for changes about to be deployed to Production. The on-call engineer can use the feed of incoming code changes to raise their awareness of what is changing. This helps speed up the identification of the source of issues if things start to fail in Production. When incidents occur, it is often due to changes somewhere in the pipeline.

最重要的是，如果您的項目涉及用于處理現場現場問題/突發事件的呼叫輪換元素，則代碼審查會提供有關即將部署到生產中的更改的提示。 待命工程師可以使用傳入代碼更改的提要來提高他們對更改內容的意識。 如果生產中開始出現故障，這有助于加快問題來源的識別。 發生事件時，通常是由于管道中某處的更改。

教書的機會 (Opportunities to teach)

Having a gate blocking unreviewed code changes going in helps ensure the health and quality of the codebase. But keeping the quality of code high requires continuous learning and education across the whole team. Code Reviews provide a direct and explicit way for the senior members of the team to teach those that are more junior. The very intent of a Code Review is to seek feedback and make the necessary changes before the code is considered ready. This explicitness removes some of the awkward barriers around providing feedback. In the context of a Code Review, the feedback is not unwarranted or unprovoked criticism. It is sought after and discussed in a public venue. This transparency helps ensure that the feedback provided is constructive and allows the feedback itself to be reviewed and critiqued.

有一個門來阻止未審查的代碼更改，有助于確保代碼庫的健康和質量。 但是要保持較高的代碼質量，需要整個團隊不斷學習和教育。 代碼審查為團隊的高級成員提供了直接和明確的方式來教那些初級的成員。 代碼審查的目的是在代碼準備就緒之前尋求反饋并進行必要的更改。 這種明確性消除了提供反饋方面的一些尷尬障礙。 在《規范審查》的背景下，反饋并非無端或無端的批評。 在公共場所受到追捧和討論。 這種透明性有助于確保所提供的反饋具有建設性，并允許對反饋本身進行審查和評論。

Encouraging this culture of asking for, providing, and accepting feedback as part of the standard process helps the team move forward in a unified way. Many senior engineers will eagerly take the opportunity to help drive the team’s standards, mentor those more junior to the codebase, and lead by example. And this is a great growth opportunity for them.

鼓勵在標準流程中尋求，提供和接受反饋的這種文化有助于團隊以統一的方式前進。 許多高級工程師將熱切地抓住機會，幫助推動團隊的標準，指導那些對代碼庫更初級的人，并以身作則。 對于他們來說，這是一個巨大的增長機會。

學習機會 (Opportunities to learn)

Receiving constructive feedback directly on the code you are developing is a great way to keep you focused on code quality. But Code Reviews offer other, more fruitful, ways to learn too.

直接接收有關正在開發的代碼的建設性反饋是使您專注于代碼質量的好方法。 但是Code Review還提供了其他更有效的學習方法。

Code Reviews are a great opportunity for those new to a codebase to see how the more seasoned on the team work. By taking the time to peruse current and existing Code Reviews, an engineer can get insight into how the team operates and how specific engineers approach problems. It is a good way to get exposure to different coding styles, problem solving and design patterns, and the inner workings of a system. As well as to observe the etiquette of the team, both in how they give and receive feedback, as well as adherence to coding standards and other expectations. Ideally, the Code Reviews should also provide specific context on the code being observed and discussion/feedback around the choices made, versus trying to wade through an enormous codebase without a guide.

對于那些剛接觸代碼庫的人來說，代碼審查是一個很好的機會，以了解團隊中經驗更豐富的人員如何工作。 通過花時間仔細閱讀當前和現有的代碼審查，工程師可以洞悉團隊的運作方式以及特定工程師如何解決問題。 這是接觸不同編碼風格，問題解決和設計模式以及系統內部工作的好方法。 除了觀察團隊的禮節外，他們如何提供和接收反饋，以及遵守編碼標準和其他期望。 理想情況下，代碼審查還應該提供有關正在觀察的代碼的特定上下文以及圍繞所做選擇的討論/反饋，而不是嘗試在沒有指南的情況下瀏覽龐大的代碼庫。

Given all these reasons I strongly encourage every engineer on my team to carve out time to participate in Code Reviews. Whether they are seniors helping raise the standards and educate others, juniors looking to expand their experience and exposure to other’s code, or anyone wanting to keep relevant on the changes flowing into a project. There is a lot of information to be gained by being a part of those discussions.

出于所有這些原因，我強烈鼓勵團隊中的每位工程師花時間參加代碼審查。 無論他們是幫助提高標準和教育他人的高年級學生，還是希望擴大他們的經驗并接觸他人法規的大三學生，還是任何想與項目變更保持聯系的人。 作為這些討論的一部分，可以獲得很多信息。

翻譯自: https://towardsdatascience.com/the-other-reasons-code-reviews-are-a-good-idea-e57399499558

代碼走查和代碼審查

總結

以上是生活随笔為你收集整理的代码走查和代码审查_代码审查是个好主意的其他原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。