Presentation on how to have effective code reviews given at Carolina Codes 2018.

1. Cameron Presley
@pcameronpresley
Cameron@TheSoftwareMentor.com
How to Have Code Reviews
Your Developers Actually Want

2. 2
Hello!

3. The
Problem

4. “Looks Good To Me
4

5. 5

6. 6

7. What about …?
Or …?
Or …
Thoughts on …?
7

8. 8

9. 9

10. 10

11. What’s
The
Goal Of A
Code
Review?

12. “
Code review is systematic
examination (sometimes referred to
as peer review) of computer source
code. It is intended to
find mistakes overlooked in
the initial development phase,
improving the overall quality of
software.
- Wikipedia
12

13. Not only for software
development
￮ Architects – Red Line Reviews
￮ Engineers – Peer Reviews
￮ Doctors – Consultations
￮ Welders – Welding Review
13

14. “
Code review is systematic
examination (sometimes referred to
as peer review) of computer source
code. It is intended to
find mistakes overlooked in
the initial development phase,
improving the overall quality of
software.
- Wikipedia
14

15. Why the focus on
finding bugs sooner?
Bugs cost more
the later they’re found
15

16. How Many Times
More?
16
Time
Introduced
Requirements Architecture Construction System
Test
Post
Release
Requirements 1 3 5-10 10 10-100
Architecture - 1 10 15 25-100
Construction - - 1 10 10-25
from Code Complete 2nd Edition

17. How Much
Savings?
IBM found that each hour of
inspection prevented about 100 hours
of related work
Assuming $25 an hour, that means
for every $25 invested, $2500 was
saved.
17

18. How Much
Savings?
Raytheon reduced its cost of rework
from 40% of project cost to 20% of
project cost
The amount spent on bug fixes
dropped by 50%
18

19. 19

20. Code
Reviews
For Me
20

21. 21

22. Which Developer Would
You Prefer?
22
0
1
2
3
4
5
6
0 1 2 3 4 5
Experience
Years Working
Developer A Developer B

23. 23

24. 24

25. 25

26. 26

27. 27
Source

28. 28
No Faster than
500 LOCs an hour

29. 29
No More than
an hour at a time

30. 30

31. Opinion Based
Improvements
31

32. “ That’s not how
I would have
done it…
32

33. 33
Is the goal to have everyone
code the same?
No, it’s to solve the problem

34. 34
Frame Suggestions Around
Context using When, What,
and Why

35. 35
Never return null when
retrieving a list of records
from the database

36. 36
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code

37. 37
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code

38. 38
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code

39. 39
When returning records from the database and
there aren’t any, we should return an empty list
because all of the list methods work on an empty
list and we don’t have to introduce error handling
code

40. 40

41. “
What should you do when
the array is empty?
41
Reinforce Joint Ownership

42. “
What should you do when
the array is empty?
What should we do when
the array is empty?
42
Reinforce Joint Ownership

43. “
This for loop is garbage,
what in the world were
you thinking?!
43
Code Is The Problem

44. “
This for loop is garbage,
what in the world were you
thinking?!
I’m having issues
understanding this for
loop, can you step me
through what it’s doing?
44
Code Is The Problem

45. 45

46. 46

47. 47

48. 48

49. What I
Look For
49

50. Quality
￮ Are inputs handled correctly?
￮ Is the right answer computed?
￮ How about nulls? Empty Arrays?
Negative numbers, etc?
￮ What about edge cases?
￮ Are errors handled gracefully?
￮ Does the app crash?
￮ Is the user presented with a
message?
50

51. 51

52. Readability
￮ Determined by your team
￮ Clear beats clever, but what makes
code “clear”?
￮ Write code simple enough for your
team to understand, but strive to
improve the lower bound
52

53. Maintainability
￮ Code is in flux
￮ The longer it takes to make changes…
￮ The more expensive the work
￮ More likely to make mistakes
￮ Are certain design principles being
followed?
￮ SOLID, DRY, YAGNI, KISS 53

54. Style
￮ Does this C# code look like it was
written by a C# developer? Or more like
a Ruby developer?
￮ Focus on
￮ Naming conventions
￮ Proper coding constructs
￮ Project structure
54

55. 55

56. Next Steps
Ask someone you respect to review your
work
￮ Company == Coworker
￮ Side Project == Friend
56

57. Next Steps
Implement Code Review Process at work?
￮ Convincing your boss? Code Complete
by Steve McConnell
￮ Trying to design the process?
Brainstorming About Code Reviews by
Geoff Mazeroff
57

58. 58
Resources
￮ The Clean Coder: A Code of Conduct for Professional Programmers by
Robert C. Martin
￮ 11 Proven Practices For More Effective, Efficient Peer Code Review
￮ Code Complete 2nd Edition by Steve McConnell
￮ Brainstorming About Code Reviews by Geoff Mazeroff
￮ http://blog.TheSoftwareMentor.com/presentations/#CodeReviews

59. Feedback!
59
http://blog.TheSoftwareMentor.com/F
eedback