Ways to preserve knowledge

German Chyzhov — Sun, 10 Jan 2021 15:17:25 +0000

Recently I found article about maintenance.

It is pretty old(2010) but looks still valid. One of the principal factors affecting maintenance complexity mentioned in the article is "Preserving knowledge".

From my experience, there could be such ways to achieve that:

Document every process and algorithm used: keep at least high level overview.
Split all project's code into areas and identify who would maintain each of them. If the person decides to leave project, then he should share his knowledge with his successor.

Which ways do you use at your projects?
If you use 2nd approach, then how do you achieve it? Do you use any tools?

Tool for recommended reviewers like mention-bot

German Chyzhov — Sun, 10 Jan 2021 14:36:27 +0000

Please share what tools do you use for identifying recommended reviewers for Pull Requests in GitHub?

Before there was a tool like Mention-Bot, but now it is archived and not supported.

P.S. I am a creator of tool for finding recommended reviewers, and I am interested which ones are used at different projects.

Repository code reviewers analysis on example of dev.to

German Chyzhov — Sun, 22 Nov 2020 20:04:40 +0000

In this post I am going to analyze different approaches for searching the best reviewers for your code and Pull Requests.
I am going to do that based on dev.to code repository.
At the end there will be an example on how to do the same but in automated way.

Problem to be solved

I am a software engineer and worked for several years as a Tech Lead on different projects. To be able to provide a software product of a high quality it is important to establish reliable processes of code review.

The hardest question to be solved during a review process setup is how to select the best possible reviewer(s) for pull requests - people, who know affected code components and used technologies well?

There could be different solutions for this:

Everyone reviews code which he wants
Pros: no pain with searching for reviewers
Cons: this approach does not guarantee enough number and quality of reviewers
Tech lead is reviewing everything
Pros: guarantee for at least one reviewer
Cons: tech lead could be overwhelmed with different tasks, so review quality would suffer; this leads to a single point of failure - if lead is absent, then process is significantly affected
Assigning best possible reviewers based on experience in affected code components, modules, libraries and frameworks
Pros: maximum reviewing quality, the best way to share knowledge within a team
Cons: hard to automate, requires either lots of manual work or using proper tools

Let's consider this Pull Request as an example https://github.com/forem/forem/pull/9621
Let's find who could be the best recommended reviewers for it!

Manual search for reviewers

We need to have a look at a git history for each affected file and understand who did the most changes for each. After that we need to combine found reviewers into a list of up to 3-5 people.

More files in PR means more time spent. We will calculate total time spent on the procedure and amount of diffs to be looked at.

This PR has 9 files changed. Author is mstruve.
Let's look at the files to see who worked mostly on it.

.travis.yml Here we may see a pretty long history of changes: https://github.com/forem/forem/commits/e883fedbfdd0209bf31af5d50a712294093f3fad/.travis.yml Candidates(excluding mstruve): rhymes, maestromac, Zhao-Andy, citizen428, nickytonline, snackattas, vaidehijoshi, etagwerker, benhalpern. That is a long list. After looking at 15 different commits, I could assume that for this file the best reviewers could be: maestromac, citizen428, rhymes. Spent: 10 minutes. Looked at: 15 diffs.
Envfile - this file was deleted completely, so skipping it. Spent: 0 minutes. Looked at: 0 diffs.
Gemfile Here is its history: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/Gemfile What I see immediately, is that it is significantly polluted by auto commits done by bots, like dependabot. Candidates(excluding mstruve): maestromac, rhymes, lightalloy, benhalpern, jacobherrington, citizen428, swrobel, atsmith813, lizthegrey, nickytonline, vaidehijoshi, joshpuetz, fdoxyz, etagwerker. That is event harder. After looking at 30 commits, I could assume that for this file the best reviewers could be: rhymes, citizen428, vaidehijoshi. Spent: 15 minutes. Looked at: 30 diffs.
Gemfile.lock - this is technical file, auto-generated normally, so could be skipped. Spent: 0 minutes. Looked at: 0 diffs.
app/views/internal/configs/show.html.erb Here as well is a long history of changes: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/app/views/internal/configs/show.html.erb Candidates(excluding mstruve): rhymes, jacobherrington, benhalpern, citizen428, vaidehijoshi, Ridhwana, lightalloy, JibranKalia, jitendra1998, maestromac, JuanVqz, icncsx, AlbertoPdRF, Zhao-Andy, lisasy. After looking at 30 commits, I could assume that for this file the best reviewers could be: rhymes, benhalpern, citizen428, Ridhwana. Spent: 15 minutes. Looked at: 30 diffs.
config/initializers/0_application_config.rb This is an easy task, the history is short: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/config/initializers/0_application_config.rb I will consider only 2 last commits, because other ones are two old. Candidates(excluding mstruve): ledestin, rhymes, both could be considered as recommended. Spent: 1 minutes. Looked at: 2 diffs.
config/sample_application.yml Here again, history is not too long: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/config/sample_application.yml I will consider only 3 last commits, because other ones are two old. Candidates(excluding mstruve): jacobherrington, citizen428, both could be considered as recommended. Spent: 2 minutes. Looked at: 3 diffs.
docs/backend/configuration.md This is an easy one: https://github.com/forem/forem/commits/03888b918784064bccb41cfead52180f2e5e7c82/docs/backend/configuration.md Candidates(excluding mstruve): citizen428, Zhao-Andy, joshpuetz. All three could be recommended ones. Spent: 2 minutes. Looked at: 4 diffs.
vendor/cache/envied-0.9.3.gem - it is a bin file, could be skipped. Spent: 0 minutes. Looked at: 0 diffs.

Now we need to combine all lists per files of recommended reviewers into one list.
To do that, we would need to look at which files were changed mostly, so have higher weight in review.
I would say, these are files 1, 5 and 7.
So, final list of recommended reviewers could be: citizen428, Ridhwana.
Other reviewers, which could be helpful: rhymes, maestromac, vaidehijoshi, benhalpern.
Totally spent: 45 minutes.
Looked at: 84 diffs.

Automated way

Add project with dev.to code repository to Efficiefy.io app
Open page with Pull Requests, see that for PR with number 9621 there is a list of rhymes, Ridhwana as a recommended reviewers.

P.S.

I would be glad to hear how do you find recommended reviewers at your projects. Would you like to have a demo?
You may see screenshots of the app by link

How do you find the best reviewers for your PR(MR)?

German Chyzhov — Tue, 10 Nov 2020 16:21:42 +0000

Normally I solve this in the following way:
1) look through the git history of different files and folders affected by changes in my Pull Request;
2) then look who is available now;
3) then assign them and ask for their review.
When I was non team lead, I was also adding here my team lead.

Is there any better(faster) way to find the best possible reviewers?

DEV Community: German Chyzhov