O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
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.
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
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.
INTRODUCED BY MICHAEL FAGAN IN 1976
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.
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
The social incentives inherent in
voluntary code review policies
encourage developers to take ownership of the code.
• 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?
• 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?
• 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?
• 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?
• Does the code leave the codebase better than what it
• 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?
Develop your own domain and
language specific checklist
both for better review and
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?
Make peace with the
simple fact that the
code you’re shipping
today has bugs.
Make peace that your
work is never done.