From LinkedIn · · 1 min
The assumptions the code was built on
A passing test establishes that the code did what the test expected. Whether the test expected the right thing is a separate question, and a review works in that gap until each assumption is supported, contradicted, or unresolved.
By Olha Shevchenko. Audits production systems on AWS and Node.js.
When I open a system for review, the evidence is already there.
Tests pass, permissions are set, the audit log has rows, the deployment pipeline is green. Each of those establishes something narrower than what it is taken to prove.
A passing test establishes that the code did what the test expected. Whether the test expected the right thing is a separate question. The review is about that gap.
The deploy is automated, apart from the bit somebody still has to do by hand. The team may know why the step exists: who added it and what they were working around. That second question takes some of the blame out of the conversation. Nobody has to defend a decision forever just because they made it.
I still need to trace what depends on the step and check what would happen without it. The history says what the step was for. The code says what it does now.
By the end, the step's assumption is supported, contradicted, or unresolved.
If the step still prevents a failure, it stays until something else prevents that failure. If the condition no longer holds, the step can go, once we know what else depends on it. If nobody remembers and the system cannot tell us, the review records what remains unknown and what has to be checked before anyone changes it.
A decision can have been reasonable then and still need changing now. Keeping it is a decision too.
A green check answers a narrower question than the one being asked.