Collaborative programming/cs

Ú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:





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) At any point, people can ask questions and ask for help from the team for looks up things in the docs ask for ideas about what to do next.
 * 9) As the researcher, if there are people in the team that have less experience than you make sure you keep them included by asking little questions: "What should we do next?" or "How can we solve this?"

Collaborative Programming Tips

 * Clarity in the goal: have a clear agenda "we are fixing this bug" or "we are adding this feature"
 * Clarity in the context: What project/files/classes are being involved in the exercise? Sometimes moving from one file to another can cause confusion to the researcher, so it's good to have the whole working space in mind.
 * Clarity in the process: How do we test things to see that they are working? Do we run phpunit? How do we debug, how do we track the errors?
 * Clarity in the authorship: When pushing code, we are pushing from a particular Gerrit user. It's impossible to have both names as authors of the code, but the commit message can have information about those who have contributed to this. Mostly if this is external contributors and volunteers.
 * Additional advice: Be mindful! if this is a session between WMF staff and external contributor, attribution is a way to engage and thank the volunteer.

How to communicate during a session?
As opposed to a workshop the goal of a pairing session is not to present a solution or a technology to your team, but rather to get to a solution together. Therefore specific communication rules apply:


 * refrain from saying things like "obviously" or "simply", because what you are implementing seems simple to you, but rather approach your teammates with empathy, and assume that you have different knowledge of different parts of the codebase
 * when somebody has a question we pause and answer as good as we possibly can
 * rather overcommunicate and talk the others through what you are trying to do
 * try to use I statements, i.e. "I believe that there's another solution" instead of "This needs to be done differently"
 * do not generalise people's experiences through others: "X and Y believe that there is a good solution" instead of "people believe that there is a good solution"
 * when you realise the other one did a mistake, do not interrupt but bring up your concerns when they have finished their point
 * use always only non-judgemental language, saying "you did it wrong" might not be the best way to make your pairs aware of a mistake, rather say: "have you considered..."
 * be careful about strong opinions, sometimes a strong opinion is justified, but more often is just a way to ignore other possible ways that are also okay
 * have a dialogue as opposed to a discussion where one has to "win" and come to a resolution together
 * do not be afraid to change your opinion, adaptability, and change of opinions are a sign of an intelligent collaborator

Also read: [Inclusive Communications Guide]

This is a safe space
If you don't feel comfortable to collaborate or have had issues in a sessions recently, please know that it's always something you can bring up with your manager, as it's their responsibility to make you feel safe. In serious cases HR will also be available to talk to you about the incidents.

What's a good way to initiate collaborative programming sessions?
They can be either ad-hoc or be scheduled sessions a few times a week to make sure you reserve time for it. Some teams do that and call them Collab sessions, for example the Platform Engineering Team and the Community Tech Team. If you would be interested in having sessions with your teammates there are several options:


 * 1) Don't hesitate to ask them directly
 * 2) Ask your Engineering Manager or Tech Lead to plan a session for you with someone from another team that's up for it
 * 3) Some teams have Code Jams, something like an internal hackathon, feel free to suggest one for your team.
 * 4) You have a big task that you are handing over to another developer to be reviewed, that can be a great moment to offer a session to give them a rough overview of files changed and how they belong together.
 * 5) You are working on a part of the codebase that you really enjoy working with and would love to share your knowledge. Publicly announce that you are open to collaboration!  (Note: This is different than giving a workshop.)

Great moments to start can be:

 * your team found a small enough bug that you think could be fixed in an hour or two
 * you are working on a feature that has a lot of impact and affects lots of people and want to make sure you do the right thing
 * you feel stuck for more than a few hours and want to talk through your solution with someone
 * you don't feel ready to design the solution of a ticket and would like some inspiration from your teammates
 * you are working on something and feel like that other teams could have some really valuable knowledge that would help you proceed/begin
 * you are completely sure about how to implement a ticket but it would be interesting to see if others agree

How to facilitate a collaborative programming session?

 * 1) Ask around for some developers that are curious about it.
 * 2) Find a non-urgent bug that you think could be progressed in an hour or two.
 * 3) Setup a call, with people in similar time zones. (if timezones are too spread out provide multiple sessions for your team)
 * 4) All jump into the call and ask tons of curious questions.

A change of mindset about the way we work together can help:
The point of having a collaborative session is not that you will all be more effective together, the point is to collaborate and learn from each other and get more conscious of anti-patterns and with a bit of practise you will actually write better code.

"Try treating programming as a learning activity that throws off running code as a byproduct" ~@KentBeck

Recommended Tools

 * one tool that has a lot of potential is https://duckly.com/ because it's working with different editors.
 * Extension for Intellij https://plugins.jetbrains.com/plugin/14225-codetogether
 * Extension for Visual Studio Code https://docs.microsoft.com/en-us/visualstudio/liveshare/use/vscode
 * just sharing your screen with an editor open can be completely fine, as long as you reassign the researcher
 * timer for sessions http://mobster.cc/ or https://mobti.me/ to help ensure that the researcher is randomly being reassigned

Acknowledgements
Throughout the creation of this guide, various people have contributed extensively with feedback, comments, and ideas, provided important input, and added sections that are truly important for the guide, this is a living document, and additions or edits are welcome. Important contributions came from Nikki Nikkhoui, Daniel Kinzler and Genoveva Galarza Heredero. Thank you all!