• Home|
  • Blogs|
  • Important Points of Code Quality Peer Review and External Review

Important Points of Code Quality Peer Review and External Review

Even though diamonds are best in world, those needs quality checks. Quality index of diamond defines its cost in market. Similarly quality of code defines how much benefits and less resource consumption your business will benefit.

In short code review is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. There are two kind of code reviews - the first is known as PEER review and the second is EXTERNAL review. Reviews helps developers to maintain consistency between design and implementation “styles” across many team members and between various projects on which the company is working.

What is a PEER Review?

A peer review is mainly focused on functionality, design, and the implementation and usefulness of proposed fixes for stated problems.

The peer reviewer should be someone with business knowledge in the problem area. Also, s/he may use other areas of expertise to make comments or suggest possible improvements.

2. Application Services

Companies can launch both customer applications and internal apps in the cloud, easily via Microsoft Azure. The cloud environment allows businesses to quickly deploy applications in the cloud, which saves on infrastructure costs while reducing the hardware and maintenance burdens on in-house IT management. Additionally, the pay-as-you go pricing and scalability structure of Azure allows SMBs to better manage their IT budgets by only paying for what they need.

What do peer reviewers look for?

1. Feature Completion

The reviewer will make sure that the code meets the requirements, pointing out if something has been left out or has been done without asking the client.

2. Potential Side Effects

The reviewer will check to see whether the changed code causes any issues in other features.

3. Readability and Maintenance

The reviewer will make sure the code is readable and is not too complicated for someone completely new to the project. Model and variable names should be immediately obvious (again, even to new developers) and as short as possible without using abbreviations.

4. Consistency

Conducting peer reviews is the best approach for achieving consistency across all company projects. Define a code style with the team and then stick to it.

5. Performance

The reviewer will assess whether code that will be executed more often (or the most critical functionalities) can be optimised.

6. Exception Handling

The reviewer will make sure bad inputs and exceptions are handled in the way that was pre-defined by the team (it must be visible/accessible to everyone).

7. Simplicity

The reviewer will assess whether there are any simpler or more elegant alternatives available.

8. Reuse of Existing Code

The reviewer will check to see if the functionality can be implemented using some of the existing code. Code has to be aggressively “DRYed” (as in, Don’t Repeat Yourself) during development.

9. Test Cases

Finally, the reviewer will ensure the presence of enough test cases to go through all the possible execution paths. All tests have to pass before the code can be merged into the shared repository.

What is an external review?

An external review addresses different issues than peer reviews. Specifically, external reviews focus on how to increase code quality, promote best practices, and remove “code smells.”

This level of review will look at the quality of the code itself, its potential effects on other areas of the project, and its adherence with company coding guidelines.

Although external reviewers may not have domain expertise, they do have discretion to raise red flags related to both the design and code and to suggest ways to solve problems and refactor code as necessary.

What do external reviewers look for?

1. Readability and Maintenance

Similar to above, the reviewer will make sure the code is readable and is not too complicated for someone completely new. Again, all model and variable names have to be immediately obvious (even to new developers) and as short as possible without using abbreviations.

2. Coding Style

The reviewer will ensure that everyone adheres to a strict coding style and will use code editors’ built-in helpers to format the code.

3. Code Smells

Finally, the reviewer will keep an eye out (or should that be a nose out?) for code smells and make suggestions for how to avoid them.

In case the term is new to you, a code smell is “a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem.”

Does external reviewers requires “domain experts”?

External reviewers don’t have to have domain knowledge of the code that they will be reviewing.

If they know about the domain, they will feel tempted to review it at a functional level, which could lead to burnout. However, if they have some business knowledge, they can estimate more easily how complex the review will be and can quickly complete the review, providing a more comprehensive evaluation of the code.

So, domain expertise is a bonus, not a requirement for external reviewer.

What if an external reviewer misses something?

We do not expect an external reviewer to make everything perfect. Something will most likely be missed. The external reviewer does not become responsible for the developer’s work by reviewing it.

Most of the organisations prefer code developed by their vendor to be reviewed by external reviewer, it helps them to understand if their decision of selecting vendor was correct or still they need to check someone else or enhance existing vendor.

How fast should developers receive a response from the external reviewer?

If a developer has requested an external review, he can expect some type of response within two hours. At the very least, the response should tell him a time frame for completion.

In some cases, the external reviewers might not respond. They’re not perfect and might have too much work to do. Developers should feel free to ping them again if they don’t hear back within two hours or try with another external reviewer.

Why can’t developers simply publish their code on Live Production Environment without External Review?

There are many reasons this is a bad idea, but here are two of the most important:

1. External reviews catch problems that would affect everyone if the code were merged into the main repository. It doesn’t make sense to cause everyone to suffer for problems that could have been caught by an external review.

2. The process of merging code causes the developer to feel that the work is done, and it’s time to go on to the next thing. It’s silly to have people feeling like something is checked off the task list when it’s really not.

Can the external reviewer ask the developer to do something that is not precisely related to the code?

Yes, the external reviewer has some discretion here.

We don’t think that continuously making auxiliary changes that are unrelated to the core functionality is the right thing to do on reviews. On the other hand, small changes (or changes that help the code maintain a consistent style) may be requested.

There should be a reasonable relationship between the scope of the developed functionality and the scope of the requested change.

GrassDew IT Solutions provide external reviewer service for code developed. We are into service business for complete Software Development Life Cycle (SDLC) starting from requirement gathering, consulting, implementation of code, different types of testings, quality assurance of delivery and maintenance/support. Any or all of these phases can be outsourced to GrassDew team.

GrassDew has four main business streams – Consulting Services, Software Solutions, Security Services and Knowledge Services. Our primary focus is on various software development and maintenance services.

To know more about our services, email us at shekhar.pawar@grassdew.com