Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Code Review Best Practices

DZone's Guide to

Code Review Best Practices

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Code review is a great software instrument and you should definitely use it to improve the quality of your code. But like any other tool, it may be misused sometimes. That’s why I came up with a list of best practices to guide you when reviewing your peers’ code.

  1. Code review is not testing: Code review is a developer-to-developer business and it doesn’t involve any testing. Code review should check if the task requirements are met in the cleanest possible way.
  2. You don’t tell what to code review: The same way you don’t tell a tester what to test, you should never tell your peer what to review. The magic of peer review comes from your peer own perspective on the current task design and implementation. Two minds are always better than one.
  3. You should always check all changes: Bugs may be hidden anywhere and you should search for them diligently. To have the whole picture you need to go through all changes.
  4. Requirements first: Requirements are the most important driving force. After all that’s what the customer is paying for. If the current changes are suboptimal you need to reopen the issue. If you happen to spot other code sections that need to be refactored you should create new issues instead of reopening the current one. The “single responsibility principle” applies to tasks as well as to coding.
  5. One-to-many activity: If you can’t make sure you grasp the code change intention it’s safer to ask somebody else to review it further.
  6. A way of learning: Code review is a great learning technique especially on large projects. Ideally you should become familiar with every aspect of your project, but if the project is too large you can at least specialize in multiple modules.

If you enjoy reading this article, you might want to subscribe to my newsletter and get a discount for my book as well.

Vlad Mihalcea's Newsletter

If you enjoyed this article, I bet you are going to love my book as well.






Happy code reviewing!

 

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
java ,devops ,tips and tricks

Published at DZone with permission of Vlad Mihalcea. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}