Mastering Code Reviews: Tips, Tricks, and Security Insights for Software Engineers

Whether you are an up-and-coming software engineer or you already work in IT, code reviews will be or are one of the most important parts of your job.

I’ve come to understand this while working at my current company, where I started as a junior developer and I published code for review like it was a race ???, neglecting quality, and trying my best to follow company standards.

As I progressed, my mentor and manager dropped the bomb on me —

it’s not about the quantity of code you churn out, it’s the quality that counts.

Yeah, my early Pull Requests were basically a playground for comments from my fellow engineers! ??

With refining my code quality and polishing my work, I started dishing out comments on other people’s PRs too. In today’s article, I’m spilling the beans on what I learned and the tips and tricks I’ve picked up along the way. ?? ?

Prioritizing Security: A Hacker’s Mindset in Code Reviews ???

When embarking on code reviews, adopt a hacker’s mindset. This means actively seeking out potential vulnerabilities within the code. Let’s explore a few examples specific to reviewing new API endpoints ??:

1. Unsanitized user input. Here, the coder missed implementing input sanitization for request and parameter values supplied by the API client.
2. Potential SQL injections. In this case, the absence of parameterized statements leaves room for potential SQL injection vulnerabilities.
3. Authorization and authentication gaps. The coder neglected to assign proper permissions or roles to the endpoint, raising concerns about unauthorized access.

It’s worth noting that many big companies use automated security tools like Snyk to identify such vulnerabilities. However, it’s unwise to rely solely on these tools.

As responsible engineers, prioritizing security and adhering to best security practices should always be our primary focus!

For more on security, check out my blog on the OWASP Top 10 ??

The Role of Task Tickets in Code Reviews ??

Before looking at the code, always look at the ticket related to the changes! Whether you use Jira ticket, GitHub or GitLab issues, always read trough the requirements, what’s the impact of the task and what should the outcome of these code changes be after deploying them to production!

Catching a bug related to the implementation of the business logic should be rare, but it does happened and such code reviews are of immense value!

Be Polite & Ask Questions ??

Remember that you are addressing a fellow team member, not just the code they wrote, so be respective when providing feedback.

Frame your comments in a constructive manner. Instead of pointing out flaws, offer suggestions for improvement.

Avoid placing blame or making personal attacks. The focus should be on enhancing the quality of the code, not criticizing the author.

Use Markdown ??

I’ve had experience with GitHub and GitLab, so I know that both tools allow for the use of Markdown when writing comments on PRs.

Here is a GitHub repo that acts as a Markdown Cheatsheet ??

One of my favorite actions, this Markdown typing allows you to do is the ability to embed code, styled based on the specified language! ??

Leveraging GitHub Suggestions for Change ??

GitHub also has the functionality to use Suggestions , which basically act as s request for change in code, but with the ability for the coder to directly commit the requested/proposed changed from the GitHub PR review! Ain’t that cool ??

The Benefits of Extracting Code to Your IDE

I’ve been against this for a long time, before finding the value in actually extracting the code locally, to my IDE. I mean yes, there are some PRs which don’t require such step, but if there is a change in business logic, some DB migration script or other more impacting change, I would opt for the code extraction!

This adds a few tools to your toolkit as code reviewer ???

• You can dig into the code easier by navigating trough it’s methods, classes and etc. much easier!
• You can debug! That’s probably the simplest, yet most important tool!
• If you’re using some auto-formatting or code-analysis tool in your IDE, it can spot some unhandled errors or syntax misalignments!
• You will have the ability to look at code offline! ?? This means you can pull the code and look at it when you’re on the train for example! ??

Patience

Remember, some reviews may take a couple of minutes, others may tkae hours. This time relies on multiple factors like :

• how skilled is the engineer writing the code.
• what’s the purpose of the code.
• how big is the PR
• is there a lot of context someone needs to have before starting to review the code.

?? There are a lot of tip & tricks I can point at when doing a code review. With that said, these are the biggest and most helpful ones to know in my opinion!

Hope you got some value from this article!

?? If so, follow me here or on Medium, where I post these blogs first (and more ??)!