The Code Audit: What it is and How it’s Done

For months the investigative journalist collects information, insight, and evidence which will be channeled into an explosive new book. The drafts are continually passed between the writer and the editor, who is constantly digging into the text, looking for errors, misspellings, etc.

A code audit functions similarly. It’s a comprehensive analysis of the code in a programming project. The goal, much like the book editor, is to find errors, as well as bugs, and actual or potential security breaches.

Our first love is, of course, writing code. But we know the importance of code audits. At ArganoUV it’s part and parcel of our process for each project we have. Because we know that code audits provide the foundation and maintenance for a solid codebase.

Evidence suggests that for each hour that is spent reviewing code, it actually saves 33 hours in maintenance.

So what’s so important, specifically, about code audits?

1. It ensures that the codebase aligns with common standards, that it’s up-to-date, secure, and doesn’t violate any copyright issues.
2. It provides the opportunity for partners to peek under the hood and have questions answered about a range of topics, such as:
   • Are there any security issues?
   • Is the code manageable?
   • Is it ideal for building on top of it?
   • Is there any open-source code or that was written in-house?
3. If your code is quite old – especially if it’s a couple of years old – then by auditing it will help check whether it is relying on outdated tools, which can potentially cause security issues.
4. It provides your team a general understanding of what your codebase looks like and the structure that it exists in.

General advice for a good code audit

One of the main reasons why there are so many grammatical blunders and spelling mistakes in the current world of published content – in my personal and limited experience as a writer and former editor – is because many of the people who are writing content are also the people who are editing that content. Having the same set of eyes scanning the text may miss a lot of important issues both in structure and style. 

Writers generally caress their content and treat it like their own offspring. And of course this means they have a strong attachment, which is not good for objective eyes. Swap the word writer” with “developer” and “content” with “code” and the narrative remains the same.

So our general advice is to have independent eyes audit your code. Developers may be too close to their own work to recognize any issues or potential threats. And also, having a separate set of eyes looking at code can create new pathways of exploration, fresh ideas and broader dialogue about future development. ArganoUV regularly carries out code audits for brands that we work with.

But if you decide to go ahead and audit in-house, consider creating an in-depth document that specifies the scope, and delegates who is going to audit which modules – BEFORE launching the code audit. It’s all too easy to get bogged down in the detail and straying too far when not having a navigation map to follow. We’d also recommend structuring the documentation into a checklist to ensure a high level of segmentation and clarity – with a greater sense of progression during the auditing.

And finally, don’t just perform an audit at the end of a project. Perform regular audits during the entire development process. Errors build up; issues become more problematic the more it’s built upon. So save time in the long run by segmenting the audits while you go.

PS: ArganoUV is one of the world’s leading Salesforce Commerce Cloud (Demandware) development & strategy teams. Contact us to see how we can work together.