I like to try to be relaxed before starting any type of audit. It's almost inevitable that as you're looking through the code, you're going to find some pieces of code that will make you think "What on Earth were they thinking when they wrote this?". So it's important to enter into the audit with a calm and open mind.
As you likely know, there can be a lot of pressure on developers to hit deadlines and budgets, and sometimes features will get rushed out to keep stakeholders or managers happy. So when the developers were writing these features they might not have written them in a way that was suitable for long term use, and may have rushed the code. Of course, in an ideal world, this would never happen and the features should always be fully thought out before being implemented. But unfortunately, this isn't always the case.
It's also important to take into account how old the project is. If the project was originally built with an older version of the language (like PHP 5.4), there might be some places where the code isn't as "clean" as it could be if it was written now. If you do come across places where the code doesn't look very clean, it could be due to constraints that the original developers had when the project was built.
You need to remember to look at the code with a critical mindset but without taking personal hits at anyone. So make sure that you don't nitpick at the smallest things, because this could lead to tension between you and the other team members. Just because you would have written a particular feature differently, doesn't necessarily mean that it's wrong. When we're looking through the code, we're looking for code that:
- Has bugs
- Is vulnerable to security exploits
- Makes testing difficult
- Makes it difficult to extend in the future.
If you come across a piece of code where you think "This works, but I could have written it better", that doesn't necessarily mean that we should flag it (unless it's causing issues or might make future development more difficult, of course).
Want to Read More?
The article above is a small snippet from my ebook Battle Ready Laravel, which is a guide to auditing, testing, fixing, and improving your Laravel applications.
The book is packed full of actionable advice, tips, tricks, and code examples.
This particular snippet is from the beginning of the Auditing section. The Auditing section covers automated and manual techniques you can use to audit your Laravel application. It discusses how to spot vulnerabilities, code smells, and places that your code can be improved.
If you'd like to get your own copy of Battle Ready Laravel, you can head to battle-ready-laravel.com and use the discount code BATTLE20 to get 20% off.