Code Reviewing Like a Champion

maltzj

July 20, 2018

Tweet Share

Transcript

1. Code Reviewing Like A Champion Jonathan Maltz - @maltzj

2. None
3. None
4. None

5. @maltzj What Will We Talk About? • Why Do Code

   Review • Basic Code Review Outline • How to Give Code Review Feedback

6. @maltzj Why do Code Review?

7. @maltzj Make Sure Code is Correct

8. @maltzj Make Sure Code is Well-Designed

9. @maltzj Share Knowledge

10. @maltzj Basic Code Review Outline

11. @maltzj 1. Build Context

12. @maltzj What’s Success? • You understand the goal of the

    change • You understand what is out of scope • You understand any high-level decisions

13. @maltzj What’s Failure? • Jumping into a code review right

    away • Not calling for backup as necessary ◦ Especially important at boundaries

14. @maltzj Authors are just as important here

15. @maltzj

16. @maltzj Protip: pre-filled templates

17. @maltzj 2. Evaluate Closer

18. @maltzj What’s Success? • High-level design feedback • Bug-finding +

    edge case coverage • Test coverage • Naming • Sharing new patterns

19. @maltzj What’s Failure? • Commenting on anything a tool can

    catch ◦ PMD ◦ Checkstyle ◦ Findbugs ◦ Pre-commit hooks • Discussing the same things repeatedly

20. @maltzj 3. Take a Step Back

21. @maltzj Could this be done easier/better/faster?

22. @maltzj How to Give Feedback

23. @maltzj • Discussion and collaboration • Authors owning their changes

    throughout the process • People being excited about receiving feedback What Do You Want To Encourage?

24. @maltzj

25. @maltzj Feedback that makes people feel worse

26. @maltzj • “Your style here is inconsistent. Align your braces

    with our code style.” • “This has a bug when running on Lollipop which will cause a crash. Fix it.” • “Why did you do this refactor? The code was better in its previous form.” How Can That Happen?

27. @maltzj

28. @maltzj “This code is good. Let’s make it even better.”

29. @maltzj 1. Start With Facts

30. @maltzj “The style guidelines say you should put braces on

    the same line and this code puts braces on a new line. Align your braces with the styleguide.”

31. @maltzj

32. @maltzj Opinion == Facts

33. @maltzj Static methods cannot be mocked in normal JUnit tests.

34. @maltzj Static methods cannot be mocked in normal JUnit tests.

35. @maltzj Static methods are bad. They cannot be mocked in

    normal JUnit tests.

36. @maltzj Link to External Resources

37. @maltzj 2. Invite a Discussion

38. @maltzj “The style guidelines say you should put braces on

    the same line and this code puts braces on a new line. Can you align your braces with the styleguide?”

39. @maltzj 3. Replace “You” with “We” or “Us”

40. @maltzj “The style guidelines say we should put braces on

    the same line and this code puts braces on a new line. Can we align the braces with our styleguide?”

41. @maltzj

42. @maltzj

43. @maltzj Rule of Three

44. @maltzj “On a scale of 1-10 I care about this

    at about a 5. What about you? What are your major concerns?”

45. @maltzj • Different concerns? Find a third way • Large

    Difference? Principle of the person who cares the most in the code review ◦ Protip: This shouldn’t always be you • Both high? Maybe need a larger decision What to do with this?

46. @maltzj Celebrate the Good Stuff

47. @maltzj

48. @maltzj External Links • Yelp’s Code Review Guidelines • Writing

    Commit Messages • How to Use Code Review To Execute Someone’s Soul • Creating a Strong Code Review Culture • Honesty Kindness, Inspiration: Pick Three • Bettercode.reviews • Giving and Getting Technical Help • Crucial Conversations • Pre-commit