Ten signs your site needs a code review before the next feature

The next feature always looks small in the ticket. One field on a form. One filter in a report. One more status in a flow the team already uses. The risk is rarely the size of the diff. The risk is the old behaviour under it. If nobody has read that behaviour since the last incident, the feature is how the same incident returns under a different label.

This list is for the person who can open the repository. It is not a full audit. An audit is a wider check with evidence, written so a non-developer can see the effect. That broader pass is in what to check first, and what not to conclude yet. Use this list earlier. If several signs are true, pause the feature long enough to read the path. Do not jump to a rewrite. A rewrite is a separate project. It needs a reason this reading has not established yet.

1. Nobody owns the behaviour this feature will change

Ask who can explain what the current page does when the input is empty, when a person has no access, and when the same request arrives twice. If the answer is “the code,” then nobody owns the rule. There is only a file. The feature will add one more branch to behaviour nobody can repeat out loud. Start the review by writing the rule in a few plain sentences. Then compare those sentences with the code. If they disagree, the feature waits until a person chooses which one is correct.

2. The only place to try the change is the live site

A feature branch that can be tested only in production is not a small feature. It is a release with no rehearsal. Find the command, pipeline, or habit that puts code on the live site. If there is no second environment, that fact matters before the ticket does. Editing production because there is nowhere else to check is how a field change turns into an incident. The practical decision is in do not patch production because a test environment is missing. A review that ignores this and comments on naming has missed the real issue.

3. Thank you and the record already disagree

Submit the form this feature will extend. Note whether thank you appeared on the site, and whether the value you sent reached the mailbox, row, or card a person actually opens the next morning. If those two events already diverge, a new field will diverge too. You will ship a cleaner form into a broken path. Common breaks are covered in why a lead never arrives and what breaks between a form and a card. Read that path before you add a column.

4. Nobody can say how many seconds the page already takes

A filter, a new column, or a heavier response lands on a page people already wait for. If you cannot put a number next to that URL or that job, you cannot tell whether the feature made it worse. Time it. Then open the slow log for that window, if you have one. Group the statement. Compare rows examined with rows sent. A quiet log does not prove a fast page. The reading order is in how to read the slow log before you refactor. “Looks fine” without the seconds is only a guess.

5. The same job can already create two records

Retries, double clicks, and webhooks that arrive twice are normal. If the current code treats the second run as a new fact, the next feature will do the same unless someone writes the rule down. Find the operation that must stay single: a payment, a card, a score, an email to a customer. Read what happens when it runs again. A review of the new code that never replays the old job will approve a duplicate. State whether the second run should change anything. Put that sentence in the ticket before implementation starts.

6. Two customers share the product, and the new page has not been opened as both

A report, a search, an export, a night job. If one product serves several customers, take two accounts and look for a row from the wrong one. Do it on the page the feature will extend, not on a single-customer demo. One leaked row is an incident, not a style issue. Common starting points are in where data isolation breaks. A review that checks only the happy path of the author’s own account will miss the join that forgot the boundary.

7. A process already grows until someone restarts it

If last Tuesday’s fix was a restart, the feature’s new loop is a candidate for the same hour next week. Record memory before the action, at the peak, and after. Buying more RAM only hides the growth until the same pattern returns. The pass is what to check before you buy memory. A review that discusses the new class but never asks what the process keeps in memory has ignored the sign in front of it.

8. A secret for this feature is already in chat or in the repository

A new integration needs a key. If the last key was sent in a message, or sits in a committed file, the review already has a finding before it has a diff. Name the system and the fact. Do not paste the secret into the review comment. Move it to a place the team already treats as private, and confirm the repository copy is gone. A feature review that approves the call but leaves the key in the thread has added a leak to a ticket that was supposed to be about a field.

9. The last release surprised the people who had to explain it

Surprise means the change and the description did not match. The branch, the command, or the person who could run it was unclear. Or a job failed all night and the morning went into rebuilding a file by hand. Read the error log for the last week before you add another moving part. Group repeated lines. Tie each repeated failure to an operation: mail that did not send, a card that was not created, a report the team retypes. A feature on top of a nightly failure is how you get two surprises. Leave one-off noise for later. Do not leave the nightly failure.

10. The proposed review is a rewrite, and nobody has read the path

Messy code that runs one clear query is maintenance. It is not automatically today’s incident. “We should rewrite this before we add the field” is often a way to avoid reading the field’s path. Reject that as the first conclusion. Read the request path, the seconds, and the release path. Then decide whether the feature is safe on this code. A queue or a cache is the same kind of early conclusion. A background job that runs the same loop still examines the same rows. The person sees a processing state instead of a wait. The cost moved. When a queue does belong, the work should leave the click and a retry must not repeat a side effect. That is a different decision, described in when a queue belongs beside the application.

What the review should contain instead

A useful review before the feature is short. Name the operation. Paste the evidence: the seconds, the second-run result, the two-account check, the place the request landed. Say what you will not change yet. Comment on structure only where it hides one of those facts. A pile of naming notes with no link to a failure is a backlog. It is not a reason to hold the feature, and it is not a reason to ship it either.

• The current rule, in sentences a teammate can repeat.
• A place to try the change that is not the live site, or an explicit note that it does not exist.
• One submission followed to the record a person actually opens.
• Seconds for the page or job the feature extends.
• The second run of any job that must stay single.
• Two accounts, if customers share the product.
• What the review will not rewrite until those lines exist.

When a second pair of eyes is the feature

A team that can open the logs can walk this list on its own. Ask for a second look when the log sits where nobody can read it, when the only database you can explain against is the live one, or when the ticket has already jumped to a rewrite without the seconds and the request path. Send the operation, the seconds, and what one test submission did. Do not send a raw log full of customer values.

That reading is the work. Services cover performance, recovery of systems already in production, and the connections around them. Selected work keeps each result next to the operation that produced it. If you have the page and the sign from this list, send those. Leave the customer rows out.