Andrew Pallant

Developers often seem scared to allow another person to look at their code.  It is like they have a fear of someone stealing what they had done or that someone is looking over their shoulder.  Software developers and web developers often hold tight to their projects.  In almost every business work is proof read or reviewed.   It is not because a lack of trust, but rather many eyes will catch mistakes.

Why do we do code reviews?
The reason for code reviews may be obvious, but since the resistance it needs to be mentioned.  Code reviews are primarily to catch logic mistakes, missing business rules and team coding standards.

When a developer is so close to a project and looks at the same code for days, weeks or months, it is easy to invert logical expressions or entirely miss basic variable checks.  Assuming both purposely and by accident that routines return the perfect values is often the biggest mistake and we are suddenly surprised when a NULL value sneaks in.

Often when we start a project we are handed pages and pages of business rules and requirements.  It is very easy to miss the small things and even the big things.  As easily it is to cross items off a list, it is just as easy to entirely miss one.  It is very viable to have a second set of eyes to review what we had just written.  Better to catch mistakes before the customer does.

Lastly team coding standards;  they are standards that either the team lead or the team together decided they would follow.  These standards are to ensure that the team writes the code in the same structure and using the same variable naming convention.  Having coding standards allows the team to work together and have the ability to read each other’s code.  It allows quick debug and editing by any team member.  Without these standards projects would be a wild wild west and would differ from team member to team member.

Types of Code Reviews

1. Team Code Reviews – Team members together would focus on a method or a group of methods.  The team together would offer suggestions and ideas to enhance the code for which they are reviewing.  It is not a time to rip the developer apart, but to offer constructive suggestions.  If a developer gets out of line, that person should be asked to leave the room.  A projector should be used if available; otherwise printing off the code or have each developer view it on their laptops are adequate methods as well.  The team lead should take a leadership role in this method guiding conversation and making notes to send out after the meeting.
2. Colleague Code Reviews – These reviews should be done by a senior or a team lead person.  The senior can be greater or equal in experience.  Same as a team review, everything should be done in a constructive manner.  If a senior developer is doing the review; the senior should be assigned by the team lead to prevent a biased review.  When the review is complete – the review should be covered in person with all developers involved.

Tips for the Reviewer

1.  Ask questions, do not make statements
2. Do not be too critical, remember to praise
3. Be sure you have your company coding standards available as a reference
4. Keep the review on the code and not the coder.   Do not make it personal
5. Keep in mind that there is more than one way to do something

Tips for the Developer

1. Remember, you wrote the code, but the code is not you.
2. Make a check list of things that are often found in the code reviews
3. Be involved in the maintenance of the coding standards
4. Always do your best and do not look for short cuts

The post Code Reviews appeared first on LDNDeveloper.