During the trunk-based development support group session at #SoCraTes2022 naturally, the code review topic came by.
Some takes ...
Some takes ...
One problem with code reviews:
We put all the collaboration in the code review but it happens too late.
@SamirTalwar
We put all the collaboration in the code review but it happens too late.
@SamirTalwar
With PRs we created a world where the amount of time we spend reviewing code has become disproportionate to the time spent creating value.
@sebrose
@sebrose
@sebrose suggests that the code review should start with the tests.
Do the tests describe the change? If not, stop the code review. Go put the missing tests.
Also, check if the tests are aligned with the acceptance criteria.
Do the tests describe the change? If not, stop the code review. Go put the missing tests.
Also, check if the tests are aligned with the acceptance criteria.
Options to avoid PRs:
- half an hour at the start of the day where the whole team reviews the commits of the last day
- have a half an hour optional call every day to discuss code with the team
@SamirTalwar
- half an hour at the start of the day where the whole team reviews the commits of the last day
- have a half an hour optional call every day to discuss code with the team
@SamirTalwar
More options to avoid PRs:
- pair programming which enables continuous code review
- ensemble programming which then also enables single-piece flow
- non-blocking code reviews on mainline
- pair programming which enables continuous code review
- ensemble programming which then also enables single-piece flow
- non-blocking code reviews on mainline
• • •
Missing some Tweet in this thread? You can try to
force a refresh
