托管代码和非托管代码_6种非技术最佳实践，可进行更好的代码审查

托管代码和非托管代码

The code review is simply one of the best software development practices. It provides many benefits, such as finding bugs, improving the quality, and sharing the knowledge throughout the team.

代码审查只是最佳的软件开发实践之一。 它提供了许多好处，例如发现错误，提高质量以及在整个团队中共享知识。

Performing code reviews isn’t straightforward, though. As a reviewer, you need to put yourself in the author’s shoes by understanding the context, how things work, and the purpose of the changes introduced and then following the technical solution.

但是，执行代码审查并非易事。 作为审阅者，您需要通过了解上下文，事物如何工作以及所引入的更改的目的，然后遵循技术解决方案来使自己陷入困境。

You may need to do even more than the author, like finding bugs, searching for alternative solutions, and comparing them. Coming up with a solution is one thing; seeking out more and comparing is another.

您可能需要比作者做更多的工作，例如查找错误，搜索替代解决方案并进行比较。 提出解决方案是一回事。 寻找更多并进行比较是另一回事。

The difficulties of code review aren’t limited to only technical reasons. A code review involves communication between multiple persons, emphasizing the need for critical thinking.

代码审查的困难不仅限于技术原因。 代码审查涉及多个人之间的沟通，强调需要批判性思维。

And most humans don’t do well when it comes to coping with criticism. Therefore code review becomes a slippery slope. A comment can either ruin or brighten the day of the author. In this article, I want to list six tips that help establish a delightful code-review experience for both the author and the reviewer.

而且大多数人在应对批评时表现不佳。 因此，代码审查成为一个滑坡。 评论可能会破坏作者的生活，也可能使作者感到高兴。 在本文中，我想列出六个技巧，这些技巧有助于为作者和审阅者建立令人愉快的代码审阅体验。

1.评论谦卑 (1. Comment Humbly)

Submitting code changes for review can be stressful because someone else will inspect the author’s work to critique it. Developers tend to own the code they write, which can cause the feedback to be taken personally, causing stress. There’s a simple solution to avoid this: Comment with a humble attitude. Below are two variations of input for the same line:

提交代码更改进行审查可能会很麻烦，因为其他人将检查作者的工作以对其进行批评。 开发人员倾向于拥有自己编写的代码，这可能导致反馈被个人采纳，从而产生压力。 有一个避免这种情况的简单解决方案：以谦逊的态度发表评论。 以下是同一行的两种输入变化：

Comment 1: “This is ugly! Why did you use an abstract class here? There’s no need to use it. You should use an interface instead.”

评论1 ：“这很丑！ 为什么在这里使用抽象类？ 不需要使用它。 您应该改用接口。”

Comment 2: “Is there a specific reason that we use an abstract class here? Using an interface here might be better since there aren’t any default implementations, and it doesn’t extend from any other class.”

评论2 ：“在这里使用抽象类是否有特定原因？ 在这里使用接口可能会更好，因为没有任何默认实现，并且它也不从任何其他类扩展。”

Can you spot the differences that make the second comment a better one? Let’s take a look:

您能找出使第二条评论更好的区别吗？ 让我们来看看：

以团队为单位负责变革 (Take responsibility for changes as a team)

The first comment uses a you-statement. But the second comment uses a we-statement, emphasizing that everyone in a team owns the code and is responsible for the changes, even if one member writes it.

第一条评论使用您的陈述。 但是第二条评论使用了我们的声明，强调团队中的每个人都拥有代码并负责更改，即使一个成员编写了代码也是如此。

专注于代码，而不是作者 (Focus on the code, not on the author)

The first comment accuses the author of the change, which puts them in a defensive position. That’s not a good start for improving the code quality.

第一条评论指责作者的更改，这使他们处于防御状态。 这不是改善代码质量的良好开始。

The second comment doesn’t make it personal. It states that there’s an abstract class, which is the main focus of the feedback. It also provides technical arguments for choosing interfaces, which helps with keeping the conversation about the code.

第二条评论并不具有个性。 它指出存在一个抽象类，这是反馈​​的主要焦点。 它还提供了用于选择接口的技术参数，这有助于保持有关代码的对话。

不要下结论 (Don’t jump to the conclusion)

The first comment immediately settles that an interface is better than an abstract class. On the other hand, the second comment doesn’t directly make a judgment. Instead, it challenges the author to compare the two alternatives. Who knows, maybe they have a valid reason to justify it.

第一条评论立即确定接口比抽象类更好。 另一方面，第二条评论不会直接做出判断。 相反，它挑战了作者比较这两种选择。 谁知道呢，也许他们有充分的理由对此进行辩护。

In summary, the first comment sabotages the communication and converts the review process to an unpleasant experience. In contrast, the second comment is opening up the collaboration.

总而言之，第一条评论破坏了交流，并将审核过程转变为令人不快的体验。 相反，第二条评论是开放合作。

2.复习欣赏 (2. Review to Appreciate)

Everyone likes a little appreciation for good work, and developers are no exception to this rule. Appreciating beautiful, clean code is an incredible tool at the hands of an experienced reviewer. Because with appreciation, a code review is no longer one-way, criticism-only feedback.

每个人都喜欢对出色的工作表示赞赏，开发人员也不例外。 在经验丰富的审阅者的手中，欣赏精美，干净的代码是一种了不起的工具。 因为有了赞赏，代码审查不再是单方面的，仅限批评的反馈。

Recognition increases the author’s morale, reduces stress, and motivates the author to process the input that requires changes to the code. The author will feel more comfortable when submitting a changeset for review in the future.

认可可以提高作者的士气，减轻压力，并激励作​​者处理需要更改代码的输入。 当将来提交变更集以进行审查时，作者会感到更加自在。

3.使用表情符号 (3. Use Emojis)

Code reviews are often an asynchronous, textual communication process. But some aspects of communication, such as emotions and intentions, are often lost while writing. To cope with that, we use emojis in our daily lives, such as when chatting or tweeting. So why not use them for code reviews?

代码审查通常是异步的文本交流过程。 但是交流的某些方面，例如情感和意图，在写作时常常会丢失。 为了解决这个问题，我们在日常生活中使用表情符号，例如聊天或发推文时。 那么，为什么不使用它们进行代码审查呢？

Here’s the emojis we use in our team. A Christmas tree() means the requested change is subjective and optional, such as personal preferences over variable names. More Christmas trees () say that the comment is more subjective, and the author can omit them. We use an owl when we want to learn more about a change rather than interrogating: “Why are you using this library here?” We scream () when we notice silly mistakes, such as typos. We clap hands () for the changes we like. And finally, when we complete the review, we celebrate it with .

这是我们在团队中使用的表情符号。 圣诞树()表示请求的更改是主观的和可选的，例如对变量名的个人偏好。 更多的圣诞树()表示评论更具主观性，因此作者可以忽略它们。 当我们想了解更多有关更改而不是询问时，我们会使用猫头鹰：“ owl为什么在这里使用此库？” 当我们发现愚蠢的错误(例如错别字)时，我们会尖叫()。 我们为喜欢的变化拍手()。 最后，当我们完成评论时，我们以celebrate庆祝。

We also use ad-hoc emojis to convey our intentions in a better way:

我们还使用临时表情符号以更好的方式传达我们的意图：

• “I don’t think this line is correct. Are you sure that it works?”
  “我认为这条线是不正确的。 您确定它有效吗？”
• I don’t think this line is correct. Are you sure that it works?
  我认为这行是不正确的。 您确定它有效吗？

It’s not easy to figure out the emotion in the first comment. The author can interpret it as rude or questioning, which can put him/her into a defensive position. But what you want from the author is to investigate and justify the functionality of the commented line. The second comment sets up a curious intention by just adding an emoji to the same sentence.

在第一条评论中弄清情感并不容易。 作者可以将其解释为粗鲁或质疑，这可能会使他/她处于防御状态。 但是您希望作者来研究并证明注释行的功能合理。 第二条注释只是通过在同一句子中添加表情符号来设置一个好奇的意图。

4.将相似的评论分组在一起 (4. Group Similar Comments Together)

It’s not helpful to post a comment for a similar mistake many times. It’s discouraging and can slow down the review tools. Each comment can also cause automatic emails to be sent to the author and other subscribers, which might quickly get disturbing.

多次针对类似错误发表评论并没有帮助。 它令人沮丧，并且可能会使审核工具变慢。 每个评论还会导致自动向作者和其他订户发送电子邮件，这可能会很快引起您的干扰。

Instead, you can consolidate them in a single comment, such as: “Typo in the object (multiple places).”

相反，您可以将它们合并为一个注释，例如：“对象中的错字(多个位置)。”

5.讨论面对面的分歧 (5. Discuss Disagreements in Person)

When there’s a disagreement that seems to take longer to resolve during a code review, the best action is to discuss the matter face to face with the author. Addressing issues in person saves both the reviewer and the author from unnecessary bickering, which causes stress and takes up time.

如果在代码审查期间似乎需要较长时间解决分歧，最好的措施是与作者面对面讨论此问题。 亲自解决问题可以使审阅者和作者免于不必要的争吵，从而避免产生压力并占用时间。

Invite your team’s tech lead to the face-to-face meeting as a tiebreaker if you and the author agree to disagree.

如果您和作者不同意，请您的团队的技术负责人作为决胜局参加面对面会议。

6.接受您没有编写最佳代码 (6. Accept That You Don’t Write the Best Code)

We software developers take great pride in the work we do. We love and own the code we write. We also want others to like our code as well.

我们的软件开发人员对我们所做的工作感到非常自豪。 我们喜欢并拥有我们编写的代码。 我们还希望其他人也喜欢我们的代码。

But this shouldn’t restrain you from having an open mind toward criticism. Your approach may not be the best one for the task, or it can have bugs. The whole goal of code review is to make the code — and thus the product — better. That’s the most crucial goal of the team.

但这不应该限制您对批评持开放态度。 您的方法可能不是完成任务的最佳方法，或者可能存在错误。 代码审查的总体目标是使代码(从而使产品)更好。 这是团队最关键的目标。

So there’s no need to take feedback personally at all. The best code is the one that each team member contributes, understands, and owns at the same level.

因此，根本没有必要亲自收集反馈。 最好的代码是每个团队成员在同一级别上贡献，理解和拥有的代码。

结论 (Conclusion)

Thanks for reading! I hope these are helpful to help you ace your next code review.

谢谢阅读！ 希望这些对您的下一次代码检查有所帮助。

翻译自: https://medium.com/better-programming/6-non-technical-best-practices-for-better-code-reviews-632d6b104302

托管代码和非托管代码