Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: chytrak 01. 07. 2015, 12:44:52
-
Zkoušel to někdo (jestli to je v našich končinách bežná praxe, tak sorry)? Jak se vám to líbilo?
Já to teda zatím nezkoušel, ale podle toho, co jsem si tak přečetl, tak bych řekl, že to je asi nej způsob psaní kódu,
protože ten druhý může vždycky pozorvat a všímat si různých detailů.
-
Zkoušeli jsme to jednou, celkem dávno. Jo, ten druhý odhalí spoustu chyb. Většinu by jich ale chytil i překladač. Nějaké chyby v logice taky chytne, to jo. Můj pocit ale je, že se to vyplatí až u softwaru s trochu vyššími nároky na spolehlivost. U nějakých řídicích systémů a podobně se to nejspíš vyplatí. U běžného kódění mi přijde produktivita dvou nezávislých lidí větší i s tím občasným laděním a hledáním chyb.
Víc než dojmologii ti ale nedám. Pokud někdo ví o nějakém objektivnějším srovnání, tak jsem sám zvědavý.
-
Myslim, ze to moc pro bezne veci nefunguje. lepsi je mit nezavisle programatory a pak treba jednoho pro cely team, ktery dela code review pro kazdy push request. Tzn zadny programator nesmi primo commitovat do public vetve. Zaroven clovek, ktery dela code review zajisti i dalsi veci jako:
* code style
* dobre komentare
* dostatecne male zmeny
* chybejici unit testy
* cokoliv kohokoliv napadne
jedine co je pro to potreba, aby za nim nejaky manager nemohl prijit a rict, hele franto, tohle proste zaclenis.
-
Nepoužívá se to asi nikde, kromě školství, tam to má smysl žáci se učí jeden od druhého.
Když je potřeba vysoká spolehlivost, tak výsledný kód řádek po řádku audituje třeba pět programátorů, ale ty původní řádky vždy píše jenom jeden.
-
Pár krát som také čosi zažil s bývalým šéfom. Pre mňa to bol iba kurz sebaovládania. Fakt veľmi zlé. Ten človek neovládal ani klávesovú skratku na vypnutie okna...
Aj teraz sa občas sa stane, že dvaja programátori sedíme za compom a niečo kódime, ale cieleným párovým programovaním by som to nenazval.
-
Párové programování? To je docela slušný anger management...
-
Tady v UK jsou firmy, ktery maji politiku "100 % produkcniho kodu musi byt naprogramovano v paru", ale to jsou extremisti :-).
Dva vyvojari v paru maji obvykle vyssi produktivitu nez dva samostatne. Zejmena z duvodu nakladu na opravu chyb. Cena bugu, jehoz oprava je na jeden radek je obvykle nekolik (malo) hodin, roste s velikosti firmy, urovne byrokracie a malou automatizaci nasazeni.
Jinak dalsi casto prehlizeny benefit je vzdelavani lidi. Kdyz das uplnyho juniora k seniorovi tak za mesic udela pokrok co sam by udelal za pul roku. Stejne tak dva seniori se od sebe hodne nauci.
-
Já si neumím představit, jak to jako vypadá. To seděj dvě opice před jednim monitorem a přetahujou se o klávesnici? Má kaźdej aspoň vlastní židli?
-
Já si neumím představit, jak to jako vypadá. To seděj dvě opice před jednim monitorem a přetahujou se o klávesnici? Má kaźdej aspoň vlastní židli?
Jo, tak nejak.
Jeden pise kod, vysvetluje proc pise to co pise. Druhej mu do toho keca a rika co tam ma blbe, a dela poznamky. Obvykle ma i vlastni stroj na kterym muze cumet do dokumentace atd..
A po nejaky intervalu se stridaji (obvykle 10 min). Vetsinou se to kombinuje s TDD, tak taky muzou stridat po kazdym cyklu red - green - refactor.
-
Hodne casto se rika "pilot a navigator".
-
Hodne casto se rika "pilot a navigator".
Co takhle "kibic"? ;)
-
Hodne casto se rika "pilot a navigator".
Co takhle "kibic"? ;)
Na kibice ti staci review ;) Navigator by mel pomahat s hledanim cesty v sirsim kontextu.
-
Podle mě se to nehodí na 100% pracovního času. Ale jako doplnění třeba v 20-50% času to může být super. Zejména ve fázi kdy nejde o rutinu, ale o kreativnější činnost. Přínos je právě to oboustranné vzdělávání, takže v tom vidím právě stejný přínos jako při výuce při tom použití na školách.
Je fakt, že dva začátečníci se v tom budou patlat asi oba, takže to moc fungovat nebude, ale pokud se dvojice obměňují a úroveň je různá, mohou z toho těžit oba - zkušenější se učí vést a sledovat typické chyby a neobratnosti nezkušených a ten méně zkušený se učí obvykle idiomy a metody pro běžnou praxi. Roste otevřenost a schopnost sdílení know-how. Navíc u toho může být leckdy sranda :-) Přínos pro celý tým může být znatelný. Předpokladem je, že do toho mají všichni chuť. Pokud je to naordinované pod tlakem zeshora, může to být pruda. Je to o lidech.
-
Funguje to hocikedy (teda ked sa realne programuje) a ma to svoje vyhody aj nevyhody. Co je podla mna vyhoda, ze sa ovela skor dojde na niektore chyby. Najlepsie sa to da pouzit asi pri novacikoch. Niektori tunajsi sociaopati si najradsej patlaju po svojom a jedine po com tuzia je byt na celom poschodi osamote, takze toto je pre nich hotovy postrach..
-
Tak můžete mít připojeno několik klávesnic, to to jsem napsal na dvou klávesnicích současně :-))) Zřejmě použít více myší s více ukazateli půjde taky.
-
IDE pro párové programování https://www.codebox.io/
-
Tak můžete mít připojeno několik klávesnic, to to jsem napsal na dvou klávesnicích současně :-))) Zřejmě použít více myší s více ukazateli půjde taky.
Žebych konečně uzřel uplatnění pro ten vícenásobný kurzor (nebo jak se to jmenovalo) ve vimu?
-
To je zajímavý, jak se najednou objevilo xy nových editorů, které všechny vypadají stejně.
-
Mne to skor pripomina autoskolu kde nejaky instruktor ma dalsiu brzdu, pripadne volant, spojku atp....
Ak sa maju striedat, straca to zmysel. Ludska povaha je ze jeden bude "drbat" druheho, lebo ho predtym "drbal" on....
Code review je rozumnejsie v spojeni s unittestami...
BTW: ak mas dvoch vyvojarov, nie "copi luwak" zuzlacov "brutalne kvalitnej a podrobnej" analyzy, nedosiahnes rovnake kody, hoci by oba hadzali rovnake vysledky... Ktory je potom ok ?!
-
Na psani odbornych textu mi to prijde k nezaplaceni (dobre, neni to SW, ale ma to podobna pravidla: predem danou strukturu, omezeny slovnik a efektivni konstrukce, jasnej zacatek a cil, chyby obou typu: logika/navrh + minor bugs (preklepy, ...)). Kdyz pisu sam, nejvetsi peklo jsou komentare spoluautoru typu: timhle chces rict co? , a jeste by se melo rict... atp., ktere jsou spravne, ale uplne bori uz vystavenou strukturu textu (Slozis pole prvku nejak a podle toho s nim pracujes. Nekdo prijde s navrhem lepsi struktury -> (kus) prace v rejzi). Kdyz jsou u toho dva, nebo je aspon ping textu kratky (obsahem, ne nutne casem), tomuhle se predejde, pac jeden ma okamzitej feedback.
-
Ludska povaha je ze jeden bude "drbat" druheho, lebo ho predtym "drbal" on....
V praxi to tak nefunguje. (Pokud se teda párové programování dělá dobrovolně a ne befelem.)
-
Teorie dobra, v praxi vam projektak omlati budget o hlavu. 90% programatorske prace dnes je prace pro opice co znaji framework a bouchaji to jak bata cvicky. Tam parove programovani nema co delat.
-
Tak u nás to celkem s úspěchem používáme, ale není to tak, že jeden programuje a druhý mu do toho kecá. Funguje to tak, že úkol se rozdělí na 2 části. Každý tu svoji část naprogramuje a zlehka otestuje....na konečné otestování si to prohodí i na případné reworky...Největší bonus tohoto je vzájemná zastupitelnost a kvalita je taky na vyšším levelu. Podle mne se to hodí na úkoly související s údržou rozsáhlých systémů.
-
Tak u nás to celkem s úspěchem používáme, ale není to tak, že jeden programuje a druhý mu do toho kecá. Funguje to tak, že úkol se rozdělí na 2 části. Každý tu svoji část naprogramuje a zlehka otestuje....na konečné otestování si to prohodí i na případné reworky...Největší bonus tohoto je vzájemná zastupitelnost a kvalita je taky na vyšším levelu. Podle mne se to hodí na úkoly související s údržou rozsáhlých systémů.
Tak to ale není párové programování...
Ale obecně přínos peer review není zdaleka jenom v chytání chyb ale právě to snížení bus factoru je hodně důležitý přínos.
-
No prostě to jde, ale je to pro machry: https://upload.wikimedia.org/wikipedia/commons/8/8f/Ken_Thompson_%28sitting%29_and_Dennis_Ritchie_at_PDP-11_%282876612463%29.jpg