Im 100% agree! Devs, in general, dont like the tedius of review code. In my experience some teams dont do the review process with 100% dedication, and when it occurs your are not garantee quality what is what do you want with code reviews.
Wouldn't rebasing the feature branch on the main branch **often** solve the issue of diverging branches? Perhaps I misunderstood the concept and need more reading.
These types of articles are very superficial and don’t consider different aspects of different teams and dynamics.
Peer programming in remote positions is pretty challenging. Even in person.
And also, trunk-based development is in no way “a first step to applying CI”.
CI/Cd needs A LOT of tests and there are many situations where tests are not covering enough code or do not exist at all. Not ideal, but a reality.
And creating them, especially for existing code, is very expensive. As is implementing TDD when your developers have no experience in it.
And there are very valid use cases where you need to have different versions of your code. For example, you develop a separate feature that can’t be released in an unfinished state but your production still needs updates during that time. I know feature flags can mitigate this, but not always.
It’s never as black and white. Every practice and tool and standard has its specific situations where they should be applied.
I can see from my network & from the job ads that less and less organization are using peer programming. It was trending few years ago, but it didn't reach a good momentum to get adapted by the masses and in reality is in diminution.
The best practice is to use what is suitable at the moment for your current project and to be agile in adopting new concepts as the project and the team grows.
There is no universal formula that works everywhere, as not every company is an unicorn.
More collaboration is often the answer to many software problems teams are encountering.
Conclusion, year 2024 and there are tons of teams and devs who still don't know what continuous integration is or what rebase is all about.
Im 100% agree! Devs, in general, dont like the tedius of review code. In my experience some teams dont do the review process with 100% dedication, and when it occurs your are not garantee quality what is what do you want with code reviews.
thanks for writing about Trunk based development.
Wouldn't rebasing the feature branch on the main branch **often** solve the issue of diverging branches? Perhaps I misunderstood the concept and need more reading.
These types of articles are very superficial and don’t consider different aspects of different teams and dynamics.
Peer programming in remote positions is pretty challenging. Even in person.
And also, trunk-based development is in no way “a first step to applying CI”.
CI/Cd needs A LOT of tests and there are many situations where tests are not covering enough code or do not exist at all. Not ideal, but a reality.
And creating them, especially for existing code, is very expensive. As is implementing TDD when your developers have no experience in it.
And there are very valid use cases where you need to have different versions of your code. For example, you develop a separate feature that can’t be released in an unfinished state but your production still needs updates during that time. I know feature flags can mitigate this, but not always.
It’s never as black and white. Every practice and tool and standard has its specific situations where they should be applied.
I can see from my network & from the job ads that less and less organization are using peer programming. It was trending few years ago, but it didn't reach a good momentum to get adapted by the masses and in reality is in diminution.
The best practice is to use what is suitable at the moment for your current project and to be agile in adopting new concepts as the project and the team grows.
There is no universal formula that works everywhere, as not every company is an unicorn.