200apps Corpus

Appearance

Development & Code · master area

Code Review ​

The reviewer reads the brief before the diff. The question is not "does this work" — it is "does this carry the meaning the chain handed in?"

Owners: Developer, Tech Lead Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Code review as chain verification.

Where it lives in the chain ​

How to do this ​

The reviewer asks the trace question:

  1. Domain language — does the code use the brief's words? gradeExam not submitForm?
  2. ADR compliance — does the implementation honour the architectural decision? If the ADR said "no domain logic in HTTP handlers," is the handler thin?
  3. Scenario coverage — does the test cover the Gherkin scenarios from amigos? Including the negative case?
  4. State coverage — are all named states from the wireframe implemented? Empty, loading, success, error, edge?
  5. Migration discipline — if the PR migrates schema, is down tested?
  6. Flag discipline — if the PR wraps a flag, is the cleanup task created with a date?

If any answer is no, the PR doesn't merge.

What good review looks like ​

The reviewer opens the Feature Brief, then the amigos scenarios, then the ADR if one was named, then the diff. They name what they checked. "Read the brief, the four scenarios, ADR-014. The handler is thin, the domain function is named, three scenarios covered. Missing: the permission-revoked-mid-flow scenario from the wireframe — please add a test." That is review. "LGTM 👍" is not.

A review that takes 4 days, returns at midnight, and contains six comments about formatting is a review that has stopped serving the chain. Reviews must be fast enough for trunk-based discipline to hold — same day, ideally same hour for small PRs. The substance is in what the reviewer checks, not in how many comments they leave.

200apps · How We Work · NWIRE

Internal corpus. Voice and structure © 200apps.