Originally published on decentphp.dev — part of the Writing decent PHP course. View this lesson on the original site.

Readable code reduces risk, but it does not remove risk.

Before merging or deploying, you still need explicit checks that prove behaviour is safe.

Before: vague confidence

Teams often approve changes with comments like:

  • "Looks fine to me"
  • "Should be safe"
  • "Tested locally"

That sounds reassuring, but it does not prove much.
If a regression appears, nobody can tell which signal was missed.

After: evidence-based verification

For each risky change, capture five checks in the PR:

  1. Behaviour check: which test or command proves the intended behaviour still works?
  2. Boundary check: what input edge case did you verify (empty value, invalid state, duplicate payload)?
  3. Data check: what confirms you did not introduce inconsistent fields or stale writes?
  4. Operational check: which metric, log, or alert should remain healthy after rollout?
  5. Rollback check: what exact condition means "stop and revert"?

Concrete PR example

Before

Refactor status update flow and clean up naming.

After

Refactor status update flow and remove duplicate status fields.

  • Behaviour check: php artisan test --filter=StatusUpdate
  • Boundary check: verified missing status returns early and writes nothing
  • Data check: confirmed only order_status is written (not status_label)
  • Operational check: watch error rate and failed queue jobs for 30 minutes
  • Rollback check: revert if status-update failures exceed baseline by 2%

Why this works better

  • reviewers can evaluate risk using evidence, not guesswork
  • on-call engineers know what healthy looks like after release
  • teams move faster over time because checks are repeatable

Lightweight pre-merge checklist

  • I can name the risk this change introduces.
  • I can point to one test that protects behaviour.
  • I checked one edge case, not just the happy path.
  • I know what I will monitor after deployment.
  • I know exactly when I would roll back.

If any answer is "no", the change is not ready for production.

From Writing decent PHP — What decent PHP looks like