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.

Ground Rules for Code Reviews

47 views

Published on

Joshua Gerth, Senior Software Engineer at New Relic

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Ground Rules for Code Reviews

  1. 1. ©2008–18 New Relic, Inc. All rights reserved
  2. 2. ©2008–18 New Relic, Inc. All rights reserved SAFE HARBOR This presentation and the information herein (including any information that may be incorporated by reference) is provided for informational purposes only and should not be construed as an offer, commitment, promise or obligation on behalf of New Relic, Inc. (“New Relic”) to sell securities or deliver any product, material, code, functionality, or other feature. Any information provided hereby is proprietary to New Relic and may not be replicated or disclosed without New Relic’s express written permission. Such information may contain forward-looking statements within the meaning of federal securities laws. Any statement that is not a historical fact or refers to expectations, projections, future plans, objectives, estimates, goals, or other characterizations of future events is a forward-looking statement. These forward-looking statements can often be identified as such because the context of the statement will include words such as “believes,” “anticipates,” “expects” or words of similar import. Actual results may differ materially from those expressed in these forward-looking statements, which speak only as of the date hereof, and are subject to change at any time without notice. Existing and prospective investors, customers and other third parties transacting business with New Relic are cautioned not to place undue reliance on this forward-looking information. The achievement or success of the matters covered by such forward-looking statements are based on New Relic’s current assumptions, expectations, and beliefs and are subject to substantial risks, uncertainties, assumptions, and changes in circumstances that may cause the actual results, performance, or achievements to differ materially from those expressed or implied in any forward-looking statement. Further information on factors that could affect such forward-looking statements is included in the filings New Relic makes with the SEC from time to time. Copies of these documents may be obtained by visiting New Relic’s Investor Relations website at ir.newrelic.com or the SEC’s website at www.sec.gov. New Relic assumes no obligation and does not intend to update these forward-looking statements, except as required by law. New Relic makes no warranties, expressed or implied, in this presentation or otherwise, with respect to the information provided. 2
  3. 3. ©2008–18 New Relic, Inc. All rights reserved GROUND RULES FOR CODE REVIEWS Improving Development Velocity and Team Communication
  4. 4. ©2008–18 New Relic, Inc. All rights reserved Senior Software Engineer, NRDB Team JOSHUA GERTH
  5. 5. ©2008–18 New Relic, Inc. All rights reserved NRQL FROM Transaction SELECT appId Senior Software Engineer, NRDB Team JOSHUA GERTH
  6. 6. ©2008–18 New Relic, Inc. All rights reserved 5 The Team Had a Problem
  7. 7. ©2008–18 New Relic, Inc. All rights reserved 5 The Team Had a Problem
  8. 8. ©2008–18 New Relic, Inc. All rights reserved 5 The Team Had a Problem ?!!??! ??? !!! !?! ?!?
  9. 9. ©2008–18 New Relic, Inc. All rights reserved 6 Collision Points if ( counter == 100 ) { return “Target reached”; }
  10. 10. ©2008–18 New Relic, Inc. All rights reserved 6 Collision Points Reviewer: The constant should be on the lefthand side. if ( counter == 100 ) { return “Target reached”; }
  11. 11. ©2008–18 New Relic, Inc. All rights reserved 6 Collision Points Reviewer: The constant should be on the lefthand side. Author: In Java you can’t do an assignment in a conditional. if ( counter == 100 ) { return “Target reached”; }
  12. 12. ©2008–18 New Relic, Inc. All rights reserved 6 Collision Points Reviewer: The constant should be on the lefthand side. Author: In Java you can’t do an assignment in a conditional. Reviewer: It’s still good practice. if ( counter == 100 ) { return “Target reached”; }
  13. 13. ©2008–18 New Relic, Inc. All rights reserved 6 Collision Points Reviewer: The constant should be on the lefthand side. Author: In Java you can’t do an assignment in a conditional. Reviewer: It’s still good practice. if ( counter == 100 ) { return “Target reached”; } The tone feels patronizing.
  14. 14. ©2008–18 New Relic, Inc. All rights reserved 6 Collision Points Reviewer: The constant should be on the lefthand side. Author: In Java you can’t do an assignment in a conditional. Reviewer: It’s still good practice. if ( counter == 100 ) { return “Target reached”; } The tone feels patronizing. Leaves the change request in an “unknown” state as it’s not Blocked or Approved.
  15. 15. ©2008–18 New Relic, Inc. All rights reserved 7 Collision Points return offset < TIME_LIMIT && getStartTime() <= timestamp;
  16. 16. ©2008–18 New Relic, Inc. All rights reserved 7 Collision Points return offset < TIME_LIMIT && getStartTime() <= timestamp; Reviewer: "offset >= 0 && offset < TIME_LIMIT" would be more clear
  17. 17. ©2008–18 New Relic, Inc. All rights reserved 7 Collision Points return offset < TIME_LIMIT && getStartTime() <= timestamp; Reviewer: "offset >= 0 && offset < TIME_LIMIT" would be more clear Author: Made the change.
  18. 18. ©2008–18 New Relic, Inc. All rights reserved 7 Collision Points return offset < TIME_LIMIT && getStartTime() <= timestamp; Reviewer: "offset >= 0 && offset < TIME_LIMIT" would be more clear Author: Made the change. Clarity is subjective.
  19. 19. ©2008–18 New Relic, Inc. All rights reserved 7 Collision Points return offset < TIME_LIMIT && getStartTime() <= timestamp; Reviewer: "offset >= 0 && offset < TIME_LIMIT" would be more clear Author: Made the change. Clarity is subjective. Author feels frustrated. Reviewer feels unappreciated.
  20. 20. ©2008–18 New Relic, Inc. All rights reserved 7 Collision Points return offset < TIME_LIMIT && getStartTime() <= timestamp; Reviewer: "offset >= 0 && offset < TIME_LIMIT" would be more clear Author: Made the change. Clarity is subjective. Author feels frustrated. Reviewer feels unappreciated. Lose/Lose.
  21. 21. ©2008–18 New Relic, Inc. All rights reserved 8 Taking a Step Back What was going on? Why was it happening? How can we fix it?
  22. 22. ©2008–18 New Relic, Inc. All rights reserved 8 Taking a Step Back What was going on? Why was it happening? How can we fix it? Code Reviews
  23. 23. ©2008–18 New Relic, Inc. All rights reserved 9 How Can We Give Effective Feedback?
  24. 24. ©2008–18 New Relic, Inc. All rights reserved 9 How Can We Give Effective Feedback? • Creative writing 101 • …. • …. • How to give critical feedback • …. Creative Writing
  25. 25. ©2008–18 New Relic, Inc. All rights reserved 9 How Can We Give Effective Feedback? • Creative writing 101 • …. • …. • How to give critical feedback • …. Creative Writing • Computer Science 101 • …. • Data structures • Algorithm analysis • …. Computer Science
  26. 26. ©2008–18 New Relic, Inc. All rights reserved 10 Types of Feedback
  27. 27. ©2008–18 New Relic, Inc. All rights reserved 10 Objective Comments Types of Feedback
  28. 28. ©2008–18 New Relic, Inc. All rights reserved 10 Objective Comments “You have created an infinite loop” “You are missing a semicolon” “Your boolean logic is wrong” Types of Feedback
  29. 29. ©2008–18 New Relic, Inc. All rights reserved 10 Objective Comments Finding these issues in a code review is rare. “You have created an infinite loop” “You are missing a semicolon” “Your boolean logic is wrong” Types of Feedback
  30. 30. ©2008–18 New Relic, Inc. All rights reserved 10 Objective Comments Subjective Comments Finding these issues in a code review is rare. “You have created an infinite loop” “You are missing a semicolon” “Your boolean logic is wrong” Types of Feedback
  31. 31. ©2008–18 New Relic, Inc. All rights reserved 10 Objective Comments Subjective Comments Finding these issues in a code review is rare. “Your variable should use camel case, not snake case” “Your method name is confusing” “Your curly brace is on the wrong line" “You have created an infinite loop” “You are missing a semicolon” “Your boolean logic is wrong” Types of Feedback
  32. 32. ©2008–18 New Relic, Inc. All rights reserved 10 Objective Comments Finding these issues in a code review is easy. Subjective Comments Finding these issues in a code review is rare. “Your variable should use camel case, not snake case” “Your method name is confusing” “Your curly brace is on the wrong line" “You have created an infinite loop” “You are missing a semicolon” “Your boolean logic is wrong” Types of Feedback
  33. 33. ©2008–18 New Relic, Inc. All rights reserved 11 Mixing Subjective with Objective “My opinion is the correct one”
  34. 34. ©2008–18 New Relic, Inc. All rights reserved 11 Mixing Subjective with Objective Disregards feelings “My opinion is the correct one”
  35. 35. ©2008–18 New Relic, Inc. All rights reserved 11 Mixing Subjective with Objective Minimizes difference 
 of opinions Disregards feelings “My opinion is the correct one”
  36. 36. ©2008–18 New Relic, Inc. All rights reserved 11 Mixing Subjective with Objective Minimizes difference 
 of opinions Causes frustration and resentment Disregards feelings “My opinion is the correct one”
  37. 37. ©2008–18 New Relic, Inc. All rights reserved 11 Mixing Subjective with Objective Minimizes difference 
 of opinions Causes frustration and resentment Can lead to a breakdown in team communication Disregards feelings “My opinion is the correct one”
  38. 38. ©2008–18 New Relic, Inc. All rights reserved Who is responsible? 12
  39. 39. ©2008–18 New Relic, Inc. All rights reserved Who is responsible? 12 “The authors of the code change are responsible for the correct execution of the change.”
  40. 40. ©2008–18 New Relic, Inc. All rights reserved When should code be reviewed? 13
  41. 41. ©2008–18 New Relic, Inc. All rights reserved When should code be reviewed? 13 Before any code is written.
  42. 42. ©2008–18 New Relic, Inc. All rights reserved When should code be reviewed? 13 Before any code is written. While writing the code.
  43. 43. ©2008–18 New Relic, Inc. All rights reserved When should code be reviewed? 13 Before any code is written. While writing the code. After the code has been written.
  44. 44. ©2008–18 New Relic, Inc. All rights reserved When should code be reviewed? 13 Before any code is written. While writing the code. After the code has been written. When the change is submitted. Mandatory
  45. 45. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules
  46. 46. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules The reviewer should be looking for the following
  47. 47. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules Errors that will cause an issue in production. 1 The reviewer should be looking for the following
  48. 48. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING Errors that will cause an issue in production. 1 The reviewer should be looking for the following
  49. 49. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING Errors that will cause an issue in production. 1 Stated goal of the change aligns with the actual changes. 2 The reviewer should be looking for the following
  50. 50. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING BLOCKING Errors that will cause an issue in production. 1 Stated goal of the change aligns with the actual changes. 2 The reviewer should be looking for the following
  51. 51. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING BLOCKING Errors that will cause an issue in production. 1 Stated goal of the change aligns with the actual changes. 2 Changes align with the team’s coding standards. 3 The reviewer should be looking for the following
  52. 52. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING BLOCKING BLOCKING Errors that will cause an issue in production. 1 Stated goal of the change aligns with the actual changes. 2 Changes align with the team’s coding standards. 3 The reviewer should be looking for the following
  53. 53. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING BLOCKING BLOCKING Errors that will cause an issue in production. 1 Stated goal of the change aligns with the actual changes. 2 Changes align with the team’s coding standards. 3 Anything they personally disagree with. 4 The reviewer should be looking for the following
  54. 54. ©2008–18 New Relic, Inc. All rights reserved 14 Establishing Ground Rules BLOCKING NON-BLOCKINGBLOCKING BLOCKING Errors that will cause an issue in production. 1 Stated goal of the change aligns with the actual changes. 2 Changes align with the team’s coding standards. 3 Anything they personally disagree with. 4 The reviewer should be looking for the following
  55. 55. ©2008–18 New Relic, Inc. All rights reserved 15 Adding Tags Subjective Comments Blocking: Objective Comments Your boolean logic is wrong You have created an infinite loop You are missing a semicolon Blocking: Blocking: Non-blocking: Your method name is confusing Non-blocking: Your curly brace is on the wrong line Non-blocking: Your variable should use camel case, not snake case
  56. 56. ©2008–18 New Relic, Inc. All rights reserved 16 Concerns
  57. 57. ©2008–18 New Relic, Inc. All rights reserved 16 Concerns 1The code our team produced would not appear uniform.
  58. 58. ©2008–18 New Relic, Inc. All rights reserved 16 Concerns 1 The author would ignore
 non-blocking comments. The code our team produced would not appear uniform. 2
  59. 59. ©2008–18 New Relic, Inc. All rights reserved 17 Sponsoring a Coding Standard Coding Standards must:
  60. 60. ©2008–18 New Relic, Inc. All rights reserved 17 Sponsoring a Coding Standard Coding Standards must: Be written in non-subjective language.
  61. 61. ©2008–18 New Relic, Inc. All rights reserved 17 Sponsoring a Coding Standard Coding Standards must: Be written in non-subjective language. Be fully supported by the sponsor.
  62. 62. ©2008–18 New Relic, Inc. All rights reserved 18 Impact
  63. 63. ©2008–18 New Relic, Inc. All rights reserved 18 Impact Tone of the subjective comments became more respectful. Provided more context.
  64. 64. ©2008–18 New Relic, Inc. All rights reserved 18 Impact Tone of the subjective comments became more respectful. Provided more context. Authors read, and
 responded to, 
 non-blocking comments.
  65. 65. ©2008–18 New Relic, Inc. All rights reserved 18 Impact Tone of the subjective comments became more respectful. Provided more context. Authors read, and
 responded to, 
 non-blocking comments. Authors felt less
 resentment and reviewers
 felt more appreciated.
  66. 66. ©2008–18 New Relic, Inc. All rights reserved 18 Impact Tone of the subjective comments became more respectful. Provided more context. Authors read, and
 responded to, 
 non-blocking comments. Authors felt less
 resentment and reviewers
 felt more appreciated. Review process 
 took less time.
  67. 67. ©2008–18 New Relic, Inc. All rights reserved 18 Impact Tone of the subjective comments became more respectful. Provided more context. Authors read, and
 responded to, 
 non-blocking comments. Authors felt less
 resentment and reviewers
 felt more appreciated. Review process 
 took less time. Onboarding new reviewers was quick and easy.
  68. 68. ©2008–18 New Relic, Inc. All rights reserved Proposed Coding Standards 19
  69. 69. ©2008–18 New Relic, Inc. All rights reserved Proposed Coding Standards 19 Expected New Proposals 0 10 20 30 W2 W4 W6 W8 W10
  70. 70. ©2008–18 New Relic, Inc. All rights reserved Proposed Coding Standards 19 Expected New Proposals 0 10 20 30 W2 W4 W6 W8 W10 Actual New Proposals 0 10 20 30 W2 W4 W6 W8 W10
  71. 71. ©2008–18 New Relic, Inc. All rights reserved Proposed Coding Standards 19 Reviewers felt their subjective feedback was being taken into consideration. Expected New Proposals 0 10 20 30 W2 W4 W6 W8 W10 Actual New Proposals 0 10 20 30 W2 W4 W6 W8 W10
  72. 72. ©2008–18 New Relic, Inc. All rights reserved 20 Team Autonomy Ground rules still support team autonomy.
  73. 73. ©2008–18 New Relic, Inc. All rights reserved 20 Team Autonomy Ground rules still support team autonomy. Each team can adopt which ever style guide they want.
  74. 74. ©2008–18 New Relic, Inc. All rights reserved 20 Team Autonomy Only define what reviewers should be looking for and how to give feedback. Ground rules still support team autonomy. Each team can adopt which ever style guide they want.
  75. 75. ©2008–18 New Relic, Inc. All rights reserved 21
  76. 76. ©2008–18 New Relic, Inc. All rights reserved 21

×