Welcome to the NZRT Wiki Podcast. Today we’re looking at the Code Review Process.

Code review is one of those practices that separates teams that ship quality software from teams that don’t. At NZRT, every code change goes through a structured review process using GitHub pull requests before anything gets merged. Let’s walk through how that works and what’s expected of you whether you’re the person writing the code or the person reviewing it.

First, let’s cover the key roles. There are two main players in every review. You’ve got the author, that’s the person who wrote the code and opened the pull request, and the reviewer, who examines the changes and gives feedback. Reviewers are looking at four main things: correctness, meaning does the code actually do what it’s supposed to do, style, meaning does it follow the team’s conventions, security, meaning does it introduce any vulnerabilities, and maintainability, meaning will future developers be able to understand and change this code without pain.

Now, not all feedback is created equal. Some comments are blocking issues, which are serious enough that the code cannot merge until they’re fixed. Others are suggestions, which are improvements the author can choose to address but aren’t required. Comments happen in threads attached to specific lines of code, so the discussion stays contextual and traceable.

So what does NZRT actually require before a pull request can merge? There are five things. The PR needs at least one approval if it’s targeting the develop branch, or two approvals if it’s going to main. All automated checks must pass, that includes linting, tests, and security scans run by GitHub Actions. The branch must be up to date with the base branch. Every conversation thread must be resolved. And if a CODEOWNER is assigned, they must have approved.

As a reviewer, your job is to genuinely understand the change, check the logic, look for security issues like exposed secrets or improper authentication, verify that edge cases and error handling are covered, confirm that new functionality has tests, and make sure documentation has been updated if needed. You should only approve if you’re actually confident in the quality of what you’re looking at.

As an author, your job starts before the review even begins. Write a clear title and description. Keep your PR focused, one feature or fix per pull request. When feedback comes in, respond to every comment, address it promptly, and request a re-review when you’re ready. Don’t merge without the required approvals, and don’t dismiss someone’s review without discussing it first.

Let’s talk through what good review communication looks like. Imagine a reviewer spots a SQL injection vulnerability. They’d explain the problem, show an example of the problematic pattern, which would be building a query by gluing a variable directly into a string, then show the correct pattern, which uses a parameterized query where a placeholder stands in for the user input and the actual value is passed separately. That separation is what prevents an attacker from manipulating the query.

When the author responds and fixes it, a good response acknowledges the catch, explains what was done to fix it, lists the specific changes made, such as switching to parameterized queries, adding input validation, and adding a unit test, and references the commit where those changes live.

Not every comment is a blocker. A reviewer might suggest extracting some logic into a separate method for reusability and explicitly flag it as not required for merge, just something worth considering for the long run.

The overall flow looks like this. You open a pull request. GitHub Actions run automatically to check lint, tests, and security. If they fail, you fix them before moving forward. If they pass, you request reviewers. Reviewers examine the code and either approve, leave comments, or request changes. If changes are requested, you address them and loop back. Once you have the required approvals and everything is green, a maintainer merges the PR and the branch gets cleaned up.

A few tips to make reviews work well for everyone. Be respectful and focus on the code, not the person. Ask questions instead of making accusations, something like “can you explain why this approach was chosen” is far more useful than just saying “this is wrong.” Suggest solutions, not just problems. Be timely, aim to review within twenty-four hours, same day if you can. Give context when you flag something, explain why it matters whether that’s security, performance, or readability. And don’t forget to call out good work when you see it. Reviews are as much about reinforcing strong patterns as they are about catching problems.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.