• 8 Tips for Great Code Reviews
  • Written by Kelly Sutton
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: xiaoxi666
  • Proofreader: Augustwuli, Raoul1996

If you’d like to receive the latest updates to this series of blogs, please join our community of hundreds of developers andSubscribe to my column.

One thing schools don’t teach you is how to do code reviews. You learn about algorithms, data structures, and programming language basics, but no one sits down and says, “Here’s something you can do to give better feedback.”

Code review is a critical step in the process of writing good software. Code review is about making it as high quality and bug-free as possible. There are other benefits to having a good code review culture: you reduce bugs; Code reviews are also a great way to develop new members and share knowledge.

Assuming that

Before reading this article, it is necessary to make a few assumptions, as follows:

  • You work in a trusted environment, or you and your team are improving your trust.
  • You can give feedback in a non-code environment as well as within your team.
  • Your team wants to produce better code and understandsperfectIt’s a verb, not an adjective. We may find better solutions for tomorrow’s work, and we need to keep an open mind.
  • Your company values code quality and understands that quality code may not “go live” quickly. The “go live” reference is meant to illustrate that many times code that is not tested and reviewed may not actually work.

With these assumptions in mind, let’s move on to the body.

1. We are human

Know that other people have invested a lot of time in the code you’re going to review, and they want to make it better. Your colleagues are trying to express themselves, and no one wants to write crappy code.

It is difficult to remain objective. Be sure to always judge the code itself and try to understand the context. Minimize the negative effects of judgment. Don’t say:

The way you write it is confusing.

Try rephrasing it to address the code itself and add to your interpretation:

This method is a little confusing, can we give this variable a better name?

This example illustrates how we, as readers, feel about the code. It’s about us and how we interpret the code, not how or what the author intended to code it.

Each Pull Request has its own difficult communication. Try to find common ground with your teammates and work together to achieve better code.

If you’ve just met a team member and have some important feedback on a Pull Request, go through the code together. This will be a good opportunity to develop a relationship with colleagues. Work with each colleague in this way until you’re no longer self-conscious.

2. Automatic check

If a computer can decide and enforce a rule, let the computer do it. Debating whether to use a space or a ‘tabs’ is a waste of time. Instead, spend your time setting rules and agreeing on them. This is also an opportunity to see how the team handles “object or submit code” in a low-risk scenario.

Programming languages and modern tool flows have no shortage of ways to execute rules and apply them over and over again. In Ruby, there is Rubocop; In JavaScript, there’s esLint. Find a helper checker like the language and embed it in the build flow.

If you find your existing helper checker lacking, write your own! Custom rules are fairly simple. In Gusto, we use custom helper checking rules to catch deprecated uses of classes, or to appropriately remind people to follow some Sidekiq best practices.

3. Review by all members

It sounds like a good idea to give Shirley all the code reviews.

Shieley is a great bull and she has always known how to program effectively. She knows the inputs and outputs of the system and has been with the company longer than all the team members put together.

Just because Shirley understands something, however, does not mean that other team members do. When reviewing Shirley’s code, younger team members may be hesitant to point out certain issues.

I realized that dividing reviews among different members resulted in beneficial team dynamics and better code. The most telling comment a junior engineer made during a code review was, “I can’t read it.” This is an opportunity to make the code cleaner and simpler.

Promote code reviews across the team.

4. Keep it readable

In Gusto, we use GitHub to manage our projects. Every

Using MarkDown is a way to increase readability. GitHub and your tool of choice may have syntax highlighting, which is very friendly for reading snippets. Embed code with a pair of backquotes (‘) or add blocks of code with three backquotes (‘ ‘) for a better communication experience.

Take advantage of Markdown syntax (especially if you write code that includes comments). Doing so will help keep your comments specific and focused.

5. Give at least one positive comment

Code reviews are inherently negative. Let me know what’s wrong with the code before I post it online. That’s what code reviews are for. Developers put in the time to write code and expect you to show them how to do it better.

Always give at least one positive comment, and make it meaningful and personal. If someone finally solves a long-running problem, be thrilled. It could be something as simple as 👍 or “like one.”

Leaving a positive comment on every code review is a subtle reminder to work together. If we produce good code, we all benefit.

6. Offer alternatives

One thing I try to do, especially when I’m just learning a programming language and framework, is to implement [the same functionality] with alternatives.

Be careful. If said incorrectly, it can come across as arrogant or selfish: “This is how I make it happen.” Try to be objective and discuss the pros and cons of the alternatives you offer. If your project is great, it will help expand everyone’s technical horizons.

7. Delay is the key factor

It’s important to fix code quickly. (Here’s a rule to make it easier: Keep code small.)

Delaying code reviews for long periods of time reduces productivity and morale. Being assigned to review PR from three days ago can be uncomfortable. Oh, it’s true. What the hell am I doing? Repeatedly switch between context build environments. To correct this, you need to remind your team that progress depends on the team, not individuals. Force your team to pay attention to delays in code reviews and make them better.

If you want to reduce your own code review delays, I recommend following this rule: Review your code before writing any new code.

As a strategy for dealing directly with delays, try pairing during code reviews. Find a pair programming workbench or share screens to browse and review code. Use pairing to generate the solution so that everyone agrees on it.

8. Advice to pr promoters: Keep code small

During a code review, the quality of the feedback you receive is inversely proportional to the amount of code in the Pull Request.

To give convincing and constructive feedback, be aware that a smaller Pull Request is easier to read.

If you keep The Pull Request small enough to avoid The Teeth, you’ll need to communicate more broadly in context. How does this Pull Request fit into this week’s work of this month? What are we going to do next and how does the Pull Request advance the work? Discussions such as whiteboard programming and face-to-face discussions are important. A smaller Pull Request makes it harder to remember its context.

Different programming languages and teams define “small” differently. For my part, I try to keep the Pull Request under 300 lines of code.

conclusion

Hopefully these 8 tips will help you and your team do better code reviews. By improving your code review process, you can get better code, better team members, and better business.

What methods does your team use to conduct code reviews? Feel free to comment on my Twitter.

Need more blog info? Please check the series Feedback for Engineers.

Special thanks to Omar Skalli, Justin Duke and Emily Field for their feedback during the writing process.

If you want to get the latest updates to this series of blogs, join the developer community of hundreds and subscribe to my column.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.