Предности и замке програмирања парова на радном месту

Програмирање у пару су два програмера који раде заједно на једној радној станици.

Формално је један програмер покретач и пише код. Други је посматрач или навигатор који прегледава сваку линију кода онако како је уписана.

Неформално, седе заједно на једној бази кода и разговарају о стварима и разграђују проблеме. Свако од њих може да напише код, а нико од њих не ради ништа друго попут провере телефона.

Неке организације широко усвајају програмирање парова, а друге их се клоне. Увек је тема за расправу и људи ће имати своје преференције. Сви смо људи и постоје тренуци када скоро сви могу имати користи од програмирања у пару.

Ипак, чини се као неефикасна употреба ресурса. Имамо два програмера. Обоје би могли да граде различите карактеристике недељу дана, на крају ћемо имати двоструко више карактеристика. Али то није случај и можда ћете на крају имати 2 сета 95% урађених функција које не можете испоручити. Заједничко програмирање може повећати нето количину стварно комплетних функција које испоручујете.

Користи

Мање грешака и задржавања грешака

Сви смо имали луде тешке грешке. То могу бити основни недостаци у целокупном приступу или грешка у куцању, нетачна инсталација или потреба за поновним покретањем система.

Као тим, шансе су да је неко од вас и раније направио сличну грешку. Или је вероватно да неко од вас познаје неког другог ко је наишао на проблем. Вероватније је да ћете тачном времену доделити проблем пре него што се вратите на таблу за цртање.

Можете разговарати о бољим стратегијама. Ово је боље него да проблем скривате цео дан, а да га не делите са другима.

Лакше наставити - Морална подршка

Често тимски рад може повећати позитивност у вези са проблемом. Када неко подели проблем кроз који пролазиш, осећаш се мање пораженим и позитивнијим у покушајима изнова и изнова и изнова ...

Теже одлагати

Тимски рад значи да не можете зауставити и проверити да ли у е-пошти, Слацку или Вхатсаппу постоји било какво жељено ометање.

Ово се чини као мала ствар. Али можете четвороструко повећати број сати које кодер проводи у уређивачу и кодирању, уместо да седите за столом и једете сате дана док не стигне кући.

Дељене најбоље праксе

Заједничко кодирање је одличан начин за размену знања у вашој компанији. Програмери могу једни другима давати савете како би побољшали свој приступ и повећали брзину.

Заједнички рад може открити знање које можда није у вашем Приручнику за нове запослене.

Брже укрцавање

Новозапослени могу да убрзају много брже упаривањем са искусним чланом тима.

Идентификујте и смањите лоше ангажовање

Може вам помоћи да рано препознате лоше запослене ако неко није погодан за посао или је ангажован због погрешне улоге. Можете нешто учинити поводом тога пре него што изгубите време обе стране.

Током интервјуа за запошљавање, тим упознат са програмирањем у пару биће бољи у процени да ли кандидат може да програмира са другима. Ако је нормалан момак који води сесије разговора одсутан, можете бити сигурни да га неко други може заменити и дати поштену анализу.

Повећајте задовољство запослених

Заједничко кодирање може приближити запослене јер деле искуства и имају више тема о којима могу разговарати. Кад други људи схвате на чему сте, имаћете више заједничког. Ово може утицати на мноштво важних пословних подручја. Може чак и побољшати теме разговора за ручком како би смањио одбојност запослених.

Кодирање може бити усамљена потрага када сте сами за рачунаром и када вам се каже да производите функције. Смањење било каквог отуђења у компанији је важно. То је један од разлога зашто бих предложио систем парног програмирања за почетнике у раној фази као и за велика предузећа.

Проблеми - када упаривање иде лоше

Програмирање у пару може забрљати ствари и потребан му је разуман приступ.

Не претерујте (или мање радите)

Присиљавање људи да проводе цео дан заједно није смислено и можда на крају мрзе једни друге.

Рафали од 1,5–2,5 сата обично најбоље функционишу. Мање је прекратко и то је губљење времена.

Наградите заједнички допринос

Ако сте двом програмеру дали важне рокове, а затим доделите једног да другом помогне око задатка, идете ка потенцијалној катастрофи. Када прегледате ко је извршио своје задатке и човек се осећа као да ништа није урадио, лични показатељи трпе. Ментално је ово лоше. Али ако је повезан са било којим системом награђивања, пуцате себи у ногу. Као мастер сцрум-а, морате бити сигурни да ћете рачунати упаривање и додијелити задатке поштено.

Уморни кодери

Више кафе и упаривање нису увек одговор. Када сте уморни и под стресом, можда не комуницирате правилно.

То може проузроковати више проблема у коду и међусобно. Неки људи имају бољи учинак на овај начин, а неки не, па можда ризикујете.

Сложени код - упаривање или дискусија

За сложенији код можда ће вам одвратити пажњу покушај упаривања. Понекад седење и објашњавање проблема може бити корисније.

Формално седење заједно и писање кода ред по ред заправо би могло да одврати пажњу.

Остале мисли

Али шта је са радницима на даљину?

Запослени који раде на даљину могу упарити програм са алаткама за дељење екрана на мрежи. Отклонио сам грешке кодова пријатеља у Бриселу док сам седео у кафани у Казахстану. Верујте ми да је то могуће.

Има ли доказа?

То су размишљања из мог искуства. Осетио сам ове предности док сам радио са разним предузећима и различитим боотцамповима.

Као научник прихватам да никада нисам обавио двоструко слепо испитивање предности. Наравно да то никада није био довољно важан приоритет у поређењу са само обављањем послова.

Али волео бих студију са преко 100 учесника који раде на истом скупу проблема. Једна група од 50 људи могла је радити у паровима, а друга група самостално. Волео бих да видим шта ће се догодити. То би могла бити лепа студија за било кога професора информатике.

Закључак

Као што видите, ја сам љубитељ програмирања у пару. Неки кодери не осећају да то ефикасно користи њихово време. Ако сте менаџер, на вама је да процените ситуацију и максимално искористите свој тим. У сваком случају, то је дефинитивно нешто што би све компаније понекад требале да дозволе.

Требало би га имплементирати динамички, а не наметати. Било који камп за подизање треба да га укључи у свој курс за изградњу добро заокруженог кодера.

Често га користимо у сопственој развојној агенцији, од решавања наших најтежих проблема до уласка новог особља. То је процес који уживамо да бисмо побољшали перформансе и знање у целој компанији. Наравно, не примењујемо га цео дан и сваки дан! Али свиђа нам се и задржавамо га.

Као што каже стара изрека „ Проблем се дели, преполовљен је.

Водим подцаст о начину размишљања о расту и технолошком покретању. Ако сте уживали у овоме, сазнаћете више претплатом.

Ако сте користили програмирање у пару, волео бих да чујем ваше мишљење о томе. Које праксе или савете користите да бисте одлучили када ћете упарити или не?