3 ms·
Absolutely! This works even better when doing the self-review with the same tool (typically, GitHub review system) as the one a real reviewer would use. Just lo
by franzb 4y ago
Absolutely! This works even better when doing the self-review with the same tool (typically, GitHub review system) as the one a real reviewer would use. Just looking at one's code in a different environment (different font, colors, etc.) helps switching from a "programmer's mind" to a "reviewer's mind".
- AndrewDucker 4y agoTotally. Looking at the diff and asking "But why did I make this change? And how would I justify it?" is very helpful.
- XorNot 4y agoExcept this is the problem with looking at patches in Github, as opposed to as source code. Github shows you such an utterly minimal view of the overall flow of the code that it's impossible in a lot of cases to tell what the intent was or why - you don't even have function-level context for it. Compare to if you simply checked out main and the PR, and ran a meld across both directories - changes would be highlighted, but now you have to read the code in context.
- notemaker 4y agoI, too, need to review my code in Gitlab/Github/Gerrit in order to catch errors - somehow they're much more prominent there (like you said, I suppose it's due to adopting a "reviewer's mindset") rather than just looking at `git diff`. But if possible I would like to review my work in the terminal as a part of my workflow, not needing to context switch to the browser. Has anyone found a good solution to that? FWIW, using tmux & nvim.
- aidos 4y agoI always review before committing with git diff in the terminal but I just find that once I create the PR I’ll spot something else when reviewing there. Not sure what it is but I think it’s just taking that moment to read through from a different perspective (might even be that a different ux gives that perspective). I don’t especially love the review workflow on GitHub - but I can definitely catch bugs there.