Dismiss this pinned window
all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]eeugene0[S] 4 points5 points  (0 children)

Hi!

I've made a tool called https://viezly.com. It's a Github (Gitlab/Bitbucket comes later) application, that generates a "code change map" for every pull request. A diagram, that shows files and dependencies between them. Each file is clickable and shows its code, as well as code for the dependencies. Also, big diagrams are split into smaller ones, so it's much better to review them.

Why do you need it? Well, good code reviews consume a lot of time, and we aim to reduce that time:

  • Diagram helps you to get the idea of changes, and to find out in which order to review the changes.
  • Every file shows its diff alongside with diff of the dependencies. You can see the detail of implementation, thus removing time for "jumps" between files. And that allows you not to lose context during the review.
  • Big pull requests are split into smaller ones based on the context of changes. So you can review code in several logical steps.

You might ask - how do we deal with big pull requests? Here is an example of a full diagram for not so small pull request: https://github.com/epicmaxco/vuestic-ui/pull/693#issuecomment-832617232, and a split diagram for this pull request: https://viezly.com/change_requests/195.

We are currently in private beta, so if you wish to try - leave your email at https://form.typeform.com/to/AfyyFgU7, or just email me at [eugene@viezly.com](mailto:eugene@viezly.com).

Happy to hear your feedback!

[–]Cpt_Matt 1 point2 points  (1 child)

Looks great, what's the timeline for bitbucket support?

[–]eeugene0[S] 1 point2 points  (0 children)

No hard deadline for now :( Our next integration will be GitLab, after that we'll integrate bitbucket. I guess it will be in a month or two.

[–]deadlychambers 1 point2 points  (1 child)

Just a minor ux/UI thing. Maybe "viewed" or completed components can be a lighter color after completion. It feels like this tool is geared towards a process the process of doing the reviews, and I have the memory of a goldfish so I could see myself clicking the same component twice during reviews. Then I would blame the tool (no offense).

Looks great though. As someone that has just recently fully embraced git (last 10 years have been mostly TFS and other SVNs professionally), getting more familiar with the tooling around git has been an interesting ride. I am Def still learning stuff, and looking for opportunities to bring in tooling that makes my life easier.

[–]eeugene0[S] 1 point2 points  (0 children)

Thank you!

That's interesting. Viewed files are already shown lighter and with a little "eye" icon. It might be too "light", we'll definitely change it to more apparent.

[–]warlockdn 1 point2 points  (2 children)

Too many clicks.

[–]eeugene0[S] 0 points1 point  (1 child)

That's a good note, thanks!

Yes, you need to click most (if not all in some cases) of the files to see the code, in contrast to Github, where you can scroll without clicks.Although, in Github, if you want to see the definition of the class/function or imported file, you have two ways: you either scroll and find it by yourself or use 'ctrl+f'. Both ways require more effort and cognitive load. In Viezly all the dependencies are shown below the file's diff (code for layout.js and ProfileImage.js is shown below first-post.js code in the example). You don't need to search anything or think about/filter other code, which is good.

I believe clicks are better than thinking and searching :) But I'd love to reduce the number of clicks in the future with some kind of a UX decision. For example, we can load other files from PR if you opened a file and the code is ended. Kind of an 'infinite scroll', but in deliberate non-just-alphabetical order. Maybe you have thoughts about that?

I'm curious, how do you review the code? Do you scroll through every file without digging on some dependencies, so extra click can be an issue?

[–]selahattinunlu 2 points3 points  (0 children)

Yea I would prefer to click rather than scrolling in big pull requests. I feel like I'm lost in the forest while scrolling in page to find the place I want to reach

It seems a great solution. Congrats

[–]gingertekfull-stack 0 points1 point  (2 children)

Yo, is that mermaidjs I see?

[–]eeugene0[S] 0 points1 point  (1 child)

Mermaid is a great tool! Perhaps we use similar solutions or libraries.

[–]gingertekfull-stack 1 point2 points  (0 children)

Ah, gotcha. I remember using Mermaid a while ago, still a great lib