Love your Pull Request (PRs)                Nasir Jamal                   @_nasj                           We are hiring  ...
What this talk is not about! 1   Git Commands / process flow 2   Technical issues around PR issue /     merging
Before issuing PRs     Take a break and go through your     code once again to keep things clean     and tidy or any obvio...
Before issuing PRs (cont..)      Do not issue a PR unless you think      your story is fully complete, i.e. specs,      in...
Before issuing PR (cont..)     Keep your PRs small     Max 200 - 400 LOCs 3   If possible 50-100 LOCs or less     - easy t...
After issuing PRs     Do not merge until all the comments     have been addressed 1   - if you have comments from more    ...
After issuing PRs (cont..)     Keep your ego away, comments are 2   feedback about your code learn a trick     or two
After issuing PRs (cont..)     Seek to understand reviewers 3   perspective
When reviewing PRs     Go at an easy pace because faster is     not better 1   - if you dont have time, dont review it    ...
When reviewing PRs (cont..)     Look for code maintainability and 2   robustness
When reviewing PRs (cont..)     Avoid sarcasm or making demands     instead suggest     - when suggest, give an example 3 ...
When reviewing PRs (cont..)     Remember you are giving a feedback 4   or clarifying things that you are not     sure
When reviewing PRs (cont..)     Your purpose is to find defects and     issues but never show that someone is 5   inferior...
When reviewing PRs (cont..)     Communicate your ideas clearly 6     - Find ways to make code better
When reviewing PRs (cont..)     Be humble, explicit and if required     talk in person, clarify and discuss 7   - to the p...
When cant agree     Know when to continue and stop the 1   debate and accept one or the other     point of view
When cant agree (cont..) 2   If required take the discussion offline     and make a decision quickly
When cant agree (cont..)     If you cant decide bring in some 3   mediation and just go with the     majority unless you c...
Things to remember 1   there is no best solution, just better 2   Issuer: Be thankful for the reviewer     for taking the ...
Things to remember (cont..) 3   Use it as a means of learning, growing,     communication, team building and     keeping t...
Upcoming SlideShare
Loading in...5
×

Love your pull_requests

255

Published on

How to handle Pull Requests and things to consider when reviewing / issuing pull requests.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
255
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Love your pull_requests

  1. 1. Love your Pull Request (PRs) Nasir Jamal @_nasj We are hiring www.housetrip.com
  2. 2. What this talk is not about! 1 Git Commands / process flow 2 Technical issues around PR issue / merging
  3. 3. Before issuing PRs Take a break and go through your code once again to keep things clean and tidy or any obvious refactoring you 1 need As Uncle Bob says: *keep the ground cleaner than you found it
  4. 4. Before issuing PRs (cont..) Do not issue a PR unless you think your story is fully complete, i.e. specs, integration/cucumber tests 2 - Otherwise you are just wasting other peoples time - Dont be sloppy
  5. 5. Before issuing PR (cont..) Keep your PRs small Max 200 - 400 LOCs 3 If possible 50-100 LOCs or less - easy to review, spot errors, minimal comments, etc
  6. 6. After issuing PRs Do not merge until all the comments have been addressed 1 - if you have comments from more than one person then make sure they all have been taken care off
  7. 7. After issuing PRs (cont..) Keep your ego away, comments are 2 feedback about your code learn a trick or two
  8. 8. After issuing PRs (cont..) Seek to understand reviewers 3 perspective
  9. 9. When reviewing PRs Go at an easy pace because faster is not better 1 - if you dont have time, dont review it otherwise you will either end up pissing off the dev with your comments or you will miss obvious errors
  10. 10. When reviewing PRs (cont..) Look for code maintainability and 2 robustness
  11. 11. When reviewing PRs (cont..) Avoid sarcasm or making demands instead suggest - when suggest, give an example 3 - ask the dev what he thinks about it or if he has any objections because you dont know what was going on his mind when he wrote it
  12. 12. When reviewing PRs (cont..) Remember you are giving a feedback 4 or clarifying things that you are not sure
  13. 13. When reviewing PRs (cont..) Your purpose is to find defects and issues but never show that someone is 5 inferior or you are … - if you really want to do it, do it in private - and most probably you will have your arse kicked
  14. 14. When reviewing PRs (cont..) Communicate your ideas clearly 6 - Find ways to make code better
  15. 15. When reviewing PRs (cont..) Be humble, explicit and if required talk in person, clarify and discuss 7 - to the point & precise without sugarcoating - be careful with icons or with your WTFs (do not offend another person)
  16. 16. When cant agree Know when to continue and stop the 1 debate and accept one or the other point of view
  17. 17. When cant agree (cont..) 2 If required take the discussion offline and make a decision quickly
  18. 18. When cant agree (cont..) If you cant decide bring in some 3 mediation and just go with the majority unless you can convert the majority
  19. 19. Things to remember 1 there is no best solution, just better 2 Issuer: Be thankful for the reviewer for taking the time out
  20. 20. Things to remember (cont..) 3 Use it as a means of learning, growing, communication, team building and keeping the code sane and bug free Issuer/Reviewer: Dont take anything 4 personally, the comments are about the code and not about you
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×