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.

Code Review: How And When

165 views

Published on

You want to improve your software skills. That’s a given. You may be a mentor or a manager who needs to improve the knowledge sharing among your software developers across different projects. Code Reviews can do just that while improving code quality in your projects. Code Review not only builds developer team spirit but also offers new ways to improve a software solution. You’ll walk away from this session with in-depth understanding of Code Review to strengthen your team.

Published in: Software
  • Be the first to comment

Code Review: How And When

  1. 1. Code Review How And When @paulmgower
  2. 2. I’m Paul Gower. Principal Consultant at Lunamark @paulmgower
  3. 3. AGENDA What Is Code Review1 2 3 How and When Why Code Review
  4. 4. What Is Code Review 1
  5. 5. Father of Code Review http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5388086&filter%3DAND%28p_IS_Number%3A5388084%29 aka Fagan Inspections
  6. 6. Fagan Inspections https://en.wikipedia.org/wiki/Fagan_inspection
  7. 7. Code Review History
  8. 8. Why Use Fagan Inspections?
  9. 9. Why Use Fagan Inspections? Good for Mission Critical Software
  10. 10. Lightweight Code Reviews https://en.wikipedia.org/wiki/Code_review
  11. 11. Over-the-shoulder
  12. 12. Email pass-around
  13. 13. Email pass-around Please don’t do this!
  14. 14. Pair Programming
  15. 15. Tool-Assisted Code Review
  16. 16. Tool-Assisted Code Review
  17. 17. Tool-Assisted Code Review
  18. 18. Tool-Assisted Code Review
  19. 19. Tool-Assisted Code Review
  20. 20. Tool-Assisted Code Review
  21. 21. Tool-Assisted Code Review
  22. 22. Tool-Assisted Code Review
  23. 23. Tool-Assisted Code Review
  24. 24. How and When 2
  25. 25. Reviewer: Focus on the code
  26. 26. Reviewer: Focus on the code Don’t say: “You didn’t name these variables well!”
  27. 27. Reviewer: Focus on the code Don’t say: “You didn’t name these variables well!” Instead: “I don’t understand these variable names, can you help me understand them?”
  28. 28. Reviewer: Be respectful
  29. 29. Reviewer: Find a positive point
  30. 30. How NOT to Code Review
  31. 31. Author: Be humble
  32. 32. Author: Prepare Before
  33. 33. “ “The objective is for everyone to find defects, including the author, not to prove the work product has no defects. People exchange work products to review, with the expectation that as authors, they will produce errors, and as reviewers, they will find errors. Everyone ends up learning from their own mistakes and other people’s mistakes.” – Jerry Weinberg, “The Psychology of Computer Programming”, 1971
  34. 34. Tips and Tricks
  35. 35. Less Than 200 Lines Of Code
  36. 36. Less Than 60 Minutes
  37. 37. Less Than 60 Minutes http://www.news.illinois.edu/news/11/0208focus_AlejandroLleras.html
  38. 38. Daily Code Review
  39. 39. Daily Code Review http://blog.fogcreek.com/effective-code-reviews-9-tips-from-a-converted-skeptic/
  40. 40. Always Use A Checklist
  41. 41. Always Use A Checklist http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De
  42. 42. Don’t Be This Guy
  43. 43. Don’t Review What Can Be Automated
  44. 44. Static Code Analysis Tools
  45. 45. Static Code Analysis Tools
  46. 46. Static Code Analysis Tools
  47. 47. Static Code Analysis Tools
  48. 48. Static Code Analysis Tools
  49. 49. Static Code Analysis Tools
  50. 50. 3 Why Code Review
  51. 51. “ “…the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.” - Steve McConnell, Code Complete, 2004
  52. 52. Before 55% Code Review Case Studies
  53. 53. Before After 2% 55% Code Review Case Studies
  54. 54. Before Code Reviews
  55. 55. After Code Reviews
  56. 56. Reasons to Code Review
  57. 57. Save Money
  58. 58. Easier To Find Other’s Mistakes
  59. 59. Alternative Implementations
  60. 60. Knowledge Sharing
  61. 61. “ “The aim is to catch what mistakes you can and to get better – not to attempt perfection.” - Erik Dietrich, “Creating Your Code Review Checklist”, 2015
  62. 62. Review • No more than 60 mins • No more than 200 lines of code • Use Static Code Analysis • Use Check Lists • Use A Code Review Tool
  63. 63. THANK YOU! @paulmgower http://bit.ly/mcc2016-cr lunamark.com

×