Successfully reported this slideshow.

Another pair of eyes

0

Share

1 of 90
1 of 90

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Another pair of eyes

  1. 1. another pair of eyes: reviewing code well adam dangoor twitter: adamdangoor github: adamtheturtle
  2. 2. why? • • •
  3. 3. why? • great reviews have helped • • “Your code sucks, and I hate you” - biog post by jml
  4. 4. why? • great reviews have helped • bad reviews have harmed • •
  5. 5. why? • great reviews have helped • bad reviews have harmed • hardly talked about •
  6. 6. why? • great reviews have helped • bad reviews have harmed • hardly talked about •
  7. 7. why? • great reviews have helped • bad reviews have harmed • hardly talked about • little to no training
  8. 8. the plan • what code review is • how I review code • some common pitfalls • tools which can help • becoming a better programmer
  9. 9. what is code review? • • •
  10. 10. what is code review? • catch bugs early - prevention is cheaper than cure • •
  11. 11. what is code review? • catch bugs early - prevention is cheaper than cure • •
  12. 12. what is code review? • catch bugs early - prevention is cheaper than cure • find other defects early
  13. 13. what is code review? • catch bugs early - prevention is cheaper than cure • find other defects early • share knowledge
  14. 14. what is code review? • catch bugs early - prevention is cheaper than cure • find other defects early • share knowledge
  15. 15. the project’s other goals
  16. 16. setting the scene
  17. 17. setting the scene: the issue
  18. 18. setting the scene: the branch eleanor~> git checkout -b show-employer-2866
  19. 19. setting the scene: the code def get_user_profile(user): “”” Get a dict representing a user’s profile. “”” user_profile = {} user_profile['Age'] = user.get_age(unit='years') user_profile['Twitter Handle'] = user.twitter_handle return user_profile
  20. 20. setting the scene: the code eleanor~> git diff diff --git a/api/profiles.py b/api/profiles.py index 776e5e0..7fff02c 100644 --- a/api/profiles.py +++ b/api/profiles.py @@ -2,7 +2,7 @@ user_profile['Age'] = user.get_age(unit='years') user_profile['Twitter Handle'] = user.twitter_handle + user_profile['Latest employer'] = + user.get_employers()[0].name return user_profile
  21. 21. setting the scene: the manual test
  22. 22. do we need a review?
  23. 23. do we need a review? (yes)
  24. 24. do we need a review for trivial changes?
  25. 25. do we need a review for urgent work?
  26. 26. stage fright
  27. 27. who should do the review? • •
  28. 28. who should do the review? • someone with authorisation (technical or social) • •
  29. 29. who should do the review? • someone with authorisation (technical or social) • not an author •
  30. 30. who should do the review? • someone with authorisation (technical or social) • not an author • someone who has written nearby code •
  31. 31. who should do the review? • someone with authorisation (technical or social) • not an author • someone who has written nearby code • or someone who has reviewed nearby code
  32. 32. but what about knowledge sharing?
  33. 33. code review as a new starter
  34. 34. code review as a new starter
  35. 35. how i do a review
  36. 36. read the spec
  37. 37. check ci
  38. 38. is the spec implemented?
  39. 39. have we interpreted the spec the same?
  40. 40. does the implementation look functionally correct?
  41. 41. has existing functionality been broken?
  42. 42. is it going to be easy to maintain?
  43. 43. is it going to be easy to maintain?
  44. 44. is everything documented?
  45. 45. learning
  46. 46. initiating a discussion
  47. 47. concluding a review • Great, this looks good to me, I’ll merge it • Please make the requested changes and then merge • Please make the requested changes and then resubmit • I’m not qualified to know whether this is a suitable change, let’s find someone else to have a look
  48. 48. getting better
  49. 49. ask for feedback
  50. 50. reviewing eleanor’s change user_profile['Age'] = user.get_age(unit='years') user_profile['Twitter Handle'] = user.twitter_handle + user_profile['Latest employer'] = + user.get_employers()[0].name return user_profile
  51. 51. reviewing eleanor’s change
  52. 52. eleanor’s next steps
  53. 53. eleanor’s next steps eleanor~> ag --ignore-case "latest employer” ~/Documents/bilbao_inc/api/profile.py user_profile['Latest employer'] = ~/Documents/bilbao_inc/api/details_email.py "Latest employer: {latest_employer}".format(
  54. 54. being nice to people
  55. 55. always say one nice thing[1] being nice to people [1] Divmod via jml
  56. 56. address the patch, not the person being nice to people
  57. 57. what else could be better?
  58. 58. what else could be better? clear next steps
  59. 59. what else could be better? the review stopped too soon user_profile['Twitter Handle'] = user.twitter_handle + user_profile['Latest employer'] = + user.get_employers()[0].name return user_profile
  60. 60. what else could be better? when to stop
  61. 61. the next round eleanor~> git diff diff --git a/api/profiles.py b/api/profiles.py index 776e5e0..7fff02c 100644 --- a/api/profiles.py +++ b/api/profiles.py @@ -2,7 +2,7 @@ user_profile['Age'] = user.get_age(unit='years') user_profile['Twitter Handle'] = user.twitter_handle + try: + user_profile['Latest employer'] = + user.get_employers()[0].name + except: + user_profile['Latest employer'] = + “This user does not have any employment history in the system yet.” return user_profile
  62. 62. the next round • performance issue • •
  63. 63. the next round • performance issue • pep 8 violation •
  64. 64. the next round • performance issue • pep 8 violation • properties vs getters
  65. 65. priorities and context
  66. 66. style guide vs style rules
  67. 67. automate the boring stuff flake8
  68. 68. automate the boring stuff coverage.py & coveralls
  69. 69. requires.io
  70. 70. automate the boring stuff landscape.io
  71. 71. automate the boring stuff docs tools
  72. 72. trade-offs
  73. 73. ignoring suggestions # pylint thinks that this is too long for a function name. # Ignore that error. def update_current_search_index(): # pylint: disable-msg=C0103
  74. 74. configuring suggestions [flake8] ignore = D203 exclude = .git,__pycache__,docs/source/conf.py,old,build,dist max-complexity = 10
  75. 75. github integration
  76. 76. reviewable.io
  77. 77. unrelated changes
  78. 78. unrelated changes
  79. 79. reviewable changes
  80. 80. reviewable changes are short Magnetic platform guide: ~200 line changes max Twisted: ~200 line changes max
  81. 81. reviewable changes include one logical unit of change
  82. 82. writing reviewable code
  83. 83. silicon valley comma
  84. 84. silicon valley comma landmarks = [ guggenheim, fine_arts_museum, basilica, + euskalduna, ] vs landmarks = [ guggenheim, fine_arts_museum, - basilica + basilica, + euskalduna, ]
  85. 85. semantic linefeeds by brandon rhodes adam~> git diff diff --git a/api/example.txt b/api/example.txt index 776e5e0..7fff02c 100644 --- a/api/example.txt +++ b/api/example.txt @@ -2,7 +2,7 @@ - The beauteous scheme is that now, + The beauty of this scheme is that now, if you change your mind about what a paragraph should look like,
  86. 86. tips vs requirements
  87. 87. learning by reviewing
  88. 88. cheers adam dangoor twitter: adamdangoor github: adamtheturtle stuffadammakes.com

×