I completely agree, but if the reviewer isn't able to (with some amount of accuracy) predict the impact the committed code will have on overall behaviour, then there's very limited value on doing the review in the first place
In any larger project, the reviewer are not able to predict impact from reading commit.
More importantly, typical reviewer have only small partia area where he has good idea about which commit is bad idea. He however does not understand whole codebase.
Knowing what the whole does and knowing what my module does are two different things.
Looking back at my reply, I think I should have added a bit of background to clarify my comment
My master's degree is in bioinformatics and I worked in the biotech industry until about a year ago. I mainly worked as a consultant for top 20 pharma companies, but also did work on different in-house projects and in academia
From my experience in the industry, I find it very unlikely that the software mentioned in the article is structured in a modular way. I've yet to see good software practices outside one or two academic projects. Most pharma companies still use copying and renaming folders as version control. Naturally I'm sceptical of any code coming from the biotech industry
On top of that, it's written in MATLAB. I have only ever seen this used by statisticians and university researchers, never by software engineers
I'm therefore willing to bet, that when the reviewers open the source code, they'll find unstructured mess of spaghetti code, that has never been refactored, reviewed or tested
So yes - I agree in all your points, but I find it unlikely that they're being applied to this particular project
