代碼走查和代碼審查

Code reviewing is an engineering practice used by many high performing teams. And even though this software practice has many advantages, teams doing code reviews also encounter quite a few code review pitfalls.

代碼審查是許多高性能團隊使用的一種工程實踐。 盡管這種軟件實踐有很多優點，但是進行代碼審查的團隊也遇到了很多代碼審查陷阱。

In this article, I explain the main code review pitfalls you should be aware of to ensure code reviewing does not slow your team down. Knowing which pitfalls and problems arise can help you to ensure a productive and effective code review experience. Those findings are based on a survey we conducted at Microsoft with over 900 participants.

在本文中，我將解釋您應注意的主要代碼審查陷阱，以確保代碼審查不會使您的團隊減速。 了解哪些陷阱和問題會幫助您確保產生高效的代碼審查經驗。 這些發現是基于我們在Microsoft進行的一項針對900多名參與者的調查得出的。

典型的代碼審查過程 (A typical code review process)

A typical tool-based code review process looks roughly like this: Once the developer has finished a piece of code, they prepare the code for being submitted for review. Then, they select reviewers who are notified about the review. The reviewers then review the code and give comments. The author of the code works on those comments and improves and changes the code accordingly. Once everybody is satisfied, or an agreement is reached, the code can be checked into the code base.

典型的基于工具的代碼審查過程大致如下：開發人員完成一段代碼后，便準備要提交以供審查的代碼。 然后，他們選擇被通知有關評論的評論者。 然后，審閱者審閱代碼并發表評論。 代碼的作者處理這些注釋，并相應地改進和更改代碼。 一旦每個人都滿意或達成協議，就可以將代碼檢入代碼庫。

In another post, I described how a typical code review process looks like at Microsoft.

在另一篇文章中，我描述了典型的代碼審查過程在Microsoft的情況。

代碼審查并不總是一個平穩的過程 (Code reviewing isn’t always a smooth process)

These steps read like a smooth process. But, like everything, in practice, things tend to be more complicated than anticipated. During the code review process there a quite a few pitfalls that can reduce the positive experience with code reviews for the whole team. If not done correctly, code reviewing can also take its tolls on the whole team’s productivity. So, let’s have a look at the difficulties and pitfalls of code reviews.

這些步驟讀起來很順利。 但是，實際上，就像一切一樣，事情往往比預期的要復雜。 在代碼審查過程中，有很多陷阱可以減少整個團隊進行代碼審查的積極經驗。 如果執行不正確，代碼審查也可能會損害整個團隊的工作效率。 因此，讓我們看一下代碼審查的困難和陷阱。

The two main types of code review pitfalls are about the time spent on code reviews, and the value code reviews provide.

代碼審查陷阱的兩種主要類型是代碼審查所花費的時間以及代碼審查所提供的價值。

Be aware of code review pitfalls. Otherwise, code reviews can slow your team down. Click To Tweet

注意代碼審查的陷阱。 否則，代碼審查會拖慢您的團隊。 點擊鳴叫

等待代碼審查反饋很痛苦 (Waiting for code review feedback is a pain)

One of the main pitfalls code authors face is to receive feedback in a timely manner. Waiting for the comments to come in and not being able to work on the code in the meanwhile can be a huge problem. Even though developers can pick up other tasks to work on, if the code review takes too long, it impacts the developer’s productivity and also the developer’s satisfaction.

代碼作者面臨的主要陷阱之一是及時接收反饋。 等待注釋進入而無法同時在代碼上工作可能是一個巨大的問題。 即使開發人員可以承擔其他工作，但如果代碼審查花費的時間太長，則會影響開發人員的工作效率以及開發人員的滿意度。

But, why does the code review feedback take so long?

但是，為什么代碼審查反饋需要這么長時間？

開發人員必須兼顧多項責任 (Developers have to juggle several responsibilities)

Well, code reviewing is not the only task the code reviewer has to perform. On the contrary, code reviewing — even though it can take a significant amount of time of a developer’s day-to-day work — is only one part of the responsibilities and tasks of a developer. So, it is very likely that the code reviewer is engaged in other activities and has to stop or finish those first before looking at the code review.

嗯，代碼審查不是代碼審查者必須執行的唯一任務。 相反，即使開發人員的日常工作可能要花費大量時間，代碼審查也只是開發人員職責和任務的一部分。 因此，代碼審查者很可能從事其他活動，并且必須先停止或完成那些活動，然后再查看代碼審查。

If the timing is not ideal, and especially if the code reviewer hasn’t anticipated this change coming along, chances are, it takes a while before they look at the review. Remote teams also have to be aware of time differences. Otherwise, code reviews might even take longer.

如果時機不理想，特別是如果代碼審閱者沒有預料到會發生這種變化，那么很可能需要一段時間才能查看審閱。 遠程團隊還必須意識到時差。 否則，代碼審查可能甚至需要更長的時間。

如果不將代碼審查視為實際工作，則開發人員將面臨問題 (Developers face problems if code reviews are not counted as actual work)

Time constraints are real, and they affect both, the code reviewer and the author of the code. Doing a proper code review takes time. If teams want developers to do code reviews but do not value or count the time developers spend on code reviews, this becomes a real problem.

時間限制是真實的，并且會影響代碼審閱者和代碼作者。 進行正確的代碼審查需要時間。 如果團隊希望開發人員進行代碼審查，但不重視或不考慮開發人員花費在代碼審查上的時間，那么這將成為一個真正的問題。

You can’t expect quality code reviews if you don’t value the time a developer spends on them. Click To Tweet

如果您不重視開發人員在代碼審查上花費的時間，就無法期望獲得高質量的代碼審查。 點擊鳴叫

不獎勵代碼審查工作和性能 (Not rewarding code reviewing efforts and performance)

It does not help to claim to value code reviews if you do not reward the effort developers spend on this task. Many companies focus on rewarding developers for the amount of code they write or the features they develop. This decreases the motivation and the ability of developers to do a good job helping each other (which includes code reviewing). Code review effort and performance should be a cornerstone for performance evaluation or promotion decisions.

如果您不獎勵開發人員在此任務上花費的精力，那么聲稱對代碼進行評估就無濟于事。 許多公司專注于獎勵開發人員編寫的代碼量或開發的功能。 這降低了開發人員做好彼此幫助的動力和能力(包括代碼審查)。 代碼審查工作和績效應成為績效評估或升級決策的基石。

If you want your team to do code reviews well, reward them for their work. Click To Tweet

如果您希望您的團隊對代碼進行良好的審查，則對他們的工作給予獎勵。 點擊鳴叫

社會因素和團隊動力 (Social factors and team dynamics)

But waiting on a code review had not always to do with the lack of time or missing reward system. Due to its social character, delayed reviews can be due to insecurities or team dynamics. Especially if the code review is overwhelming, or if the reviewer is new to the code, doing a code review can be overwhelming:

但是等待代碼審查并不總是與缺少時間或缺少獎勵系統有關。 由于其社交性質，延遲審核可能是由于不安全感或團隊動態所致。 尤其是如果代碼審查不勝枚舉，或者如果審查者是新來的代碼，那么進行代碼審查可能會很麻煩：

I’m expected to participate, but I’m not quite sure how. I’ll wait until someone else starts. — study participant

我預計會參加，但是我不確定如何參加。 我將等到其他人開始。 -研究參與者

大評論很難復習 (Large reviews are hard to review)

Another significant code review pitfall is large reviews. Imagine you are the reviewer, and you just got this review. You think, well, I am quickly going to look at that, but once you open the review, you see this large code change. Several files have been changed, and all changes tangle throughout the code base. What’s your first reaction?

另一個重要的代碼審查陷阱是大型審查。 假設您是審閱者，而您剛剛獲得了此審閱。 您認為很好，我很快就去研究一下，但是一旦您打開審閱，您就會看到這個巨大的代碼更改。 幾個文件已更改，所有更改在整個代碼庫中都纏在一起。 您的第一React是什么？

Probably: holy cow!

可能是：圣牛！

That’s right. That is exactly what we saw when analyzing thousands of code reviews. Not only does review time increase with the size of the code change, but also feedback quality decreases. Well, that’s probably understandable.

那就對了。 這正是我們在分析數千個代碼審查時所看到的。 評審時間不僅隨著代碼大小的變化而增加，而且反饋質量也會下降。 好吧，這可能是可以理解的。

10 lines of code = 10 issues.

10行代碼= 10個問題。

500 lines of code = “looks fine.”

500行代碼=“看起來不錯”。

Code reviews.

代碼審查。

— I Am Devloper (@iamdevloper) November 5, 2013

— I Am Devloper(@iamdevloper) 2013年11月5日

Large code changes are just incredibly difficult to review. If, in addition, the code reviewer is not that familiar with the part of the code base the change took place in, reviewing can quickly become a nightmare.

大型代碼更改非常難以審核。 此外，如果代碼檢查者對更改所基于的代碼庫部分不太熟悉，那么檢查很快就會成為噩夢。

Large code reviews are hard to review. The quality of the review decreases with the size of the change, thus limiting the value teams get out of from code reviews. Click To Tweet

大代碼審查很難審查。 評審的質量隨著更改的大小而降低，從而限制了價值團隊從代碼評審中脫身的價值。 點擊鳴叫

了解代碼更改需要一些指導 (Understanding code changes needs some guidance)

Understanding code changes, and especially the motivation for a code change, is another code review pitfall many reviewers face. If there is no description explaining the purpose of the change, code reviewing becomes much harder. We saw in the study that if the code reviewer does not understand the code change, or if she is overwhelmed by the amount of change, she cannot give insightful feedback.

了解代碼更改，尤其是代碼更改的動機，是許多審閱者面臨的另一個代碼審閱陷阱。 如果沒有說明來說明更改的目的，則代碼審查將變得更加困難。 我們在研究中看到，如果代碼審閱者不理解代碼更改，或者如果她對更改量感到不知所措，那么她將無法提供有見地的反饋。

It’s just this big incomprehensible mess. Then you can’t add any value because they are just going to explain it to you and you’re going to parrot back what they say.

就是這么大的不可理解的混亂。 然后，您將無法添加任何價值，因為他們只會向您解釋它，而您會模仿他們的話。

— interviewed developer13

—采訪了developer13

沒有獲得有價值的反饋會降低開發人員從代碼審查中獲得的利益和動力 (Not getting valuable feedback decreases the developers’ benefit from and motivation for code reviews)

Without doubt, spending the time on code reviews and not getting useful feedback back is a problem. Even though the team might still benefit from the knowledge transfer, the developer’s motivation to do code reviews and the benefits from code reviews decrease when they do not get valuable feedback.

毫無疑問，將時間花在代碼審查上并沒有得到有用的反饋是一個問題。 即使團隊仍然可以從知識轉移中受益，但是當開發人員沒有獲得有價值的反饋時，他們進行代碼審查的動機和代碼審查的好處就會減少。

There are several reasons why reviewers do not or can’t give insightful feedback. It can be that the code reviewer did not have the right expertise. Another common reason is that the reviewer did not have enough time to look thoroughly through the change.

審稿人沒有或無法提供有見地的反饋有多種原因。 可能是代碼檢查者沒有適當的專業知識。 另一個常見原因是審閱者沒有足夠的時間來徹底了解更改。

Maybe the code reviewer does not understand the code. It can also be that the code reviewer does not know what issues to look for. Understanding what makes for valuable code review feedback and implementing best practices mitigates this pitfall.

也許代碼審查者不理解代碼。 也可能是代碼審閱者不知道要查找什么問題。 了解什么能使有價值的代碼審查反饋有效，并實施最佳實踐可以減輕這種陷阱。

一旦主要的討論是關于樣式，就需要采取行動 (Once the main discussion is about styling, you need to act)

Another problem that can happen during a code review is called bikeshedding. Bikeshedding means that developers focus on smaller issues and start disputing minor issues and overlook the serious ones.

在代碼審查期間可能發生的另一個問題稱為Bikeshedding。 Bikeshedding意味著開發人員專注于較小的問題，并開始爭論較小的問題，而忽略了嚴重的問題。

The reasons for that are manifold. Common behind the scenes challenges that lead to bikeshedding is that developers do not understand the code change or that they do not have enough time for the code reviews. Sometimes bikeshedding can be a sign that there are issues with the team dynamics.

原因是多種多樣的。 導致脫機的幕后常見挑戰是，開發人員不了解代碼更改，或者他們沒有足夠的時間進行代碼審查。 有時，騎車流失可能表明團隊動力存在問題。

If people dispute about minor issues during code reviews, you have to take a look at the underlying issue. Time pressure, too large reviews, rivalry? Click To Tweet

如果人們在代碼審查期間對次要問題提出異議，則必須查看潛在問題。 時間壓力，太大的評論，競爭？ 點擊鳴叫

達成共識可能需要面對面的討論 (Reaching consensus might need a face-to-face discussion)

Sometimes it can happen that it is hard to reach a consensus. This can occur between code reviewer and code author, or also between several code reviewers directly. Such situations must be handled carefully as team dynamics are closely connected to these happenings. Communication via tools and in written form can aggravate this problem. If there seems to be any tension, or contentious issues to discuss, switching to face-to-face (either in person or via a video call) might be a good idea.

有時可能很難達成共識。 這可以在代碼審閱者和代碼作者之間發生，也可以直接在多個代碼審閱者之間發生。 由于團隊動態與這些情況密切相關，因此必須謹慎處理這種情況。 通過工具和書面形式進行的交流會加劇這個問題。 如果似乎存在任何緊張關系或有待討論的問題，那么(面對面或通過視頻通話)面對面交流是一個好主意。

代碼審查的好處勝于努力 (The benefits of code review outweigh the effort)

I hope this list of code review pitfalls did not change your mind about code reviews. Because, the good news is that if you are aware of the code review pitfalls and counteract them, code reviews are a very beneficial engineering technique. And, there are even more proven ways to work effectively with code reviews.

我希望這份代碼審查陷阱清單不會改變您對代碼審查的看法。 因為，好消息是，如果您知道代碼審查的陷阱并加以彌補，那么代碼審查是一種非常有益的工程技術。 而且，還有更多行之有效的方式來與代碼審查一起使用。

代碼審查最佳實踐 (Code review best practices)

In the next blog post in this code review series, I show best practices to help to minimize the code review pitfalls and challenges and ensure your team gets the best out of the code review practice. So keep on reading. To be notified when I publish the next post, follow me on twitter.

在此代碼審查系列的下一篇博客文章中，我將展示最佳實踐，以幫助最大程度地減少代碼審查的陷阱和挑戰，并確保您的團隊從代碼審查實踐中獲得最大的收益。 因此，請繼續閱讀。 要在我發布下一篇文章時得到通知，請在Twitter上關注我。

I prepared an exclusive Code Review e-Book for my newsletter subscribers. So make sure you subscribe to my email list and secure your Code Review e-Book including a handy cheat sheet of code review best practices.

我為通訊訂閱者準備了獨家的Code Review電子書。 因此，請確保您已訂閱我的電子郵件列表，并確保您的《代碼審查》電子書安全，其中包括一份方便的代碼審查最佳實踐速查表。

Originally published at https://www.michaelagreiler.com on April 6, 2019.

最初于2019年4月6日發布在https://www.michaelagreiler.com 。

翻譯自: https://www.freecodecamp.org/news/how-to-avoid-code-review-pitfalls-that-slow-your-productivity-down-b7a8536c4d3b/

代碼走查和代碼審查

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的代码走查和代码审查_如何避免代码审查陷阱降低生产率的全部內容，希望文章能夠幫你解決所遇到的問題。

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