points by Buttons840 6 hours ago | 0 comments
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?
[–] NewJazz 3 hours ago
[–] jeffbaumes 2 hours ago
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
[–] Buttons840 2 hours ago
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.
[–] jayknight 5 hours ago
I mean if it's a code review, you gotta review the code.
[–] johannes1234321 5 hours ago
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?)
[–] karakrakow 4 hours ago
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
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