At Peak Games, one of the most important development practices is Code Review. We believe that, with Code Review we have * increased the code quality * decreased the bugs * encouraged collaboration * kept the code maintainable * created common language in the team In this presentation I try to give some samples and practices about * How we are doing Code Review. * What are the findings to be able to make it more effective. * What are we doing to make “Code Review” as a part of our development culture.

1. Code
Review
May 2015
@hakansaglam

2. Hakan Saglam
developing since 2000
doing code review since 2004
software developer @ havelsan
lead software developer @ oytek
project manager @ software ag
technical coordinator @ sony
solution architect @ sony
head of mobile development @ peak games

3. THE USUAL SUSPECTS
by Matt Owen

4. What is code review?

5. It is intended to find and fix mistakes
overlooked in the initial development phase,
improving both the overall quality of software
and the developers' skills.
CODE INSPECTION
INTRODUCED BY MICHAEL FAGAN IN 1976

6. CODE TEST

7. CODE TESTREVIEW

8. The
reviewer
and the
author
are a
team

9. Why should we do code review?

10. one hour
of inspection
20 hours
of testing
82 hours
rework
Each hour of inspection saved 20 hours of testing and
82 hours of rework effort had the defects found by
inspection remained in the released products.

11. If we do review at the earlier
stage, the cost to fix this will be
less. It is 2400% cheaper
to fix any issues in development
stage than in the production
environment.
http://www.kunal-chowdhury.com/2013/06/code-review-and-its-importance.html
http://www.veracode.com/blog/2015/03/how-code-review-best-practices-saved-one-company-millions

13. IS IT ALL ABOUT
BUGS?
BEYOND
THAT DEFINITION

14. DISCUSSIONS
COMMIT
DISCUSS
DISCUSS
DISCUSS
COMMIT
MERGE
https://flic.kr/p/fHgQDg
COMMIT DISCUSS

15. CULTURE
Every Code Review is an
opportunity to learn and teach.
And a very simple way to build
an engineering culture.
https://flic.kr/p/89YLs1

16. Who should make code review?

17. ALL TEAM
Team
Leader
Junior
Developer
Senior
Developer
Solution
Architect
Technical
Specialist
https://flic.kr/p/9XdG3M

18. The social incentives inherent in
voluntary code review policies
encourage developers to take ownership of the code.
AUTONOMY
http://alysonschafer.com/wp-content/uploads/2014/08/autonomy_makes_children_more_responsible.jpg

19. How should we do code review?

20. CODE
REVIEW
WAS
HARD

21. 1 CODE
REVIEW
via
TOOLS

22. BREAK
TASKS
INTO
SMALLER
PIECES
https://flic.kr/p/bBZMoJ
team

23. DEFINITION OF DONE
An agreed team definition of
done is essential to produce
high quality code.
team
https://flic.kr/p/8oXJWd

24. http://www.slideshare.net/lemiorhan/fix-your-broken-windows-with-code-review-phpist14
Reorder commits
with rebase
to make the review easier.
author

25. RUBBER
DUCK
DEBUGGINGhttps://flic.kr/p/39jEVr
author

26. author

27. LET’S DO
CODE
REVIEW
Instead of finding
your own solution,
try to understand
author’s solution.
https://flic.kr/p/4eLyGd
reviewer

28. MASLOW PYRAMID
OF CODE REVIEW
CORRECT
SECURE
READABLE
ELEGANT
ALTURIST
reviewer
http://blog.d3in.org/post/111338685456/maslows-pyramid-of-code-review

29. CORRECT
• Does the code do what it’s supposed to?
• Does it handle edge cases?
• Is it adequately tested to make sure that it stays correct?
• Is it performant enough for this use case?
reviewer

30. SECURE
• Does the code have vulnerabilities?
• Is the data stored safely?
• Is personal identification information handled correctly?
• Could the code be used to induce a DOS?
• Is input validation comprehensive enough?
reviewer

31. READABLE
• Is the code easy to read and comprehend?
• Does it make clear what the business requirements are?
• Are variables, functions and classes named appropriately?
• Does it use consistent coding convention?
reviewer

32. ELEGANT
• Does the code leverage well-known patterns?
• Does it achieve what it needs to do without sacrificing
simplicity and conciseness?
• Does the code reuse existing functions when applicable?
• Would you be proud of this code?
reviewer

33. ALTURIST
• Does the code leave the codebase better than what it
was?
• Does it inspire other engineers to improve their code?
• Is it cleaning up unused code?
• Is it improving documentation, introducing better patterns
through small-scale refactoring?
reviewer

34. reviewer
CHECKLIST
Develop your own domain and
language specific checklist
both for better review and
better coding.

35. reviewer
author
GIVE FEEDBACK
FEEDBACK EMBRACE
FEEDBACK
FEEDBACK
https://flic.kr/p/baYdD4

36. authorreviewer
WATCH
your
WORDS
LEAVE
your
EGOhttps://flic.kr/p/kr98Fr

37. https://flic.kr/p/7JAXE4
IMPLEMENT
AGREED
CHANGES
author

38. MERGE
PULL REQUEST
reviewer
http://www.inc.com/uploaded_files/image/how-to-merge-corporate-culutres-pop_8709.jpg

39. https://www.previousnext.com.au/blog/automated-drupal-testing-github-pull-requests
CODE
REVIEW
via
TOOLS
RECAP

40. TWO DEVELOPER
ONE MACHINE
https://flic.kr/p/84RfxX
PAIR PROGRAMMING
2

41. pair
SOME
TASKS
NEEDS TO BE
COMPLETED
IN ONE
BLOCK
OF
TIME
http://groundedpsyche.com/wp-content/uploads/2015/01/Iceberg.png

42. THINGS CAN
HAPPEN
pair
THAT ARE NOT
PART OF THE PLAN
https://flic.kr/p/fq4RiW

43. ONBOARD
YOUR
NEW
COMERS
pair
https://flic.kr/p/5hbe4x

44. SOME-
TIMES
YOU
JUST
NEED
HELP
pair

45. TEAM REVIEW
3
LET’S GET
TOGETHER

46. team
GETTING READY
FOR NEW
TECHNOLOGIES
http://www.kaizen-news.com/wp-content/uploads/2014/02/5s-ingrediants.jpg

47. team POST PROJECT
REVIEWS
(a.k.a.)
AFTER PARTY
CLEANING
https://flic.kr/p/2PVtrp

48. TO MAKE
THE RIGHT MOVES
team
SOFTWARE ENGINEERING
PRINCIPALS
https://flic.kr/p/4hLh9S

49. CODE REVIEW
PRACTICES
PULL REQUESTS
PAIR
PROGRAMMING
TEAM REVIEW
RECAP

50. What is code review?
Why it is needed?
Who should make review?
How we can do it with tools?
How we can do it in pairs?
How we can do it as team?

51. Make peace with the
simple fact that the
code you’re shipping
today has bugs.
Make peace that your
work is never done.
https://flic.kr/p/8ZxReChttp://www.pushing-pixels.org/2015/04/15/make-peace.html

52. @hakansaglam