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.

How to Have Code Reviews Your Developers Actually Want

127 views

Published on

This phrase can stir up a lot of emotions for people. For some, it's aggravation because they're a waste of time, for others, it's stressful because it feels like you're getting personally attacked. However, for some, it's a great learning experience that leads to the team improving. Do you want to be in the latter group? Then this talk is for you!

In this presentation, I'll first show you the benefits of code review and the business case for why they should happen. Next, I'll show some of the most common mistakes that teams make during the review process and how to mitigate them. After talking about the bad, we'll talk about what to look for in your code review process. Finally, I'll wrap things up by showing the game plan I use for code reviews.

Intended for developers of all levels, attendees will leave understanding the reasons why we should have code reviews, signs of bad reviews, signs of good reviews, and have a starting template.

Prerequisites

No prerequisites are required.

Published in: Software
  • Be the first to comment

  • Be the first to like this

How to Have Code Reviews Your Developers Actually Want

  1. 1. How To Have Code Reviews Your Developers Actually Want CAMERON PRESLEY @PCAMERONPRESLEY HTTP://BLOG.THESOFTWAREMENTOR.COM
  2. 2. About Me
  3. 3. Outline ◦Why We Should Have Code Reviews ◦Common Mistakes Teams Make ◦Good Code Reviews Look Like… ◦What I Look For In a Review ◦How I Do a Code Review
  4. 4. What Do We Mean By Code Review?
  5. 5. Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. - Wikipedia
  6. 6. Concept is not unique to software development
  7. 7. Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. - Wikipedia
  8. 8. Why the focus on finding bugs sooner?
  9. 9. Bugs cost more the later they’re found
  10. 10. How Much Does It Cost To Fix A Bug? Time Introduced Requirements Architecture Construction System Test Post Release Requirements 1 3 5-10 10 10-100 Architecture - 1 10 15 25-100 Construction - - 1 10 10-25 from Code Complete 2nd Edition
  11. 11. IBM found that each hour of inspection prevented about 100 hours of related work Assuming $25 an hour, that means for every $25 invested, $2500 was saved.
  12. 12. Raytheon reduced its cost of rework from 40% of project cost to 20% of project cost The amount spent on bug fixes dropped 50%
  13. 13. As professionals, we are responsible for doing what’s best for our employer Plenty of incentives for companies to have code reviews But it’s not all about the company, what do we get out of it?
  14. 14. Developers start out knowing how to write code, but not much finesse Takes time to learn the nuances of development However, it’s not just time in the job, it’s constantly learning new techniques and perspectives
  15. 15. Which developer would you prefer? 5 years of experience or the same 1 year of experience 5 times?
  16. 16. How can you gain the experience? By learning from those who came before you There’s always someone who knows more than you and code reviews provide a way to gain that knowledge
  17. 17. The more experience you gain The more employable you are The more valuable you are
  18. 18. Why We Should Have Code Reviews It’s the right thing to do for the company ◦ Cheaper to fix bugs the sooner they’re found ◦ Relatively cheap way to mitigate risk for the company It’s the right thing to do for us ◦ Allows us to perfect our craft ◦ Shows us how others think about problems
  19. 19. Common Mistakes
  20. 20. Reviewing too much
  21. 21. We can’t review a ton of changes and expect to find any issues How much code is too much?
  22. 22. IBM partnered with SmartBear and Cisco to determine some best practices for code reviews Published as 11 Best Practices for Code Review
  23. 23. Source
  24. 24. Instead, break the down the work We should strive for smaller pieces of work Big changes will happen ◦ Need to have more frequent code reviews
  25. 25. Opinion Based Improvements
  26. 26. That’s not how I would have done it
  27. 27. Is the goal to have everyone code the same? No, it’s to solve the problem
  28. 28. If you have a suggestion, make sure to back it up with facts, not with gut reactions
  29. 29. Attacking the Developer
  30. 30. Reinforcing Joint Ownership Instead of… “What should you do when the array is empty?” What about … “What should we do when the array is empty?”
  31. 31. Code Is The Problem Instead of … “This for loop is garbage, what in the world were you thinking?” What about … “I’m having issues understanding this for loop, can you step me through what it’s doing?”
  32. 32. What Does A Good Code Review Look Like?
  33. 33. A Good Code Review Will Have Tight Collaboration ◦ Are both people working together? Fact Based Improvements ◦ Are suggestions based on merit? Knowledge Sharing ◦ Are both people learning something new? Bugs Being Caught
  34. 34. Tight Collaboration Everyone involved are asking questions and having a discussion Not one person should do all of the talking
  35. 35. Improvements Based on Facts Can be hard to classify “good” code or to give feedback that isn’t solely opinion based Frame the suggestion with your reasoning why. For example: “It looks like we have that same logic in a few different places, we should extract that logic out to a shared function/method so if we need to change it, it’s in one place.”
  36. 36. Knowledge Sharing One developer should not be solely responsible for a part of the application. Leads to problems like we can’t make changes without Cameron here By sharing business knowledge and the design of the code, other developers can pick up the context quickly
  37. 37. Knowledge Sharing
  38. 38. Catching Bugs Main business goal of code reviews are catching bugs If a bug is found, add it to your review notes After the review is over, go fix the bugs and get another review
  39. 39. Good Code Reviews Look Like Tight Collaboration Fact Based Improvements Knowledge Sharing Bugs Being Caught
  40. 40. What I Look At Quality Readability Maintainability Style
  41. 41. Quality Are inputs handled correctly? ◦Does the code give the correct answer for the input? ◦How about nulls? Empty arrays? Negative numbers, etc.? ◦What about edge cases? Are errors handled gracefully? ◦Does the app crash? Is the user presented with a message?
  42. 42. Readability Source
  43. 43. Readability This is determined by your team ◦Concise for one team is unintelligible for another Clear beats clever, but what makes code “clear”? ◦No surprises, the team can understand it Write code simple enough for a junior to understand, but strive to improve the lower bound
  44. 44. Maintainability Code is always in flux The longer it takes to change ◦ The more expensive the work is ◦ More likely to make a mistake Ensuring that relevant software design principles are being followed ◦ SOLID, DRY, YAGNI, KISS
  45. 45. Style Does the C# code looks like it was written by a C# developer? Or more like a JavaScript developer? Focus on ◦Naming conventions ◦Proper use of code constructs ◦Project structure
  46. 46. How I Do Code Reviews
  47. 47. Features
  48. 48. Framing – Understand the Need Describe the pain point in business terms Not only frames the problem in terms that your user understands, but it teaches the business If using Domain-Driven-Design, helps with ubiquitous language
  49. 49. Inspection – Examining the Solution Does the architecture make sense? ◦ If the application is service-oriented, then it doesn’t make sense for the feature to be layered Is it maintainable? ◦ It’s ok to have technical debt, but we’re looking for mortgage on a home, not Ferrari on a credit card Are the tests well written? ◦ You are writing tests, right…?
  50. 50. Verification – Trying Out the Feature Use the new feature like a user and see how well it solves the pain point Keep an eye out for steps that don’t make sense or where technical details bleed through
  51. 51. Reviewing Features Have we identified the pain point? Does the solution follow current architecture? Does the code follow our standards and guidelines? Are there tests over the new functionality? Does the feature work seamlessly, or are there rough patches?
  52. 52. Bugs
  53. 53. Framing In basic terms, what is the problem? ◦ Focus on what the user would be doing and stick with your domain language Can we consistently reproduce the error? ◦ If we can’t consistently reproduce the problem, how can we verify that the bug is ever fixed? Have we found the root cause? ◦ Have we found the source of the issue? Or are we just patching a symptom? ◦ Common mistake when working with new developers
  54. 54. Walkthrough – Top Down Start with the big picture and then drill down to the affected pieces
  55. 55. Walkthrough – Bottom Up Start with the pieces to build a foundation and then walk it up to form the big picture
  56. 56. Walkthrough – Special Focus Is there any part that the developer wants some extra attention on? Remember, the goal is to find bugs sooner than later ◦ So if there’s a particular rough spot, call it out and make sure you get it right Asking for help is not a weakness, it shows maturity
  57. 57. Walkthrough - Reviewing Majority of code review should be spent here Provides feedback on the work done, ideas for improvement Check that the code is readable, maintainable, follows correct style, and is of adequate quality Developer and Reviewer agree on changes needed (if any)
  58. 58. Verification Demonstrate the fix ◦ Verify that the bug no longer happens with the fix ◦ Bonus points if you have a unit test that fails because the bug exists Are there any other workflows impacted by the changes? ◦ If there are, can we verify we didn’t break something?
  59. 59. Reviewing Bug Fixes Can we reproduce it? Have we found the root cause? Does the fix follow our standards and quality? Are any workflows impacted by the changes? Have we functionally verified that the bug is fixed?
  60. 60. Wrapping Up Why We Should Have Code Reviews Common Mistakes Teams Make Good Code Reviews Look Like… What I Look For In a Review How I Do a Code Review
  61. 61. Resources The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin 11 Proven Practices For More Effective, Efficient Peer Code Review Code Complete 2nd Edition by Steve McConnell Brainstorming About Code Reviews by Geoff Mazeroff
  62. 62. Contact Information Email: Cameron@TheSoftwareMentor.com Twitter: @PCameronPresley Blog: http://blog.thesoftwarementor.com

×