Use cases / Engineering leadership, architects and anyone new to a codebase
Knowing the shape of a whole repository, not only its changes
Review the default branch as it stands: the design drawn and graded, every line checked, the code as a map.
The problem
Pull request reviews see a change at a time. Nobody sees the building: the import that runs the wrong way three layers down, the service the code calls that nothing documents, the runtime that went out of support last year.
What visualdiff does
- Pick a repository from a connected host, or paste any public repository link; the default branch is read unless you name another. The branch is downloaded as one archive, read in memory and never kept.
- The blueprint draws its layers, packages and imports, follows one request through, and grades the design in nine areas, every check listed with where it failed and the practice it comes from.
- The rules a pull request meets run over every line; the map shows how far each module sits from the internet and what depends on it, and the matrix shows the imports that run the wrong way.
- Each review of a branch is kept: compare any two with the changes painted on the blueprint, or draw several repositories together to see which call which and what they share.
A push to a reviewed branch reviews it again, so the picture is the code as it is today, not as somebody drew it last year.
Related
- Reviewing pull requests written by agentsAgents open pull requests faster than anyone can read them. Read the 10% that decides whether it is safe.
- Large refactors that hide a behaviour changeA refactor is supposed to change nothing. Find the one line that does.
- Stopping hallucinated dependenciesSlopsquatting: attackers register the package names models invent. Catch them at review.
- Seeing which running systems a change reachesThe diff says rds.tf. The map says orders-db, the API in front of it, and the queue behind it.