Software development code review checklist

Sound familiar?

• System crashes and downtime, caused by an unstable platform
• Security and data breaches
• Missed targets, from development deadlines to KPIs
• Budgets overrunning, even in non-technical cost centres
• Low agility, making integrations a constant struggle
• Frustrations over usability, sapping productivity and morale
• Over-reliance on the few developers who can fix the code
• Disappointing customer reviews

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.

Code review process checklist

1. Set your scope before you start

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:

• Informing your development roadmap, e.g. whether to refactor existing code or migrate to a new system
• Stabilising and future-proofing existing infrastructure
• Reducing feature development cycle time and cost
• Identifying security risks and mitigations
• Benchmarking current performance against industry best practice and coding standards
• Planning for the implementation of effective test strategies
  Identifying opportunities to enhance existing performance

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.

2. Build valuable context

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:

• Database schemas
• Continuous integration setup
• Build environment and deployment pipelines
• Issue tracking systems
• Uptime and performance reports
• Bug reports
• Statistics
• Test plans

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.

3. Conduct static analysis

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:

• PHPMetrics to provide code metrics
• Sensiolabs Insight to report bugs
• Nessus to identify vulnerabilities
• PHPCS to assess coding standards

A checklist of areas to cover in your static analysis includes:

Code metrics

• Size
• Structure
• Complexity
• Repetition
• Coupling and cohesion
• Dependencies
• Use of library code vs custom
• Inheritance
• Maintainability
• Test coverage

Bugs

• Runtime errors
• Missing commands
• Incorrect syntax
• Logical inconsistencies
• Control flow issues
• Naming conventions not followed

Vulnerabilities

• Security violations, like nested passwords
• Weak cryptography algorithms
• Unauthorised access to sensitive data logs
• Shortcuts to high-level database settings
• Application backdoors

Coding standards

• Performance against industry standards and best practice
• Adherence to custom conventions and design patterns
• Clarity and intent of comments
• Use of version control

(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.)

4. Go beyond the code

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:

Libraries and frameworks

• Patches
• Versions
• Long-term support

Design patterns and style guides

• Structure
• Classes
• Objects
• Behaviour

Test coverage

• Strategy
• Speed
• Coverage
• Evidence

Structure

• Maintainability
• Scalability
• Speed of development
• Onboarding of new team members
• Documentation

Security

• Authentication
• Authorisation
• Session management
• Data validation
• Error handling
• Logging
• Encryption

Additional areas

Depending on the agreed project scope, the human element of your code review may extend to business processes beyond the code itself, for example:

• Architecture review
• Agile working
• User experience
• Usability
• Business case and vision
• Backlog management processes
• Team structure
• Project governance

5. Make your findings count

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:

Codebases

• Does the report analyse all codebases identified in the tech terms of reference?
• Does it cover all relevant code and API dependencies?

Issues

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?

Recommendations

• Does the report address all risks and issues?
• Does it respond to initial technical and executive concerns? Does it relate to desired outcomes?
• Is there a roadmap for the way forward?

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?’.