Code revision
It’s also known as peer review or walk-through. It refers to a thorough review of a code module during the software development cycle to make sure that every requirement is met, and all possible improvements have been implemented. Code review can be applied to small parts of a program, such as subroutines or methods, or complete programs to make sure everything works as it should. The purpose for this is to make sure that our code is complete from both the programmer’s perspective and the client’s perspective, to make sure that it meets both OO patterns and the functionality requirements from the documentation and use cases.
A review team can be as big or as small as the piece of code that we’re reviewing, so it all comes down to the size of the project, and the size of the code that we’re looking at. Ideally, it should consist of at least the programmer and one or two reviewers that know what the code is supposed to do, but can provide external opinions by looking at the bigger picture. Some people argue that there should also be a leader, who makes the final decisions of what stays and what changes.
While code review seems beneficial in all aspects, it also has some disadvantages, just like anything, so you’ve got to analyse and figure out whether or not the pros outweigh the cons for your case.
Some of the advantages include that two or more heads think better than one, especially when one of those heads has been looking at everything from a close, restricted perspective. A new set of heads will be able to look at things that the original programmer might have missed, painting a bigger, better picture to look at. This improves communication between co-workers, and also encourages other programmers to become familiar with all the pieces of code of the project; even the ones they weren’t in charge of.
Another main advantage of code review is the fact that it increases the chances of getting things right from the very beginning, which avoids having to change code later down the road, when it costs more time, effort, and money. This also helps us identify bugs before the user has to find them.
However, the main disadvantage, especially when you’re supposed to meet a deadline, is the fact that it takes longer to complete a project, since it has to go through several layers of review before it gets a green light. This is because programmers now have to make sure they understand both their code and their coworkers’ code, and this means that they need to spend extra time doing that.
Programmers and team leaders also need to be committed to attending the meetings. Otherwise, this will all fail and end in wasted time that programmers could’ve spent looking for problems by themselves. Criticism is also something that needs to be taken care of, since it can become a source of trouble if the environment is not purely professional. If a programmer takes criticism personally, it may cause friction between co-workers, which will result in wasted time.
The whole purpose of this is to make sure our applications are better in every aspect, so if you observe that this method is not working for you or your project, you might want to consider looking into an alternative, such as pair programming, which I personally am a fan of.
