"Surviving Code Reviews" by Lorna Mitchell Whether your code is being reviewed by colleagues or an open source project maintainer, a smooth code review contributes to a slick development process. Every developer should be able to read code as well as write it, and becoming expert at code review is a great way for developers of all levels to improve both their coding skills and their patch acceptance rates! This session looks at how the code review process works and gives concrete advice on preparing a pull request, reviewing a change, and communicating feedback. Recommended for anyone who collaborates on a project with other people.

1. Surviving Code Reviews
Lorna Mitchell
ROME 18-19 MARCH 2016

2. Surviving Code Reviews
Lorna Mitchell, CodeMotion Rome 2016

3. maintainer and team lead

4. unsolicited advice

5. stories

6. 3 ingredients

7. code

8. words

9. perspective

10. what does it do?

11. feature/bug

12. ticket(s)?

13. If there aren't any
acceptance criteria for
your patch, invent some

14. all the code

15. git diff master
git diff master...HEAD

16. tools

17.
TOO BIG

18. common code mistakes

19. exotic code, no comments

20. Committing commented
code is like leaving litter
on a campsite

21. contributing.md

22. can you break your code?

23. I can

24. missing data

25. permissions

26. user is an idiot

27. tests

28. coding standards

29. syntax check

30. Your commit history will
be part of my project
until the end of time

31. git reset --soft $(git merge-base master HEAD)

32. more info than diff

33. accurate

34. sane format

35. http://chris.beams.io/posts/git-commit/

36. SFW

37. apologies

38. will it merge?

39. git merge --no-commit --no-ff feature
git merge --abort

40. fix it

41. rebase

42. A pull request is the start
of a conversation about a
feature

43. source/target

44. diff

45. title

46. description

47. what does it do?

48. what will I observe?

49. why do I care?

50. code review

51. "review" vs "merge"

52. anyone

53. peer review vs gatekeepers

54. key skills

55. Being able to see what
you're NOT looking at is
a reviewer's superpower

56. documentation

57. tests

58. database patch

59. deployability

60. template

61. email

62. report

63. monitoring

64. cron job

65. and if not ...

66.
reject

67. automated build

68. constructive feedback

69. colleagues vs contributors

70. too much feedback

71. sandwich technique

72. harsh feedback

73. Pull requests have a
lifecycle, be prepared to
champion them to the
end

74. 3 ingredients

75. code

76. words

77. perspective

78. Thankyou
http://lornajane.net
This work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 3.0
Unported License.