I feel a bit theoretical today.
Lets say you have a team of 5 people working on some big project. The project is usual 3-tier project, so there is a datastore and datastore layer needs to be written.
Now lets assume one guy designed the datastore and now writes ORM stuff he is pretty much done, but cannot check in until code reviews are done. Sometimes code reviews are fast, sometimes they are not. If they are not, you are now stuck, team cannot progress as a team because common dependency is not checked in, and everyone is dependent on it.
What can you do?
- Create a “dirty” branch everyone makes checkins to, so you have a non-reviewed prototype faster, everyone can grab latest changes and work on them.
- Pair programming
- Fix interfaces of datastore layer
The idea kinda works at the early stage of development, but later it brings problems, now everyone shall check in to development, but as development is non-reviewed you cannot send a code review diff between it and your code. So you shall do a code review on diff between development and mainline and a significant part of code is not yours.
The branch changes too fast, interfaces are flaky everyone merges very frequently with frequent conflicts.
The development branch outlives its initial purpose at the moment of first code review that makes a baseline for everyone else. Longer you drag it, more problems you’ll have. Now what you do is actually stop have everything there code-reviewed and progress further in GitFlow style or whatever else you prefer.
Now lets grab one of code reviewers and do pair-programming with that guy. By the time of code review your reviewer agrees to code more or less. The problem with approach is it is not a peer review, it is a self review!
This is just a recursion, the interface itself shall be code reviewed! Moreover nor reviewers, nor the author sees reall application of that interface, and it can be based on incorrect assumptions, which will break whole team productivity.
A big story on productivity is also doing work while code is on review (being penalized with merges afterwards), this kinda can be done with first approach with for example git, when you merge your feature branch into mainline. However if you allow development to progress your merge will break it, which comes to “stop and have everything reviewied”…
I am walking in circles or what.