Code Review

Why code reviews at all?

  1. 4 eye principle to avoid mistakes (human quality gate)

  2. Improve code quality by giving valuable feedback (like using streams instead of loops)

  3. Knowledge sharing

  4. Early feedback (pair programming?)

  5. A common feeling of good code within the team

  6. Give hints about edge cases

Who reviews?

  • Who has context,

  • Who has skills,

  • Who cares deeply,

  • Who needs to learn?

  • If you have time, go ahead and review

  • Assign yourself to the review-ticket

What is not part of the review?

  • Demand overwhelming changes that invalidates the whole PR
    → get early feedback on your work OR create follow up refactor tickets

  • Demand changes to unrelated code

  • Demand changes to the code formatting

  • Don’t check out and do maven install, that's what our CI is for

  • Don’t check out, build and test the frontend for every PR

As a reviewer:

  • Answer to the auto-comment bot’s checklist

  • Check Commit Messages → TSK-XXX: Your commit message.

  • Check that the PR fulfills the ticket

  • Check the SonarCloud analysis link for new issues

  • Check the answer to the bot asking for the updated documentation

  • Check test coverage

  • Check for edge cases and unwanted side effects

  • Check for readability

  • Ask what you do not understand

  • You are allowed to share personal feelings about clean code as suggestions

  • Have a good feeling to push this code to production