Thought about code review

Do you wonder how to teach your team to make code reviews that are not a waste of time? My suggestions so far:

1. If you focus on code formatting you’re not doing it right. When you have tools, hooked (pre-commit hook) which checks that for you – it’s better.

We have githooks autoinstalator

We even have githooks autoinstalator

2. Use your brainpower for something simple tools can not do – try to understand what you read. As long as code compiles it’s ok for machine. Reviews are meant to make your team write code for (other) people.

constvscomment

3. Reviewer HAVE TO spot issues. She/he can have solutions, but when there’s none – a discussion should be initialized.

imposibru

4. Review doesn’t have to be 1 on 1. Invite rest of the team for their feedback.
invitation

5. Some action points after review would be “make refactor of this… some day”. This is at your team discretion if it’s possible to apply suggestions after review – sometimes it just can not be done.

This doesn't elaborate on point above -- I just think it's funny.

This doesn’t elaborate on point above — I just think it’s funny.

6. Sometimes you have to back your opinion. I remember explaining many times why commented code is worse than deleted code. Now others slap me with this when I leave some code for later:

comment

Share Button

Leave a Reply

Your email address will not be published. Required fields are marked *