Wątek przeniesiony 2023-06-27 16:10 z Off-Topic przez Riddle.
somekind napisał(a):
Pair-programming nie stosuje się do naparzania kodu, który wie się jak napisać, tylko do znajdowania rozwiązań, przy których w pojedynkę ślęczałoby się godzinami. Druga osoba nie ma tu czego spowolnić.
XDDD chyba w zdroworosądkowym podejściu a nie gdy rozmawia się o tym z wyznawcami, którzy stosują ja codziennie i tak zalecają
anonimowy napisał(a):
XDDD chyba w zdroworosądkowym podejściu a nie gdy rozmawia się o tym z wyznawcami, którzy stosują ja codziennie i tak zalecają
Jakimi wyznawcami?
Jakie codziennie?
Kto tak zaleca?
Konkrety, bo mam wrażenie, że zamiast pisać na temat, to opisujesz jakieś swoje wyobrażenie tematu. A z tym, to się już rozprawił @Riddle wcześniej.
@somekind: Sam sobie zaprzeczasz.
Najpierw piszesz:
somekind napisał(a):
Jakimi wyznawcami?
Jakie codziennie?
Kto tak zaleca?
a potem piszesz
Konkrety, bo mam wrażenie, że zamiast pisać na temat, to opisujesz jakieś swoje wyobrażenie tematu. A z tym, to się już rozprawił @Riddle wcześniej.
Powołując się na Riddle, który jako pierwszy post w tym temacie napisał:
Riddle napisał(a):
Ja tak pracuję praktycznie codziennie, czasem nawet w trzy osoby.
Nie, nie zaprzeczam sobie. Powołałem się na treść konkretnego postu jakiejś osoby, a nie na jej pierwszy post w tym temacie, w tym roku, czy w ogóle na forum.
Zadałem proste pytania, ale skoro zamiast na nie odpowiedzieć kluczysz, to widzę, że nie masz za bardzo nic sensownego do powiedzenia w temacie.
Tylko że nie jest wystarczające aby dowozili szybciej niż pojedynczy programista. Aby ten model był opłacalny ekonomicznie to muszą dowozić co najmniej 2x szybciej, bo masz zaangażowane 2x więcej osób (albo inaczej - 2x mniej zadań równoległych przy tej samej liczbie osób). I jestem na 99% przekonany że nie dowożą szybciej niż dwóch programistów pracujących nad dwoma problemami niezależnie.
Jeśli kod piszą dwie osoby, to można od razu mergować taki kod, bo nie ma potrzeby na code review. Robiliśmy na początku PR'y, ale nikt nigdy na nich nic nie znajdował, więc uznaliśmy że gra nie warta świeczki - od razu można mergować.
A to akurat właśnie nie działa, bo dwie osoby piszące razem kod będą dobrze znały wspólny kontekst i nie zauważą np. że kod jest niezrozumiały dla kogoś z zewnątrz. Bardzo wielką zaletą CR jest możliwość pokazania kodu komuś kto go właśnie wcześniej nie widział i musi się zmierzyć z całością od razu, bez całego wcześniejszego kontekstu. Jeżeli to idzie gładko, znaczy że kod jest dobry.
W prawdziwej pracy nigdy nie korzystałem, bo nie było potrzeby / okazji. Natomiast w przypadku rekrutacji dosyć często do PP dochodziło i wspominam to dobrze - Ot takie "zczelendżowanie" na żywym organizmie :)
Krolik napisał(a):
Tylko że nie jest wystarczające aby dowozili szybciej niż pojedynczy programista. Aby ten model był opłacalny ekonomicznie to muszą dowozić co najmniej 2x szybciej, bo masz zaangażowane 2x więcej osób (albo inaczej - 2x mniej zadań równoległych przy tej samej liczbie osób). I jestem na 99% przekonany że nie dowożą szybciej niż dwóch programistów pracujących nad dwoma problemami niezależnie.
Tutaj są trzy błędy które widzę.
Po pierwsze, wychodzisz z założenia (jak już wielu przed Tobą), że proces programowania to jest po prostu "wytwarzanie linijek". Ale nagraj się kiedyś jak pracujesz przez 8h, to zobaczysz ile czasu schodzi na faktyczne pisanie i dostarczanie linijek, ile na debugowanie, ile na wymyślanie rozwiązań, ile na testowanie, ile na wymyślenie modelu, etc. Przy czym weź pod uwagę, że czasem rozwiązuje się problemy w aplikacji, które zajmują kilka dni żeby je znaleźć, a po sesji debugowania okazuje się że bugfix tego to jest np jedna linijka - w odpowiednim miejscu - tylko że znalezienie tego miejsca, i wydedukowanie że to jest najlepsze miejsce na naprawę tego buga, to jest 99% wysiłku poświęcone na jego naprawę.
Drugi błąd, to jest to że "dowiezienie więcej rzeczy" == "lepiej". Przy czym Agile uczy nas że czasem możesz dowieść więcej rzeczy, które są mniej wartościowe. Jeśli pracujesz w dwie osoby, praktycznie zawsze problem jest zrozumiany lepiej, z szerszej perspektywy, więc nawet jeśli objętościowo linijek i feater'ów jest dowiezionych mniej, to nadal one z reguły są lepiej dopasowane do wymagań klienta i product ownera. Jest oczywiście sytuacja gdzie takie coś nie ma sensu - i to by było w sytuacji w której masz perfekcyjną wiedzę o oprogramowaniu, kliencie i feature'ze który chcesz napisać - kiedy nie potrzebujesz żadnych analiz, gadać z nikim, nie potrzebujesz nic wymyślić - tylko piszesz, że tak powiem "na pałę". Wtedy faktycznie pair programming nie ma sensu, i można to zrobić samemu (jakbyś robił jakiś trywialny program). Tylko że z mojego doświadczenia wynika że w dużych aplikacjach tak praktycznie nigdy nie jest, zawsze te rzeczy są skomplikowane.
No bo czym jest Pair Programming w gruncie rzeczy - to jest rozłożenie odpowiedzialności za dostarczenie funkcjonalności na więcej osób niż jedną, w celu zwiększenia jakości, dopasowania, stopnia przetestowania, zmniejszenia ilości błędów podczas developowania.
I po trzecie, kolejne błędne przekonanie jest takie że nad jednym taskiem pracuja zawsze dwie osoby i tylko dwie osoby. Podczas gdy w pair programming z prawdziwego zdarzenia ludzie zmieniają pary w trakcie taska, więc czasem na jednym zadaniem/funkcjonalnością pracują 3-4 osoby. Jeśli jeden task zajmie powiedzmy 5 dni na dostarczenie, to nie ma żadnego powodu żeby każdego z tych 5 dni nie pairować się z kimś innym.
Natomiast co do Aby ten model był opłacalny ekonomicznie to muszą dowozić co najmniej 2x, to weź pod uwagę, że często funkcjonalności dostarczane z PP są dużo wyższej klasy, niż przez kogoś dostarczonego w pojedynkę - takie funkcjonalności będą dostarczały mniej bugów, oraz będą łatwiejsze do zmiany w przyszłości. Więc nawet jeśli ktoś w PP dostarczałby powiedzmy z prędkością x1.8, to nadal to się opłaca, jeśli wytworzony w ten sposób kod oszczędzi późniejszych tasków na pracę z nimi.
No i jeszcze kolejny argument - jeśli pracujemy w dwie osoby, to skupiamy woje uwagi na kod nawzajem. Czasem dochodzi do sytuacji że jednej osobie jest się łatwiej rozkojarzyć, uciec na poboczne tory, etc. Nie mówię tutaj oczywiście o oglądaniu YouTube'a, tylko czasem jest sytuacja w której ktoś naprawia buga lub próbuje zrobić feature, i zaczyna go robić w nieodpowiedni sposób i zajmie mu powiedzmy 20 minut żeby się zorientować że to jest zła droga. Może też szukać jakiejś informacji gdzieś w wiki lub gdzieś w historii przez 20 minut - obecność drugiej osoby, która ma takie info od razu skraca ten czas.
Krolik napisał(a):
I jestem na 99% przekonany że nie dowożą szybciej niż dwóch programistów pracujących nad dwoma problemami niezależnie.
Szybciej może nie.
Powiedziałbym że tak samo szybko, albo delikatnie wolniej (rzędu 4-8%).
Tylko czy oznacza to od razu że skoro dwie osoby na raz oddadzą task 4-8% wolniej, to oznacza to od razu że to jest nieopłacalne? Moim zdaniem nie, bo:
za 3h", to dwie osoby na raz są w stanie to dostarczyć, jedna niekoniecznie.Krolik napisał(a):
A to akurat właśnie nie działa, bo dwie osoby piszące razem kod będą dobrze znały wspólny kontekst i nie zauważą np. że kod jest niezrozumiały dla kogoś z zewnątrz. Bardzo wielką zaletą CR jest możliwość pokazania kodu komuś kto go właśnie wcześniej nie widział i musi się zmierzyć z całością od razu, bez całego wcześniejszego kontekstu. Jeżeli to idzie gładko, znaczy że kod jest dobry.
Już mówiłem - nic nie stoi na przeszkodzie żeby zmieniać się podczas taska, tak żeby więcej osób mogło popracować nad zadaniem.
Poza tym - ja tylko powiedziałem że my w zespole nie robimy Code Review, bo uznaliśmy to za zbędne. Jeśli Ty masz ochotę, to nikt Ci nie broni spędzić dnia z kimś na Pair Programming, a potem i tak oddać taki task do Review, droga wolna, be must guest! :> Ja tylko mówię, że my uznaliśmy że to nic dodatkowego nie wnosi i z tego zrezygnowaliśmy, ale jeśli Ty nie chcesz to nie musisz.
Czym innym jest współpraca w celu rozwiązania problemu, a czym innym siedzenie obok siebie i korzystanie z tej samej klawiatury i komputera. Mam głębokie przekonanie, że coś takiego nie ma prawie nigdy sensu i jest niekomfortowowe.
gajusz800 napisał(a):
Czym innym jest współpraca w celu rozwiązania problemu, a czym innym siedzenie obok siebie i korzystanie z tej samej klawiatury i komputera. Mam głębokie przekonanie, że coś takiego nie ma prawie nigdy sensu i jest niekomfortowowe.
Czyli punkt #2 z mojej wypowiedzi wyżej - nigdy tego nie próbowałeś, ale narzekasz.
Po pierwsze, wychodzisz z założenia (jak już wielu przed Tobą), że proces programowania to jest po prostu "wytwarzanie linijek". Ale nagraj się kiedyś jak pracujesz przez 8h, to zobaczysz ile czasu schodzi na faktyczne pisanie i dostarczanie linijek, ile na debugowanie, ile na wymyślanie rozwiązań, ile na testowanie, ile na wymyślenie modelu, etc.
Ale co to ma do rzeczy? Nie, wcale nie zakładam, że to jest wytwarzanie linijek.
Mogę dać dwóm osobom osobne zadania - jedna np. robi nowego ficzera w komponencie A, a druga poprawia błąd w komponencie B. I to nie jest ważne, że tej pracy każda z tych osób poświęci 50%-90% czasu na inne rzeczy niż kodowanie, bo te pozostałe rzeczy też robią niezależnie równolegle i nie wchodzą sobie w drogę. Nawet w skrajnym przypadku, gdzie prawie niczego nie trzeba kodować, dajmy na to, obie osoby poprawiają każda innego buga, to nadal każda może robić swoją analizę swojego buga niezależnie i debugować w innym miejscu. Tymczasem dwie osoby pracujące nad jednym bugiem być może znajdą go szybciej niż jedna osoba jednego buga, ale nie jestem przekonany, czy znajdą i poprawią go w połowie czasu, tak aby starczyło jeszcze drugie 50% czasu na poprawienie drugiego.
Większość badań nad pair programming własnie robi tn błąd - porównuje do wydajności pojedynczego programisty, zamiast porównywać do wydajności pary programistów pracujących niezależnie od siebie.
Drugi błąd, to jest to że "dowiezienie więcej rzeczy" == "lepiej"
Jeśli pracujesz w dwie osoby, praktycznie zawsze problem jest zrozumiany lepiej, z szerszej perspektywy, więc nawet jeśli objętościowo linijek i feater'ów jest dowiezionych mniej, to nadal one z reguły są lepiej dopasowane do wymagań klienta i product ownera.
Od tego jest CR plus komunikacja asynchroniczna i krótkie spotkania na skonsultowanie pewnych rzeczy jeśli zachodzi potrzeba.
To jest efektywniejsze, bo maksymalizuje zyski ze wspólnej wiedzy i obgadania pewnych spraw, ale nie wprowadza opóźnień.
Po drugie, jak już mówiłem, wytworzony w ten sposób kod jest wyższej jakości i jest tańszy do utrzymania na dłuższą metę, nie mówiąc o tym że funkcjonalność często jest lepsza i ma mniej bugów.
Są skuteczniejsze sposoby zapewniania lepszej jakości kodu, bez konieczności angażowania drugiej osoby na 100% czasu taska. Dobry język ze statycznym typowaniem, autoformatowanie + checksstyle + analiza statyczna, code review, testy. Innymi słowy - pair programming, ale drugą osobą w parze jest maszyna.
Poza tym podkreślasz tylko zalety, ale pomijasz koszty.
W przypadku klasycznej sesji pair programming, gdzie jedna osoba "wymyśla" a druga pisze, schodzi masę dodatkowego czasu na komunikację. Dodatkowo zawsze traci się trochę czasu na to, że jeden czeka na drugiego. Nie ma cudów, nie da się zrobić tak że obajw cały czas coś robią. Tak samo nie zawsze są idealnie zgodni i zawsze trochę czasu pójdzie na dyskusje. Dlatego Twoje 1.8x jest IMHO mocno naciągane. Z mojego doświadczenia para programistów dowozi czasem minimalnie szybciej niż pojedynczy programista konsultujący się z innymi w ramach potrzeby i zwykle dostarcza nieco wyższej jakości rozwiązania niż przeciętny programista, ale im masz lepszych programistów tym efekt parowania jest mniejszy - bo najczęściej obie osoby w parze są zgodne i tylko się nawzajem utwierdzają w swoich rozwiązaniach. Czyli masz klasyczne: nieco wyższa jakość kosztem niemal 2x niższej produktywności. Ponieważ jakość można jednak osiągnąć bez tak drastycnzego obniżania produktywności innymi sposobami, to nie jestem przekonany do stosowania tej metody. I prawdopodobnie dlatego nie spopularyzowała się ona praktycznie nigdzie.
Krolik napisał(a):
Po pierwsze, wychodzisz z założenia (jak już wielu przed Tobą), że proces programowania to jest po prostu "wytwarzanie linijek". Ale nagraj się kiedyś jak pracujesz przez 8h, to zobaczysz ile czasu schodzi na faktyczne pisanie i dostarczanie linijek, ile na debugowanie, ile na wymyślanie rozwiązań, ile na testowanie, ile na wymyślenie modelu, etc.
Ale co to ma do rzeczy? Nie, wcale nie zakładam, że to jest wytwarzanie linijek.
Mogę dać dwóm osobom osobne zadania - jedna np. robi nowego ficzera w komponencie A, a druga poprawia błąd w komponencie B. I to nie jest ważne, że tej pracy każda z tych osób poświęci 50%-90% czasu na inne rzeczy niż kodowanie, bo te pozostałe rzeczy też robią niezależnie równolegle i nie wchodzą sobie w drogę. Nawet w skrajnym przypadku, gdzie prawie niczego nie trzeba kodować, dajmy na to, obie osoby poprawiają każda innego buga, to nadal każda może robić swoją analizę swojego buga niezależnie i debugować w innym miejscu. Tymczasem dwie osoby pracujące nad jednym bugiem być może znajdą go szybciej niż jedna osoba jednego buga, ale nie jestem przekonany, czy znajdą i poprawią go w połowie czasu, tak aby starczyło jeszcze drugie 50% czasu na poprawienie drugiego.
Większość badań nad pair programming własnie robi tn błąd - porównuje do wydajności pojedynczego programisty, zamiast porównywać do wydajności pary programistów pracujących niezależnie od siebie.Drugi błąd, to jest to że "dowiezienie więcej rzeczy" == "lepiej"
Jeśli pracujesz w dwie osoby, praktycznie zawsze problem jest zrozumiany lepiej, z szerszej perspektywy, więc nawet jeśli objętościowo linijek i feater'ów jest dowiezionych mniej, to nadal one z reguły są lepiej dopasowane do wymagań klienta i product ownera.Od tego jest CR plus komunikacja asynchroniczna i krótkie spotkania na skonsultowanie pewnych rzeczy jeśli zachodzi potrzeba.
To jest efektywniejsze, bo maksymalizuje zyski ze wspólnej wiedzy i obgadania pewnych spraw, ale nie wprowadza opóźnień.Po drugie, jak już mówiłem, wytworzony w ten sposób kod jest wyższej jakości i jest tańszy do utrzymania na dłuższą metę, nie mówiąc o tym że funkcjonalność często jest lepsza i ma mniej bugów.
Są skuteczniejsze sposoby zapewniania lepszej jakości kodu, bez konieczności angażowania drugiej osoby na 100% czasu taska. Dobry język ze statycznym typowaniem, autoformatowanie + checksstyle + analiza statyczna, code review, testy. Innymi słowy - pair programming, ale drugą osobą w parze jest maszyna.
Poza tym podkreślasz tylko zalety, ale pomijasz koszty.
W przypadku klasycznej sesji pair programming, gdzie jedna osoba "wymyśla" a druga pisze, schodzi masę dodatkowego czasu na komunikację. Dodatkowo zawsze traci się trochę czasu na to, że jeden czeka na drugiego. Nie ma cudów, nie da się zrobić tak że obajw cały czas coś robią. Tak samo nie zawsze są idealnie zgodni i zawsze trochę czasu pójdzie na dyskusje. Dlatego Twoje 1.8x jest IMHO mocno naciągane. Z mojego doświadczenia para programistów dowozi czasem minimalnie szybciej niż pojedynczy programista konsultujący się z innymi w ramach potrzeby i zwykle dostarcza nieco wyższej jakości rozwiązania niż przeciętny programista, ale im masz lepszych programistów tym efekt parowania jest mniejszy - bo najczęściej obie osoby w parze są zgodne i tylko się nawzajem utwierdzają w swoich rozwiązaniach. Czyli masz klasyczne: nieco wyższa jakość kosztem niemal 2x niższej produktywności. Ponieważ jakość można jednak osiągnąć bez tak drastycnzego obniżania produktywności innymi sposobami, to nie jestem przekonany do stosowania tej metody. I prawdopodobnie dlatego nie spopularyzowała się ona praktycznie nigdzie.
Napisałem Ci przecież:
Riddle napisał(a):
- Po piąte - jakoś nie słyszę od ludzi z góry że mój zespół jest wolniejszy, mimo że jesteśmy jedynym w firmie który stosuje PP.
Poza tym, o czym my w ogóle gadamy. Widać że nigdy nie praktykowałeś takiego podejścia, więc czemu to co piszesz miałoby być wiarygodne? To są Twoje domysły. Ja tak pracuję od kilku lat w zespole, więc wiem o czym mówie.
Riddle napisał(a):
Na pewno każdy z was miał sytuację że czasem PR/MR'y siedziały godziny jak nie dni w review, zwłaszcza takie które miały wiele iteracji.
Masz złe przeświadczenie jak działają review. Wynika to pewnie z nie wiedzy jak może to wyglądąć:
Riddle napisał(a):
gajusz800 napisał(a):
Czym innym jest współpraca w celu rozwiązania problemu, a czym innym siedzenie obok siebie i korzystanie z tej samej klawiatury i komputera. Mam głębokie przekonanie, że coś takiego nie ma prawie nigdy sensu i jest niekomfortowowe.
Czyli punkt #2 z mojej wypowiedzi wyżej - nigdy tego nie próbowałeś, ale narzekasz.
No i nie zamierzam, nie wyobrażam sobie żeby jakiś kaczan pisał ze mną na klawiaturze na 4 ręce. Mogę współpracować z innymi, ale to już nie dla mnie. Może być jeszcze iść razem do kibla posiedzieć na jednej muszli, mniej więcej to samo
Większość zadań mogłem zrobić 10-50 razy szybciej niż ta osoba, ale wybrałem tą wolniejszą wersję i ten czas wykorzystałem na dyskusje, obserwacje, wspólną ocenę kodu.
Tego typu sesje cyklicznie wyrzucały na brzeg wartościowe pytania do przemyślenia, chociaż w sumie łatwo je zlekceważyć. U mnie to było jedno z większych doświadczeń/wydarzeń pod kątem rozwoju na przestrzeni ostatnich 2 lat i w połączeniu z pobocznymi akcjami jakie miały wtedy miejsce zmieniłem diametralnie sposób w jaki programuję więc warto, ale nie każdy do tego się nadaje i nie każdy czerpie z tego wartość.
Jest oczywiście sytuacja gdzie takie coś nie ma sensu - i to by było w sytuacji w której masz perfekcyjną wiedzę o oprogramowaniu, kliencie i feature'ze który chcesz napisać - kiedy nie potrzebujesz żadnych analiz, gadać z nikim, nie potrzebujesz nic wymyślić - tylko piszesz, że tak powiem "na pałę". Wtedy faktycznie pair programming nie ma sensu, i można to zrobić samemu (jakbyś robił jakiś trywialny program). Tylko że z mojego doświadczenia wynika że w dużych aplikacjach tak praktycznie nigdy nie jest, zawsze te rzeczy są skomplikowane.
Założenie że jakikolwiek zysk np. programista A przekazał jakąś ciekawostką programiście B usprawiedliwia każdy spędzony czas
nie jest poprawny.
I po trzecie, kolejne błędne przekonanie jest takie że nad jednym taskiem pracuja zawsze dwie osoby i tylko dwie osoby. Podczas gdy w pair programming z prawdziwego zdarzenia ludzie zmieniają pary w trakcie taska, więc czasem na jednym zadaniem/funkcjonalnością pracują 3-4 osoby. Jeśli jeden task zajmie powiedzmy 5 dni na dostarczenie, to nie ma żadnego powodu żeby każdego z tych 5 dni nie pairować się z kimś innym.
o cholera!
to już nie angażuje się tylko dwóch osób, a jeszcze na złożonego taska na 5dni trzeba dodać dodatkowy narzut context-switchu dla aż 4! :D
Już samo programowanie w przerwach pomiędzy spotkaniami jest upierdliwe, a tu jeszcze trzeba w połowie taska przesiąść się do innego i w niego wdrożyć?
I jeszcze to w jakiś magiczny sposób wychodzi +- tak samo wydajnie?!
Natomiast co do Aby ten model był opłacalny ekonomicznie to muszą dowozić co najmniej 2x, to weź pod uwagę, że często funkcjonalności dostarczane z PP są dużo wyższej klasy, niż przez kogoś dostarczonego w pojedynkę - takie funkcjonalności będą dostarczały mniej bugów, oraz będą łatwiejsze do zmiany w przyszłości. Więc nawet jeśli ktoś w PP dostarczałby powiedzmy z prędkością x1.8, to nadal to się opłaca, jeśli wytworzony w ten sposób kod oszczędzi późniejszych tasków na pracę z nimi.
Pokaż obliczenia na prawdziwym projekcie i jak wykonujesz pomiary.
Duży % kodu jaki widziałem był pisany raz i nie było potrzeby aby go dotykać.
Może też szukać jakiejś informacji gdzieś w wiki lub gdzieś w historii przez 20 minut - obecność drugiej osoby, która ma takie info od razu skraca ten czas.
Do tego nie trzeba PP.
Jeśli przyjdzie PO i powie "ja chce mieć to na za 3h", to dwie osoby na raz są w stanie to dostarczyć, jedna niekoniecznie.
"ja chce mieć to na za 3h" bez komentarza, gdzie takie rzeczy się dzieją? w firmie która ma 2 programistów i jednego klienta który odpowiada za 100% zleceń?
Po drugie, jak już mówiłem, wytworzony w ten sposób kod jest wyższej jakości i jest tańszy do utrzymania na dłuższą metę, nie mówiąc o tym że funkcjonalność często jest lepsza i ma mniej bugów.
tańszy, często lepszy, ma mniej bugów
a gdzie na to dane?
Po trzecie, my w ten sposób oszczędzamy na code review - co jest dużym zyskiem czasu, więc dla nas to jest opłacalne. Na pewno każdy z was miał sytuację że czasem PR/MR'y siedziały godziny jak nie dni w review, zwłaszcza takie które miały wiele iteracji.
o tym pod jakim względem CR jest lepsze niż to co ty proponujesz (PP+Fast merge) już pisał @Krolik
Po piąte - jakoś nie słyszę od ludzi z góry że mój zespół jest wolniejszy, mimo że jesteśmy jedynym w firmie który stosuje PP.
Jest jeszcze tylko tak pewnie plus minus tysiąc innych czynników mogących mieć na to wpływ.
WeiXiao napisał(a):
Duży % kodu jaki widziałem był pisany raz i nie było potrzeby aby go dotykać.
Jest bardzo dużo kodu, który latami się nie zmienia, nikt nie musi analizować, zaglącać, testy się na nim nie sypią - po prostu działa.
Taki kod zwykle określam jako martwy/zombie.
pierdu pierdu, fajnie się takie rzeczy na 4p piszę, ale czy rzeczywistość to odzwierciedla?
nawet w projekcie mającym tak wielu maintainerów jak kernel, w którym pewnie nie raz, nie dwa przekopuje się jakieś featuresy aby ugrać trochę wydajności, security czy chociażby zaktualizować jakieś komentarze/meta dane
w kilkanaście sekund ręcznie z gh ui znajdujesz kod który od np. 4 lat nie był zmieniany
https://github.com/torvalds/linux/blob/master/kernel/iomem.c Jul 12, 2019
https://github.com/torvalds/linux/blob/master/security/inode.c Jul 19, 2019
https://github.com/torvalds/linux/blob/master/crypto/cbc.c on Dec 11, 2020
https://github.com/torvalds/linux/blob/master/crypto/crct10dif_common.c on Sep 12, 2013
a teraz, weź to przełóż na jakiś pierwszy lepszy webowy projekt - co tam chcesz zmieniać? klient dostał wersję i zadowolony, raz na pół roku poprosi o nowy feature
WeiXiao napisał(a):
pierdu pierdu, fajnie się takie rzeczy na 4p piszę, ale czy rzeczywistość to odzwierciedla?
nawet w projekcie mającym tak wielu maintainerów jak kernel, w którym pewnie nie raz, nie dwa przekopuje się jakieś featuresy aby ugrać trochę wydajności, security czy chociażby zaktualizować jakieś komentarze/meta dane
w kilkanaście sekund ręcznie z gh ui znajdujesz kod który od np. 4 lat nie był zmieniany
I to na pewno kod w który nikt nie zagląda, nie próbuje zrozumieć, nie analizuje wydajności - bo to jakiś podrzędny OS - niegdzie nie stosowany.
(Pisałem o tym, ale wiadomo czytanie jest niepopularne).
a teraz, weź to przełóż na jakiś pierwszy lepszy webowy projekt - co tam chcesz zmieniać? klient dostał wersję i zadowolony, raz na pół roku poprosi o nowy feature
Zrobiłem troche takich projektów, czasem nawet klient nie prosi o żaden feature - i dlatego wiem, że takie projekty (albo moduły w projektach) są zasadniczo martwe.
Oczywiście, że mocno uogólniam - gdzieś tam pewnie jest doskonały kawałek kodu, który działa i nikt nigdy nie musi do niego zaglądać (wydajność, debug itp), ale to raczej wyjątki.
I to na pewno kod w który nikt nie zagląda, nie próbuje zrozumieć, nie analizuje wydajności - bo to jakiś podrzędny OS - niegdzie nie stosowany.
nie rozumiem - sugerujesz że osiągnięcie w/w (czytelność/wydajność etc) wymaga niekończącego się refaktora?
Zrobiłem troche takich projektów, czasem nawet klient nie prosi o żaden feature - i dlatego wiem, że takie projekty (albo moduły w projektach) są zasadniczo martwe.
Jeżeli ma userów to nie jest martwy.
W temacie: tak stosowałem, nie mam pojęcia czy "poprawnie". Wariant pierwszy - byłem czegoś uczony, lub uczyłem kogoś. Wyjątkowo efektywna metoda nauki. Wariant drugi, pisanie kodu "produkcyjnego" - w cholerę męczące, bo wymaga utrzymania koncentracji przez dłuższy czas i ciężko tego nie robić, ale też efektywne, bo 2 skoncentrowane na pracy osoby "tworzą kod" dużo szybciej, a dobre code review też zajmuje czas, więc chociażby na tym etapie ta osoba nie przy klawiaturze coś robi. Do tego na plus, że te uwagi są zgłaszane na bieżąco, więc poprawki są dużo szybsze + mniejsza szansa na przepalenie pół dnia i wywalenie całego PR'a. Lubię w ten sposób pisać, chociaż wkurza mnie traktowanie pair programming jak religii, ale ogólnie nie przepadam za "programistycznym voo doo
Co do fascynującej dyskusji o martwym i żywym kodzie, to faktu, że kod w przyszłości nie będzie zmieniany, nie wiemy w momencie jego pisania, więc jest to trochę bezprzedmiotowe, szczególnie, że napisanie dobrze, wcale nie jest wolniejsze od napisania źle, a już na 1000% nie jest wolniejsze od napisania źle 5 razy, żeby w końcu napisać dobrze.
napisanie dobrze, wcale nie jest wolniejsze od napisania źle
prawie zawsze jest, wynika to wręcz z fundamentalnych praw.
np. możesz napisać kod z pominięciem obsługi błędów - pliki zawsze są, sieć nigdy nie rzuca timeoutami, etc, etc. no i jasne, zazwyczaj zadziała i napiszesz to szybciej, ale jest źle napisane.
@WeiXiao: No bez jaj, kod albo działa, albo nie działa. Jak czasami nie działa, to nie działa. Równie dobrze możesz to rozciągnąć też na nie napisanie kodu - do momentu kiedy nikt nie kliknie guzika, to wszystko jest przecież w porządku.
no to nadal - pohakowanie ifem vs. jakaś większa zmiana w designie?
Przecież to jest wręcz definicja technologicznej inwestycji ;) (tech debt)
In software development, or any other IT field (e.g., Infrastructure, Networking, etc.) technical debt (also known as design debt[1] or code debt) is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time
WeiXiao napisał(a):
napisanie dobrze, wcale nie jest wolniejsze od napisania źle
prawie zawsze jest, wynika to wręcz z fundamentalnych praw.
np. możesz napisać kod z pominięciem obsługi błędów - pliki zawsze są, sieć nigdy nie rzuca timeoutami, etc, etc. no i jasne, zazwyczaj zadziała i napiszesz to szybciej, ale jest źle napisane.
piotrpo napisał(a):
@WeiXiao: No bez jaj, kod albo działa, albo nie działa. Jak czasami nie działa, to nie działa. Równie dobrze możesz to rozciągnąć też na nie napisanie kodu - do momentu kiedy nikt nie kliknie guzika, to wszystko jest przecież w porządku.
Różnicie się definicjami.
Czym innym jest błąd, jest, siedzi w kodzie - czym innym okolicznosć która go ujawnia, albo rzeczownik "ujawnienie się błędu" / "awaria", co w konsekwencji myslowej oznacza, że "błąd" na wieki może pozostawać nieujawniony w postaci "awarii".
Kto dłubał w C, ten wie.
"Hakowanie if'em", to zwykle skutek tego, że wcześniej ktoś "pisał na szybko". Zwykle też wraca z testów i zostaje tam dopisany kolejny if, a później kolejny, bo te haki tylko wydają się rozwiązywać problem i jedynie wydają się być szybkim rozwiązaniem.
Jakiś czas temu miałem okazję oglądać, na szczęście z bezpiecznej odległości, jak aplikacja, której rolą jest pobrać pliki i je wyświetlić wracała kilka razy od klienta, była ponownie ifowana itd. Jej podstawowymi problemami był burdel w kodzie i jak to napisał @AnyKtokolwiek "nie ujawnione błędy" typu wycieki pamięci. Pomimo swojej trywialności ma sporo klientów i spore przychody, ale też iluś tam użytkowników powodowało, że nieujawnione błędy stawały się ujawnione. Pracy przy tym ifowaniu, przepychaniu przez testy itd. spokojnie wystarczyłoby na głębsze spojrzenie w bebechy i ich poprawienie, ale nie wiedzieć czemu wybierano "quick fix", ostatecznie trafiono z tym ifem, ale koszty takiego niedbałego developmentu były wielokrotnie wyższe niż napisania raz a dobrze.
Prawdopodobnie istnieją jakieś krańcowe przypadki, w których "hak" faktycznie się opłaci. Ale jest to rzadkość.
Mi się zdarzyło najczęściej na różnych hackathonach. Albo mi się skrajnie podobało albo nie podobało - rzadko pomiędzy. Najczęściej ma to sens jak jedna osoba ma pomysł a druga zna konkretną technologię.
Jakieś pół roku temu dołączyłem do globalnego korpo. Automatyzujemy różne tematy w ich chmurze. Od początku jestem na pair programmingu z włochem. Na początku grzaliśmy ile się dało. W pewnym momencie zdaliśmy sobie sprawę, że tak się nie da bo się zajedziemy. Rozmawialiśmy z naszymi melażerami, że potrzebujemy aby delivery odbywało się w zespole scrumowym bo na to co powstało można rzucić spokojnie ludzi. Panom w gangach się nasz pomysł nie podoba więc każą nam dalej cisnąć w takiej formie do kolejnego kwartału. Wraz z kolegą z europy południowej nauczyliśmy się wymyślać różne problemy które sprawiają, że robota nie idzie tak szybko jak mogłaby. Białe kołnierzyki kupują ściemę.
Miang napisał(a):
a konkretnie jakie zalety? ja widzę same wady
Musisz użyć intuicji...