Temat: Code review - wasze opinie

Osobom które mają wątpliwości czy code review jest potrzebne, polecam zajrzenie tutaj:
http://www.ioccc.org/years.html

Jest tam np. piękny program typu emulator PC zrobione w jednej linijce :)
cable3

Code review będzie potrzebne zawsze, dopóki projekty nie będą opisywały pojedynczych linijek kodu.
Architektura, projekt bazy czy klas to piękne założenia i fajnie jest pracować gdy się je ma, ale nawet przy ich obecności można popełnić programy podobne do ww.

Temat: Code review - wasze opinie

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

Swego czasu usłyszałem, że projektant powinien programować a programista projektować. To brzmiało bardzo mądrze. :-)

Temat: Code review - wasze opinie

Jakub W.:

2. Jeśli CR stosuje się ponieważ "mamy w zespole świerzaka" to ... problem "swierzaka" powinien zostać rozwiązany na etapie rekrutacji (nie zatrudniamy ludzi bez odpowiedniej wiedzy) ew. etapie wdrożenia w projekt.

No w sumie tak, świat byłby piękniejszy gdyby ludzie rodzili się oszlifowanymi diamentami i każdy zespół programistyczny skłądał się z samych takich perełek... rzeczywistość jednak zazwyczaj wygląda tak, że w zespole masz ludzi z doświadczeniem i znających projekt (i oni powinni stanować większość) ale masz też kliku nowoprzyjętych (niekoniecznie niedoświadczonych, ale jeszcze nie wdrożonych w projekt) i kilku początkujących, którzy gdzieś muszą to doświadczenie zdobyć.
No chyba że według Ciebie ludzie po studiach albo po przeczytaniu 2 książek powinni być przygotowani do pracy i wytwarzania kodu wysokiej jakości, to ja podziękuje w tym momencie.

Temat: Code review - wasze opinie

Jakub W.:
2. Jeśli CR stosuje się ponieważ "mamy w zespole świerzaka" to ... problem "swierzaka" powinien zostać rozwiązany na etapie rekrutacji (nie zatrudniamy ludzi bez odpowiedniej wiedzy) ew. etapie wdrożenia w projekt.

Nie? To kwestia preferencji. Jest raczej wręcz przeciwnie, (z reguły) firmy chętnie zatrudniają ludzi niedoświadczonych bo można ich poddać obróbce. Ogłoszenia typu "student ostatnich lat z 5-letnim doświadczeniem" są wręcz plagą.

Temat: Code review - wasze opinie

Jarosław Ż.:

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)

"nie dopuszczają zbiorowej odpowiedzialności za dzieło" - i to jest źródło patologii

- 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

czyli mamy (w skrócie):
Klient => Projektant => Architekt => Programista <= kontroler (code review) <= Team leader (kontroler?)
Naprawdę? Czy programista jest tak mało godny zaufania, że nie może podjąć żadnej decyzji? Tylko potrzebuje:
- osoby która powie co mają zrobić (klient)
- osoby która napisze im co mają zrobić (projektant)
- osoby która napisze szerzej co mają to zrobić (architekt)
- osoby która wytknie im błędy (code review)
- osoby która każe to zrobić (Team leader)

To mi przypomina bardziej system nauczania niż współpracę.

W takiej strukturze programista nie ponosi żaden odpowiedzialności. Wszyscy go pilnują, to po co się starać? Tak naprawdę to można by go w sumie zautomatyzować prawda? Tylko trzeba by programistę, żeby go zautomatyzował ;).Ten post został edytowany przez Autora dnia 30.01.14 o godzinie 11:54

Temat: Code review - wasze opinie

Grzegorz G.:
Gdyby w projekcie brali udział sami "seniorzy", to nie wydaje mi się, żeby code review było potrzebne.

Czyżby? Określenie "seniora" to taka ładna nazwa "starszego programisty", rzecz jasna z wieloletnim doświadczeniem. Nie wiem jak długo trzeba programować i jakie mieć doświadczenie żeby się takim nazywać. To że ktoś jest seniorem jeszcze nie oznacza że nie popełnia błędów. Code Review można by uznać za niepotrzebne może tylko i wyłącznie w przypadku gdyby kod został dokładnie sprawdzony pod każdym względem i wspaniałomyślnie programiści by uznali że będzie już zamknięty na jakiekolwiek modyfikacje. Można by go przeglądać ale to wyłącznie w celu przypomnienia sobie pewnych rzeczy.

A co do seniorów to nie dość że każdy ma inne doświadczenie, to jeszcze jest różny staż pracy i tu wcale nie powinno być niczym dziwnym jeśli programista z 20 lat doświadczenia uznał że kod pisany przez programistę z 10 letnim doświadczeniem należałoby jeszcze w jakiś sposób zmodyfikować.

Temat: Code review - wasze opinie

Adrian C.:
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?

wystarczy, ze czyta dokumentację projektanta

Temat: Code review - wasze opinie

Kamil M.:
według mnie, jakkolwiek rozbudowana będzie hierarchia tych pracowników, zawsze elementem najniższego poziomu jest ten koder/klepacz, który tak naprawdę

demagogia, hierarchia jest prosta:
- analiza i projektowanie: produktem jest uzgodniony z zamawiającym projekt logiki działania tego co ma powstać
- realizacja: developer implementuje powyższe

zła wiadomość: praca developera ZAWSZE jest odtwórcza bo inna być nie może (to nie developer nie decyduje o tym "do czego to jest").

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

tego nie, ale podział na komponenty i klasy w tym algorytmy (np. metody udzielania upustów) jak najbardziej

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

dokładnie tak,

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

ale przed tym sie tu mam nadzieje wszyscy bronimy, i dlatego Mietek nie jest architektem

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

po prostu ktoś nie realizuje (lub nie potrafi) projektu i tu faktycznie Jakub ma 100%

Temat: Code review - wasze opinie

Grzegorz G.:
czyli mamy (w skrócie):
Klient => Projektant => Architekt => Programista <= kontroler

> (code review) <= Team leader (kontroler?)
> Naprawdę? Czy programista jest tak mało godny zaufania, że nie

może podjąć żadnej decyzji? Tylko potrzebuje:
- osoby która powie co mają zrobić (klient)
- osoby która napisze im co mają zrobić (projektant)
- osoby która napisze szerzej co mają to zrobić (architekt)
- osoby która wytknie im błędy (code review)
- osoby która każe to zrobić (Team leader)

To mi przypomina bardziej system nauczania niż współpracę.

nie czytasz, wyłącznie:
- analityk-architekt
- deveoper

zarządzanie jakością to problem kompetencji każdego z nich

W takiej strukturze programista nie ponosi żaden odpowiedzialności. Wszyscy go pilnują, to po co się starać? Tak naprawdę to można by go w sumie zautomatyzować prawda? Tylko trzeba by programistę, żeby go zautomatyzował ;).

w tej którą opisałeś ty zapewne tak

zbiorowa odpowiedzialność to prosta droga to "wszyscy poprawnie wykonali swoja robotę a system jest do du..py".

Temat: Code review - wasze opinie

Jarosław Ż.:

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

ale przed tym sie tu mam nadzieje wszyscy bronimy, i dlatego Mietek nie jest architektem

przed czym się bronimy? błędy i niekompetencja są naturalne i pewne, więc warto zawczasu eliminować błędy i wprowadzać dobre praktyki

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

po prostu ktoś nie realizuje (lub nie potrafi) projektu i tu faktycznie Jakub ma 100%

nie! dokumentacja nie schodzi tak głęboko, a jeśli schodzi to z kolei nie uwierzę, ze jej stworzenie może być tanie lub szybkie, sam napisałeś:

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

tego nie, ale podział na komponenty i klasy w tym algorytmy (np. metody udzielania upustów) jak najbardziej

i

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

dokładnie tak,

dokumentacja opisuje architekturę i procesy, ale to nadal daleko wyższy poziom abstrakcji niż decyzja "10 takich samych IFów" czy "pętla po liście 10 elementów i jeden IF robiący to samo na podstawie parametru z listy"

Temat: Code review - wasze opinie

Jarosław Ż.:
- analityk-architekt
- deveoper

zarządzanie jakością to problem kompetencji każdego z nich

No ale w tym przypadku każdy ma określone zadanie. Wymieniliście tu kilku ludzi którzy wspólnie biorą udział w realizacji projektu. Ale np. taki freelancer jeśli działa w pojedynkę ma na głowie wszystko.

zbiorowa odpowiedzialność to prosta droga to "wszyscy poprawnie wykonali swoja robotę a system jest do du..py".

Niech będzie zbiorowa, pod warunkiem że każdy z nich zna się na rzeczy i ma ściśle ustalony zakres obowiązków. Co by było gdyby analityk wtrącał się w szczegóły implementacji kodu który został napisany przez deva znającego się na rzeczy? Mówię oczywiście o istotnych szczegółach które to już zostały poruszone np. warningi albo pewne instrukcje mające istotny wpływ na funkcjonowanie aplikacji.

Dam przykład. Załóżmy że piszę system oparty o SSN i do celów zapisania wyszkolonej sztucznej sieci neuronowej używam serializacji. Ale ktoś inny proponowałby żebym zaimplementował to inaczej (tzn. jakiś odczyt i zapisywanie wag oraz ilości neuronów). A więc to samo można często zrobić na kilka różnych sposobów. Powinienem chyba wiedzieć czego można użyć. No ale serializacja nie musi być dobrym rozwiązaniem, szczególnie w przypadkach gdyby klasa SSN była rozbudowana o jakieś nowe pola.Ten post został edytowany przez Autora dnia 30.01.14 o godzinie 13:37

Temat: Code review - wasze opinie

Kamil M.:
przed czym się bronimy? błędy i niekompetencja są naturalne i pewne,

jak u kogo... tu trzymam stronę Jakuba: jeżeli z góry zakłada że ma zespół niekompetentnych ludzi to faktycznie tylko Agile ma sens, ale uwierz, że są firmy które maja ludzi kompetentnych ... jak to Jakub zauważył: panują na d tym kogo i po co rekrutują...

więc warto zawczasu eliminować błędy i wprowadzać dobre praktyki

nadal uważasz to za dobra praktykę?

po prostu ktoś nie realizuje (lub nie potrafi) projektu i tu faktycznie Jakub ma 100%

nie! dokumentacja nie schodzi tak głęboko, a jeśli schodzi to z kolei nie uwierzę, ze jej stworzenie może być tanie lub szybkie, sam napisałeś:

to jak "głęboko" ja schodzę z dokumentacja zależy wyłącznie od ryzyka jakie stwarzają developerzy:
- developer Agile: dokumentacja jest głęboka (do klas włącznie)
- develoepr z dużymi kompetencjami: dokumentacja jest "płytka" (raczej tylko komponenty i ich logika)

dokumentacja opisuje architekturę i procesy, ale to nadal daleko wyższy poziom abstrakcji niż decyzja "10 takich samych IFów" czy "pętla po liście 10 elementów i jeden IF robiący to samo na podstawie parametru z listy"

tego nie neguję, ale potem ja zmierzę jakość Twojej pracy: czas odpowiedzi systemu, i ocenię Cię nie po kodzie którego na pewno nie będę czytał, czy ilości ifów w kodzie, tyko po czasie odpowiedzi systemu, a potem po tym na ile wycenisz rozwiąjanie tego funkcjonalnosci :)

to z tego powodu właśnie mało mnie obchodzi ile godzin siedział programista, płacę za efekt, i tu znowu nawiążę do Jakuba: kiepski programista wygeneruje Ci tu duże koszty, a mądry Klient nie będzie za to płacił.

I w tym kontekście przytoczę pytanie tytułowe bo ja cały czas pisze na temat :): w czym tu pomaga Ci code review?Ten post został edytowany przez Autora dnia 30.01.14 o godzinie 13:42

Temat: Code review - wasze opinie

Jarosław Ż.:

Grzegorz G.:
może podjąć żadnej decyzji? Tylko potrzebuje:
- osoby która powie co mają zrobić (klient)
- osoby która napisze im co mają zrobić (projektant)
- osoby która napisze szerzej co mają to zrobić (architekt)
- osoby która wytknie im błędy (code review)
- osoby która każe to zrobić (Team leader)

To mi przypomina bardziej system nauczania niż współpracę.

nie czytasz, wyłącznie:
- analityk-architekt
- deveoper

A gdzie klient? Jak go odetniemy po podpisaniu kontraktu / zatwierdzeniu planu to też to słabo widzę.

zarządzanie jakością to problem kompetencji każdego z nich

W takiej strukturze programista nie ponosi żaden odpowiedzialności. Wszyscy go pilnują, to po co się starać? Tak naprawdę to można by go w sumie zautomatyzować prawda? Tylko trzeba by programistę, żeby go zautomatyzował ;).

w tej którą opisałeś ty zapewne tak

zbiorowa odpowiedzialność to prosta droga to "wszyscy poprawnie wykonali swoja robotę a system jest do du..py".

Jeśli wszyscy poprawnie wykonali swoją robotę to system nie może być do dupy. W przeciwnym razie mamy do czynienia z tzw. "moral hazard".Ten post został edytowany przez Autora dnia 30.01.14 o godzinie 13:44

Temat: Code review - wasze opinie

Jarosław Ż.:

jak u kogo... tu trzymam stronę Jakuba: jeżeli z góry zakłada że ma zespół niekompetentnych ludzi to faktycznie tylko Agile ma sens, ale uwierz, że są firmy które maja ludzi kompetentnych ... jak to Jakub zauważył: panują na d tym kogo i po co rekrutują...

ale ja nie zakładam że wszyscy sa niekompetentni, po prostu w każdym zespole jest rotacja osób, przyjmowani są nowi, przyjmowani są niedoświadczeni i każdy musi się wdrożyć - oczywiste jest że tacy ludzie muzsą być w mniejszości i może przy okazji - w temacie - code review nie musi dotyczyć wszystkich, to nie jest tak ze każdy sprawzda każdego, albo że jakiś doświadczony pracownik nic innego nie robi tylko czyta czyjś kod zamiast pracować, a klient płaci, oczywiście że tak nie jest

więc warto zawczasu eliminować błędy i wprowadzać dobre praktyki

nadal uważasz to za dobra praktykę?

jakie znów "to" ? tak, uważam dobre praktyki (uszczelnianie rur) za dobre praktyki w przeciwieństwie do złych praktyk (zabetonowywanie ich) :)

to jak "głęboko" ja schodzę z dokumentacja zależy wyłącznie od ryzyka jakie stwarzają developerzy:
- developer Agile: dokumentacja jest głęboka (do klas włącznie)

"do klas włącznie" to nie jest głęboko

dokumentacja opisuje architekturę i procesy, ale to nadal daleko wyższy poziom abstrakcji niż decyzja "10 takich samych IFów" czy "pętla po liście 10 elementów i jeden IF robiący to samo na podstawie parametru z listy"

tego nie neguję, ale potem ja zmierzę jakość Twojej pracy: czas odpowiedzi systemu, i ocenię Cię nie po kodzie którego na pewno nie będę czytał, czy ilości ifów w kodzie, tyko po czasie odpowiedzi systemu, a potem po tym na ile wycenisz rozwiąjanie tego funkcjonalnosci :)

to z tego powodu właśnie mało mnie obchodzi ile godzin siedział programista, płacę za efekt, i tu znowu nawiążę do Jakuba: kiepski programista wygeneruje Ci tu duże koszty, a mądry Klient nie będzie za to płacił.

I w tym kontekście przytoczę pytanie tytułowe bo ja cały czas pisze na temat :): w czym tu pomaga Ci code review?

ale tą samą metodę, robiącą to samo, można napisać na różne sposoby, które będą działać tak samo szybko, tak samo wydajnie i ich implementacja może potrwać tyle samo czasu, jedyna różnica to właśnie koszt utrzymania/rozwoju takiego kodu, ale o to będą pytać team leadera, który z kolei musi mieć pojęcie jaki kod tworzą jego klepacze i tu właśnie wchodzi code review

Temat: Code review - wasze opinie

Dariusz R.:

Jarosław Ż.:
- analityk-architekt
- deveoper

zarządzanie jakością to problem kompetencji każdego z nich

No ale w tym przypadku każdy ma określone zadanie. Wymieniliście tu kilku ludzi którzy wspólnie biorą udział w realizacji projektu. Ale np. taki freelancer jeśli działa w pojedynkę ma na głowie wszystko.

czyli w zasadzie albo pracuje sam i nie powinien brać za projekty "większe niż" albo jest najmowany do pełnienia konkretnej roli w w dużych projektach.

Jako ktoś kto dostaje do ręki efekty różnych projektów: nie ma nic gorszego niż jedna osoba, która uważa, że potrafi przeanalizować zarządzanie firmą, jej logikę działania, potem opracować optymalna architekturę systemu, i wykonać implementację, tu ewidentnie "banki od wszystkiego są do niczego".

Każda z tych dziedzin: analiza biznesowa i projektowanie oraz inżynieria oprogramowania to duże obszary wiedzy, trzeba stale się dużo uczyć, mając na uwadze projekty w rodzaju (cytat z tego wątku) 4GB kodu, nie ma szans na "omnibusa".

Ze swojego doświadczenia powiem: nawet malutki CRM dla 15 osobowej firmy wymaga dużej wiedzy z obu wyżej wskazanych obszarów (wymagana wiedza lekarza nie zależy od tego czy ma leczyć kompanie wojska czy jednego przedszkolaka). Moje doświadczenie mówi: wielkość projektu nie determinuje ilości ról w projekcie. Ja nawet do małych projektów angażuję np. na godzinę dziennie kierownika projektu czy koordynatora , bo jak sam jestem analitykiem i szefem projektu to narażam swojego klienta na porażkę.

zbiorowa odpowiedzialność to prosta droga to "wszyscy poprawnie wykonali swoja robotę a system jest do du..py".

Niech będzie zbiorowa, pod warunkiem że każdy z nich zna się na rzeczy i ma ściśle ustalony zakres obowiązków.

albo ma zakres obowiązków i odpowiada za cos konkretnego albo nie ma ;)

Co by było gdyby analityk wtrącał się w szczegóły implementacji kodu który został napisany przez deva znającego się na rzeczy?

dobry analityk tego nie zrobi, analogicznie w drugą stronę

Temat: Code review - wasze opinie

Grzegorz G.:

nie czytasz, wyłącznie:
- analityk-architekt
- deveoper

A gdzie klient? Jak go odetniemy po podpisaniu kontraktu / zatwierdzeniu planu to też to słabo widzę.

a gdzie napisałem, że go odcinam? Klient ma spokój, jego rola jest wyłącznie udzielanie informacji (jak u lekarza :))

Jeśli wszyscy poprawnie wykonali swoją robotę to system nie może być do dupy. W przeciwnym razie mamy do czynienia z tzw. "moral hazard".

no to wracamy do początku: jeżeli jest do du..py to jak szukasz miejsca i przyczyny?

Temat: Code review - wasze opinie

Kamil M.:

Jarosław Ż.:

jak u kogo... tu trzymam stronę Jakuba: jeżeli z góry zakłada że ma zespół niekompetentnych ludzi to faktycznie tylko Agile ma sens, ale uwierz, że są firmy które maja ludzi kompetentnych ... jak to Jakub zauważył: panują na d tym kogo i po co rekrutują...

ale ja nie zakładam że wszyscy sa niekompetentni, po prostu w każdym zespole jest rotacja osób, przyjmowani są nowi, przyjmowani są niedoświadczeni i każdy musi się wdrożyć -

wracamy do początku: więc jak i kogo rekrutujesz?
po drugie zakładanie z góry, że łapanka pod projekt i duża rotacja (np. przetargi) to dobra metoda na projekty IT to oda razu powiem: to recepta na najgorsze i najkosztowniejsze projekty.

na szczęście (witaj Jakub :)) są firmy i znikomej rotacji ....

nadal uważasz to za dobra praktykę?

jakie znów "to" ? tak, uważam dobre praktyki (uszczelnianie rur) za dobre praktyki w przeciwieństwie do złych praktyk (zabetonowywanie ich) :)

jeżeli uszczelniasz rurę raz na 10 lat to jest to dobry system, jeżeli uszczelniasz permanentnie to ni e nie jest to dobra metoda na dobre rury.

to jak "głęboko" ja schodzę z dokumentacja zależy wyłącznie od ryzyka jakie stwarzają developerzy:
- developer Agile: dokumentacja jest głęboka (do klas włącznie)

"do klas włącznie" to nie jest głęboko

dla analityka projektanta to jest głęboko :), ja nie nie jestem wrogiem developerów tylko ich partnerem :) ktoś tu słusznie napisał, że metody to programista a nie analityk

ale tą samą metodę, robiącą to samo, można napisać na różne sposoby, które będą działać tak samo szybko, tak samo wydajnie i ich implementacja może potrwać tyle samo czasu, jedyna różnica to właśnie koszt utrzymania/rozwoju takiego kodu, ale o to będą pytać team leadera, który z kolei musi mieć pojęcie jaki kod tworzą jego klepacze i tu właśnie wchodzi code review

ale głównie chodzi o ta różnice właśnie :) i o tych klepaczy (to nie moje słowa :)))

widzę, że chyba jednak zgadzamy się ze sobą każdy ze swojej perspektywy :) Ten post został edytowany przez Autora dnia 30.01.14 o godzinie 14:20

Temat: Code review - wasze opinie

Jarosław Ż.:

ale tą samą metodę, robiącą to samo, można napisać na różne sposoby, które będą działać tak samo szybko, tak samo wydajnie i ich implementacja może potrwać tyle samo czasu, jedyna różnica to właśnie koszt utrzymania/rozwoju takiego kodu, ale o to będą pytać team leadera, który z kolei musi mieć pojęcie jaki kod tworzą jego klepacze i tu właśnie wchodzi code review

ale głównie chodzi o ta różnice właśnie :) i o tych klepaczy (to nie moje słowa :)))

zgadzam się! i po to właśnie jest code review (rozumiane dosłownie jako czytanie czyjegoś kodu) żeby szef zespołu miał pogląd na temat tego co robią jego pracownicy, mógł zareagować jeśli robią coś nietak, a przed swoim zwierzchnikiem mógł udzielić informacji na temat kosztów dalszych prac

widzę, że chyba jednak zgadzamy się ze sobą każdy ze swojej perspektywy :)

chyba tak :) dziękuję za dyskusję, dla mnie koniec ;)

Temat: Code review - wasze opinie

Kamil M.:

Jarosław Ż.:

ale tą samą metodę, robiącą to samo, można napisać na różne sposoby, które będą działać tak samo szybko, tak samo wydajnie i ich implementacja może potrwać tyle samo czasu, jedyna różnica to właśnie koszt utrzymania/rozwoju takiego kodu, ale o to będą pytać team leadera, który z kolei musi mieć pojęcie jaki kod tworzą jego klepacze i tu właśnie wchodzi code review

ale głównie chodzi o ta różnice właśnie :) i o tych klepaczy (to nie moje słowa :)))

zgadzam się! i po to właśnie jest code review (rozumiane dosłownie jako czytanie czyjegoś kodu) żeby szef zespołu miał pogląd na temat tego co robią jego pracownicy, mógł zareagować jeśli robią coś nietak, a przed swoim zwierzchnikiem mógł udzielić informacji na temat kosztów dalszych prac

widzę, że chyba jednak zgadzamy się ze sobą każdy ze swojej perspektywy :)

chyba tak :) dziękuję za dyskusję, dla mnie koniec ;)

dla mnie też, ja tez dziękuję :)

Temat: Code review - wasze opinie

Jarosław Ż.:
Ze swojego doświadczenia powiem: nawet malutki CRM dla 15 osobowej firmy wymaga dużej wiedzy z obu wyżej wskazanych obszarów (wymagana wiedza lekarza nie zależy od tego czy ma leczyć kompanie wojska czy jednego przedszkolaka). Moje doświadczenie mówi: wielkość projektu nie determinuje ilości ról w projekcie. Ja nawet do małych projektów angażuję np. na godzinę dziennie kierownika projektu czy koordynatora , bo jak sam jestem analitykiem i szefem projektu to narażam swojego klienta na porażkę.

Zdaję sobie z tego sprawę. Realizowałem CRM-y ale w tym przypadku miałem jasno zdefiniowane wymagania od klienta. Od zera to sobie napisałem oprogramowanie dla freelancerów, dość niewielki projekt bo jakieś 32K linii kodu i ze 20 formatek, to oczywiście stosowanie do swoich potrzeb. Dużo mu jeszcze brakuje żeby być pełnowartościowym oprogramowaniem, ale dość dobrze pozwala na kontrolowanie pracy w tym obszarze.