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
What to Upload to SlideShare
Weiter
Herunterladen, um offline zu lesen und im Vollbildmodus anzuzeigen.

4

Teilen

Code Review Best Practices

Herunterladen, um offline zu lesen

We know that Code Reviews are a Good Thing. We probably have our own personal lists of things we look for in the code we review, while also fearing what others might say about our code. How to we ensure that code reviews are actually benefiting the team, and the application? How do we decide who does the reviews? What does "done" look like?

In this talk, Trisha will identify some best practices to follow. She'll talk about what's really important in a code review, and set out some guidelines to follow in order to maximise the value of the code review and minimise the pain.

Ä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 Best Practices

  1. 1. — Trisha Gee (@trisha_gee) Developer & Technical Advocate, JetBrains Code Review Best Practices
  2. 2. This code works
  3. 3. Having Opinions On Code Is An Occupational Hazard
  4. 4. Having Opinions On Code Is An Occupational Requirement
  5. 5. Are we harder on other people’s code than our own?
  6. 6. What to look for in a code review
  7. 7. http://jb.gg/book/codereview
  8. 8. • Gateway Reviews • Knowledge Sharing • Early Design Feedback Different workflows https://blog.jetbrains.com/upsource/tag/code-review-workflows/
  9. 9. What should you look for when reviewing code?
  10. 10. It Depends
  11. 11. My First Code Review My job is to Find Problems
  12. 12. Anti-Pattern Nit picking
  13. 13. Anti-Pattern Design changes when the code works
  14. 14. Anti-Pattern Inconsistent feedback
  15. 15. Anti-Pattern The Ghost Reviewer
  16. 16. Anti-Pattern Ping pong reviews
  17. 17. Developers hate code reviews
  18. 18. Code Reviews are a Massive Waste of Time
  19. 19. 1. Why?
  20. 20. Ensure code meets standards
  21. 21. Find bugs
  22. 22. Share knowledge
  23. 23. Check code is understandable
  24. 24. Ensure code does what it’s supposed to
  25. 25. Collaborate on design
  26. 26. Evolve application code
  27. 27. 2. When?
  28. 28. • During implementation? • When it’s ready to merge? • After it’s been merged? When do you review?
  29. 29. • When everyone agrees? • When a gatekeeper agrees? • When all comments are addressed? When is the review complete?
  30. 30. 3. Who?
  31. 31. Who reviews the code?
  32. 32. Who signs it off?
  33. 33. 4. Where?
  34. 34. Pairing
  35. 35. Showing code to a colleague at a computer
  36. 36. Mob reviewing in a conference room
  37. 37. Remote screen-sharing
  38. 38. In the IDE, checking out a commit or branch
  39. 39. Using code review software
  40. 40. 5. What?
  41. 41. 1. Why 2. When 3. Who 4. Where Requires you to know:
  42. 42. • Fit with the overall architecture • SOLID principles, Domain Driven Design, Design Patterns or other paradigms of choice • New code follows team’s current practices • Code is in the right place • Code reuse • Over-engineering • Readable code and tests • Testing the right things • Exception error messages • Subtle bugs • Security • Regulatory requirements • Performance • Documentation and/or help files been updated • Spelling, punctuation & grammar on user messages What to look for https://blog.jetbrains.com/upsource/tag/what-to-look-for/
  43. 43. Human reviewers should be doing what cannot be automated
  44. 44. Understand the constraints
  45. 45. Why: Knowledge Sharing Purpose isn’t to reject the code
  46. 46. Why: Knowledge Sharing Focus is on how easy it is to understand the code
  47. 47. When: At the end Too late for design
  48. 48. When: At the end Should have specific checks
  49. 49. 6. How?
  50. 50. Automate Everything You Can
  51. 51. Submitting for review Annotate your code
  52. 52. Submitting for review Reviews should be small
  53. 53. Reviewing Should be clear Who is reviewing
  54. 54. Reviewing Respond in a timely fashion
  55. 55. Reviewing Checklist of What to look for
  56. 56. Comments Bear in mind Why, When and What
  57. 57. Comments Be constructive
  58. 58. Comments Be specific
  59. 59. Accept or Reject
  60. 60. Accept or Raise Concern Next steps should be clear
  61. 61. Making changes Respond in a timely fashion
  62. 62. Making changes Respond to comments
  63. 63. Resolving The goal is to accept the review
  64. 64. Resolving Should be clear Who signs it off
  65. 65. Resolving …and When
  66. 66. Have Clear Objectives
  67. 67. 1. Why 2. When 3. Who 4. Where 5. What 6. How Clarity Comes From Understanding
  68. 68. Not to prove how clever you are The Goal Is To Ship The Code
  69. 69. http://bit.ly/CRGood
  • saber13812002

    Dec. 28, 2020
  • ali2005

    Dec. 7, 2019
  • MassimilianoCalipari

    Nov. 20, 2019
  • FrankSpeck1

    Oct. 5, 2018

We know that Code Reviews are a Good Thing. We probably have our own personal lists of things we look for in the code we review, while also fearing what others might say about our code. How to we ensure that code reviews are actually benefiting the team, and the application? How do we decide who does the reviews? What does "done" look like? In this talk, Trisha will identify some best practices to follow. She'll talk about what's really important in a code review, and set out some guidelines to follow in order to maximise the value of the code review and minimise the pain.

Aufrufe

Aufrufe insgesamt

5.210

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

3.488

Befehle

Downloads

61

Geteilt

0

Kommentare

0

Likes

4

×