Download as PDF, PPTX
Uploaded byHakan Saglam
Voxxed days 2015-hakansaglam-codereview
The document discusses the importance of code review in software development, emphasizing its role in improving code quality and developer skills while reducing costs associated with fixing defects later in the process. It outlines best practices for conducting code reviews, including collaborative techniques such as pair programming and the establishment of a team definition of done. Additionally, it highlights various aspects of code quality that reviewers should evaluate, such as correctness, security, readability, elegance, and the overall impact on the codebase.
More Related Content
Similar to Voxxed days 2015-hakansaglam-codereview
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
Voxxed days 2015-hakansaglam-codereview
- 1.
- 2. Hakan Saglam developing since2000 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 byMatt Owen
- 4. What is codereview?
- 5. It is intendedto 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.
- 7.
- 8.
- 9. Why should wedo code review?
- 10. one hour of inspection 20hours 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 doreview 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 ALLABOUT BUGS? BEYOND THAT DEFINITION
- 14.
- 15. CULTURE Every Code Reviewis an opportunity to learn and teach. And a very simple way to build an engineering culture. https://flic.kr/p/89YLs1
- 16. Who should makecode review?
- 17.
- 18. The social incentivesinherent 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 wedo code review?
- 20.
- 21.
- 22.
- 23. DEFINITION OF DONE Anagreed 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 tomake the review easier. author
- 25.
- 26.
- 27. LET’S DO CODE REVIEW Instead offinding your own solution, try to understand author’s solution. https://flic.kr/p/4eLyGd reviewer
- 28. MASLOW PYRAMID OF CODEREVIEW CORRECT SECURE READABLE ELEGANT ALTURIST reviewer http://blog.d3in.org/post/111338685456/maslows-pyramid-of-code-review
- 29. CORRECT • Does thecode 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 thecode 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 thecode 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 thecode 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 thecode 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 owndomain and language specific checklist both for better review and better coding.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. pair SOME TASKS NEEDS TO BE COMPLETED INONE BLOCK OF TIME http://groundedpsyche.com/wp-content/uploads/2015/01/Iceberg.png
- 42. THINGS CAN HAPPEN pair THAT ARENOT PART OF THE PLAN https://flic.kr/p/fq4RiW
- 43.
- 44.
- 45.
- 46.
- 47. team POST PROJECT REVIEWS (a.k.a.) AFTERPARTY CLEANING https://flic.kr/p/2PVtrp
- 48. TO MAKE THE RIGHTMOVES team SOFTWARE ENGINEERING PRINCIPALS https://flic.kr/p/4hLh9S
- 49.
- 50. What is codereview? 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 withthe 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.