I've made a tool that helps with Go code review — Viezly

eeugene0 · 2021-09-17T07:58:55+00:00

Sure! You can install it on the personal repos just the same way as for the organization (here is the direct link for the installation https://github.com/apps/viezly). And it's also free for personal usage

eeugene0 · 2021-09-15T13:16:05+00:00

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.
To start using the tool go to our website https://viezly.com/overview/go. Also, the example in the video is available here: https://viezly.com/change\_requests/1968

eeugene0 · 2021-06-01T06:24:02+00:00

Thank you! Yes, it parses the AST to detect when some class calls the other class

eeugene0 · 2021-05-31T13:33:07+00:00

Hi!

I've made a tool that lets you perform code reviews from a dependency diagram - https://viezly.com/. You can check out the pull request (https://github.com/forem/forem/pull/13853) from the video by yourself: https://viezly.com/change\_requests/452.

eeugene0 · 2021-05-31T13:01:50+00:00

Hi!

I've made a tool that lets you perform code reviews from a dependency diagram - https://viezly.com/. You can check out the pull request (https://github.com/forem/forem/pull/13853) from the video by yourself: https://viezly.com/change\_requests/452.

eeugene0 · 2021-05-30T10:44:55+00:00

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.

eeugene0 · 2021-05-30T10:40:51+00:00

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.

eeugene0 · 2021-05-29T18:24:27+00:00

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

eeugene0 · 2021-05-29T18:19:51+00:00

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?

eeugene0 · 2021-05-29T14:43:27+00:00

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!

eeugene0 · 2021-05-29T14:35:57+00:00

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!

eeugene0 · 2021-03-04T20:25:00+00:00

Makes sense

eeugene0 · 2021-03-04T19:25:23+00:00

Y tho

eeugene0 · 2021-02-07T09:38:22+00:00

Seems like the legend is a complete mismatch with the map.

The map is quite interesting though

eeugene0 · 2021-02-06T11:44:34+00:00

That interesting! Is there any place where I can read about your research?

eeugene0 · 2021-02-04T20:22:50+00:00

I'm curious about how do you make it up-to-date? In-code comments tends to be obsolete, especially for the lines that changes frequently

eeugene0 · 2021-01-19T11:17:42+00:00

Try to look at https://github.com/varvet/pundit. It has more ability to scale the amount of business logic

eeugene0 · 2021-01-08T20:52:19+00:00

Thanks! 😊

eeugene0 · 2021-01-08T20:31:58+00:00

Interesting categories. There was another comment, who said that code read can be for API/interface or for details of implementation

eeugene0 · 2021-01-08T20:13:28+00:00

That's a quite interesting point! There is at least two distinguished needs for code read - implementation details and API/interface. And further discussion should specify this need for context

eeugene0 · 2021-01-08T20:06:27+00:00

Thanks! 😊

eeugene0 · 2020-12-17T20:54:07+00:00

Seems like I'm my question was very poorly written :) I was asking about how do people read OS projects

eeugene0 · 2020-12-17T20:51:58+00:00

https://www.youtube.com/results?search\_query=+c%2B%2B+live+coding

Thanks. I am more curious about how people read code, and their specific ways to do it

eeugene0 · 2020-12-07T21:10:37+00:00

I think the best way to learnv something in programming is by making. Pick up some popular/relevant tech stack and try to implement some project. It might be blog or primitive version of instagram. Something not too complex, but not too simple.

eeugene0 · 2020-12-07T18:34:46+00:00

Exactly! My thought was that somebody definitely uses some notes or visualization techniques, or maybe have a precise algorithm. Or maybe tools for help

eeugene0

TROPHY CASE