Mietin sellaista ohjelmankirjoittamistapaa, että huoneessa yksi kirjoittaa ja muut katsovat videotykiltä tai sisäisessä verkossa mitä kirjoitetaan voidakseen suullisesti kommentoida. Se voisi olla mukavaa vaihtelua ja joissain tilanteissa myös tehokkaampaa.
Sitten tulisi sanottua ainakin jotain tällaista:
-hei tuosta unohtui puolipiste
-laita se toiselle puolelle sulkuja
-hyvä muuttujan nimi olisi ...
-tuossa vector on tehokkain
-float riittää tähän
Se voisi olla työnjakoon verrattuna tehokkaampaa erityisesti silloin jos huoneessa olijoiden taidot / ajattelun nopeus on hyvin erilaista erilaisissa kysymyksissä. Ja muut kuin kirjoittaja voivat tehdä mahdollisesti tarvittavat laskutoimitukset ja ohjelmointikomponenttien dokumentaation tutkimiset, niin ajatus ei katkea.
Sitten tulisi sanottua ainakin jotain tällaista:
-hei tuosta unohtui puolipiste
-laita se toiselle puolelle sulkuja
-hyvä muuttujan nimi olisi ...
-tuossa vector on tehokkain
-float riittää tähän
Se voisi olla työnjakoon verrattuna tehokkaampaa erityisesti silloin jos huoneessa olijoiden taidot / ajattelun nopeus on hyvin erilaista erilaisissa kysymyksissä. Ja muut kuin kirjoittaja voivat tehdä mahdollisesti tarvittavat laskutoimitukset ja ohjelmointikomponenttien dokumentaation tutkimiset, niin ajatus ei katkea.
Vastaukset 4
Vanhimmat
Hyvä idea, jopa niin hyvä että se on jo keksitty:
http://www.ketteratkaytannot.fi/Kaytannot/Pariohjelmointi/
Tuo yksi koodaa muut (kuinka monta?) on liian tehoton kaupalliseen tuotantoon, joten yrityspuolella käytännössä jäljelle jää vain pariohjelmointi. Toki (yliopisto)tutkimus, opiskelu ym. jutuissa voisi olla ihan ok ja 3-4 ryhmä voisi olla hyvinkin toimiva sopivassa projektissa.
Pariohjelmoinnissa on mielenkiintoista tuo toiselta parempien käytäntöjen ym. oppiminen, jonka pitäisi nostaa koko tiimiin tuottavuutta. Paria pitäisikin vaihtaa siinä vaiheessa kun toiselta ei enää opita uutta.
> Tuo yksi koodaa muut (kuinka monta?) on liian tehoton kaupalliseen tuotantoon
Ihan "kaupallisessa tuotannossa" olen tuota muutaman kerran käyttänyt. On käytännöllinen silloin, kun pitää tehdä kriittinen komponentti nopeasti. Puolipisteiden unohtelut sun muut eivät nyt ole iso ongelma (viimeistään käännösvaiheessa jää kiinni), ja onpa koodareilla eroja koodinkirjoitustavassakin siinä määrin, että jotkut jättävät melkein säännönmukaisesti moisia pois ja korjailevat erissä (mikä ei minusta ole yhtään sen huonompi tapa, kuin kirjoittaa kerralla oikein).
Sen sijaan logiikkavirheet tai laiska ohjelmointi (mitä sitä poikkeuksia kiinniottamaan, heitellään eteenpäin ja printataan lopuksi logiin vaan), ovat sellaista tavaraa, joka on mieluiten saata kiinni heti koodia ensimmäisen kerran kirjoitettaessa. Myös keskustelu parin kanssa on suotavaa, siinä kun samalla itselle selkiytyy se logiikka, jolla koodinpätkää lähtee tuottamaan.
Tosin tuo sitten vaatii kaksi suhteellisen pätevää koodaria saman asian kimppuun. Ei välttämättä löydy jokaisesta keskisuurestakaan yrityksestä niin montaa. Saati sitten, että olisi aikaa vierihoitoon. :)
"Ihan "kaupallisessa tuotannossa" olen tuota muutaman kerran käyttänyt. On käytännöllinen silloin, kun pitää tehdä kriittinen komponentti nopeasti."
Tarkoitatko nyt pari- vai ryhmäohjelmointia?
"Puolipisteiden unohtelut sun muut eivät nyt ole iso ongelma (viimeistään käännösvaiheessa jää kiinni), ja onpa koodareilla eroja koodinkirjoitustavassakin siinä määrin, että jotkut jättävät melkein säännönmukaisesti moisia pois ja korjailevat erissä (mikä ei minusta ole yhtään sen huonompi tapa, kuin kirjoittaa kerralla oikein)."
Samaa mieltä.
"Sen sijaan logiikkavirheet tai laiska ohjelmointi (mitä sitä poikkeuksia kiinniottamaan, heitellään eteenpäin ja printataan lopuksi logiin vaan), ovat sellaista tavaraa, joka on mieluiten saata kiinni heti koodia ensimmäisen kerran kirjoitettaessa. Myös keskustelu parin kanssa on suotavaa, siinä kun samalla itselle selkiytyy se logiikka, jolla koodinpätkää lähtee tuottamaan."
Taas samaa mieltä.
"Tosin tuo sitten vaatii kaksi suhteellisen pätevää koodaria saman asian kimppuun. Ei välttämättä löydy jokaisesta keskisuurestakaan yrityksestä niin montaa. Saati sitten, että olisi aikaa vierihoitoon. :)"
On totta että jos tasoero on liian suuri niin homma menee vierihoidoksi, mutta tästä hyötyy "hoidettava" jonka osaaminen parantuu ja sitä kautta koko tiimin (ja firman) tuottavuus paranee, mutta ei tietenkään heti vaan viiveellä.
Vierihoidollista parikoodausta olisi varmaan hyvä käyttää vain osa-aikaisesti (1-2 vk), esim. projektin alussa voi olla sopivasti löysää, jolloin saataisiin minimaalinen ajallinen haitta. Samantasoistenkaan pariohjelmointia tuskin kannattaa harjoittaa kuin sopivissa määrin ja tilanteesta riippuen.
Juu, parikoodausta lähinnä on tullut harrastettua, mutta onpa joskus parin taakse tullut seisomaan kolmas henkilö kahvikupin kanssa laukomaan kommentteja. Ei ehkä ollut varsinaisesti tarkoitus, mutta kaikki on kotiinpäin. :)
Vierihoito oli minulta väärä sana. Vierihoitoon se juuri menee, kun kokenut opastaa kädestä pitäen kokematonta, mikä on toki suotavaa, mutta varsinainen pariohjelmiointi ei sitä varsinaisesti ole...