Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Nächste SlideShare
Real World Java 9 (QCon London)
Weiter
Herunterladen, um offline zu lesen und im Vollbildmodus anzuzeigen.

1

Teilen

Code Review Matters and Manners

Herunterladen, um offline zu lesen

A code review is basically a technical discussion which should lead to improvements in the code and/or sharing
knowledge in a team. As with any conversation, it should have substance and form.

What’s involved in a good code review? What kind of problems do we want to spot and address? Trisha Gee will talk
about things a reviewer may consider when looking at changes: what potential issues to look for; why certain
patterns may be harmful; and, of course, what NOT to look at.

But when it comes to commenting on someone’s work, it may be hard to find the right words to convey a useful message
without offending the authors - after all, this is something that they worked hard on. Maria Khalusova will share
some observations, thoughts and practical tricks on how to give and receive feedback without turning a code review
into a battlefield.

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Code Review Matters and Manners

  1. 1. Trisha Gee (@trisha_gee) Maria Khalusova (@mariaKhalusova) JetBrains Code Review Matters and Manners
  2. 2. Matters
  3. 3. What To Look For • Formatting • Naming Conventions • “Final” Keyword • Line Length • Empty Statements • Modifier Order • Javadoc comments • ….
  4. 4. Automate these checks Don’t Sweat the Little Things
  5. 5. Design: Details • Is the code in the right place? • Appropriate data structures used? • Have opportunities for code re-use been taken? • Have new dependencies been introduced? • Is the code making use of existing libraries? • Is it utilising new idioms?
  6. 6. Design: High Level • Does the new code fit with the overall architecture? • Does this new code follow the current design practices? • Have appropriate design patterns been used? • Does the code follow SOLID principles, Domain Driven Design or other preferred approaches? • Is the code overly complex or over-engineered?
  7. 7. Do it in advance, or as you go Code Review is Too Late For Design
  8. 8. Usability • UI • API
  9. 9. Design • UI • API
  10. 10. Usability • Readability • Maintainability • Extensibility
  11. 11. Functionality • Does it do what it’s supposed to? • Does it meet performance requirements? • Does it meet security requirements? • Are there other regulatory requirements?
  12. 12. Decide on priorities, apply consistently Understand what’s important
  13. 13. Automate these checks Don’t Sweat the Little Things
  14. 14. Decide on priorities, apply consistently Understand what’s important
  15. 15. Do it in advance, or as you go Code Review is Too Late For Design
  16. 16. Don’t Sweat the Little Things
  17. 17. Understand What’s Important • Functionality • Does it do what it’s supposed to? • Does it meet “non-functional” requirements? • Usability • Readability • Maintainability • Extensibility
  18. 18. Understand What’s Important • Is the code in the right place? • Are the data structures that have been used appropriate? • Have opportunities for code re-use been taken? • Is the code overly complex or over-engineered? • Have new dependencies been introduced? • Is the code making use of existing libraries? • Is it utilising new idioms from language updates?
  19. 19. Code Review is Too Late for Design • Is the code in the right place? • Are the data structures that have been used appropriate? • Have opportunities for code re-use been taken? • Is the code overly complex or over-engineered? • Have new dependencies been introduced? • Is the code making use of existing libraries? • Is it utilising new idioms from language updates?
  20. 20. Code Review is Too Late for Design • Does the new code fit with the overall architecture? • Does this new code follow the current design practices? • Which design patterns are used in the new code? Are these appropriate? • Does the code follow SOLID principles, Domain Driven Design etc?
  21. 21. Does it do what it’s supposed to?
  22. 22. Is anything wildly wrong with it?
  23. 23. Manners
  24. 24. How to have code review discussions without starting a war in the comments?
  25. 25. This happens… “Instead of touching other people’s code, do something useful with your life” “Look at the bullshit you wrote” “The above code is shit, and it generates shit code. It looks bad and there’s no reason for it”
  26. 26. Project Aristotle: Psychological safety first
  27. 27. It’s not only about being polite… “Comments must end with a period” “Something is wrong. I’m not sure what it is. It just doesn’t feel right, you know what I mean?”
  28. 28. Why do you leave feedback? There’s a problem To help someone improve To start a discussion To praise good work Because of the pressure to find a problem To boost own ego
  29. 29. Basic code review manners Appropriate timing and place Indicate when you’re done with a review Discuss changes, not people Be specific Don’t demand, ask questions Don’t use sarcasm Suggest alternatives
  30. 30. A few tips on wording Don’t be rude. “WTF is this?” “That’s a dumb idea…” Who, What, Where, How, And Why? “This will not work if…” vs “What happens if..?” Avoid using “obviously”, “simply”, “just” Avoid possessive adjectives “Your method returns…” vs “This method returns…” Never say never (and “always”, “nothing”, etc.)
  31. 31. There’s a catch :) “Look at the bullshit you wrote”
  32. 32. “A fool thinks himself to be wise, but a wise man knows himself to be a fool.” William Shakespeare “Everyone you will ever meet knows something you don't.” Bill Nighy
  33. 33. Receiving feedback Invite teammates to review your code Separate criticism from self Immediate reaction isn’t always the best one Ask questions Be grateful for the feedback
  34. 34. Trisha Gee (@trisha_gee) Maria Khalusova (@mariaKhalusova) JetBrains Questions? http://bit.ly/CR-MM/
  • MohammadSemnani

    Dec. 31, 2017

A code review is basically a technical discussion which should lead to improvements in the code and/or sharing knowledge in a team. As with any conversation, it should have substance and form. What’s involved in a good code review? What kind of problems do we want to spot and address? Trisha Gee will talk about things a reviewer may consider when looking at changes: what potential issues to look for; why certain patterns may be harmful; and, of course, what NOT to look at. But when it comes to commenting on someone’s work, it may be hard to find the right words to convey a useful message without offending the authors - after all, this is something that they worked hard on. Maria Khalusova will share some observations, thoughts and practical tricks on how to give and receive feedback without turning a code review into a battlefield.

Aufrufe

Aufrufe insgesamt

3.471

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

2.786

Befehle

Downloads

29

Geteilt

0

Kommentare

0

Likes

1

×