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 Want

213 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 a review. 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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

How To Have Code Reviews Your Developers Want

  1. 1. How To Have Code Reviews Your Developers Actually Want CAMERON PRESLEY @PCAMERONPRESLEY HTTP://BLOG.THESOFTWAREMENTOR.COM
  2. 2. About Me ◦Software Engineer at Pilot Flying J ◦Musician, Boardgamer, Process Geek ◦Organizer of @FunctionalKnox and @Knox_Hacks ◦Work one-on-one with developers to help improve their career
  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. How Many Of You Are New To The Industry (less than 2 years)?
  15. 15. 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
  16. 16. Which developer would you prefer? 5 years of experience or the same 1 year of experience 5 times?
  17. 17. 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
  18. 18. The more experience you gain The more employable you are The more valuable you are
  19. 19. 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
  20. 20. Common Mistakes
  21. 21. Reviewing too much
  22. 22. We can’t review a ton of changes and expect to find any issues ◦ We can only focus on so much code at a time But how much can we optimally review? IBM partnered with SmartBear and Cisco to determine some best practices for code reviews
  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. Stick to facts and ideas with reasoning It’s normal for us to think “we wouldn’t of done it that way” when reviewing code But the goal is to not have everyone code like me If you have a suggestion, make sure to back it up with facts, not with gut reactions
  27. 27. Attacking the Developer
  28. 28. Instead, Attack the Code Ownership (using “we” instead of “you”) ◦ “What should you do when the array is empty?” ◦ “What should we do when the array is empty?” Code is the problem (not the developer) ◦ “This for loop is garbage, what in the world were you thinking?” ◦ “I’m having issues understanding this for loop, can you step me through what it’s doing?”
  29. 29. What Does A Good Code Review Look Like?
  30. 30. 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
  31. 31. Tight Collaboration Both you and the reviewer are asking questions Discussion, not interrogation No one person is doing all the talking This leads to joint ownership
  32. 32. 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.”
  33. 33. 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
  34. 34. Knowledge Sharing
  35. 35. 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
  36. 36. Good Code Reviews Look Like 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
  37. 37. What I Look At Quality ◦ Are there any bugs? Readability ◦ How easy is it for me to understand? Maintainability ◦ How easy is it to make changes? Style ◦ Does the code follow language guidelines?
  38. 38. Quality Are inputs handled correctly? ◦ Does the code give the correct answer for the input? ◦ How about nulls? Empty arrays? Negative numbers, etc.? Are errors handled gracefully? ◦ Does the app crash? Is the user presented with a message? Edge Cases ◦ Does it handle input at the edges of validity?
  39. 39. Readability Source
  40. 40. 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 complex enough to remove clutter
  41. 41. Maintainability Code is always in flux The longer it takes for me to make a change, the costlier the work is The longer it takes, the more likely I’ll make a mistake Ensuring that relevant software design principles are being followed
  42. 42. Style Does the C# code looks like it was written by a C# developer? Or more like a C++ developer? Focus on ◦ Naming conventions ◦ Proper use of code constructs ◦ Project structure Known as being “idiomatic”
  43. 43. What To Expect From A Code Review
  44. 44. High Level You and the other developer (reviewer) will sit down to look at the changes You’ll lead the review by showing what changes were made and why Reviewer will make some suggestions and find some bugs You’ll address the bugs and decide on which suggestions to implement
  45. 45. Leading the Reviewer What problem were you trying to solve? ◦ “There’s a bug when processing a transaction on Feb 29th“ What changes did you make and why? ◦ “Had to change our leap year logic” Is there an area in particular you want the reviewer to focus on? ◦ “This section works, but I think it could be written cleaner, what do you think?”
  46. 46. During the Review Questions will be asked ◦ “Could you step me through how you found this bug?” ◦ “What happens when the year isn’t a leap year?” Suggestions will be made ◦ “This leap year logic is being used elsewhere in the application, we should probably extract it out” Bugs will be found
  47. 47. How I Do Code Reviews
  48. 48. Features
  49. 49. 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
  50. 50. 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…?
  51. 51. 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 ◦ The “View Report” option is under the “About” file menu ◦ Dumping an exception message to the main window ◦ Telling the user the application lost connection to its database
  52. 52. 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?
  53. 53. Bugs
  54. 54. Framing In basic terms, what is the problem? ◦ Focus on what the user would be doing and stick with your domain language Can you 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
  55. 55. Walkthrough – Developer Fix Two different approaches ◦ Start with the big picture (i.e. how everything hangs) and then drill down to the affected pieces ◦ Start with the pieces to build a foundation and then walk it up to form the big picture Avoid bouncing back and forth, the code should be telling a story, therefore the review should have a flow
  56. 56. Walkthrough – Special Focus Is there any part that the developer wants some extra attention on? ◦ “This works, but I think there’s a better solution, do you have a suggestion?” ◦ “The business rules for approving this request is tricky, can you help me double check it?” 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 Peer Reviews in Software – A Practical Guide by Karl E. Wiegers
  62. 62. Contact Information Email: Cameron@TheSoftwareMentor.com Twitter: @PCameronPresley Blog: http://blog.thesoftwarementor.com

×