Temat: Code review - wasze opinie

Rafał G.:
Co jest droższe dla klienta, częstsze - przyrostowe dostarczanie nowych funkcjonalności przy zapewnieniu jak najkrótszego Time to Market, czy być może rzadsze dostarczanie kompletnej funkcjonalności (w modelu Watferall'owym), która w momencie dostarczenia już w powiedzmy 50% nie jest już potrzebna ?

1. jeżeli zapewnisz "open close principia" to OK
2. co tu rozumiesz pod pojęciem "waterfall"? bo jeżeli mityczne 5 lat analizy i 10 lat developemtu to jesteś jakieś 50 lat wstecz
3. waterfall to "powiedzmy 50% nie jest już potrzebna" to taki mit do straszenia dzieci... ile razy brałeś udział w takim projekcie??

Wydaje się, że klienci muszą teraz liczyć swoje pieniądze jak nigdy wcześniej - co może być wskazówką, czemu masowo porzucają podejście sekwencyjne do produkcji softu na rzecz tego iteracyjnego.

wskazówka: nie porzucają a wracają :) bo z tego żyję w 100% i forsują umowy fixed-price niedopuszczając do kolejnej "agile/T&M"

Być może nie dotyczy to mniejszych projektów, które jeszcze można jakoś ogarnąć przy planowaniu, ale duże projekty są już pod tym względem bezlitosne.

i chodzi generalnie o większe projekty: postaw przyrostowo drapacz chmur... planowanie (jak się potrafi) daje kilkukrotnie niższe koszty niż przyrostowe zwinne bez planowania ... ale to tylko z praktyki wiem... swojej i nie tylko

ile razy w życiu porządnie zaprojektowałeś to co potem zakodowałeś???Ten post został edytowany przez Autora dnia 27.01.14 o godzinie 22:41

Temat: Code review - wasze opinie

Kamil M.:
Panowie Żeliński i Wojt jak zawsze w swoim stylu na temat nowoczesnych metod wytwarzania kodu :)

nowoczesnych :D czy nowy bo to nie to samo :D

Temat: Code review - wasze opinie

Jarosław Ż.:

3. waterfall to "powiedzmy 50% nie jest już potrzebna" to taki mit do straszenia dzieci... ile razy brałeś udział w takim projekcie??

aż chciałoby się zapytać na odczepne - a ile razy Ty brałeś udział w DOBRZE PROWADZONYM projekcie agile'owym?

wskazówka: nie porzucają a wracają :) bo z tego żyję w 100% i forsują umowy fixed-price niedopuszczając do kolejnej "agile/T&M"

dlatego, że się sparzyli trafiając na niekompetentnych ludzi. W forsowanym przez Ciebie podejściu jest takie samo ryzyko, że ktoś coś zawali, źle zaprojektuje i też będą koszty, płacz i zgrzytanie zębów

nowoczesnych :D czy nowy bo to nie to samo :D

przeredaguję:
Panowie Żeliński i Wojt w charakterystycznym dla siebie tonie "i tak gówno wiecie" na temat Agile'u, testów jednostkowych, code review i refaktoryzacji :)

Temat: Code review - wasze opinie

Jarosław Ż.:
2. co tu rozumiesz pod pojęciem "waterfall"? bo jeżeli mityczne 5 lat analizy i 10 lat developemtu to jesteś jakieś 50 lat wstecz

no może np właśnie to: http://en.wikipedia.org/wiki/Waterfall_model ? Widzę, że bardzo lubi Pan wyolbrzymiać. Nigdzie nie jest napisane, że takie sekwencyjne podejście do projektu automatycznie oznacza jakieś "mityczne" wymiary. Jest po prostu sekwencyjne, a co za tym idzie mniej elastyczne w przypadku konieczności naniesienia zmian.

3. waterfall to "powiedzmy 50% nie jest już potrzebna" to taki mit do straszenia dzieci... ile razy brałeś udział w takim projekcie??

Kilku. Każdy z nich zakończył się opóźnieniem - spowodowanym zmianą wymagań przez klienta na etapie powiedzmy 50-70% zaawansowania prac developerskich. Co z tego, że umowa jest spisana z przecinkami ? Zdecydowanie wolę ciągłą współpracę z klientem niż opieranie się na przecinkach w umowie i dziale prawnym.

Wydaje się, że klienci muszą teraz liczyć swoje pieniądze jak nigdy wcześniej - co może być wskazówką, czemu masowo porzucają podejście sekwencyjne do produkcji softu na rzecz tego iteracyjnego.

wskazówka: nie porzucają a wracają :) bo z tego żyję w 100% i forsują umowy fixed-price niedopuszczając do kolejnej "agile/T&M"

To jak Pan wytłumaczy sytuację, w której coraz więcej firm wdraża Scrum i coraz więcej firm docenia szeroko pojęte metodologie Agile oraz powiązane z nią dobre praktyki (CI, Continous Delivery itp.) ?

Być może nie dotyczy to mniejszych projektów, które jeszcze można jakoś ogarnąć przy planowaniu, ale duże projekty są już pod tym względem bezlitosne.

i chodzi generalnie o większe projekty: postaw przyrostowo drapacz chmur... planowanie (jak się potrafi) daje kilkukrotnie niższe koszty niż przyrostowe zwinne bez planowania ... ale to tylko z praktyki wiem... swojej i nie tylko

Porównanie trochę z innej bajki :) Sądząc po Pana wypowiedziach można sądzić, że dosłownie zjadł Pan zęby na większości zagadnień związanych z programowaniem i zarządzaniem projektami, a nie wie Pan tak podstawowej rzeczy jak ta, że nie każde narzędzie nadaje się do wszystkiego.

Ale nawet zostając przy obszarze "budowlanym" to przykład polskich autostrad pokazuje, że jednak można nie być w stanie zaplanować wszystkiego (gigantycznego wzrostu cen materiałów, złodziejstwa na budowie, chińskich podwykonawców itp itd).

ile razy w życiu porządnie zaprojektowałeś to co potem zakodowałeś???

Mam nadzieję, że wiele razy. Pytanie tylko - czy muszę zaprojektować 6 miesięcy wprzód, żeby nazwać to dobrym projektem ? Czy może 3 to już za mało? Jaki czas/jaka ilość pracy musi być zaprojektowana, żeby spełniła Pana definicję "porządnego zaprojektowania" ?Ten post został edytowany przez Autora dnia 28.01.14 o godzinie 00:19

Temat: Code review - wasze opinie

Jarosław Ż.:

Rafał G.:
Co jest droższe dla klienta, częstsze - przyrostowe dostarczanie nowych funkcjonalności przy zapewnieniu jak najkrótszego Time to Market, czy być może rzadsze dostarczanie kompletnej funkcjonalności (w modelu Watferall'owym), która w momencie dostarczenia już w powiedzmy 50% nie jest już potrzebna ?

1. jeżeli zapewnisz "open close principia" to OK

Wg poniższego źródła zachodzi sprzeczność w tym co piszesz.
http://en.wikipedia.org/wiki/Open/closed_principle

W pierwotnym założeniu "Open/closed principle" zapewniało unikanie code review przez akcentowanie dziedziczenia. A właśnie dyskutujemy o code review...

Obecnie unika się raczej zmiany interfejsu niż implementacji.

Unikanie code review jest jak unikanie pisania makr w Excelu - może się udać, tylko po co???

Temat: Code review - wasze opinie

Nowoczesnych czyli takich w których masz czas na popełnianie błędów, wybór złych technologii jak i masz czas na wycofanie się ze złych decyzji i pójście inną drogą :)

Też pracowałem w waterfallu bliskim PRINCE2 i nie znajduję większych zalet oprócz dupochronów w postaci tony makulatury. Bądź co bądź wydaje mi się że to czego klient oczekuje to przede wszystkim produkt dobrej jakości, dostarczany w przewidywalnym czasie a nie kruczki prawne w umowach i specyfikacjach.

Temat: Code review - wasze opinie

Kamil M.:

Jarosław Ż.:

3. waterfall to "powiedzmy 50% nie jest już potrzebna" to taki mit do straszenia dzieci... ile razy brałeś udział w takim projekcie??

aż chciałoby się zapytać na odczepne - a ile razy Ty brałeś udział w DOBRZE PROWADZONYM projekcie agile'owym?

unikam jak ognia, te kilka razy (jako podwykonawca miałem tylko swój kawałek do zrobienia ale znam całe te projekty z ich skutkami) to porażki, ale może miałem pecha, dodam uczciwie, że nie mam na myśli projektów badawczych R&D i start-up'ów tylko trudne biznesowe projekty.

dlatego, że się sparzyli trafiając na niekompetentnych ludzi.

tu pełna zgoda

W forsowanym przez Ciebie podejściu jest takie samo ryzyko, że ktoś coś zawali, źle zaprojektuje i też będą koszty, płacz i zgrzytanie zębów

ja od lat niczego nie forsuję, pokazuje jednie że planowanie (bo tym także jest projektowanie) powoduje, że błędne koncepcje są odrzucane o rząd a nie raz o dwa rzędy niższym kosztem i na samym początku projektu jeszcze na etapie studium wykonywalości...

po drugie "moje podejście" to nie moje podejście tylko jedno z popularnych na świecie podejść (zamiast wikipediii i blogów polecam książki Larmana i wielu innych), polegające na dość rygorystycznym obiektowym projektowaniu poprzedzającym kodowanie (to tylko tak zwane OOAD), dzięki czemu projekty, szczególnie te duże i złożone, mają od początku znaną i opanowaną architekturę.

nowoczesnych :D czy nowy bo to nie to samo :D

przeredaguję:
Panowie Żeliński i Wojt w charakterystycznym dla siebie tonie "i tak gówno wiecie" na temat Agile'u, testów jednostkowych, code review i refaktoryzacji :)

nie, ja i Jakub zadajemy obrzydliwie proste pytania na które nie potrafią udzielić odpowiedzi zwolennicy tak zwanych zwinnych metod, przypomnę:

- jak (jakim wzorem) mierzysz jakość kodu
- jak "code review" wpływa na poprawę tego wskaźnika
- ile kosztuje stosowanie tej metody vs. inne (benchmarkking)

to obrzydliwie proste pytania jakie zada każdy księgowy projektu.

"Panowie Żeliński i Wojt w charakterystycznym dla siebie tonie" po prostu zadają te proste pytania, na które z reguły nie padają konkretne odpowiedzi.

Problem z metodami o jakich "piszecie Wy" polega na tym, że to metody bez mierników... wiec mówienie o podnoszeniu ich jakości czy ich wyższości nad innymi nie ma żadnego sensu bo to niesprawdzalne tezy.

A projekty mają bardzo prosty miernik jakości w postaci porównania "planowanego terminu, zakresu i budżetu" z wykonanym. Bajanie o zmienności wymagań w toku itp. to tylko uznanie, że się nie panuje nad zakresem projektu. Bajanie, że mityczny wodospad to jakieś wielomiesięczne szczegółowe i niepotrzebne planowanie to dowód, że ten kto tak mówi, nawet raz nie brał w takim projekcie udziału (tak się robiło 40 lat temu ale przyznaję, że niektóre dzisiejsze duże firmy nadal tak postępują).

Gdyby klienci w projektach za które płacą, mogli zobaczyć kod napisany i wyrzucony do kosza, tak jak mogą zobaczyć odpadki po zrobieniu stołu przez stolarza, i gdyby mogli ze zrozumieniem zobaczyć ten wynikowy kod jak mogą zobaczyć stół od spodu, to Agile (tak pojmowany jak się tu pisze) pozostał by tylko na stronach swojego manifestu...

Temat: Code review - wasze opinie

Rafał G.:

Jarosław Ż.:
2. co tu rozumiesz pod pojęciem "waterfall"? bo jeżeli mityczne 5 lat analizy i 10 lat developemtu to jesteś jakieś 50 lat wstecz

no może np właśnie to: http://en.wikipedia.org/wiki/Waterfall_model ?

wybacz, ale żadna z uczelni, z która współpracuje nie uznaje już WIKi jako źródła, ja też od lat...

Jest po prostu sekwencyjne, a co za tym idzie mniej elastyczne w przypadku konieczności naniesienia zmian.

To niestety nie jest prawda, nanoszenie zmian na etapie projektowania jest znacznie szybsze i tańsze. Poszerzanie zakresu w dobrym projekcie praktycznie nie wymaga zmian.

3. waterfall to "powiedzmy 50% nie jest już potrzebna" to taki mit do straszenia dzieci... ile razy brałeś udział w takim projekcie??

Kilku. Każdy z nich zakończył się opóźnieniem - spowodowanym zmianą wymagań przez klienta na etapie powiedzmy 50-70% zaawansowania prac developerskich.

tu przytoczę słowa Twoje kolegi powyżej: niekompetencja. Dodam, że jeżeli klient zmienia wymagania w toku projektu, to jest to niekompetencja tego klienta.

Co z tego, że umowa jest spisana z przecinkami ? Zdecydowanie wolę ciągłą współpracę z klientem niż opieranie się na przecinkach w umowie i dziale prawnym.

Ja też, ja jednak pisząc o umowie mam na myśli część opisująca zakres projektu.

Wydaje się, że klienci muszą teraz liczyć swoje pieniądze jak nigdy wcześniej - co może być wskazówką, czemu masowo porzucają podejście sekwencyjne do produkcji softu na rzecz tego iteracyjnego.

wskazówka: nie porzucają a wracają :) bo z tego żyję w 100% i forsują umowy fixed-price niedopuszczając do kolejnej "agile/T&M"

To jak Pan wytłumaczy sytuację, w której coraz więcej firm wdraża Scrum i coraz więcej firm docenia szeroko pojęte metodologie Agile oraz powiązane z nią dobre praktyki (CI, Continous Delivery itp.) ?

bo to nadal nowinka i szukanie panaceum na brak planowania i (faktycznie) nie raz brak kompetencji biznesowych po stronie zamawiających, ja zaś mam coraz więcej klientów, którzy z tych metod rezygnują po pierwszych tak prowadzonych projektach.

i chodzi generalnie o większe projekty: postaw przyrostowo drapacz chmur... planowanie (jak się potrafi) daje kilkukrotnie niższe koszty niż przyrostowe zwinne bez planowania ... ale to tylko z praktyki wiem... swojej i nie tylko

Porównanie trochę z innej bajki :) Sądząc po Pana wypowiedziach można sądzić, że dosłownie zjadł Pan zęby na większości zagadnień związanych z programowaniem i zarządzaniem projektami, a nie wie Pan tak podstawowej rzeczy jak ta, że nie każde narzędzie nadaje się do wszystkiego.

a gdzie napisałem, że cokolwiek się nadaje do wszystkiego? Są projekty typu R&D czy sturt-up'y, które są prowadzone "zwinie" bo tu nie ma zakresu i trudno je prowadzić inaczej, i wspominam o tym nie raz. Większość projektów w rodzaju portale społecznościowe czy nowatorskie pomysły to materiał na metodę "zabieramy się za to, może coś z tego wyjdzie" i nie widz e w tym niczego złego. Ale realizacja projektu np. "nowy system CRM" czy "nowy system zarządzania magazynem" itp. to twardy biznes a nie prace badawcze.

W kwestii moich "zębów" - 100% moich projektów od prawie 10 lat to sprzątanie po zwinnych zespołach więc mam porównanie, bo nie raz dokładnie ten sam projekt zaczynam jeszcze raz od początku, bo po poprzednikach niczego nie można powtórnie wykorzystać.

Ale nawet zostając przy obszarze "budowlanym" to przykład polskich autostrad pokazuje, że jednak można nie być w stanie zaplanować wszystkiego (gigantycznego wzrostu cen materiałów, złodziejstwa na budowie, chińskich podwykonawców itp itd).

nasze autostrady raczej nie są chlubnym przykładem, zamiast państwowego marnotrawstwa sugeruję jako przykład raczej jednak prywatne inwestycje w centrum miasta typu biurowce lub wielkie osiedla.

ile razy w życiu porządnie zaprojektowałeś to co potem zakodowałeś???

Mam nadzieję, że wiele razy. Pytanie tylko - czy muszę zaprojektować 6 miesięcy wprzód, żeby nazwać to dobrym projektem ?

a co Wy z tymi "6 m-cy naprzód", nie straszmy ludzi, czytają....

Czy może 3 to już za mało? Jaki czas/jaka ilość pracy musi być zaprojektowana, żeby spełniła Pana definicję "porządnego zaprojektowania" ?

Chodzi o to by zaprojektować a nie żeby spędzać czas, długie spędzanie czasu na współpracy z klientem to domena Agile i projektów T&M. Jakości projektu nie ocenia się po tym ile czasu nad nim spędzono, a po tym co z niego zostało po skończeniu implementacji i wdrożenia.

Temat: Code review - wasze opinie

Piotr L.:

Jarosław Ż.:

Rafał G.:
Co jest droższe dla klienta, częstsze - przyrostowe dostarczanie nowych funkcjonalności przy zapewnieniu jak najkrótszego Time to Market, czy być może rzadsze dostarczanie kompletnej funkcjonalności (w modelu Watferall'owym), która w momencie dostarczenia już w powiedzmy 50% nie jest już potrzebna ?

1. jeżeli zapewnisz "open close principia" to OK

Wg poniższego źródła zachodzi sprzeczność w tym co piszesz.
http://en.wikipedia.org/wiki/Open/closed_principle

o moim podejściu do WIKI już pisałem... proszę napisz coś od siebie...

Temat: Code review - wasze opinie

Piotr L.:
W pierwotnym założeniu "Open/closed principle" zapewniało unikanie code review przez akcentowanie dziedziczenia. A właśnie dyskutujemy o code review...

wybacz, to bełkot (ach ta WIKI). Open-close to cecha architektury AOO (zaliczana do dobrych praktyk projektowania), związana z hermetyzacją, dająca jako efekt przyrost kodu po pojawieniu się nowych wymagań (przypadków użycia) a nie wymianę juz powstałego kodu.

Obecnie unika się raczej zmiany interfejsu niż implementacji.

ale permanentna zmiana implementacji nie świadczy dobrze o jej autorze....

Temat: Code review - wasze opinie

Mateusz G.:
Nowoczesnych czyli takich w których masz czas na popełnianie błędów, wybór złych technologii jak i masz czas na wycofanie się ze złych decyzji i pójście inną drogą :)

wiem, T&M, za wszystko płaci klient, developer nie ponosi żadnego ryzyka projektu bo "współpracuje i stara się", tępię to jak karaluchy....

Też pracowałem w waterfallu bliskim PRINCE2 i nie znajduję większych zalet oprócz dupochronów w postaci tony makulatury.

patologiczne projekty....

Bądź co bądź wydaje mi się że to czego klient oczekuje to przede wszystkim produkt dobrej jakości, dostarczany w przewidywalnym czasie a nie kruczki prawne w umowach i specyfikacjach.

zdefiniuj to co wytłuściłem?

Temat: Code review - wasze opinie

Jarosław Ż.:

nie, ja i Jakub zadajemy obrzydliwie proste pytania na które nie potrafią udzielić odpowiedzi zwolennicy tak zwanych zwinnych metod, przypomnę:

- jak (jakim wzorem) mierzysz jakość kodu

nie mierzę formalnie, szkoda czasu ;) intuicyjnie widzę i czuję czy kod jest dobry kiedy mam go zmienić lub kiedy piszę testy jednostkowe, są one proste i kompletne
z ciekawości - a jakim wzorem Ty to mierzysz?

- jak "code review" wpływa na poprawę tego wskaźnika

o tym już wcześniej była mowa - code review pozwala utrzymać spójność w rozwiązaniu powtarzających się problemów (mniejszych niż możliwe do rozwiązania przez wzorce projektowe), wyeliminować potencjalne błędy osób nowych/młodych zanim będzie za późno żeby je cofnąć

- ile kosztuje stosowanie tej metody vs. inne (benchmarkking)

nasi klienci się nie skarżyli

Problem z metodami o jakich "piszecie Wy" polega na tym, że to metody bez mierników... wiec mówienie o podnoszeniu ich jakości czy ich wyższości nad innymi nie ma żadnego sensu bo to niesprawdzalne tezy.

ale my nie próbujemy udowodnić wyższości, tylko dajemy świadectwo tego, że metody zwinne są RÓWNIE skuteczne, jeśli są prowadzone przez kompetentne osoby

A projekty mają bardzo prosty miernik jakości w postaci porównania "planowanego terminu, zakresu i budżetu" z wykonanym.

jw. "nasi klienci się nie skarżyli", żaden z projektów w których brałem udział (oczywiscie moje doświadczenie jest jeszcze dość krótkie, więc też nie było ich znowu AŻ tyle) nie skończył się przeciąganiem o miesiące ani przekroczeniem budżetu o kilkadziesiat procent

Bajanie o zmienności wymagań w toku itp. to tylko uznanie, że się nie panuje nad zakresem projektu.

nie, to rzeczywistość projektów gdzie klient też często na początku nie wie do końca czego oczekuje i z tego wynikają (często duże) zmiany w trakcie kodowania. Tak, to domena startupów, R&D, itp., ale takich projektów jest mnóstwo i coraz więcej.

Temat: Code review - wasze opinie

Jarosław Ż.:

Kamil M.:

Jarosław Ż.:

3. waterfall to "powiedzmy 50% nie jest już potrzebna" to taki mit do straszenia dzieci... ile razy brałeś udział w takim projekcie??

aż chciałoby się zapytać na odczepne - a ile razy Ty brałeś udział w DOBRZE PROWADZONYM projekcie agile'owym?

unikam jak ognia, te kilka razy (jako podwykonawca miałem tylko swój kawałek do zrobienia ale znam całe te projekty z ich skutkami) to porażki, ale może miałem pecha, dodam uczciwie, że nie mam na myśli projektów badawczych R&D i start-up'ów tylko trudne biznesowe projekty.

dlatego, że się sparzyli trafiając na niekompetentnych ludzi.

tu pełna zgoda

W forsowanym przez Ciebie podejściu jest takie samo ryzyko, że ktoś coś zawali, źle zaprojektuje i też będą koszty, płacz i zgrzytanie zębów

ja od lat niczego nie forsuję, pokazuje jednie że planowanie (bo tym także jest projektowanie) powoduje, że błędne koncepcje są odrzucane o rząd a nie raz o dwa rzędy niższym kosztem i na samym początku projektu jeszcze na etapie studium wykonywalości...

po drugie "moje podejście" to nie moje podejście tylko jedno z popularnych na świecie podejść (zamiast wikipediii i blogów polecam książki Larmana i wielu innych), polegające na dość rygorystycznym obiektowym projektowaniu poprzedzającym kodowanie (to tylko tak zwane OOAD), dzięki czemu projekty, szczególnie te duże i złożone, mają od początku znaną i opanowaną architekturę.

nowoczesnych :D czy nowy bo to nie to samo :D

przeredaguję:
Panowie Żeliński i Wojt w charakterystycznym dla siebie tonie "i tak gówno wiecie" na temat Agile'u, testów jednostkowych, code review i refaktoryzacji :)

nie, ja i Jakub zadajemy obrzydliwie proste pytania na które nie potrafią udzielić odpowiedzi zwolennicy tak zwanych zwinnych metod, przypomnę:

- jak (jakim wzorem) mierzysz jakość kodu
- jak "code review" wpływa na poprawę tego wskaźnika
- ile kosztuje stosowanie tej metody vs. inne (benchmarkking)

to obrzydliwie proste pytania jakie zada każdy księgowy projektu.

To są pytania w rodzaju "po co panu tyle farby, Panie Rembrant?"

Żeby się przekonać jak code review wpływa na jakość kodu wystarczy wyłączyć warningi na jakiś czas w projekcie C++ lub udawać że ich nie ma. Może to nawet zaoszczędzić pracy - na początku.

Code review można nawet "zautomatyzować", pisząc jakieś długaśnie makra w jednym z narzędzi do analizy statycznej. Będzie to wymagało trochę inwestycji czasu, ale wyeliminuje subiektywną ocenę.
Piszę w cudzysłowie, bo dla mnie zautomatyzowane code review to po prostu analiza statyczna kodu.

wybacz, to bełkot (ach ta WIKI). Open-close to cecha architektury AOO (zaliczana do dobrych praktyk
projektowania), związana z hermetyzacją, dająca jako efekt przyrost kodu po pojawieniu się nowych wymagań
(przypadków użycia) a nie wymianę juz powstałego kodu.

Tak czy inaczej prowadzi to do powstania nowego kodu który trzeba sprawdzić.

Obecnie unika się raczej zmiany interfejsu niż implementacji.

ale permanentna zmiana implementacji nie świadczy dobrze o jej autorze....

Gdyby zmiana kodu pociągała za sobą przemyślenia w rodzaju "co ludzie powiedzą" to nie było by całej gałęzi programowania znanej powszechnie pod hasłem "maintenance". Ludzie radośnie tworzyli by nowe klasy/programy/projekty i nie musieli się uczyć czym jest inżynieria oprogramowania. Po prostu stwierdzaliby że odcinają się grubą kreską i robią coś po swojemu.
No chyba że uprawialiby metodologię Copy-Paste, ale to chyba jest passe?Ten post został edytowany przez Autora dnia 28.01.14 o godzinie 10:24

Temat: Code review - wasze opinie

Kamil M.:

Jarosław Ż.:

nie, ja i Jakub zadajemy obrzydliwie proste pytania na które nie potrafią udzielić odpowiedzi zwolennicy tak zwanych zwinnych metod, przypomnę:

- jak (jakim wzorem) mierzysz jakość kodu

nie mierzę formalnie, szkoda czasu ;)

no to ja od tego momentu dziękuje ;) także za resztę :)

Temat: Code review - wasze opinie

Piotr L.:

- jak (jakim wzorem) mierzysz jakość kodu
- jak "code review" wpływa na poprawę tego wskaźnika
- ile kosztuje stosowanie tej metody vs. inne (benchmarkking)

to obrzydliwie proste pytania jakie zada każdy księgowy projektu.

To są pytania w rodzaju "po co panu tyle farby, Panie Rembrant?"

nie, to są pytania: za co ja Panu płacę skoro płacę... a to co obserwuję w zespołach "agile" to permanentne unikanie mierzalności swojej pracy przy zachowaniu stałości terminów i wysokości wystawianych faktur...

Żeby się przekonać jak code review wpływa na jakość kodu wystarczy wyłączyć warningi na jakiś czas w projekcie C++ lub udawać że ich nie ma. Może to nawet zaoszczędzić pracy - na początku.

aha, czyli chodzi o literówki i błędy składniowe.... ok.. a jak się to ma do jakości oprogramowania?

Code review można nawet "zautomatyzować", pisząc jakieś długaśnie makra w jednym z narzędzi do analizy statycznej. Będzie to wymagało trochę inwestycji czasu, ale wyeliminuje subiektywną ocenę.
Piszę w cudzysłowie, bo dla mnie zautomatyzowane code review to po prostu analiza statyczna kodu.

wybacz, to bełkot (ach ta WIKI). Open-close to cecha architektury AOO (zaliczana do dobrych praktyk
projektowania), związana z hermetyzacją, dająca jako efekt przyrost kodu po pojawieniu się nowych wymagań
(przypadków użycia) a nie wymianę juz powstałego kodu.

Tak czy inaczej prowadzi to do powstania nowego kodu który trzeba sprawdzić.

a po co na innym wątku bronili TDD????

Obecnie unika się raczej zmiany interfejsu niż implementacji.

ale permanentna zmiana implementacji nie świadczy dobrze o jej autorze....

Gdyby zmiana kodu pociągała za sobą przemyślenia w rodzaju "co ludzie powiedzą" to nie było by całej gałęzi programowania znanej powszechnie pod hasłem "maintenance". Ludzie radośnie tworzyli by nowe klasy/programy/projekty i nie musieli się uczyć czym jest inżynieria oprogramowania. Po prostu stwierdzaliby że odcinają się grubą kreską i robią coś po swojemu.
No chyba że uprawialiby metodologię Copy-Paste, ale to chyba jest passe?

skoro tak postrzegasz "open-close" to ja tu już podziękuje...

Temat: Code review - wasze opinie

Jarosław Ż.:

Piotr L.:

- jak (jakim wzorem) mierzysz jakość kodu
- jak "code review" wpływa na poprawę tego wskaźnika
- ile kosztuje stosowanie tej metody vs. inne (benchmarkking)

to obrzydliwie proste pytania jakie zada każdy księgowy projektu.

To są pytania w rodzaju "po co panu tyle farby, Panie Rembrant?"

nie, to są pytania: za co ja Panu płacę skoro płacę... a to co obserwuję w zespołach "agile" to permanentne unikanie mierzalności swojej pracy przy zachowaniu stałości terminów i wysokości wystawianych faktur...

Żeby się przekonać jak code review wpływa na jakość kodu wystarczy wyłączyć warningi na jakiś czas w projekcie C++ lub udawać że ich nie ma. Może to nawet zaoszczędzić pracy - na początku.

aha, czyli chodzi o literówki i błędy składniowe.... ok.. a jak się to ma do jakości oprogramowania?

1) Warningi to nie błędy
2) Warningi dotyczą jakości oprogramowania, np. nieużywana zmienna lub użycie zmiennej przed ustawieniem jej wartości

Widać, że nie pracujesz jako programista lub nie rozumiesz zasad pracy na tym stanowisku (albo tylko tak to przedstawiasz). W każdym razie wychodzisz od założeń klienta, którego często gęsto jakość kodu nie obchodzi, bo chce mieć projekt na wczoraj i nie interesuje go że tego kodu już nigdzie nie użyjesz (może nawet napisał to w umowie - wyłączność).

Jak ma się code review do kosztów? Na pewno je zwiększa - koszty wytworzenia zmiany / oprogramowania.
Przy czym w założeniu zmniejsza koszty inne - utrzymania, rozwoju oprogramowania oraz wdrożenia nowego pracownika.

Temat: Code review - wasze opinie

Jarosław Ż.:

Kamil M.:

Jarosław Ż.:

nie, ja i Jakub zadajemy obrzydliwie proste pytania na które nie potrafią udzielić odpowiedzi zwolennicy tak zwanych zwinnych metod, przypomnę:

- jak (jakim wzorem) mierzysz jakość kodu

nie mierzę formalnie, szkoda czasu ;)

no to ja od tego momentu dziękuje ;) także za resztę :)

mimo wszystko, proszę o odpowiedź - jakiego Ty używasz wzoru do tego celu?

Temat: Code review - wasze opinie

Z Pana wypowiedzi wynika, że jest Pan niemalże rycerzem w lśniącej zbroi, który niczym na białym rumaku przyjeżdża i ratuje wszystkie możliwe projekty, które Ci niedouczeni i niekompetentni ludzie utopili próbując (ucząc się?) na nich metodyk zwinnych.

Ponieważ to PLAN jest odpowiedzią na wszystkie problemy. PLAN i jego brat PROJEKT. Te dwa mityczne byty, które uratują prawie każdy projekt - szczególnie w Pana rękach.

I za to tym razem ja też dziękuję, ale tym razem Panu. Gdyby nie Pan nie wiedziałbym teraz, że metodyki zwinne w ogóle nie działają, a to co obserwuję i czytam jest tylko jakimś wielkim oszustwem ludzi, którzy za pieniądze klienta robią co chcą, zawalają projekty i udają, że wszystko jest ok :)

Temat: Code review - wasze opinie

.Ten post został edytowany przez Autora dnia 13.08.16 o godzinie 21:39

Temat: Code review - wasze opinie

Paweł W.:
"Most Wojta-Zelinskiego - anomalia czasoprzestrzenna, która dowolne tematy zamienia w dyskusje o Agile"

Akurat w przypadku code - review to nie powinno dziwić.

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.

Eh ... gdybym zobaczył że tam jest moje nazwisko to odpowiedź była by mniej merytoryczna :-)
Z drugiej strony - fajnie być zakwalifikowanym do tak szacownego grona :-)Ten post został edytowany przez Autora dnia 28.01.14 o godzinie 17:21