What is Code Review ?

What Is Code Review?

It is the act of potential flows of source code, intended to
detect the consistency with the overall design, estimating
the code quality and adherence to the coding standards.

It is especially productive to detect security vulnerabilities,
potential troubles such as memorye leak, race conditions,
boilerplate detection.  

Who shouldn’t do the code review :

During this above 60 months of journey in this software orbit,
I have found that sometimes the comments from the reviewer
is really violating the aim of “Code review”
due to their lack of knowledge in the specified domain. 

E.g. If you will review your JAVA 8 / Spring Boot written code
from a ‘C’ developer who is unaware about the features
of the technology you have used, he might not be able to
provide productive code review comments.
He might sought that “Lambda” is not providing code
readability, use a normal loop instead. 

So before doing the code review, the reviewer should be more
experienced than you on the specific
technology at least and must have the functional requirement
understanding about the story/task as well as
should be good enough on the specific programming
language.

I always try to get my code review by someone with more
experienced on the specific language/domain
so that I can capture any domain-specific scenario which
has been missed during think through the process.

Checklist for code review

Below are some checklists points which should be taken
care during the code review:
a) Clean code

The code is the heart of your software. If the heart will be not clean,

there might be a chance of early death. 

So always the code should be care like a “baby”.

There are lots of area to achieve the code as cleaner.

Below are the some points:

• Must follow the naming conventions(e.g. OOPs principle). 

• A method definition must not be more than 15-20 lines. If required, use modularity. 

• Never user abbreviations . 

• Use the features of provided language

b) Code Coverage

This is the most important points I have figured out .
Sometimes the developers develop the number
of codes but used never.
This is like we cook foods without planning the events
which causes waste and environment can be polluted.

There are lots of tools available to checks the
code smell and code coverage.
We should use this before approving the code.

1. Cobertura
2. JaCoCo 
3. NCover

Refer for more: https://www.guru99.com/code-coverage-tools.html   .

c) Exception Handling

Prefer Custom Exception handling with proper message/status code.

d) Performance & Memory 

Creating the instances is a heavy cost-effective for
any programming language.

It is better to use Design patterns where ever you can.

e) Reusability of code snippets

f) Security

g) Commenting and formatting

h) Unit test

Check https://dzone.com/articles/java-code-review-checklist for more.

Common code review approaches

Over-the-Shoulder

This is a very older technique, but the easiest way to
engage in peer code review.

Once your code is ready with your unit testing, find a
qualified colleague to your workstation

and do the code review by explaining the features you
have implanted. 

(Bring a notebook and  collect the review comments)

Using Tools

There are lots of 3-rd party open sources available such as
1. Collaborator.
2. Review Assistant.
3. Codebrag.
4. Gerrit.
5. Codestriker.
6. Rhodecode.
7. Phabricator.
8. Crucible.
9. Veracode.
10.Review Board.
The email threads

The author sends an email of the code to the reviewers for code review.
This technique is preferred by open source projects.