Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Voxxed days 2015-hakansaglam-codereview

2,472 views

Published on

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.

Published in: Software

Voxxed days 2015-hakansaglam-codereview

  1. 1. Code Review May 2015 @hakansaglam
  2. 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. 3. THE USUAL SUSPECTS by Matt Owen
  4. 4. What is code review?
  5. 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. 6. CODE TEST
  7. 7. CODE TESTREVIEW
  8. 8. The reviewer and the author are a team
  9. 9. Why should we do code review?
  10. 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. 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
  12. 12. IS IT ALL ABOUT BUGS? BEYOND THAT DEFINITION
  13. 13. DISCUSSIONS COMMIT DISCUSS DISCUSS DISCUSS COMMIT MERGE https://flic.kr/p/fHgQDg COMMIT DISCUSS
  14. 14. 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
  15. 15. Who should make code review?
  16. 16. ALL TEAM Team Leader Junior Developer Senior Developer Solution Architect Technical Specialist https://flic.kr/p/9XdG3M
  17. 17. 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
  18. 18. How should we do code review?
  19. 19. CODE REVIEW WAS HARD
  20. 20. 1 CODE REVIEW via TOOLS
  21. 21. BREAK TASKS INTO SMALLER PIECES https://flic.kr/p/bBZMoJ team
  22. 22. DEFINITION OF DONE An agreed team definition of done is essential to produce high quality code. team https://flic.kr/p/8oXJWd
  23. 23. http://www.slideshare.net/lemiorhan/fix-your-broken-windows-with-code-review-phpist14 Reorder commits with rebase to make the review easier. author
  24. 24. RUBBER DUCK DEBUGGINGhttps://flic.kr/p/39jEVr author
  25. 25. author
  26. 26. LET’S DO CODE REVIEW Instead of finding your own solution, try to understand author’s solution. https://flic.kr/p/4eLyGd reviewer
  27. 27. MASLOW PYRAMID OF CODE REVIEW CORRECT SECURE READABLE ELEGANT ALTURIST reviewer http://blog.d3in.org/post/111338685456/maslows-pyramid-of-code-review
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. reviewer CHECKLIST Develop your own domain and language specific checklist both for better review and better coding.
  34. 34. reviewer author GIVE FEEDBACK FEEDBACK EMBRACE FEEDBACK FEEDBACK https://flic.kr/p/baYdD4
  35. 35. authorreviewer WATCH your WORDS LEAVE your EGOhttps://flic.kr/p/kr98Fr
  36. 36. https://flic.kr/p/7JAXE4 IMPLEMENT AGREED CHANGES author
  37. 37. MERGE PULL REQUEST reviewer http://www.inc.com/uploaded_files/image/how-to-merge-corporate-culutres-pop_8709.jpg
  38. 38. https://www.previousnext.com.au/blog/automated-drupal-testing-github-pull-requests CODE REVIEW via TOOLS RECAP
  39. 39. TWO DEVELOPER ONE MACHINE https://flic.kr/p/84RfxX PAIR PROGRAMMING 2
  40. 40. pair SOME TASKS NEEDS TO BE COMPLETED IN ONE BLOCK OF TIME http://groundedpsyche.com/wp-content/uploads/2015/01/Iceberg.png
  41. 41. THINGS CAN HAPPEN pair THAT ARE NOT PART OF THE PLAN https://flic.kr/p/fq4RiW
  42. 42. ONBOARD YOUR NEW COMERS pair https://flic.kr/p/5hbe4x
  43. 43. SOME- TIMES YOU JUST NEED HELP pair
  44. 44. TEAM REVIEW 3 LET’S GET TOGETHER
  45. 45. team GETTING READY FOR NEW TECHNOLOGIES http://www.kaizen-news.com/wp-content/uploads/2014/02/5s-ingrediants.jpg
  46. 46. team POST PROJECT REVIEWS (a.k.a.) AFTER PARTY CLEANING https://flic.kr/p/2PVtrp
  47. 47. TO MAKE THE RIGHT MOVES team SOFTWARE ENGINEERING PRINCIPALS https://flic.kr/p/4hLh9S
  48. 48. CODE REVIEW PRACTICES PULL REQUESTS PAIR PROGRAMMING TEAM REVIEW RECAP
  49. 49. 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?
  50. 50. 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
  51. 51. @hakansaglam

×