#SydPHP - Pull Requests - The Good, The Bad & The Ugly
Download as PPTX, PDF•0 likes•113 views
The document provides insights into effective practices for creating and reviewing pull requests (PRs) in software development. Key points include maintaining clear, concise commit messages, keeping PRs small, and focusing on collaboration during code reviews rather than judgment. It also highlights the importance of constructive feedback and avoiding toxic behaviors in the code review culture.
![Always add rationale or
examples to comments
“This doesn’t look like it’s following
our standard for array notation in
standard XYZ [link here]”
“This looks like it’d work great with
a pipeline pattern - there’s a great
article about it here [link]”](https://image.slidesharecdn.com/sydphp-pr-goodbadugly-180628225712/85/SydPHP-Pull-Requests-The-Good-The-Bad-The-Ugly-19-320.jpg)
#SydPHP - Pull Requests - The Good, The Bad & The Ugly
- 1. PULL REQUESTS - The good, the bad and the ugly
- 2. Aaron Weatherall Senior Software Engineer @ THE ICONIC Self-confessed API guru Amateur boat builder Blogger and writer Ex-writer of bad pull request Faithful servant to a fluffy white demigod/cat named Minx. G’day!
- 3. Disclaimer: All images in these slides were shameless ripped from Google. #SozNotSoz
- 4. So, you want to open a pull request, huh?1
- 5. So, you want to create a PR? ◉ Does it have good, atomic commit messages? ◉ Ensure standards and best practices are used ◉ Don’t expect CR without tests.. don’t do it ◉ Always plan for code review ◉ Open it early, but keep it short-lived Note: This is the most serious slide, it gets better from here, OK?
- 7. DO Keep your PRs small Would you want to review this?
- 8. DO use a meaningful title Does the title summarise the purpose of the code? Would future you know what this is about?
- 9. DO Include a full description! Add supporting docs, screenshots or mockups if applicable!
- 10. DO add labels if required If code shouldn’t be merged yet or it’s a work in progress, tag it!
- 11. Don’t explain your code! (If you need to explain it, it’s probably not ready to merge!) DON’T explain your code!
- 12. Don’t ask for approval, ask for review! Review, not approval!
- 14. Remember: You are NOT your code. (Except this guy.. he actually is)
- 15. Start with a smile! Try to remember that the code was written by a competent, intelligent engineer that we hired.
- 16. Do your homework and understand the context ◉ Review PR title/description ◉ Read supporting documentation ◉ Pull branch and test ◉ Ask questions Don’t just check syntax!
- 17. Syntax checking if for chumps ◉ Scrutinizer (PHP) ◉ CodeClimate (JS) ◉ Codebeat ◉ Codacy Don’t syntax check.. automate!
- 18. Use questions and recommendations to drive dialogue “Hey do you think this might be better in it’s own class?” “This looks like it’d work really well using the xyz pattern, what do you think?”
- 19. Always add rationale or examples to comments “This doesn’t look like it’s following our standard for array notation in standard XYZ [link here]” “This looks like it’d work great with a pipeline pattern - there’s a great article about it here [link]”
- 20. Collaborate, don’t be a backseat driver! “Hey I like what you’ve done here, but have you considered the impact of xyz feature?” VS “Don’t do this”
- 21. Always take the opportunity to teach.. never judge. “Hey, I’ve noticed you’re doing a lot of xyz, have you checked out the auto-generate feature in ABC? I’m happy to help you set it up” VS “Why would you do this? There are tools for that”
- 22. Leave positive feedback or emojis for stuff you LIKE! CR isn’t just about the stuff that’s wrong, it’s also about the stuff that’s RIGHT.
- 24. Passing off opinion as fact “This method should be static” “No one uses singletons anymore” “This is an ugly way of doing this” “Customers won’t like that button”
- 25. The avalanche of comments “Add a linebreak” “And here” “Here to” “Here to” “Here to” “And here” … x 50
- 26. Can you solve xyz while you’re at it? “Hey since you’re adding this, simple, innocuous feature, maybe you should refactor the router to do xyz instead” Bad example, but you get the point!
- 27. Asking judgemental questions “Why didn’t you just do ___ here?” “I’m not sure why you didn’t just do ___ instead” “Why do people do this?” Play nice and take the time to teach, they genuinely might not have thought of it!
- 28. Sarcastic or negative emojis 😭
- 29. “Unlearning toxic behaviors in a code review culture” by Sandya Sankarram - Engineer @ SurveyMonkey thei.co/bw7