Whether you’re experiencing specific issues with your software systems, or just feel that they’re not performing as well as they could, a code review is a great first step to pinpoint problem areas and identify actions for improvement.
In order for your code review to deliver the relevant and accurate insight you need to move forward, it’s important that you go about it in the right way. In this post then I’ll explore the key elements of an effective code review process – providing you with a checklist you can refer back to when assessing your applications and services.
Before you begin reviewing your software, it’s important to understand why you are conducting a review at all, and what you want to achieve. Start by defining strategic goals for your code review project; these might include:
Other questions to ask during this initial kick-off period include what ‘success’ looks like, what the highest-priority areas for review are, and whether there are any known issues that need to be investigated. Together, details will help shape the scope of your project, informing the number and type of codebases requiring review (for example backend vs frontend) as well as any additional dependencies that may need to be factored in.
Once you understand what kind of code review you are conducting and why, it’s time to begin gathering information about the codebases you’ll be reviewing. Check whether there are any existing assets available that may provide valuable contextual information, such as:
Consider too talking directly to the software development team working on the codebase, to understand current development practices and coding standards; team surveys and one-to-one interviews are helpful here.
A key component in the code review process, static analysis is typically completed by a technical analyst who will employ a range of automated tools to rapidly assess the code against a series of industry-standard benchmarks. The most appropriate tools for your code review will depend on a number of factors including the languages and frameworks your software is based on, but some of the ones we use most often at Box UK are:
A checklist of areas to cover in your static analysis includes:
(For a more comprehensive look at common coding standards and why they matter, take a look at this blog post we’ve written specifically on this topic.)
To deliver you a complete 360° view of your software systems, your static analysis should be complemented by a manual assessment of your code, typically conducted by a skilled senior software consultant .
Adding a human touch to your code review allows you to go beyond the quantitative detail of your code to look at your supporting software development processes and technology ecosystem, and typically covers areas such as:
Depending on the agreed project scope, the human element of your code review may extend to business processes beyond the code itself, for example:
Of course, your code review is only really valuable if it delivers actionable insight, so it’s important to clearly document your findings in a central report, repository or similar, which covers:
Does the report highlight all risks and issues identified by the code analysis?
Has it excluded all bias?
Are all findings from consultant research documented?
At Box UK we have extensive experience delivering this level of practical insight for a range of clients including Sodexo , Jaguar Land Rover and RS Components – supporting the creation of a business case for change, and creating a shared vision for the future that all stakeholders can work towards. Visit our Code Review service page to learn more about how we can help you get to grips with underperforming software, and if you’re interested in finding out more about the elements of an effective software review checklist and the outcomes is can deliver, download our white paper ‘Rescue or Replace – Can Your Ageing Software Platform Carry You Into The Future?’ .