Voxxed days 2015-hakansaglam-codereview
•
9 likes•3,041 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Voxxed days 2015-hakansaglam-codereview
Similar to Voxxed days 2015-hakansaglam-codereview (20)
Recently uploaded
Recently uploaded (20)
Voxxed days 2015-hakansaglam-codereview
- 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
- 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
- 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?
- 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?
- 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
- 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.
- 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
- 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