Temat: Code review - wasze opinie

Kolejny wątek który z merytorycznej dyskusji czysto programistycznej (ciekawej) spadł do wątku promującego usługi Pana naprawiającego robotę tych złych programistów...

Temat: Code review - wasze opinie

Jarosław S.:
Kolejny wątek który z merytorycznej dyskusji czysto programistycznej (ciekawej) spadł do wątku promującego usługi Pana naprawiającego robotę tych złych programistów...

przepraszam, zamieniam się w słuch.... bo statystyki od lat 70-tych niezmiennie mówią o ponad 70% porażek projektów IT... ja szukam sposobu na te pozostałe 30%, ale ok, słucham i już nic nie pisze... ;) Ten post został edytowany przez Autora dnia 28.01.14 o godzinie 22:32

Temat: Code review - wasze opinie

OK, wrócę do początku:

Jarosław Ż.:

Gdybyśmy w projekcie nie robili code review to ….

to trzeba by każdego nauczyć pisać dobry kod ....

Gdyby kod pisały maszyny (może kiedyś tak będzie), to w tym zdaniu miałbyś rację i de facto można by dyskusję zamknąć. Ale ludzie są tylko ludźmi i trzeba ich sprawdzać.

Ktoś kto twierdzi że dobrych specjalistów nie trzeba sprawdzać albo udaje że takiego kosztu nie ma (bo np. nie chce za niego płacić), albo nie zdaje sobie sprawy jak bardzo zawartość kodu zależy nie tylko od wyboru programisty, ale też od pogody, terminów, krzesła czy... aktualnie posiadanej wiedzy o projekcie.

Jarosław Ż.:

To, że Tobie code-review jest nie potrzebne to nie znaczy, że to zbędne narzędzie. Masz pewną ograniczoną perspektywę ze względu na rolę w procesie wytwarzania jaką odgrywasz.
Code-review to świetne narzędzie - po prostu nie dla Ciebie.

zgadzam się z Tobą ale tu mamy chyba nieporozumienie polegające na tym, ze
- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)

I tak i tak. Nie ma dwóch ludzi o tym samym poziomie wiedzy. A nawet jeśli trafisz na bliźniaków, to jeden może być akurat zakochany a drugiemu zdechły rybki. I efekt: takie same wymagania a różny wynik.

Nawet stosowanie wzorców projektowych, które z założenia definiują dość dokładnie co jak zrobić, nie jest obiektywne i zależy, zacytuje ostatnio czytanego autora "od dobrego smaku".

A person who never made a mistake never tried anything new.
Albert Einstein

Temat: Code review - wasze opinie

Piotr L.:
OK, wrócę do początku:

Jarosław Ż.:

Gdybyśmy w projekcie nie robili code review to ….

to trzeba by każdego nauczyć pisać dobry kod ....

Gdyby kod pisały maszyny (może kiedyś tak będzie), to w tym zdaniu miałbyś rację i de facto można by dyskusję zamknąć. Ale ludzie są tylko ludźmi i trzeba ich sprawdzać.

ale to chyba mowa o czymś w rodzaju kontrolera ortografii w wordzie, a ten (ani osoba korektora) nie ma nic wspólnego z jakością programu, czy sie mylę?

Ktoś kto twierdzi że dobrych specjalistów nie trzeba sprawdzać

bo nie trzeba... sami sobie z tym radzą... jak każdy dobry prawnik itp. jaki sena ma angażowanie do każdej roboty dwóch ludzi???

...

- czy code review to zarządzanie projektem i uczenie ludzi
- czy code review to element kontroli jakości (podobnie jak ktoś po mnie czyta, poprawia listerówki ki i stylistykę)

I tak i tak.

które z tych dwóch ma sens w komercyjnym projekcie?

Nawet stosowanie wzorców projektowych, które z założenia definiują dość dokładnie co jak zrobić, nie jest obiektywne i zależy, zacytuje ostatnio czytanego autora "od dobrego smaku".

zapewne

A person who never made a mistake never tried anything new.
Albert Einstein

dodaj do tego to kto jak często się myli... i jakie wnioski z tego wyciąga...Ten post został edytowany przez Autora dnia 28.01.14 o godzinie 22:36

Temat: Code review - wasze opinie

Piotr L.:
OK, wrócę do początku:

ja też:
"Gdybyśmy w projekcie nie robili code review to …. "

to co?

(i miałem nie pisac wieć od teraz tylko słucham)

Temat: Code review - wasze opinie

Jarosław Ż.:

Piotr L.:
OK, wrócę do początku:

ja też:
"Gdybyśmy w projekcie nie robili code review to …. "

to co?

(i miałem nie pisac wieć od teraz tylko słucham)

Pytasz konkretnie mnie?

Moja odpowiedź:
...to do użycia wchodziłby kod, który działa zgodnie z założeniami i bez błędu, napisany w ekspresowym tempie, ale nie da się go przeczytać. W związku z czym jego analiza w celu późniejszego rozszerzenia trwać będzie nie minuty a godziny lub dni.

(Zanim wspomnisz o dziedziczeniu, OOAD weź pod uwagę, że niektórzy pracują w trochę starszych technologiach).

Temat: Code review - wasze opinie

Piotr L.:

Jarosław Ż.:

Piotr L.:
OK, wrócę do początku:

ja też:
"Gdybyśmy w projekcie nie robili code review to …. "

to co?

(i miałem nie pisac wieć od teraz tylko słucham)

Pytasz konkretnie mnie?

Moja odpowiedź:
...to do użycia wchodziłby kod, który działa zgodnie z założeniami i bez błędu, napisany w ekspresowym tempie, ale nie da się go przeczytać. W związku z czym jego analiza w celu późniejszego rozszerzenia trwać będzie nie minuty a godziny lub dni.

(Zanim wspomnisz o dziedziczeniu, OOAD weź pod uwagę, że niektórzy pracują w trochę starszych technologiach).

o to to!
brak nadzoru nad programistami (szczególnie nowymi w projekcie lub młodszymi, a jak wiadomo takich nie jest mało) powoduje, że kod będzie działał zgodnie z analizą, zgodnie z projektem i zgodnie z wymaganiami, ale jego jakość (tak, ta niemierzalna wzorem) będzie taka, że inna osoba która trafi w to samo miejsce w kodzie będzie potrzebowała godzinę żeby rozgryźć jak co działa by móc dopisać pół linijki i poprawić babola, który może się tam trafić, bo ten pierwszy zrobi tam spaghetti z 30 ifami - na to nie ma wpływu ani istnienie dokumentacji ani jej nieistnienie (przepraszam że o to zahaczam) bo ona nie definiuje tego jak ma być zaimplementowana każda metoda, a rzut oka doświadczonego programisty (niski koszt dla klienta) może od razu wyłapać takie kwiatki i skierować do poprawy - większy koszt, ale nadal mniejszy niż wcielenie takiego kodu w życie i dalsze się z nim zmaganie

Temat: Code review - wasze opinie

Ja dorzucę jeszcze jeden aspekt sprawy, który jest pewną pochodną kilku poruszonych wcześniej przez przedpiśców kwestii, ale chyba nie został wyartykułowany wprost.
Mianowicie: nie zapominajmy o tym, że firma tworząca oprogramowanie nie powinna być tworem statycznym, jak fabryka garnków, ale musi dawać w swoich produktach to "coś", czego nie ma w produktach konkurencji (z resztą nawet producenci garnków o tym wiedzą, i co poniektórzy np. malują swoje garnki w kwiatki ;) ).
Chodzi o to, że jakość oprogramowania, która, jak wcześniej zauważono, mierzalna jest nie tylko stopniem spełnienia wymagań projektowych czy niezawodnością, ale i łatwością utrzymania kodu, ma bezpośredni wpływ na biznesowy byt firmy na rynku - nawiązując do jednej z wcześniejszych wypowiedzi, nie chciałbym mieć do czynienia z firmą, która robi dobry produkt bardzo szybko i tanio, ale późniejsze modyfikacje trwają tygodniami (spaghetti, brak standardów kodowania itd).
Jeśli więc wyniki review kodu będą wykorzystywane nie tylko do karania ("i po premii..."), ale również w celach edukacyjnych wewnątrz organizacji (promowanie wewnętrznych standardów, uzupełnianie/wyrównywanie poziomu wiedzy), w efekcie przyniosą one wymierne korzyści w przyszłości w postaci ulepszenia jakości produktów.
A ponieważ nie ma organizacji, której nie dałoby się ulepszyć (bez urazy ;) ), review kodu jest potrzebny zawsze - i to nie w kontekście projektu, ale raczej w kontekście organizacji.
To tyle z mojej strony.

Temat: Code review - wasze opinie

Jarosław Ż.:

Piotr J.:
Nie masz czasem wrazenie, ze tak mocno chcesz przekonac innych, ze sie myla, ze zaczynasz dyskusje sam ze soba? ;-)

ale ja nikogo do niczego nie przekonuję :) tylko dziele się swoja wiedzą, to że polemizują z cudzym zdaniem jest tylko polemika, czy gdzieś napisałem, ze ktoś coś robi źle? Ktoś tu pisze, że dokumentacja i projektowanie jest zbędna a ja, że jest potrzebna, na poparcie swojej tezy ja piszę, że moja praktyka i literatura (podaje która i nie jest to WIKI) projektowanie przed kodowaniem jest tańsze niż kodowanie z pominięciem projektowania w odpowiedzi czytam, 'a właśnie że nie" bez żądnych argumentów :)

Tu moge sie zgodzic. Z tego co czytam glowna walka brzmi "zero dokumentacji" vs" wszystko udokumentowane".

Osobiscie prawadze projekty agilowe, ktore maja pelna dokumentacje tego jak to ma wygladac na koniec - wiem gdzie zmierzam, ale nie jak tam dojsc, to jest ta "agilowa" czesc, bo faktycznie bieganie za uciekajacym celem potrafi zmarnowac kupe siana, zamiast stworzyc kod.Ten post został edytowany przez Autora dnia 29.01.14 o godzinie 00:48

Temat: Code review - wasze opinie

Kamil M.:

Jakub W.:

Podobnie jak wszystko co jest "Agile" CR koncentruje się na usuwaniu skutków (zły kod... co prawda ktoś wspomniał o części "edukacyjnej" całego procesu ale ciężko mi uwierzyć w to, że podczas takich tutoriali programista jest w stanie nauczyć się pisania kodu odpornego na np. race condition ), a nie przyczyn negatywnych zjawisk spotykanych w projekcie.

a jakie są przyczyny w przypadku wdrażania nowego pracownika?

Musisz doprecyzować.
W tym przypadku tłumaczę pytanie na: jakie są przyczyny (w domyśle - negatywnych zjawisk) w przypadku wdrażania nowego pracownika.

NNT: w wątku popełniłem niezamierzonego "plusa" :-)

Temat: Code review - wasze opinie

Jakub W.:

Kamil M.:

Jakub W.:

Podobnie jak wszystko co jest "Agile" CR koncentruje się na usuwaniu skutków (zły kod... co prawda ktoś wspomniał o części "edukacyjnej" całego procesu ale ciężko mi uwierzyć w to, że podczas takich tutoriali programista jest w stanie nauczyć się pisania kodu odpornego na np. race condition ), a nie przyczyn negatywnych zjawisk spotykanych w projekcie.

a jakie są przyczyny w przypadku wdrażania nowego pracownika?

Musisz doprecyzować.
W tym przypadku tłumaczę pytanie na: jakie są przyczyny (w domyśle - negatywnych zjawisk) w przypadku wdrażania nowego pracownika.

NNT: w wątku popełniłem niezamierzonego "plusa" :-)

Chodzi mi o to że, idąc Twoim tokiem rozumowania - wdrożenie nowego pracownika tworzy PROBLEM (zły kod), code review pozwala wyeliminować SKUTKI tego problemu, więc moje pytanie brzmi: co w tej sytuacji jest PRZYCZYNĄ i jakie środki pozwoliłyby ją wyeliminować?

Temat: Code review - wasze opinie

Panowie.
Problem jest dokładnie tego samego rodzaju, co podczas produkcji samochodu w fabryce.
Oczywiście, że najtaniej byłoby wszystko pospawać na stałe, po cholerę śrubki, jakieś liczenie wytrzymałości - tu spaw, tam spaw, jeszcze jeden dla pewności, i na pewno się nie rozleci, a będzie tanio, szybko i dobrze.
Problem tylko później przy serwisie - koła nie wymienisz, bo przyspawane, bezpieczniki przylutowane do przewodów (skrzynka bezpiecznikowa? po co? niepotrzebny koszt przy produkcji). Odnoszę wrażenie, że zdaniem wielu osób właśnie takie rzeczy NIE SĄ ISTOTNE Z BIZNESOWEGO PUNKTU WIDZENIA. I nic bardziej błędnego.
A review kodu pomaga wyłapać takich spawaczy i albo spróbować nauczyć ich przykręcać śrubki (w prawo, panie Zenku, w prawo), albo nawet wytłumaczyć, że u nas w firmie standardem jest gwint metryczny, i nie należy brać pod uwagę śrub z gwintem calowym, bo to sięrobi niestandardowe. A jeśli ktoś nie zrozumie, to wylać na zbity pysk.
W dużym skrócie: robienie roboty porządnie (kiedyś było nawet takie, nieco chyba już przestarzałe, słowo: rzetelnie) jest niczym innym jak budowaniem DOBREGO wizerunku firmy. Zaryzykuję nawet stwierdzenie, że jeśliby ludzie zaczęli robić robotę PORZĄDNIE, to wielu speców od PR nie miałoby roboty (BTW: ciekawe, kto jest tańszy: dobry programmer czy dobry spec od PR?)
Skrytospawaczom kodu mówimy kategorycznie: NIE!Ten post został edytowany przez Autora dnia 29.01.14 o godzinie 14:57

Temat: Code review - wasze opinie

Kamil M.:
Chodzi mi o to że, idąc Twoim tokiem rozumowania - wdrożenie nowego pracownika tworzy PROBLEM (zły kod), code review pozwala wyeliminować SKUTKI tego problemu, więc moje pytanie brzmi: co w tej sytuacji jest PRZYCZYNĄ i jakie środki pozwoliłyby ją wyeliminować?

Przyczyną jest zła edukacja (w szkole) lub złe praktyki wyniesione z poprzedniej firmy, w której nie rozumiano, że TRZEBA robić dobry kod.

Temat: Code review - wasze opinie

Jarosław Ż.:

Piotr L.:
OK, wrócę do początku:

ja też:
"Gdybyśmy w projekcie nie robili code review to …. "

to co?

(i miałem nie pisac wieć od teraz tylko słucham)

A przeglądacie czasem coś co zrobił inny projektant? No, to tu jest dokładnie tak samo. Odnoszę wrażenie, że kolega wychodzi z założenia, że projektant projektuje, a programista ma wklepać. W sensie, że praca tego ostatniego jest stricte odtwórcza. Może tak bywa, zwykle to jest tak, że na każdym poziomie są konkretne problemy do rozwiązania. Jak by było inaczej kod byłby generowany z diagramów uml.

Przy okazji. To, czy wygeneruję klasy i będę przeglądał na tym poziomie, zaglądając od czasu do czasu do jakiejś metody - to nie ma znaczenia.

Chyba EOT, bo 5 stron o tym samym chyba wystarczy.

Temat: Code review - wasze opinie

Jaki EOT? Genialna ta dyskusja.

Ciężko odnieść się do wszystkiego, ale mam wrażenie, że wszyscy na tym forum mają rację. Każdy bazuje na swoim doświadczeniu, a to jest diametralnie różne. Czynnik decydujący o tym czy coś działa czy nie działa jest ściśle zależny od konkretnego projektu i ludzi w tym projekcie. Gdyby w projekcie brali udział sami "seniorzy", to nie wydaje mi się, żeby code review było potrzebne. Code review to poprostu sposób rozwiązania problemu. Jeśli taki problem istnieje to trzeba go rozwiązać. Jeśli nie, to nie! Jestem przeciwnikiem suplementów diety w IT.

"statystyki od lat 70-tych niezmiennie mówią o ponad 70% porażek projektów IT"
Dokładnie! Mamy XP, Scrum, Kanban, Waterfall i dziesiątki innych podejść, a statystki są dalej takie same. Czy gmail albo facebook to był projekt fixed-price? Czy dało się zaprojektować facebook przed rozpoczęciem implementacji, żeby wyglądał tak jak wygląda? Czy tworzenie oprogramowana dla ZUSu powinno być agile? Dlaczego oprogramowanie dla ZUS w Polsce i ObamaCare w Stanach jest tak samo beznadziejne i kosztowne? Czy oprogramowanie do sterownika ABSu w samochodzie powinno być agile? Czy sterowanie odpaleniem bomb nuklearnych powinno być XP?

Mam wrażenie, że właśnie po takiego typu dyskusjach powstało http://agilemanifesto.org/. Ale dyskusja zamiast się skończyć rozgorzała na dobre i powstało http://manifesto.softwarecraftsmanship.org/. Teraz manifesty stały się modne! Widzieliście np. http://www.reactivemanifesto.org/?

I na koniec manifest dla osób, którzy są naprawdę sfrustrowani całą tą otoczką i po prostu chcą programować i robić to dobrze http://programming-motherfucker.com/

Temat: Code review - wasze opinie

EOT, bo skoro każdy ma rację to nikt nie ma.
Przegląd kodu to narzędzie. Jak każde może być dobrze użyte, albo źle. W tym sensie dwie osoby o dokładnie przeciwnych opiniach mogą mieć rację - jeżeli bazują na różnych doświadczeniach. A do tego, tego typu dyskusje się zwykle sprowadzają. Jak ze wszystkimi narzędziami - kwestia zysków w stosunku do nakładów. Trzeba zdawać sobie sprawę co i jak można osiągnąć i z jakimi kosztami się to wiąże. Skoro, zostało to już przedstawione, to następny etap jest oznacza pyskówkę / wycieczki personalne. ;)

Temat: Code review - wasze opinie

Michał Z.:
A przeglądacie czasem coś co zrobił inny projektant? No, to tu jest dokładnie tak samo.

odpowiem za siebie:
- dobry analityk projektant jest jedynym autorem swojego dokumentu, po nim sprawdza odbiorca.
- poważne firmy (analitycy, projektanci a także kodeksowa umowa o dzieło) nie dopuszczają zbiorowej odpowiedzialności za dzieło (projekt nim jest)
- jeżeli są przeglądy to są to raczej recenzje (sugestie a nie nakaz wprowadzenia zmiany)

Odnoszę wrażenie, że kolega wychodzi z założenia, że projektant projektuje, a programista ma wklepać.

dokładnie tak, po drodze jest jeszcze architekt

W sensie, że praca tego ostatniego jest stricte odtwórcza.

jeżeli w danym projekcie ma role "kodera" to prawie ta, tak samo jak inżynier budownictwa "realizuje" projekt architektoniczny, zależnie od projektu oczywiście dostaje obszar swobody i rozwiązuje problemy, ale nie architektoniczne (ja np. od programisty oczekuję rozwiązania problemów z wymaganiami pozafunkcjonalnymi - jest ich masa, ale nie dopuszczam ingerencji w architekturę.

Może tak bywa, zwykle to jest tak, że na każdym poziomie są konkretne problemy do rozwiązania. Jak by było inaczej kod byłby generowany z diagramów uml.

o generowaniu kodu zapomnijmy, ale szkielet komponetów i klas dziedzinowych z UML, czemu nie...

ale zgadzam się z tym, że na każdym poziomie sa okreśłone problemy na co wyżej zwróciłem uwagę

Przy okazji. To, czy wygeneruję klasy i będę przeglądał na tym poziomie, zaglądając od czasu do czasu do jakiejś metody - to nie ma znaczenia.

tak więc przegląd kodu jako sprawdzanie jak pracuje programista, w moich oczach ma sens jako zarządzanie ryzykiem projektu, przegląd kodu jako element nauki (ale raczej nie w projekcie za pieniądze zamawiającego) też ma sens (choć może jednak także do książęk go zagonić).

przegląd kodu jako lekarstwo na niedobory kompetencji zespołu do mnie absolutnie nie przemawia... jakakolwiek zbiorowa odpowiedzialność, za jakikolwiek produkt, w moich projektach jest niedopuszczalna.

EOT :)

P.S.
nie każdy tu uważa, że ma rację... wielu po prostu prezentuje swoje zdanie i doświadczenieTen post został edytowany przez Autora dnia 30.01.14 o godzinie 10:21

Temat: Code review - wasze opinie

Piotr G.:
Panowie.
Problem jest dokładnie tego samego rodzaju, co podczas produkcji samochodu w fabryce.
Oczywiście, że najtaniej byłoby wszystko pospawać na stałe, po cholerę śrubki, jakieś liczenie wytrzymałości - tu spaw, tam spaw, jeszcze jeden dla pewności, i na pewno się nie rozleci, a będzie tanio, szybko i dobrze.

Chcesz żeby pan Heniek na hali produkcyjnej decydował o tym czy koło przyspawać czy przykręcić? W takiej sytuacji każdy pan Heniek powinien mieć obok siebie kontrolera. Tylko skąd kontroler ma to wiedzieć co lepsze?

Temat: Code review - wasze opinie

Musisz doprecyzować.
W tym przypadku tłumaczę pytanie na: jakie są przyczyny (w domyśle - negatywnych zjawisk) w przypadku wdrażania nowego pracownika.

NNT: w wątku popełniłem niezamierzonego "plusa" :-)

Chodzi mi o to że, idąc Twoim tokiem rozumowania - wdrożenie nowego pracownika tworzy PROBLEM (zły kod), code review pozwala wyeliminować SKUTKI tego problemu, więc moje pytanie brzmi: co w tej sytuacji jest PRZYCZYNĄ i jakie środki pozwoliłyby ją wyeliminować?

To jest pomieszanie z poplątaniem.

CR to taka kontrola jakości kodu (chociaż może to coś innego), a żeby jakość kontrolować to trzeba najpierw jakąś mieć.

Jeśli ktoś uważa, że CR "zapewnia jakość" to albo inaczej rozumiemy to pojęcie albo ten ktoś nie rozumie skąd jakość się bierze.

IMHO jakość kodu jest pochodną umiejętności stworzenia zespołu dobrych projektantów / programistów z nie z okresowego przeprowadzania CR.

Wszystko tak na prawdę zależy do tego czym to CR ma tak na prawdę być:

1. Jeśli jest to metoda eliminacji błędów które powstają w związku z tym, że "każdy może mieć słabszy dzień" to ok - wtedy CR staje się metodą _kontroli_ jakości

2. Jeśli CR stosuje się ponieważ "mamy w zespole świeżaka" to ... problem "świeżaka" powinien zostać rozwiązany na etapie rekrutacji (nie zatrudniamy ludzi bez odpowiedniej wiedzy) ew. etapie wdrożenia w projekt.Ten post został edytowany przez Autora dnia 30.01.14 o godzinie 13:25

Temat: Code review - wasze opinie

Jarosław Ż.:

Michał Z.:

Odnoszę wrażenie, że kolega wychodzi z założenia, że projektant projektuje, a programista ma wklepać.

dokładnie tak, po drodze jest jeszcze architekt

o, i tu jest pies pogrzebany :) według mnie, jakkolwiek rozbudowana będzie hierarchia tych pracowników, zawsze elementem najniższego poziomu jest ten koder/klepacz, który tak naprawdę decyduje jak zaimplementuje daną cząsteczkę kodu, czy ma użyć "if/else" czy operatora trójargumentowego - i tego mu nikt z gory nie narzuci ani nie opisze w dokumentacji

W sensie, że praca tego ostatniego jest stricte odtwórcza.

jeżeli w danym projekcie ma role "kodera" to prawie ta, tak samo jak inżynier budownictwa "realizuje" projekt architektoniczny, zależnie od projektu oczywiście dostaje obszar swobody i rozwiązuje problemy, ale nie architektoniczne (ja np. od programisty oczekuję rozwiązania problemów z wymaganiami pozafunkcjonalnymi - jest ich masa, ale nie dopuszczam ingerencji w architekturę.

>
no właśnie, architektura musi być zgodna z dokumentacją, ale implementacja metod to odpowiedzialność kodera,

kontynuując rozważania budownicze - architekt każe zrobić instalację wodną w łazience, opisuje jakimi rurkami, którędy, itd., ale pan Mietek z panem Józkiem nie mają cierpliwości do nawjiania konopii i poprawnego ułożenia uszczelek, tylko stosują metodę "zaklejmy to wszystko dużą ilością kleju/silikonu" - dzięki temu funkcjonalnie jest okej, bo woda w kranie jest i nie cieknie, ale ewentualna naprawa będzie kosztowna i upierdliwa

a jeśli zrobilibyśmy code review... przychodzi majster i widzi co tamci dwaj zrobili, to od razu ich opieprzy, pokaże do czego służą konopie i rurki w kuchni i łazience na piętrze już będą zrobione tak jak sie należy

(teraz każdy będzie pisał EOT, myśląc że jego słowo będzie dobrym podsumowaniem :D)