Cum ar trebui organizat pair programmingul intr-o echipa? Cate ore/zi sau pe saptamana? Cum ar trebui sa se deruleze un sesiunea de pair/programming? Unul scrie si altul isi da cu parerea?
Ce experiente ati avut voi? Placute sau neplacute!
1 Like
Nu stiu daca ar fi o idee buna. S-ar lua la bataie destu de rapid.
acu, serios, eu n-as putea sa lucrez cu cineva in spate
Eu consider pair programming unul dintre cele mai puternice technici agile. Uite cum am procedat noi la Syneto.
- Am convenit, in urma unor discutii, de comun acord, sa incercam aceasta practica timp de aproximativ 6 luni.
- Ne-am interzis sa scriem cod si sa dam commit cu cod scris de o singura persoana. Daca cineva a scris ceva singur, nu a dat commit. A sters tot ce a scris, a chemat un partener, au rescris impreuna, si au dat commit. De regula a iesit un cod de 2x mai bun decat prima incercare scrisa singur.
- Se exclud de la punctul 2. taskurile triviale cum ar fi modificarea culorii unui buton pe UI sau schimbarea unui string dintr-un mesaj de eroare.
- Dupa timpul parcurs, am facut o alta intalnire in care am ridicat toate restrictiile si am tras concluziile noastre proprii asupra cand si cum sa facem pair programming.
Iata cateva idei / reguli:
- Unul scrie detaliile de implementare celalt se gandeste la un nivel mai sus
- Unul se gandeste la chestii foarte aproapre de cod, pe o amploare de 5-7 linii (aprox o metoda), la denumiri de variabile, asignari, if-uri, etc. Celalt se uita de la un nivel de mai sus si observa duplicare de cod intre 2 metode de exemplu, sau ca o conditie srisa a fost deja implementata ca o alta metoda privata mai jos.
- Schimbati frecvent rolurile. Cel mai extrem ce am facut era la 30 secunde, cu timer. Dar sunt cel mai comfortabil cu metoda de la punctul 5.
- Mereu folositi o singura tastatura, niciodata doua. Simplul fapt ca nu poti sa scrii in secunda in care-ti vine o idee, te face sa te gandesti altfel, la un alt nivel.
- Faceti TDD. Primol scrie testul, celalt implementarea, primul face refactoring cand testele sunt pe verde. Acum celalt scrie testul, primul implementarea, celalat refactoring. Ciclul se repeta. Este chiar distractiv.
Avantajele cele mai importante ce am constatat noi:
- Distributia cunostintelor. Nu inseamna ca cineva din backend va deveni expert pe UI, dar cu siguranta va invata si intelege anumite chestii ce vor duce la o colaborare mult mai buna. Vor intelege de ce cei de la UI au nevoie de anumite formatari de date, da un anumit fel de API, etc. Si vice versa.
- Oamenii, colegii, vor invata sa colaboreze exponential mai bine.
- Cei noi isi vor gasi mentori. Mentorii vor petrece mai mult timp cu ucenicii.
- Nu mai e nevoie de code review. Deloc.
- Reducerea numarului de bug-uri. Semnificativ.
Mai sunt si altele, dar astea sunt top 5.
Cum facem pairing acum?
- Cei mai seniori fac pairing intre ei cand e vorba de implementarea unei probleme mai “challenging”, mai grele. Lucrurile triviale se fac singure.
- La lucruri mai triviale, mai usoare, cei seniori fac pairing cu cei mai incepatori.
- Nu uitati, un lucru trivial pentru un senior, este unul greu pentru un incepator. Deci, incepatorii simt nevoia sa faca pairing la alt nivel si la alte taskuri.
Ce am invatat eu personal?
- Foarte mult in domeniul de design si arhitectura alaturi de un mentor.
- JS alaturi de colegul de la UI
- System alaturi de colegul cel mai bun pe system de operare
- Am invatat sa colaborez, sa primesc si sa ofer sfaturi
- Am invatat sa-mi apreciez mai mult colegii
9 Likes
Foarte de curand am auzit de conceptul asta, deci nu pot sa comentez, dar imi suna foarte bine. Eu oricum cer des feedback, pentru ca vreau sa scot din mine cod cat mai bun si nu merg pe ideea “stiu cum se face, deci e totul in regula”.
1 Like
Vara asta sunt student la GSoC14 si am doi mentori. Prima parte a programului mai mult scriam cod, faceau review, corectam, o luam de la capat. Relativ recent am avut ocazia sa scriu cod cu ambii mentori practic in acelasi fisier, si nu numai ca le-am preluat standardele riguroase, dar am avut ocazia sa observ cum gandesc si cum isi impart timpul intre taskuri.
Mi se pare un concept foarte bun; Ce-i drept nu am auzit de el pana nu am citit aceasta postare, dar cred ca are mult potential.
1 Like