Unwritten Manual for Pair Programming
•
4 gostaram•1,290 visualizações
This is the content I delivered at several seminars and conferences about pair programming.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Unwritten Manual for Pair Programming
Semelhante a Unwritten Manual for Pair Programming (20)
Mais de Lemi Orhan Ergin
Mais de Lemi Orhan Ergin (19)
Último
Último (20)
Unwritten Manual for Pair Programming
- 1. unwritten manual of pair programming Lemi Orhan Ergin
- 2. What is the purpose of pair programming?
- 3. teaching domain mentorship showing code getting confirmation finding bugs
- 4. teaching domain mentorship showing code getting confirmation finding bugs
- 6. (all the other points are side-products) producing software high quality
- 7. Test Driven Development Behavior Driven Development Acceptance Testing Unit Testing Continuous Integration Continuous Delivery Emergent Simple Design Code Review Design Patterns Clean Code Principles Coding Standards SOLID Principles Continuous Deployment Enterprise Environments Version Control Systems PAIR PROGRAMMING a practice in development
- 8. P.J. Plauger, one of the implementors of C: "At each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.” 1978-1988 1995 “Developing in Pairs” pattern in Jim Complien's book "Pair Programming Illuminated", by Laurie Williams and Robert Kessler, is the first book devoted exclusively 2002 PAIR PROGRAMMING
- 9. Core Practice in Extreme Programming http://www.extremeprogramming.org/rules/pair.html PAIR PROGRAMMING
- 11. Social Skill PAIR PROGRAMMING it means it is not suitable for everyone
- 15. Pairing does not amplify my productivity. Instead, it erases all the bad habits I have that keep me from being a superstar on my own. h!p://www.sarahmei.com/blog/201%4/14/thoughts-on-two-months-of-pairing
- 16. PAIR PROGRAMMING 2 developers 1 machine 1 monitor 1 keyboard 1 mouse
- 21. MANY PEOPLE HATE IT So that's why I don't like pair programming. My weaknesses are exaggerated and my strengths are vetoed. For me, pairing doesn't work. For plenty of others, it very clearly does work. But not me. And that's why I quit the best company I've ever worked for: Pivotal Labs. h!p://mwilden.blogspot.com.tr/2009/11/why-i-dont-like-pair-programming-and.html
- 22. Learn how to do Have desire Define coding standards Have experienced people Practice and be patient Inspect and adapt PRACTICE PROGRAMMING PAIR TO MAKE STEPS YOURINDISPENSABLE
- 24. DRIVER TacticianStrategist NAVIGATOR Codes Thinks about how to code better Doesn’t dictate the code Programs out loud Thinks through problems Reviews code Does sanity testing Reads and checks
- 25. Besides, if people program solo, they are more likely to make mistakes, more likely to over design, and more likely drop the other practices, particularly under pressure. XP Explained
- 26. Higher quality in code Higher morale Better collaboration Shared knowledge Quicker to market Automatic code review Useful for training people Lower defect rates Faster defect removal Cannot force people Tiring Hard to setup common infra Hard to keep focus Clash of egos Harder for introverts No multiple committers Easy to do anti-patterns More effort on first & last sprint BENEFITS CAVEATS
- 27. 10 EASY
- 28. Select you pair wisely1 Don't force people who don't like each other to pair Two juniors might not be a good idea
- 29. Start with a reasonably well- defined task before you sit down2 It's better if you do not need to investigate a lot how to program or which technologies to use
- 30. Agree on one tiny goal at a time3 Define your checkpoints. Select minor goals.
- 31. Rely on your partner and support him4
- 32. Talk a lot!5 Does that look correct to you? Do you think this is a valid test? What’s next? Trust me! Do you have any better idea? I suggest better names for variables and classes I suggest to implement in smaller steps I suggest possible inputs that we haven’t covered Let me give you some details about this technology Think out loud
- 33. Sync up frequently6 Ask for agreement Ask if you miss something
- 34. Take a moment to celebrate7
- 35. Rotate pairs in every 90 minutes8 Do not exceed 4-6 hours a day Understand not everything has to be paired
- 36. Criticize the practice9 Do you do retrospectives?
- 37. Schedule the pairings if required Pairing full time is not practical 25% for 3 days in a week 50% for 2 days in a week Revisit how you pair after sprints Talk on pairing schedules daily 10
- 38. 10 EASY
- 39. Give breaks1 Pair programming is an exthausting practive. Never exceed 50 mins. You can use pomodoro counters for 25 mins intervals.
- 40. Switch the keyboard It's not a mentorship program, it is a development practice. Give that f*ucking keyboard to your pair and switch the roles. 2
- 41. Write tests, no matter what You can get the most out of pair programming if you write tests. Try to write tests first and push yourself to do TDD. 3
- 42. Take your personal time You need to read more, practice more, investigate more, learn more. Take your time for working alone at least few hours a day. 4
- 43. Full day pairing is ok, but not sustainable You have to come to office at the same time, go to lunch together, take breaks at the same time, leave the office at the same time. 5
- 44. Ask for used shortcuts, and learn Learn all the tricks and shortcuts your pair uses. If you notice your pair goes fast, stop him/her and ask the trick. 6
- 45. Do not worry about silly mistakes Hey you know that. It is normal to do silly mistakes. Relax. If your pair makes you stressed, let him/her know! 7
- 46. No one should be forced to pair However if pair programming is a core practice in your company, you might have to spend a lot of time with pairing. 8
- 47. Ask for your pair's opinion Pairing is a matter of attitude. Do not always tell what to do. Ask for suggestions and discuss together. 9
- 50. Do not fall into Anti-Pattern trap Know the ways how you can screw up pairing and do your best accordingly.
- 51. Superman I am fast, give me keyboard Absent-Mind Ed I am too distracted The Back-Seat Driver Tons of non-trivial comments The King of Shortcuts Navigator knows all shortcuts and pushes to use Fearful Freddie Refusing to refactor code that you didn't write The Anti-Mentor Leaving the newbie alone while pairing The Soloist Works solo as much as possible The Defactorator Revert all refactorings the others did ANTIPATTERNS
- 52. TYPES OF PAIRING
- 53. A writes a new test and sees that it fails B implements the code to pass the test B writes the next test A implements it And so on Refactoring is done whenever needed PING-PONG PAIRING Well suited for applying TDD If you aim to do remote pair programming, start with ping-pong
- 54. GIT-PONG PAIRING $ git remote add personA <URL> $ git fetch personA $ git checkout personA/master $ git checkout -b feature/PA-231 add your changes and commit $ git push personA feature/PA-231 A B $ git checkout feature/PA-231 add your changes and commit $ git pull personA feature/PA-231
- 55. A writes test B writes production code Repeat for 4-5 times A refactors all Switch roles MICRO PAIRING Similar to ping-pong, but you may pass a succeeding test and switch the keyboard
- 56. It is an advanced skill, best suited for seasoned, well-practiced teams Any number of pairs might work on a task at various times until it is complete PROMISCUOUS PAIRING A does pair programming with B B does pair programming with C C does pair programming with D on the same task even on the same day
- 57. 1 driver, multiple navigators Big projector or big TVs Switch every 15 minutes MOB PROGRAMMING The whole team works on the same thing, at the same time, in the same space, and at the same computer
- 59. ENJOYremember whatever you do do not forget to https://www.flickr.com/photos/fraserspeirs/3394902061 Joe O'Brien and Jim Weirich while doing ruby code review