Hacker News Reader

Comment by Buttons840 | Hacker News Reader

The human experience of reviewing PRs hasn't really moved beyond "look at these 2000 lines of text and think really hard".

At least for me. Am I missing something?

View on HN

I at least:

Use CI results to control quality, no nitpicking style means easier review

Review tests one by one, to make sure I understand what the submitter is trying to test and if they actually did so

Check files off one-by-one, compartmentalizing understanding as I go

Complain loudly when PRs try to change too many subsystems or different functionality, especially if less related changes are not separated into standalone commits

I often have Claude make code walks specifically to present walls of code more sanely, add diagrams, bring in code context outside the diff, etc. This is one manifestation I made but I think there are many ways people are solving this (or roll your own tool!) https://github.com/jeffbaumes/code-walk

This is a great idea. Combine this with a tool that allows you to mark the lines of code you have reviewed and understand, and you're on your way to systematically working through the PR.

I mean if it's a code review, you gotta review the code.

Yes, but code can be presented in different ways. This depends of course to a degree on the submitter (large changeset touching a lot of files or smaller change sets building upon each other?) but also could be presented differently (highlighting changes to data structures, identifying core parts of code and helper routines - lots of room for imagination)

Also mind: one doesn't only have to review changes code, but also review what hasn't been changed (are preconditions of other code still met?)

I've been trying to auto generate diagrams on PRs I'm reviewing. Flows changes via sequence diagrams, state changes and schema changes, post it to the PR with a skill. Then look at the relevant code based on the diagrams. Then \code-reviews. Moderately helpful. YMMV

Reply on news.ycombinator.com