audit

Audit: Reading Code That Already Works

Everything you are looking at ships and passes its tests. That is the constraint. You are not hunting for bugs; you are finding the places where the structure will make the next change expensive or risky, and saying which ones are worth paying to fix now.

That framing matters, because a review that lists everything imperfect is indistinguishable from a review that found nothing important.

Read in this order

1. The public surface. Exported functions, classes and endpoints. This is what other code depends on, so problems here have the largest blast radius and the highest migration cost.

2. The names. Read them without reading the bodies. Any name that turns out to be wrong once you read the implementation is a finding, because every future reader will make the same mistake you just did.

3. The imports. They show the dependency direction at a glance. Business logic importing a web framework, an ORM or a mail client is the single most reliable structural smell.

4. The longest functions. Not because length is the problem, but because that is where several responsibilities usually ended up together.

5. The tests. Tests are a readout of the design. Heavy mocking means tangled dependencies. Long setup means complicated construction. Absent tests for the core logic usually means the core logic is hard to reach.

What to look for

Responsibilities that drifted together. Describe the unit in one sentence. If you need "and", note where the seam is: which parts change for different reasons, and on whose schedule.

Names that have gone stale. A function called validate_user that also creates a session. A TempFile class that outlives the request. A config parameter that is actually a feature flag. The code changed, the name did not, and the name is what the next reader trusts.

Dependency direction. Which module could not be tested, reused or moved without dragging something heavy behind it? That is coupling with a cost you can name.