Kolaborativní programování

Úvod

Toto je průvodce se sadou doporučení pro společné programovací sezení a učení, který je určen všem inženýrům, přispěvatelům a dobrovolníkům, kteří píší kód nebo se učí kódovat a mají zájem spolupracovat více. Tato příručka je určena také začátečníkům nebo středně pokročilým uživatelům/kodérům. Jako každý, kdo přispívá k práci nadace Wikimedia Foundation, může být inspirativní pravidelně se vracet k našim hodnotám a přemýšlet: Co to znamená pro způsob, jakým spolu pracujeme na každodenní bázi? Když přemýšlíte o více společných způsobech psaní kódu, tento vyniká:

Jsme v tom spolu. Spolupráce není vždy jednoduchá. Někdy bojujeme. Spolupráce je náročná, ale stojí za to. Děláme to, protože nás to dělá silnějšími. Problémy lépe řešíme společně. Aby to dobře fungovalo, každý z nás musí být k sobě upřímný, odpovědný a transparentní.

Rozhodně musí člověk zažít dobré párové programování, aby se přesvědčil, že to dělá opakovaně. Ve skutečnosti je trochu těžké se do toho dostat, protože se můžete cítit zranitelní a vystavení všem pozorováním, ale brzy poté nastane bod, kdy vám otevřenost ukázat způsob vaší práce umožní vybudovat důvěru v týmu, protože si uvědomujeme, že nikdo neví. to všechno a každý si musí věci vyhledat a pořádně promyslet. Obrovskou výhodou párového sezení je, že "jsme v tom spolu" a ostatní vám mohou pomoci přemýšlet a zkoumat. Co když přístup k více kolaborativnímu způsobu psaní kódu skutečně vyřeší problémy způsobem, který řeší nedostatek rozmanitosti a vede ke kódu, který je méně náchylný k chybám?

Jaký problém se to snaží vyřešit?

Znalosti o naší kódové základně se mohou snadno umlčet, takže část kódové základny nebude udržována tak, jak by si zasloužila, a je těžké ji pochopit, když se lidé pohybují a soustředí se na jinou práci. Není to nikoho chyba a je to jen v povaze pohybu talentů, ale můžeme proti tomu aktivně bojovat neustálým sdílením znalostí. Existuje mnoho způsobů, jak sdílet znalosti, například psané dokumenty, workshopy a společné programovací sezení jsou jedním z nich.

Pokud se dotýkáme částí nám neznámé kódové základny, někdy nevíme, s kým mluvit, a bylo by hezké vědět, na které týmy se obrátit s konkrétními otázkami. Zejména s rostoucím počtem vývojářů se nezdá, že by stálo za námahu probírat seznam lidí, kteří by mohli vědět o funkci, které se právě dotýkáte nebo implementujete, nebo o technologii, o které se chcete dozvědět, a zdá se, že je jednodušší pracovat sám. Potenciálně více lidí se opakovaně nebo paralelně potýká se stejným problémem, protože nevědíí, od koho by se mohli učit a sdílet s ním zkušenosti.

Kromě toho se zdá, že všechny týmy mají své termíny, které musí splnit, a není čas ani prostor na spolupráci nebo výuku. Zdá se, že spolupráce zpomaluje pokrok na naší vlastní práci.

Terminologie

Není to všechno stejné: Párové programování, programování Mob a společné programování? Ano, je to v podstatě stejné, zatímco programování Mob umožňuje více členů, kteří přispívají do relace. Rozhodli jsme se používat Collaborative Programming jako obecnější termín, který zahrnuje všechny ostatní.

Další výhody

• může to vést k rozmanitějším týmům a skupinám, kde se lidé opravdu cítí vítáni, kde se aktivně sdílí znalosti a kde chtějí vývojáři zůstat
• větší různorodost názorů v procesu tvorby kódu vede k širšímu spektru řešených problémů
• zlepšení zkušeností vývojářů
• studie ukazují, že se zdá, že rychlost malých týmů vzrostla

kvalitu kódu lze zlepšit

• pocit sounáležitosti v týmech
• lepší sdílení znalostí

Zatímco někteří z nás zažili kolaborativní programování jako přínosný přístup, ve skutečnosti to podporují různé studie:

• Alistair Cockburn, Laurie Williams. "Náklady a přínosy párového programování". 
• John T. Nosek. "Případ pro společné programování". 

Ukázková struktura relace kolaborativního programování

Role

• Spisovatel - vedení relací
• Výzkumník - čtení dokumentace a vyhledávání věcí

Zde je doporučené nastavení pro relaci společného programování. Pokud se vám to všechno zdá příliš rigidní, přeskočte doporučení a udělejte si vlastní věc: Seznamte se a ukažte si navzájem svůj kód a promluvte si o něm, důležité je, že na procesu spolupracujete.

1. Neexistují žádná pravidla, existuje pouze soubor doporučení.
2. Není podmínkou vstoupit do relace, když člověk zná kódovou základnu nebo konkrétní jazyk, protože budete pracovat jako tým (skupina dvou až pěti lidí), který se sejde kvůli hovoru.
3. Jedna osoba vždy chvíli vede relaci a sdílí svou obrazovku a realizuje jeden malý krok problému, který chce skupina vyřešit společně, říkejme této osobě spisovatel.
4. Jeden další člen týmu je "výzkumník", který klade zvědavé otázky a navrhuje věci k vyzkoušení a implementaci, které by mohly být jedním z kroků řešení.
5. Pokud máte dobré nastavení párového programovacího nástroje, je to skvělé, takže různí lidé mohou být aktivní, jinak ten, kdo ukazuje jejich kód, spisovatel, může postupovat podle pokynů výzkumníka
6. Nejdůležitější je, že role výzkumníka se předává každých 10-15 minut.
7. Být spisovatelem, ujistěte se, že popisujete, co se snažíte dělat, když píšete, a jako pozorovatel se ujistěte, že zůstáváte zapojeni a ptáte se na věci, o kterých si nejste jisti.
8. Kdykoli mohou lidé klást otázky a požádat tým o pomoc při hledání věcí v dokumentech a požádat o nápady, co dělat dál.
9. Jako výzkumník, pokud jsou v týmu lidé, kteří mají méně zkušeností, než vy, ujistěte se, že je zapojíte tím, že jim položíte malé otázky: "Co bychom měli dělat dál?" nebo "Jak to můžeme vyřešit?"

Tipy pro společné programování

• Jasnost cíle: Mít jasnou agendu "opravujeme tuto chybu" nebo "přidáváme tuto funkci"
• Jasnost v kontextu: Jaký projekt/soubory/třídy jsou zapojeny do cvičení? Někdy může přesun z jednoho souboru do druhého způsobit zmatek výzkumníkovi, takže je dobré mít na paměti celý pracovní prostor.
• Jasnost v procesu: Jak testujeme věci, abychom viděli, že fungují? Spouštíme phpunit? Jak ladíme, jak sledujeme chyby?
• Jasnost v autorství: Při vkládání kódu vložme od jakého konkrétního uživatele Gerritu je. Je nemožné mít obě jména jako autory kódu, ale zpráva odevzdání může obsahovat informace o těch, kteří k tomu přispěli. Většinou jde o externí přispěvatele a dobrovolníky.
• Další rada: Buďte opatrní! pokud se jedná o sezení mezi zaměstnanci WMF a externím přispěvatelem, atribuce je způsob, jak zapojit dobrovolníka a poděkovat mu.

Jak komunikovat během sezení?

Na rozdíl od workshopu není cílem párování představit řešení nebo technologii vašemu týmu, ale spíše dospět k řešení společně. Proto platí specifická pravidla komunikace:

• Neříkejte věci jako "samozřejmě" nebo "jednoduše", protože to, co implementujete, se vám zdá jednoduché, ale spíše přistupujte ke svým spoluhráčům s empatií a předpokládejte, že máte různé znalosti o různých částech kódové základny.
• Když má někdo otázku, zastavíme se a odpovíme tak dobře, jak jen můžeme
• Spíše přehnaně komunikujte a mluvte s ostatními o tom, o co se snažíte
• Zkuste použít výroky I, tj. "Věřím, že existuje jiné řešení" místo "To je třeba udělat jinak"
• Nezobecňujte zkušenosti lidí prostřednictvím druhých: Použijte "X a Y věří, že existuje dobré řešení" místo "lidé věří, že existuje dobré řešení"
• Pokud si uvědomíte, že ten druhý udělal chybu, nepřerušujte ho, ale vyslovte své obavy, až dokončí svůj názor
• Používejte vždy pouze nesoudící jazyk, říkat "udělal jsi to špatně" nemusí být nejlepší způsob, jak upozornit vašeho parťáka na chybu, spíše řekněte: "Uvažovali jste..."
• Buďte opatrní na silné názory, někdy je silný názor oprávněný, ale častěji je to jen způsob, jak ignorovat další možné způsoby, které jsou v pořádku
• Veďte dialog na rozdíl od diskuse, kde se musí "vyhrát" a společně dospět k řešení
• Nebojte se změnit svůj názor, přizpůsobivost a změna názorů je znakem inteligentního spolupracovníka

Přečtěte si také: [Inkluzivní průvodce komunikací]

Toto je bezpečný prostor

Pokud se necítíte na spolupráci nebo jste měli v poslední době na sezeních problémy, vězte, že je to vždy něco, o čem můžete mluvit se svým manažerem, protože je jeho odpovědností, abyste se cítili bezpečně. Ve vážných případech bude k dispozici také HR, aby si s vámi o incidentech promluvil.

Jaký je dobrý způsob, jak zahájit sezení společného programování?

Mohou být buď ad-hoc, nebo plánované sezení několikrát týdně, abyste si na ně vyhradili čas. Některé týmy to dělají a nazývají jej Collab sessions, například Platform Engineering Team a Community Tech Team . Pokud byste měli zájem o setkání se svými spoluhráči, existuje několik možností:

1. Neváhejte se jich zeptat přímo
2. Požádejte svého technického manažera nebo technického vedoucího, aby pro vás naplánoval relaci s někým z jiného týmu, který je pro to připraven
3. Některé týmy mají Code Jams , něco jako interní hackathon, klidně navrhněte jeden pro svůj tým.
4. Máte velký úkol, který předáváte jinému vývojáři ke kontrole, což může být skvělý okamžik k tomu, abyste jim nabídli relaci, která jim poskytne hrubý přehled o změněných souborech a o tom, jak k sobě patří.
5. Pracujete na části kódové základny, se kterou vás práce opravdu baví, a rádi byste se o své znalosti podělili. Veřejně oznamte, že jste otevřeni spolupráci! (Poznámka: To je něco jiného než pořádání workshopu.)

Skvělé okamžiky pro začátek mohou být:

• Váš tým našel dostatečně malou chybu, o které si myslíte, že by mohla být opravena během hodiny nebo dvou
• Pracujete na funkci, která má velký dopad a ovlivňuje mnoho lidí, a chcete se ujistit, že děláte správnou věc
• Cítíte se zaseknutí na více než pár hodin a chcete si s někým promluvit o svém řešení
• Necítíte se připraveni navrhnout řešení problému a chtěli byste inspiraci od svých spoluhráčů
• Na něčem pracujete a máte pocit, že ostatní týmy by mohly mít opravdu cenné znalosti, které by vám pomohly pokračovat/začít
• Jste si zcela jisti, jak zavést lístek, ale bylo by zajímavé zjistit, zda ostatní souhlasí

Jak usnadnit relaci společného programování?

1. Zeptejte se na nějaké vývojáře, které to zajímá.
2. Najděte nenaléhavou chybu, o které si myslíte, že by mohla být vyřešena za hodinu nebo dvě.
3. Navažte hovor s lidmi v podobných časových pásmech. (pokud jsou časová pásma příliš rozprostřena, poskytněte svému týmu více relací)
4. Všichni vstupte do hovoru a ptejte se spousty zvědavých otázek.

Změna myšlení ohledně způsobu naší spolupráce může pomoci:

Smyslem společného sezení není to, že budete všichni společně efektivnější, jde o to, abyste spolupracovali a učili se jeden od druhého, abyste si více uvědomili anti-vzorce a s trochou praxe skutečně napíšete lepší kód.

"Zkuste s programováním zacházet jako s výukovou aktivitou, která odhodí běžící kód jako vedlejší produkt" ~@KentBeck

Doporučené nástroje

• Jeden z nástrojů, který má velký potenciál, je https://duckly.com/, protože pracuje s různými editory.
• Rozšíření pro Intellij: https://plugins.jetbrains.com/plugin/14225-codetogether
• Rozšíření pro Visual Studio Code: https://docs.microsoft.com/en-us/visualstudio/liveshare/use/vscode
• Pouhé sdílení obrazovky s otevřeným editorem může být zcela v pořádku, pokud změníte přiřazení výzkumníka
• Časovač pro relace http://mobster.cc/ nebo https://mobti.me/, který pomůže zajistit, že výzkumník bude náhodně přeřazen

Poděkování

Během tvorby této příručky různí lidé rozsáhle přispívali zpětnou vazbou, komentáři a nápady, poskytovali důležité vstupy a přidávali části, které jsou pro průvodce skutečně důležité, jedná se o živý dokument a doplňky nebo úpravy jsou vítány. Důležité příspěvky přišly od Nikki Nikkhoui, Daniel Kinzler a Genoveva Galarza Heredero. Děkuji vám všem!