Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
another pair of eyes:
reviewing code well
adam dangoor
twitter: adamdangoor
github: adamtheturtle
why?
•
•
•
why?
• great reviews have helped
•
•
“Your	code	sucks,	and	I	hate	you”	
-	biog	post	by	jml
why?
• great reviews have helped
• bad reviews have harmed
•
•
why?
• great reviews have helped
• bad reviews have harmed
• hardly talked about
•
why?
• great reviews have helped
• bad reviews have harmed
• hardly talked about
•
why?
• great reviews have helped
• bad reviews have harmed
• hardly talked about
• little to no training
the plan
• what code review is
• how I review code
• some common pitfalls
• tools which can help
• becoming a better progr...
what is code review?
•
•
•
what is code review?
• catch bugs early - prevention is cheaper than cure
•
•
what is code review?
• catch bugs early - prevention is cheaper than cure
•
•
what is code review?
• catch bugs early - prevention is cheaper than cure
• find other defects early
what is code review?
• catch bugs early - prevention is cheaper than cure
• find other defects early
• share knowledge
what is code review?
• catch bugs early - prevention is cheaper than cure
• find other defects early
• share knowledge
the project’s other goals
setting the scene
setting the scene:
the issue
setting the scene:
the branch
eleanor~>	git	checkout	-b	show-employer-2866
setting the scene:
the code
def	get_user_profile(user):	
			“””	
			Get	a	dict	representing	a	user’s	profile.	
			“””	
			...
setting the scene:
the code
eleanor~> git diff
diff --git a/api/profiles.py b/api/profiles.py
index 776e5e0..7fff02c 10064...
setting the scene:
the manual test
do we need a review?
do we need a review?
(yes)
do we need a review
for trivial changes?
do we need a review
for urgent work?
stage fright
who should do the review?
•
•
who should do the review?
• someone with authorisation (technical or social)
•
•
who should do the review?
• someone with authorisation (technical or social)
• not an author
•
who should do the review?
• someone with authorisation (technical or social)
• not an author
• someone who has written nea...
who should do the review?
• someone with authorisation (technical or social)
• not an author
• someone who has written nea...
but what about
knowledge sharing?
code review as a new
starter
code review as a new
starter
how i do a review
read the spec
check ci
is the spec
implemented?
have we interpreted
the spec the same?
does the implementation
look functionally correct?
has existing functionality
been broken?
is it going to be easy to
maintain?
is it going to be easy to
maintain?
is everything
documented?
learning
initiating a discussion
concluding a review
• Great, this looks good to me, I’ll merge it
• Please make the requested changes and then merge
• Ple...
getting better
ask for feedback
reviewing eleanor’s
change
user_profile['Age'] = user.get_age(unit='years')
user_profile['Twitter Handle'] = user.twitter_...
reviewing eleanor’s
change
eleanor’s next steps
eleanor’s next steps
eleanor~> ag --ignore-case "latest employer”
~/Documents/bilbao_inc/api/profile.py
user_profile['Late...
being nice to people
always say one nice
thing[1]
being	nice	to	people
[1] Divmod via jml
address the patch, not
the person
being	nice	to	people
what else could be
better?
what else could be
better?
clear	next	steps
what else could be
better?
the	review	stopped	too	
soon
user_profile['Twitter Handle'] = user.twitter_handle
+ user_profil...
what else could be
better?
when	to	stop
the next round
eleanor~> git diff
diff --git a/api/profiles.py b/api/profiles.py
index 776e5e0..7fff02c 100644
--- a/api/p...
the next round
• performance issue
•
•
the next round
• performance issue
• pep 8 violation
•
the next round
• performance issue
• pep 8 violation
• properties vs getters
priorities and context
style guide vs style
rules
automate the boring
stuff
flake8
automate the boring
stuff
coverage.py	&	coveralls
requires.io
automate the boring
stuff
landscape.io
automate the boring
stuff
docs	tools
trade-offs
ignoring suggestions
#	pylint	thinks	that	this	is	too	long	for	a	function	name.	
#	Ignore	that	error.	
def	update_current_...
configuring suggestions
[flake8]	
ignore	=	D203	
exclude	=	.git,__pycache__,docs/source/conf.py,old,build,dist	
max-complex...
github integration
reviewable.io
unrelated changes
unrelated changes
reviewable changes
reviewable changes are
short
Magnetic platform guide: ~200 line changes max
Twisted: ~200 line changes max
reviewable changes
include one logical unit of
change
writing reviewable
code
silicon valley comma
silicon valley comma
landmarks = [
guggenheim,
fine_arts_museum,
basilica,
+ euskalduna,
]
vs
landmarks = [
guggenheim,
fi...
semantic linefeeds
by brandon rhodes
adam~> git diff
diff --git a/api/example.txt b/api/example.txt
index 776e5e0..7fff02c...
tips vs requirements
learning by reviewing
cheers
adam dangoor
twitter: adamdangoor
github: adamtheturtle
stuffadammakes.com
Another pair of eyes
Another pair of eyes
Upcoming SlideShare
Loading in …5
×

Another pair of eyes

216 views

Published on

https://ep2016.europython.eu/conference/talks/another-pair-of-eyes-reviewing-code-well

Published in: Software
  • Be the first to comment

  • Be the first to like this

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

×