Code reviews can be painfully hard to review. Remember those with 1000+ LOC changed and multiple approves without any comment? Yeah (:
So we build a tool for easier review, that splits big changes into smaller parts. Also, you can see the architectural diagram for the changed code. It's useful for finding the entry file for review. And with navigation via file dependency, it's really easy to understand the changes in pull requests without spending a lot of time on it.
At Viezly we do a lot of experiments for the code review interface. Our goal is better code reading in code review. We did pretty good progress on that, so I'm happy to share our main features:
- Code visualization to find an entry point to start review. And to get a bird-eye view on changes
- Dependency navigation - once any file is opened, you can see its diff with its dependencies diff. And you can navigate into deeper dependencies on the left sidebar
- Pull request split. We detect big pull requests and split them into smaller parts. Thus you can a power of small pull requests (more comments), and the team can share the review on one pr between several people.
> - When reviewing PRs and wanting to check out some surrounding code that is not part of the actual PR.
It's interesting to see how suitable is the IDE for code review for different people. For me, it's usually pretty much overload, since it's focused on writing, not reading. But GitHub is really doing a great job of eliminating the necessity of cloning the branch for the review.
I'm doing a few experiments in this area on a tool called Viezly (example: https://viezly.com/change_requests/3986). Its focus is on dependency and navigation. So it's a light version of IDE-in-the-cloud for these cases of code review.
Viezly is a tool that visualizes git diff and splits big pull requests into smaller ones. It has an experimental code review interface. We aim to make a code reading problem easier and with more quality.