Almost everyone who works with agile software engineering practices is aware of Code Review, and most of you already had a chance to participate in such kind of acitivities. Unfortunately very few people realize that Code Reviews is not only an approach of making the architecture and code better, but also important communication point between peers, where ones judge and others get judged. Teams which don’t follow the basic rules of efficient communication and problem solving during Сode Reviews, have a high risk of being affected by issues, which can lately ruin their team attitude and even personal relations between the colleagues. Having faced with such negative experiences, I’ve collected a plenty of bad practices running a Code Review and asked my colleagues about their emotions after being “code reviewed” in unproper way. With all of that we’ll try to understand the most dangerous pitfalls of weak Code Reviews, their influences on team morale and will also leave some place for your experiences with this approach from your side. As a result you’ll have a clear idea about how no to run a Code Review and avoid personal issues in your daily work.

1. How not to run
Code Reviews
Viktor Malyi
Software Testing Engineer
Garmin Würzburg GmbH, Germany

2. 2
Hallo!
Software Testing
Engineer Würzburg (Germany)
Earlier:
Web-apps testing
Backend testing
Performance testing
iOS, Android apps testing
Leading testing teams

3. 3
What I do?

4. 4
Today
What do we think code review is?
What is code review in reality?
What to avoid?
What to pursue?

5. 5
Why doing Code Reviews?
Of course to
find bugs!

6. 6
Other reasons for doing
Code Reviews?
• To help
• To teach/learn
• Or to criticize?

7. 7
Code Review meetings

8. 8
„Over the shoulder“

9. 9
Remote reviews
(tools-assisted)

10. 10
It’s not only about the code…

11. 11
Resistance to code review

12. 12
„Ego-Effect“

13. 13
Core Developers…
… get their reviews
approved quicker*…
Impact of Developer Reputation on Code Review Outcomes in OSS Projects: An Empirical Investigation
Amiangshu Bosu, Jeffrey C. Carver. Department of Computer Science, University of Alabama

14. 14
… and more often*
Impact of Developer Reputation on Code Review Outcomes in OSS Projects: An Empirical Investigation
Amiangshu Bosu, Jeffrey C. Carver. Department of Computer Science, University of Alabama

15. 15
There is a
problem

16. 16
You’re judged each time

17. 17
Do you feel that the
code reviews you
do for other people
are constructive
and clear?*
No
2 %
I don't know
31 %
Yes
67 %
*International online survey among IT-Professionals, November 2014, 310 participants

18. 18
Do you feel that
code reviews
you do for other
people have
been considered
picky?*
No
21 %
I don't know
56 %
Yes
23 %
*International online survey among IT-Professionals, November 2014, 310 participants

19. 19
Why do you think your reviews
are considered picky?*
*International online survey among IT-Professionals, November 2014, 310 participants
Not constructive and clear
“-1” numerous times
Too many emotions
Bad personal relations
0% 5% 10% 15% 20% 25% 30% 35% 40%
Multiple answers allowed

20. 20
Have you ever had a
feeling that the one
who reviews your
code criticizes you
personally and not
your code?*
Yes
15 %
No
85 %
*International online survey among IT-Professionals, November 2014, 310 participants

21. 21
Which implications it
has?
*International online survey among IT-Professionals, November 2014, 310 participants
Hard to get "+1"
0% 5% 10% 15% 20% 25% 30% 35%
Multiple answers allowed
Non-constructive and
emotional comments
I have to wait for review
too long

22. 22
Words can hurt
„Never do this in
such a way!“
„Why it’s used
here at all?“
„It’s all wrong!“
„WTF!?!“
„It’s obvious!“

23. 23
What to pursue?

24. 24
Ask questions rather than
make statements
You did it wrong…
What was the reason of…

25. 25
Don’t ask „Why?“
Why the variable is not local?
It seems that the variable…

26. 26
Praise/Reward/Honour
Well done!
Good job! Let’s add this
to our coding standards!

27. 27
Use code conventions

28. 28
Project-specific checklist
• Based on experience
• Includes critical programming issues
• Includes common mistakes
• Great source for teaching newcomers

29. 29
Review less, find more
Smart Bear case study on informal code reviews, 2006, 2500 reviews, 3.2 MLOC, 50 developers

30. 30
Explain more first
Smart Bear case study on informal code reviews, 2006, 2500 reviews, 3.2 MLOC, 50 developers

31. 31
Reviews must identify as
many defects as possible,
regardless of personality
who „caused“ or found
them

32. 32
PS
by SmartBear Software

33. Thanks!
v.stratus@gmail.com
@victormalyy