How To Perform Code Reviews: -

1. The Standard of Code Review: -

The most important thing according to me in today's World is to perform code reviews as well as to nurture what the other person has written. It may be correcting him or explaining him about the changes he needs to make in his code.

Therefore it's really important to perform reviews on code and thus below are some important techniques and strategies on exactly how to correctly perform code reviews.

First, developers must be able to?make progress?on their tasks. If you never submit an improvement to the codebase, then the codebase never improves. Also, if a reviewer makes it very difficult for?any?change to go in, then developers are to make improvements in the future.

On the other hand, it is the duty of the reviewer to make sure that each Code is of such a quality that the overall code health of their codebase is not decreasing as time goes on. This can be tricky, because often, codebases degrade through small decreases in code health over time, especially when a team is under significant time constraints and they feel that they have to take shortcuts in order to accomplish their goals.

Also, a reviewer has ownership and responsibility over the code they are reviewing.?A key point here is that there is no such thing as “perfect” code—there is only?better?code. Reviewers should not require the author to polish every tiny piece of a code before granting approval. Rather, the reviewer should balance out the need to make forward progress compared to the importance of the changes they are suggesting. Instead of seeking perfection, what a reviewer should seek is?continuous improvement. A Code that, as a whole, improves the maintainability, readability, and understandability of the system shouldn’t be delayed for days or weeks because it isn’t “perfect”.

2. What to look for in a code review

a) Functionality: -

Mostly, we expect developers to test Code well-enough that they work correctly by the time they get to code review. However, as the reviewer you should still be thinking about edge cases, looking for concurrency problems, trying to think like a user, and making sure that there are no bugs that you see just by reading the code.

You?can?validate the Code if you want—the time when it’s most important for a reviewer to check a Coder's behavior is when it has a user-facing impact, such as a?UI Change. It’s hard to understand how some changes will impact a user when you’re just reading the code. For changes like that, you can have the developer give you a demo of the functionality if it’s too inconvenient to patch in the Code and try it yourself.

b) Complexity: -

Is the Code more complex than it should be? We tend to check this at every line as are individual lines too complex? Are functions too complex? Are classes too complex? “Too complex” usually means?“can’t be understood quickly by code readers.”?It can also mean?“developers are likely to introduce bugs when they try to call or modify this code.”

A particular type of complexity is?where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved?now, not the problem that the developer speculates?might?need to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.

c) Summary: -

• The code is well-designed.
• The functionality is good for the users of the code.
• Any UI changes are sensible and look good.
• Any parallel programming is done safely.
• The code isn’t more complex than it needs to be.
• The developer isn’t implementing things they?might?need in the future but don’t know they need now.
• Code has appropriate unit tests.
• Tests are well-designed.
• The developer used clear names for everything.
• Comments are clear and useful, and mostly explain?why?instead of?what.
• Code is appropriately documented.
• The code conforms to our style guides.

3. Speed of Code Reviews: -

• The velocity of the team as a whole is decreased.?Yes, the individual who doesn’t respond quickly to the review gets other work done. However, new features and bug fixes for the rest of the team are delayed by days, weeks, or months as each Coder waits for review and re-review.
• Developers start to protest the code review process.?If a reviewer only responds every few days, but requests major changes to the code each time, that can be frustrating and difficult for developers. Often, this is expressed as complaints about how “strict” the reviewer is being. If the reviewer requests the?same?substantial changes (changes which really do improve code health), but responds?quickly every time the developer makes an update, the complaints tend to disappear.?
• Code health can be impacted.?When reviews are slow, there is increased pressure to allow developers to submit code that are not as good as they could be. Slow reviews also discourage code cleanups and further improvements to existing Code's.

Speed vs. Interruption

There is one time where the consideration of personal velocity trumps team velocity.?If we are in the middle of a focused task, such as writing code, don’t interrupt yourself to do a code review.?Research has shown that it can take a long time for a developer to get back into a smooth flow of development after being interrupted. So interrupting yourself while coding is actually?more?expensive to the team than making another developer wait a bit for a code review.

Instead, wait for a break point in your work before you respond to a request for review. This could be when your current coding task is completed, after lunch, returning from a meeting, coming back from the breakroom, etc.

4. How To Write Code Review Comments: -

Giving Guidance

The main role here is portrayed by the Developer but we are not required to do detailed design of a solution or write code for the developer.

This doesn’t mean the reviewer should be unhelpful, though. In general you should strike an appropriate balance between pointing out problems and providing direct guidance. Pointing out problems and letting the developer make a decision often helps the developer learn, and makes it easier to do code reviews. It also can result in a better solution, because the developer is closer to the code than the reviewer is.

However, sometimes direct instructions, suggestions, or even code are more helpful. The primary goal of code review is to get the best CL possible. A secondary goal is improving the skills of developers so that they require less and less review over time.

Remember that people learn from reinforcement of what they are doing well and not just what they could do better. If you see things you like in the CL, comment on those too! Examples: developer cleaned up a messy algorithm, added exemplary test coverage, or you as the reviewer learned something from the CL. Just as with all comments, include?why you liked something, further encouraging the developer to continue good practices.

Accepting Explanations

If you ask a developer to explain a piece of code that you don’t understand, that should usually result in them?rewriting the code more clearly. Occasionally, adding a comment in the code is also an appropriate response, as long as it’s not just explaining overly complex code.