On Saturday, February 18, 2012 4:27:02 AM UTC, A. L. wrote:

> Wiec prosze mi tu nie opowiqdac dyrdymolow o "programowaniu parami".
> Takie cos mozliew byloby w zaawansowanym socjalizmie, ale z tym
> systemem dawno sie, mam nadzieje, pozegnalismy.

To ciekawe, bo "pair programming" wymyslono OIMW w USA. I to zanim Obama zostal
prezydentem ;-)

> A jak dwoch bedzie
> pracowac nad tym samym, to na ogol jeden bedzie zasuwal a drugi bedzie
> sie opierdalal.

To macie jakas kiepska atmosfere w zespole.

> Zwlaszca ze parca programisty, jako myslowa, jest
> jednooosobowa.

Bzdura. Wielokrotnie debugowalem kod razem z kims, wymieniajac sie przypuszczeniami,
czemu cos nie dziala. Wielokrotnie rozwazalem z druga osoba najlepszy sposob
zaimplementowania danej funkcjonalnosci.

A juz pomysl, ze "praca myslowa" jest z definicji jednoosobowa, jest zupelnie
smieszny.

RW

do góry

On 17/02/2012 21:55, A.L. wrote:
> Programwoanie w parch to paranoja. Jedyna forma programwoanai w parach
> ktora znam to nie taka ze dwoch pracuje nad tym samym problemem, ale


przypomniał mi się taki przykład: program miał wiele wątków roboczych i
każdy wątek ma własne połączenie TCP do publikacji wyników obliczeń.
Równolegle było wykonywanych paręset "strumieni" obliczeń, praca
zdarzeniowa, żaden wątek nie przypisany do konkretnego "strumienia" a
więc, siłą rzeczy, żaden strumień nie ma własnego połączenia TCP (liczba
wątków i połączeń TCP znacznie mniejsza od liczby "strumieni" obliczeń
to konieczność wynikające z ograniczeń sieci i maszyny). Często nowe
wyniki obliczeń są w odstępach milisekundowych, czasami częsciej.
Połączenia TCP do publikacji wyników są do procesu "multipleksera",
każdy subskrybent ma do niego jedno własne połączenie TCP. No i w
efekcie czasami subskrybenci otrzymują efekty obliczeń dla "strumieni"
którymi są zainteresowani w odwróconej kolejności (dokładnie dlaczego
tak się dzieje, pozostawiam jako ćwiczenie dla czytelnika). Rozwiązanie
proste, zrobić osobną pulę połączeń TCP i przypisać każdy "strumień" do
jednego połączenia w puli.

Żeby rozważyć problem robię sobie sesję chat z kolegą (który pracuje w
Australi) i podajemy swoje rozwiązania. Moje jest bardziej
skomplikowane, bo dodatkowo balansuje ruch w momentach mniejszej
aktywności. Kolegi jest prostsze. Dyskusja 15-30min i już wiemy co robić
(to prostsze, ale z pomiarem kosztu braku balansowania ruchu). Potem ja
programuję, testuję, 2godz później proszę kolegę o przeczytanie patcha
jakieś 50wierszy i szukamy gdzie mogą być błędy (liczenia hasha z "nazwy
strumienia" daje negatywne wartości bo zapomniałem że czasami "char"
jest signed). Później jeszcze jeden drobiazg, proszę zupełnie innego
kolegę o sprawdzenie mojego kodu (bo ten w Australi już śpi). Potem
wszystko jest już w moim ręku, kolega następnego dnia tylko proponuje
drobne poprawki.

Czyli "programowanie parami", ale takie że odległość między
programistami to czasami >16000 km a czasami kilka metrów, programuje
jeden, a tylko początek i zakończenie jest wspólne.

Ja to nazywam "praca zespołowa", ale chyba jestem mało nowoczesny.


B.

do góry

On 18/02/2012 15:55, A.L. wrote:
> On Sat, 18 Feb 2012 09:46:22 +0000, Andrzej Jarzabek
>>
>> Co to ma do rzeczy? Do programowania w parach nie zatrudnia się
>> dodatkowych ludzi.
>>
>
> No to skad sie ich bierze? Zrzucani sa na spadochronach?...

Zazwyczaj jest tak, że jak ktoś planuje produkować jakieś
oprogramowanie, to już ma zatrudnionych programistów. Jeśli nie ma, to i
tak musi ich zatrudnoć, niezależnie od tego, czy będą programować
parami, czy nie.

do góry

On 18/02/2012 15:54, A.L. wrote:
> On Sat, 18 Feb 2012 09:56:00 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>> A w to akurat jestem w stanie uwierzyć, znaczy nie wiem jaki jest A.L. w
>> życiu, ale jeśli jest taki, na jakiego pozuje na grupie, to jak
[...]
>
> Kolega wlasnie awansowal do KF. Przypominam, ze zgodnie z moja
> polityka, do KF sie idzie gdzy zamiast dyskutowac o tym o czym pisze
> merytorycznie dyskutuje sie o chechach mojego charakteru

Do A.L. nie piszę skoro ma mnie w KF, ale ewentualnym zainteresowanym
zwrócę uwagę, że nie pisałem o tym, jaki on jest, tylko o tym, co pisze
na grupie. Faktyczna osobowość dyskutanta jest mi obojętna.

Natomiast ta w ogóle cechy osobowości w temacie "programowanie parami -
wydajne czy marnotrawne" jak najbardziej należą do meritum.

do góry

On 18/02/2012 14:48, wloochacz wrote:
> W dniu 2012-02-18 14:46, Jacek pisze:
>> Ja odnosnie programowania w parach.
>> Jeżeli jest zespół 20 programistów, to oznacza to, że
>> jest 10 par?;)
> I mają tylko 10 komputerów!
> Widzisz, jaka oszczędność! :P
> Coś jak w radzieckim wojsku...

Raczej 30.

do góry

On 18/02/2012 14:12, M.M. wrote:
> Andrzej Jarzabek<a...@g...com> napisał(a):
[...]
> A co gdy programiste powali jakas wredna mutacja grypy? Wtedy drugi
> orientuje sie na tyle dobrze w kodzie pierwszego ze ma jakies sensowne
> szanse na naniesienie poprawki w jego kodzie. Co w sytuacji gdy pracownik
> calkowicie odejdzie z firmy? Wtedy drugi zna kod na tyle ze moze wprowadzic
> szybko inna osobe.

Akurat XP odnosi się do tego bardziej radykalnie, przez "collective code
ownership" (tak, zupełnie jak kolektywy w ZSRR). Pary nie są ustalone, i
oczekuje się, że praktycznie każdy będzie miał orientację w praktycznie
dowolnym kawałku programu.

do góry

On 18/02/2012 13:46, Jacek wrote:
> Ja odnosnie programowania w parach.
> Jeżeli jest zespół 20 programistów, to oznacza to, że
> jest 10 par?;)

To raczej oznacza, że zespół jest za duży.

do góry

Edek Pienkowski <e...@g...com> napisał(a):

> Ja jak już wspomniałem nie programowałem w parach. Ale jakoś nie
> rozumiem: można rozmawiać siedząc obok, często gapimy się w ekran
> patrząc albo na projekt albo na przykład na rezultaty, okazji
> do komunikacji jest mnĂłstwo bez "programowania w parach".
No pewnie ze jest, ale do komunikacji musi byc przynajmniej para osob :D

> CZy
> dobrze rozumiem, Ĺźe programowanie w parach oznacza samo
> klepanie kodu w parach? Tego nie rozumiem, jeżeli się rozmawia
> o kodzie, robi review, planuje itd. to samo pisanie kodu jest
> czynnością raczej nudną i dość mechaniczną.
Dwie osoby stanowia juz maly zespol, czasami zadania sa tak latwe,
ze angazowanie do nich wiecej niz jednej osoby nie ma sensu. Ale
programowanie nawet prostych rzeczy nie nalezy do latwych zadan.
Wielokrotnie kumple mnie uratowal przed strata czasu, a ja kumpla,
nawet w stosunkowo latwych zadaniach.

Nie wiem juz... moze to ja zle rozumiem okreslenie programowania w
parach. Na pewno nie chce powiedziec zeby dwie sprzataczki zamiataly
jedna miotla. Chodzi o przydzial wiekszego pod-zadania dla dwoch-trzech
osob a w szczegolach one same dziela sie praca miedzy soba, pomagaja
sobie i kontroluja siebie na wzajem. Jesli jednak zadanie okazuje za proste
albo niewygodne na dwie-trzy osoby to wykonuje je jedna osoba a pozostale
zajmuja sie nastepnym zadaniem. Przeciez nie trzeba sie zmuszac do pracy w
parach jesli w danym zadaniu jest to bez sensu.

Do tego czasami pojawiaja sie wzgledy bezpieczenstwa, albo/i wysokich
kosztow jakie powoduja pomylki. Nawet jesli praca w parach podnosi
koszty pracy o 100% a efektywnosc zwieksza tylko o 5%, to moze zapobiec
kosztownym pomylkom i ostatecznie moze sie oplacac - dokladnie przy
czyms takim pracowalem. Gdy system zaczal tluc szyby, wybijac zeby i
przelewac pieniadze nie na to konto to praca w pojedynke byla
wrecz niemozliwa. Musialy sie dwie osoby zastanawiac nad kazda linia kodu.


Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 19/02/2012 09:26, M.M. wrote:
>
> Nie wiem juz... moze to ja zle rozumiem okreslenie programowania w
> parach. Na pewno nie chce powiedziec zeby dwie sprzataczki zamiataly
> jedna miotla. Chodzi o przydzial wiekszego pod-zadania dla dwoch-trzech
> osob a w szczegolach one same dziela sie praca miedzy soba, pomagaja
> sobie i kontroluja siebie na wzajem. Jesli jednak zadanie okazuje za proste
> albo niewygodne na dwie-trzy osoby to wykonuje je jedna osoba a pozostale
> zajmuja sie nastepnym zadaniem. Przeciez nie trzeba sie zmuszac do pracy w
> parach jesli w danym zadaniu jest to bez sensu.

XP zaleca faktyczną pracę parami przynajmniej przy tworzeniu kodu
produkcyjnego. Nie tak, jak piszesz, tylko bez rozdzielania się,
faktycznie pracując przy jednym stanowisku.

Porównanie ze sprzątaczkami to idiotyzm.

> Do tego czasami pojawiaja sie wzgledy bezpieczenstwa, albo/i wysokich
> kosztow jakie powoduja pomylki. Nawet jesli praca w parach podnosi
> koszty pracy o 100% a efektywnosc zwieksza tylko o 5%, to moze zapobiec
> kosztownym pomylkom i ostatecznie moze sie oplacac - dokladnie przy
> czyms takim pracowalem. Gdy system zaczal tluc szyby, wybijac zeby i
> przelewac pieniadze nie na to konto to praca w pojedynke byla
> wrecz niemozliwa. Musialy sie dwie osoby zastanawiac nad kazda linia kodu.

Na pewno jednak też zdajesz sobie sprawę, że niezależnie od strat
spowodowanych w produkcji, znajodwanie i naprawianie błędów w programach
jest nieproporcjonalnie bardziej prachochłonne niż pisanie nowego kodu.

do góry

On 18/02/2012 20:53, Bronek Kozicki wrote:
> On 17/02/2012 21:55, A.L. wrote:
>
> przypomniał mi się taki przykład: program miał wiele wątków roboczych i
[...]
> Ja to nazywam "praca zespołowa", ale chyba jestem mało nowoczesny.

Teoria jest taka, że komunikacja twarzą w twarz jest bardziej efektywna.
Pewnie to zależy od osoby, ale np. w moim przypadku to się sprawdza - a
niestety ostatnio głównie komunikuję się w pracy przez chata i maila.

Druga sprawa jest taka, że to, co opisujesz jest tylko możliwe wtedy,
kiedy masz innych członków zespołu pracujących nad tym samym, co ty. A
to ma te same wady, które są przypisywane programowaniu parami.

do góry