During one of our final Software Testing lectures last week, we were able to participate in a code review, examining and critiquing a given program. I really enjoyed taking part in this activity, because it helped me understand the program on a deeper level. After all, I wouldn’t really be able to spot any places to improve without first knowing what each line of the program was doing!
For this blog post I wanted to take a look at different code review strategies, as well as any advantages or disadvantages that may arise when using this method of software testing. I was reading these posts for more information: https://smartbear.com/learn/code-review/what-is-code-review/ and https://smartbear.com/blog/collaborate/pros-and-cons-of-code-review-methods-infographic/.
Code review is what it sounds like. Team members work together to review written code and notice areas of possible improvement. There are different ways to go about this process, each of which having their own unique advantages and consequences. The articles that I read listed 5 strategies, and they are described as follows:
- The Email Thread – For this method, a file in need of reviewing is sent to every team member taking part in the code review. This can be helpful when it is difficult to find time in everyone’s schedules to meet. However, long email threads can get complicated for the developers to look through.
- Pair Programming – For this method of programming, developers sit side-by-side and work on the same code together. This method is great to incorporate code review into the development process but may provide some bias due to emotional connections to the work put in.
- Meeting-Based – For this method, smaller groups of reviewers meet with printouts of code or code on a projector. Then, they examine, line-by-line, any issues or problems with the program. While this is a very in-depth approach, this also takes a lot of time. Additionally, some development teams are stationed across the world from each other.
- Over-the-Shoulder – This informal method simply entails another developer standing over the shoulder to the author of the program, as the author walks through each change to the code. This is great for in-person collaboration, but there aren’t really any standardized metrics involved in this method. There is also no traceability to the conversation later.
- Tool-Assisted – This method involves an external tool (whether browser or IDE based) used by the team to successfully review code while also solving some of the issues above, like keeping track of online comments, noting any change in code, and enforcing any standardized metrics. However, some tools may be costly, or may not fit as easily into the workflow of the development team.