Problem that for developer who will made the task understanding take time T, while for not in area…
Andrey Nikishaev
1

Obviously, if in your team people are specialising in a particular parts of code, then code review would not produce any good results (the same as pairing).

In my case there is no “specialism” among developers in the same team, specialisation is between teams. The code itself is quite interesting (it is not your usual boring web application, it is quite technical). It is heavy on concurrency and as we know one of the areas where code reviews are indispensable is concurrency (it is very difficult to test).

We use Gerrit for code reviews.

The tricks for a team leader to ensure that code reviews work are:

  • Ensure that your code is always code reviewed by your team members and always react positively when a problem is found and make changes to the code you written. This will ensure that team members don’t see a problem someone found in their code as a assault on their position.
  • Don’t nitpick, accept that different people write code differently. Insist on changes only in case of a bug or a change that does not fit overall design. Be polite and try to explain.
  • Have coding standards and ensure that tools for automatic code formatting are used (both Eclipse and IntelliJ allow this and you can copy formatting rules between computers — when someone joins the company, just send them the formatting setup file). This will prevent “formatting wars”.
  • Have static code analysis tools run as part of CI (e.g. Sonar), this will reduce disagreements — it is easier to accept criticism from a machine then from a fellow developer.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.