Not sure about the quality of code you’ve got from your freelance developer? Or it was for a while since you upgraded your app and you want another development team to make the work for you? Well, in any case, you’ll need to look under the hood or make a Code Review as it called in software development. As it said: Need a fresh start? Start with a code review!
Moreover, everything is code these days. Architecture and design documents can be expressed in code. You may use some kind of project management software, this software is code too. One little typo somewhere in there could make immediate tenfold cost increase.
Code Review Definition
Code review is a systematic examination of software source code. This process is performed with the goal of improving the overall quality of software by elimination mistakes in the overlooked code.
Code review usually performed by those who maintain software codebase in order to evaluate a proposed changes to that codebase, regardless of the source of the proposed change. Meaning, you should perform it no matter who maintain your software and no matter what changes you intend to introduce.
If you need additional work on the project after a while - you definitely need to perform code review first. Unless you want to ruin a working system.
Code Review & Peer Review
You might be heard about peer code review or simply peer review. And you may wonder aren’t peer review and code review the same. Shortly speaking – yes. But it’s better not calling them peer reviews because it puts too much focus on the peer, that is being reviewed, and not enough focus on the code. Because eventually, we’re reviewing code, not the person building or reviewing it.
Throughout this article, as well as in other sources, you will stumble on the following terms.
- Change – an individual unit of work altering what exists.
- Submission – a collection of changes, no matter small or a big one.
- Pull – get a piece of code/submission for a review.
- Submitter – the person proposing the submission.
- Reviewer – the people evaluation the submission.
- Annotation – remarks or rating bestowed upon the submission.
- LOC – Line of code. The term often used to express the amount of work needed to perform.
Code Review Types
Karl Wiegers propose such categorization of common code review forms on a formality spectrum. This table could also provide you guidance while selecting an appropriate review technique.
If you need another development company to make a review, you should incline toward formal types of inspection and team reviews. Your development team probably use a walkthrough, pair programming or pass around methods depending on the organization of work on the project.
Changing development team: Code review should be performed by a new team BEFORE taking a project. Not in the middle or after signing the contract.
What Things to Look For?
- Algorithmic complexity.
- Exception & error handling.
- Exception, class & variable naming.
- Long styles & methods.
- One commit = one purpose.
- Logging sufficiency.
- Style confirmation.
Code reviews can be performed verbally during pair programming sessions, or by reviewing code on websites like GitHub. We use GitHub internally for our projects and its submit/pull system is a stellar example of good code review system.
What is the purpose of code review?
The primary goal of code review is to find defects before they enter the maintained code base. Thus, its core function is to reduce defects, preferably before they occur in the live version of your software.
Aside from that, there are two human problems that code review also solves:
Team Synchronization – it allows you to be certain that all team members have a good concept of where the architecture is going. What the project is supposed to be doing in the long term. If your team does not have this vision, you’ll eventually spend additional resources on add-ons, redevelopment, and recompilation.
From this point of view, code review is an efficient mechanism that makes development lean and reduces waste. Code review reduces the feedback cycle, so the people can maintain their mental model in synchronizations with the architecture and the implementation.
Adit App Architecture – code review can enable developers to continuously review changes to the infrastructure, and in this way, there is an audit and discussion of each decision. Thus, it enables communication between developers and architects or project owners.
As a result, your project becomes more lean and adaptive to changes that occur outside of the “development world”. Business logic changes and improvements could be discussed bidirectionally and can be performed in less time.
Reduces Amount of Legacy Code – Code review allows us to build knowledge of how things changed over time and how things came to be this way. Implementing the practice of constantly code reviewing creates some sort of Tribal knowledge.
Code review ensures maintainability – It forces developers to annotate changes, make excessive documentation and make it searchable. This way, a new developer on the project will spend less time getting into the code, written by someone else. Plus, your project will become more resistible to staff turnover.
Lack of Code Review eventually results in lost opportunities, lost revenues, security deterioration, and increased maintenance costs.
Code Review Best Practice
- Annotate source code before the review.
- Review size should not exceed 400 lines of code (LOC) at a time.
- Keep reviews informal and short. Cisco Systems found that there was negligible difference in the number of defects found in formalized and informal peer reviews. But informal reviews are faster.
- Enable creating new work items. This what GitHub feature request stand for. Allow advancements not only repairs.
- Don’t let reviews slow down development unnecessarily. If you find that they’re getting slower – don’t write any new code until previous reviews are completed, or at least stable.
After all, code review helps developers and app owners to answer two principal question:
- Does it work?
- Does it work correctly?
Those are things we care about most. Code Review helps to achieve those goals.
Need a Code Review?
Tony Sol is the business development manager of GBKSOFT, overseeing the production of all writings for both internal blog and external platforms. He is technical-driven person always looking for new benefits of merging business and software.
Other Articles of Tony
Similar Blog Articles
App Development 101 – Software Requirements Specification
Every software project needs a really good specification in order to succeed. Just like every construction needs a specification. But it takes a lot of time and patience to write down all the details on the paper. Plus attention to detail and mindfulness will help a lot. It must be acknowledged that specifications (software requirement...
The Guide to Software Testing Process
Some people thought that avoiding testing stage of the software development was a good idea. They thought it would save thier budget. How wrong they were…
UI and Design
Difference Between Web Design and Web Development
What is the difference between website design and website development? This is one of the most frequent question asked by tech newbies on such platforms as Quora, or simply in Google search. The general answer to this question is designers create a design (appearance) of website or application while developers write a code (program) making...