Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
May 14, 2020 12:56 pm GMT

We need to talk about code reviews

Recently, a friend start to discuss with me about some approaches used when developers review his code. He seemed angry about some comments so I decided to do this post, expressing my opinion about things that he said and I frequently saw and read in blogs.

The trampoline

So, you are developing a feature, put your code for review, the reviewer made some comments, you complete the suggestions, the reviewers accept your changes (The LOOKS GOOD moment) and you push your code. But ... lets talk about the real world.

You develop your feature, and very excited you put your code for review, the review started ... The reviewers made some comments and suggestions some trivial and others not so easy neither clear. You started to address the suggestions and ask for clarification and talk why you cannot did some things. Your updates are good but looking to your new code, there are some things that the reviewers found that they dont like about your first code. You again made the suggested changes, but new problems are found and this cycle repeats...

The big problem here is that in each interation, new problems are addressed, causing a infinite loop in the review, and you might be thinking: "Ok, sometimes the code needs to be improved, its impossible to avoid those things" although there are a million of reasons for this happens, I think that some common factors to this happen is when your team do not have good guidelines and patterns to review the code or when the comments made by the reviewers are so complicated to understand, and the author cannot achieve the goal.

The whole process needs to be clear for both sides, in the mind of the reviewer needs to be clear the list of things that needs to be completed in order to finish the task, and for the author what things that he need to do to complete the task.

The nitpick comments

I don't know if you passed through for this situation, but usually if your code have four spaces instead of two, if you don't have a blank line at the end of the file you'll receive: NIT: {comment}

What do you think about this? These tasks seems things easily replaced for an automated checker, things like prettier and eslint are so useful. If my team pass for this situation, may i should ask myself we really have good style guidelines? and we are also providing some automated solution?

The divergent reviews

Beyond the fact quoted in the previous topic if my team doesn't have good style guidelines and a more methodic method to review, probably different reviewers will have different opinions, if all the team doesn't know what the priorities, or the best practices, How are they will agree?

Whithout time, bro

Sometimes you see yourself leaving the review for a time that you can look well and your mind is in the right place. Maybe the review is large or the architecture is complex or is a breaking change, right?

Right, but nobody wants to be blocked, if the code is not in production, what the value it have?

Of course, there are many reasons to cause this, but if you are an author try to split your reviews in small pieces, and make sure that the purpose is really clear. And if you are a reviewer ensure that you have a piece of your time to review the things.


Original Link: https://dev.to/fannyvieira/we-need-to-talk-about-code-reviews-31oa

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To