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.
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
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
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
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
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
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