Temat: Kto płaci za dobry kod?

Kontynuując wątek: http://www.goldenline.pl/forum/3255980/jak-sie-teraz-p...
który poszedł w nieco inną stronę oto wniosek, a raczej pytanie które mi się nasunęło: "Kto płaci za dobry kod?"

Temat: Kto płaci za dobry kod?

Marcin M.:

Łukasz K.:
Będąc też kilkakrotnie na rekrutacjach zauważyłem, że zawsze pojawiają się tylko pytania ze znajomości języka lub biblioteki. Nigdy nie dostałem pytania sprawdzającego abstrakcyjne myślenie

Programowanie jest sztuką, wie to każdy kto z programuje z pasji. Problem w tym, że pracodawcy zwykle nie potrzebują ludzi, którzy potrafią sami przeanalizować biznes i stworzyć abstrakcję od początku. Potrzebny jest zastęp szeregowych programistów, którzy mogą nie mieć zielonego pojęcia o analizie obiektowej. Pytania o framework mają zapewnić, że pracownik będzie w stanie szybko wdrożyć się w kod i nie pogubi się w nim. Ogromna większość roboty to maintanace starych systemów, nie refactoring/developing.
Pisząc to wcale nie chcę wyrazić, że mi się to podoba. Moim zdaniem takie podejście jest tanie i skuteczne do czasu. Zatrudnianie programistów, którzy piszą bez podstawowych umiejętności obiektowych i robienie na zasadzie "ma działać" prowadzi do powstania potworów, w których po pewnym czasie nikt nie jest w stanie się połapać.

O ile w dużych firmach/korporacjach jest tak jak piszesz o tyle małe firmy, które chcą stworzyć własny produkt nie mogą sobie na to pozwolić. Właśnie dlatego rynek IT jest taki dynamiczny bo zespół kilkunastu bardzo dobrych programistów jest w stanie konkurować z gigantami i odbierać im rynek.Ten post został edytowany przez Autora dnia 02.06.13 o godzinie 11:12

Temat: Kto płaci za dobry kod?

Zgadzam się z Waszym punktem widzenia.

Z własnego wcześniejszego doświadczenia w dużych firmach wiem, że często rozwiązaniem problemów niewydajnego kodu jest zatrudnienie większej liczby programistów/zakupienie dodatkowej infrastruktury etc. Jest to raczej dość iluzoryczne rozwiązanie :)

Z drugiej strony, obecnie prowadząc swoją firmę, jakość i wydajność zawsze stawiamy na pierwszym miejscu - z racji tego, że w naszym biznesie (gry online) nie ma miejsca na długie czasy przetwarzania :), a z drugiej pozwala nam to ograniczać zbędne koszty.

Temat: Kto płaci za dobry kod?

Michał P.:
Kontynuując wątek: http://www.goldenline.pl/forum/3255980/jak-sie-teraz-p...
który poszedł w nieco inną stronę oto wniosek, a raczej pytanie które mi się nasunęło: "Kto płaci za dobry kod?"

Np. my (Nexelem.com). Crap w kodzie prowadzi do dodatkowych kosztów (oczywiście w długim terminie) i ogólnego niezadowolenia (nawet osobnika który ten crap wytworzył). Moje doświadczenia wskazują jednoznacznie, ze tworzenie dziadostwa *zawsze* się mści (i z reguły boli bardziej niż zrobienie od początku *porządnie*).

Temat: Kto płaci za dobry kod?

Wiadomo, że nikt nie zatrudnia specjalnie kiepskich programistów, czy specjalnie pisze potworne systemy. Moim zdaniem głównej mierze problem wynika z:
- przepychanek na linii biznes-IT, czyli dla biznesu ma być na wczoraj i najlepiej za 0 PLN bo kryzys etc..
- częstej zmiany teamu piszącego dany system, po kilku takich zmianach 3/4 systemów przypasowuje się do "wzorca" Big Ball of Mud
(http://en.wikipedia.org/wiki/Big_ball_of_mud)
- braku zrozumienia architektury i braku umiejętności obiektowych (szczególnie abstrakcyjnego myślenia) u części programistów

Żaden system nie powstaje od razu jednoznacznie źle napisany, wręcz przeciwnie, większość systemów projektują doświadczeni ludzie, którzy wiedzą co robią. Według mnie tym, co najbardziej zabija duże systemy jest nie trzymanie się pierwotnych założeń i architektury.
Czy nie mieliście może przypadku, że poprawiając coś napotkaliście na "przepięknie" napisany SQL pomimo tego, że do komunikacji z bazą służy określony interfejs ? Czy logikę biznesową umieszczoną w kodzie strony .jsp, pomimo tego, że istnieje jej odpowiednik w obiektach domeny ? Refaktoring czegoś takiego jest bardzo trudnym i drogim procesem, dlatego też zwykle się to zostawia. Po pewnym czasie takie zmiany się nawarstwiają tworząc coś, czego nie da się utrzymywać.

Temat: Kto płaci za dobry kod?

Marcin M.:
....

Żaden system nie powstaje od razu jednoznacznie źle napisany, wręcz przeciwnie, większość systemów projektują doświadczeni ludzie, którzy wiedzą co robią. Według mnie tym, co najbardziej zabija duże systemy jest nie trzymanie się pierwotnych założeń i architektury.
Czy nie mieliście może przypadku, że poprawiając coś napotkaliście na "przepięknie" napisany SQL pomimo tego, że do komunikacji z bazą służy określony interfejs ? Czy logikę biznesową umieszczoną w kodzie strony .jsp, pomimo tego, że istnieje jej odpowiednik w obiektach domeny ? Refaktoring czegoś takiego jest bardzo trudnym i drogim procesem, dlatego też zwykle się to zostawia. Po pewnym czasie takie zmiany się nawarstwiają tworząc coś, czego nie da się utrzymywać.

Prawda. Dlatego zawsze wyznawałem zasadę skauta - która w przypadku Nexelem jest na poziomie circa 20% czasu poświęconego na pisanie nowej funkcjonalności (czas poświęcany na ciągły mniej lub bardziej drobny refactoring).
Ale samo to już jest niezwykle rzadkie (przynajmniej w polskich firmach większych rozmiarów).Ten post został edytowany przez Autora dnia 02.06.13 o godzinie 21:31

Temat: Kto płaci za dobry kod?

Wiadomo, że nikt nie zatrudnia specjalnie kiepskich programistów, czy specjalnie pisze potworne systemy.
Moim zdaniem głównej mierze problem wynika z:
- przepychanek na linii biznes-IT, czyli dla biznesu ma być na wczoraj i najlepiej za 0 PLN bo kryzys etc..
- częstej zmiany teamu piszącego dany system, po kilku takich zmianach 3/4 systemów przypasowuje się do "wzorca" Big Ball of Mud
(http://en.wikipedia.org/wiki/Big_ball_of_mud)
- braku zrozumienia architektury i braku umiejętności obiektowych (szczególnie abstrakcyjnego myślenia) u części programistów

Żaden system nie powstaje od razu jednoznacznie źle napisany, wręcz przeciwnie, większość systemów projektują doświadczeni ludzie, którzy wiedzą co robią. Według mnie tym, co najbardziej zabija duże systemy jest nie trzymanie się pierwotnych założeń i architektury.
Czy nie mieliście może przypadku, że poprawiając coś napotkaliście na "przepięknie" napisany SQL pomimo tego, że do komunikacji z bazą służy określony interfejs ? Czy logikę biznesową umieszczoną w kodzie strony .jsp, pomimo tego, że istnieje jej odpowiednik w obiektach domeny ? Refaktoring czegoś takiego jest bardzo trudnym i drogim procesem, dlatego też zwykle się to zostawia. Po pewnym czasie takie zmiany się nawarstwiają tworząc coś, czego nie da się utrzymywać.

Hm... z postu wynika (może się mylę), że _zazwyczaj_ "projekt (projektanci) jest dobry, programiści są dobrzy a system _czasami_(?) kończy w błocie"; chyba czegoś nie rozumiem.Ten post został edytowany przez Autora dnia 02.06.13 o godzinie 22:07

Temat: Kto płaci za dobry kod?

Marcin M.:
Wiadomo, że nikt nie zatrudnia specjalnie kiepskich programistów, czy specjalnie pisze potworne systemy. Moim zdaniem głównej mierze problem wynika z:
- przepychanek na linii biznes-IT, czyli dla biznesu ma być na wczoraj i najlepiej za 0 PLN bo kryzys etc..
- częstej zmiany teamu piszącego dany system, po kilku takich zmianach 3/4 systemów przypasowuje się do "wzorca" Big Ball of Mud
(http://en.wikipedia.org/wiki/Big_ball_of_mud)
- braku zrozumienia architektury i braku umiejętności obiektowych (szczególnie abstrakcyjnego myślenia) u części programistów

Żaden system nie powstaje od razu jednoznacznie źle napisany, wręcz przeciwnie, większość systemów projektują doświadczeni ludzie, którzy wiedzą co robią. Według mnie tym, co najbardziej zabija duże systemy jest nie trzymanie się pierwotnych założeń i architektury.
Czy nie mieliście może przypadku, że poprawiając coś napotkaliście na "przepięknie" napisany SQL pomimo tego, że do komunikacji z bazą służy określony interfejs ? Czy logikę biznesową umieszczoną w kodzie strony .jsp, pomimo tego, że istnieje jej odpowiednik w obiektach domeny ? Refaktoring czegoś takiego jest bardzo trudnym i drogim procesem, dlatego też zwykle się to zostawia. Po pewnym czasie takie zmiany się nawarstwiają tworząc coś, czego nie da się utrzymywać.

Zgadzam się.
Dodam tylko, że w mojej opinii degradacja systemów następuje w głównej mierze nie przez nowych (trzeba czasu, żeby zrozumieli aplikację) lub niedoświadczonych programistów, lecz przez osoby które odbierają przydzielone im wcześniej zadania czyli Team Leadów / Seniorów etc.
Jako osoby z większym doświadczeniem i znajomością systemu powinni "stać na straży" jakości kodu.

Czy zdarzyło się Wam kiedykolwiek, że oddane przez Was zadanie realizujące poprawnie swoją funkcjonalność zostało odrzucone (zwrócone do poprawy) tylko z powodu niskiej jakości kodu?
W mojej karierze nie miałem takiego przypadku chociaż teraz jak czasami przeglądam kod, który pisałem jeszcze kilka lat temu to mi wstyd :)Ten post został edytowany przez Autora dnia 02.06.13 o godzinie 22:16

Temat: Kto płaci za dobry kod?

Łukasz K.:

Jako osoby z większym doświadczeniem i znajomością systemu powinni "stać na straży" jakości kodu.

Tak - ale zawsze się coś prześlizgnie - nie ma siły (może reviewer ma kaca ? ;). Po to jest ciągły refactoring aby takie rzeczy zamiatać nawet jak się prześlizgną.

Czy zdarzyło się Wam kiedykolwiek, że oddane przez Was zadanie realizujące poprawnie swoją funkcjonalność zostało odrzucone (zwrócone do poprawy) tylko z powodu niskiej jakości kodu?
W mojej karierze nie miałem takiego przypadku chociaż teraz jak czasami przeglądam kod, który pisałem jeszcze kilka lat temu to mi wstyd :)

eeee.... zwykle u nas będzie chyba mniej więcej co drugie review (np. mało mówiąca nazwa metody, za długa metoda, zbyt skomplikowana metoda, nazewnictwo zmiennych itd itp).
Zresztą jest to dosyć naturalne. Krytyczne dla tworzonego kodu jest to by był czytelny i zrozumiały. Z założenia jest on bardziej zrozumiały dla twórcy (zwłaszcza w momencie lub blisko momentu tworzenia - z racji tego, że jesteśmy w kontekście). Reviewer jest pierwszą linią weryfikacji czy aby na pewno utworzony kod jest zrozumiały dla kogoś kto jest trochę poza kontekstem ale musi dany kod zrozumieć.

Kod jest kilka razy częściej czytany niż pisany. To jedno / dwa odbicia zadania na review przez czytelność i następujące poprawki (w momencie kiedy wszyscy zainteresowani są blisko kontekstu) zwrócą się z nawiązką za miesiąc, kwartał czy pół roku.Ten post został edytowany przez Autora dnia 02.06.13 o godzinie 22:24

Temat: Kto płaci za dobry kod?

Hola hola, za chwilę zaczniecie recytować CC wuja Boba... Problem polega na tym, że dla zdecydowanej większości biznesmenów to nie przemawia. Po prostu pisać chlewiaty kod bardziej się opłaci. Dla nich liczy się zysk tu i teraz, a kodzenie utożsamiają bardziej z pracą akordową niż sztuką. Jak przemówić do biznesmenów pseudo-(kiedyś)-programistów? Jak udowodnić wymierne długofalowe korzyści? Czy to w ogóle możliwe...

Temat: Kto płaci za dobry kod?

Michał P.:
Hola hola, za chwilę zaczniecie recytować CC wuja Boba... Problem polega na tym, że dla zdecydowanej większości biznesmenów to nie przemawia. Po prostu pisać chlewiaty kod bardziej się opłaci. Dla nich liczy się zysk tu i teraz, a kodzenie utożsamiają bardziej z pracą akordową niż sztuką. Jak przemówić do biznesmenów pseudo-(kiedyś)-programistów? Jak udowodnić wymierne długofalowe korzyści? Czy to w ogóle możliwe...

Mówię z perspektywy właściciela firmy - za każdą godzinę refactoringu muszę zapłacić. Jasne czasami trzeba zrobić coś na okrętkę (ale musi to być ekstremalnie rzadko i trzeba to wtedy zamknąć szczelnymi granicami i otworzyć od razu task na refactoring). Ważne aby każdy manago (czy biznesmenów - jak ich nazywasz) rozumiał, że to jest dług i tyle:
a) trzeba będzie go spłacić
b) trzeba będzie zapłacić więcej.
Czasami ten tradeoff się opłaca - ale raczej rzadziej niż się wydaje (nigdy nie ma później mniej pracy).

Raczej się nam zdarza (jak już trzeba) robić coś co nie jest full-wypas wersją danej funkcjonalności ale za to dobrze robiącą to co ma robić (tą swoją okrojoną część).

Generalnie literatury i badań na ten temat było sporo. Łatwiej to oczywiście przemawia do biznesmenów o przeszłości technicznej. Jeżeli chodzi o suche dane to polecam poszperać u Capersa-Jonesa.

Temat: Kto płaci za dobry kod?

Pawel D.:

eeee.... zwykle u nas będzie chyba mniej więcej co drugie review (np. mało mówiąca nazwa metody, za długa metoda, zbyt skomplikowana metoda, nazewnictwo zmiennych itd itp).
Zresztą jest to dosyć naturalne. Krytyczne dla tworzonego kodu jest to by był czytelny i zrozumiały. Z założenia jest on bardziej zrozumiały dla twórcy (zwłaszcza w momencie lub blisko momentu tworzenia - z racji tego, że jesteśmy w kontekście). Reviewer jest pierwszą linią weryfikacji czy aby na pewno utworzony kod jest zrozumiały dla kogoś kto jest trochę poza kontekstem ale musi dany kod zrozumieć.

Chyba tylko takim podejściem małe firmy są w stanie osiągnąć sukces.
Zazdroszczę "jakości" w pracy.

Temat: Kto płaci za dobry kod?

Łukasz K.:

Chyba tylko takim podejściem małe firmy są w stanie osiągnąć sukces.
Zazdroszczę "jakości" w pracy.

Chyba nie ma specjalnie czego zazdrościć. Z czasem okazało się, że to zaledwie czubek góry lodowej jeśli chodzi o jakość (i swoją drogą temat na zupełnie inny wątek).

Temat: Kto płaci za dobry kod?

Jakub W.:
Hm... z postu wynika (może się mylę), że _zazwyczaj_ "projekt (projektanci) jest dobry, programiści są dobrzy a system _czasami_(?) kończy w błocie"; chyba czegoś nie rozumiem.

Nigdzie nie napisałem że programiści są zwykle dobrzy. Napisałem, że każda firma chcę zatrudniać dobrych programistów. Dlaczego nie zawsze się to udaje, to też ciekawy temat na kolejną dyskusję.

Temat: Kto płaci za dobry kod?

Michał P.:
Hola hola, za chwilę zaczniecie recytować CC wuja Boba... Problem polega na tym, że dla zdecydowanej większości biznesmenów to nie przemawia.

Dlatego, jeżeli chcesz przekonywać do dobrych praktyk, to idź "uzbrojony". Tak jak napisał Paweł - literatury i badań było sporo i jak poszperasz w sieci, to z pewnością będziesz w stanie jakąś krótką, ale ciekawą prezentację stworzyć. A jeżeli dorzucisz do tego kilka wymownych przykładów tzn. takich, z odpowiednimi cyframi, to już każda osoba, która będzie miała wydać jakiekolwiek pieniądze, zastanowi się, czy rzeczywiście opłaca się tworzyć "po łebkach".

Po prostu pisać chlewiaty kod bardziej się opłaci. Dla nich liczy się zysk tu i teraz [...]

Ludzie mają skłonność do patrzenia krótkowzrocznego, dlatego warto uzmysłowić im, że niektóre decyzje nie oznaczają cięcia kosztów, są równoznaczne z ich przesunięciem w czasie i zwiększeniem.

Jak przemówić do biznesmenów pseudo-(kiedyś)-programistów? Jak udowodnić wymierne długofalowe korzyści?

Dane, statystyki i przykłady, a nie opowieści, o tym, że trzeba dbać o jakość kodu, bo rośnie dług techniczny. Do niewielu klientów takie argumenty przemówią (chyba, że mają już za sobą przykre doświadczenia). Co innego, jeżeli przedstawisz informacje pokazujące co się dzieje, gdy nie stosuje się dobrych praktyk; przedstawisz cyfry, które dają powód do zastanowienia.

Czy to w ogóle możliwe...

Programiści zajmują się rozwiązywaniem problemów i ten, jak każdy inny, daje się rozwiązać. Chociaż nie zawsze w idealny sposób i niestety jeszcze nikt żadnego wzorca nie odkrył ;)

Temat: Kto płaci za dobry kod?

@Sebastian, to nie jest zły pomysł... Znasz jakieś wiarygodne badania na ten temat? I nie koniecznie tylko ze Stanów, kiedyś widziałem chyba w chipie nawet takie artykuł o jakości kodu wytwarzanego w PHP - aczkolwiek nie chcę teraz wywoływać wojny, wiem że PHP działa na niektórych jak płachta na byka :) Ja tam akurat lubię.

Ale wracając do meritum, jeśli nie konkretne badania, to przynajmniej firmy które się tym zajmują np. ObjectMentor Martina... Znasz coś jeszcze?

Temat: Kto płaci za dobry kod?

Napisałem Ci przecież - Capers-Jones. Jak wpiszesz w google to znajdziesz sporo materiałów takich jak np. opracowanie The Economics of Software Quality czy Combining Inspections, Static Analysis and Testing to Achieve Defect Removal Efficiency Above 95%.

A jak poświęcisz więcej niż 5min to pewnie jeszcze kilka kolejnych...

PS. A jak dorzucisz jeszcze frazę "shift left software" to znajdziesz artykuły o średnich kosztach defektów z różnych faz które uciekły na produkcję. To + powyższe daje Ci niezły punkt startowy.Ten post został edytowany przez Autora dnia 03.06.13 o godzinie 13:44

Temat: Kto płaci za dobry kod?

@Paweł już podał sporo i tak, jak napisał, jeżeli poświęcisz pięć minut to z pewnością znajdziesz sporo.
Kiedyś robiłem taką prezentację, ale niestety nie udało mi się jej odnaleźć, ale z tego co kojarzę, to stworzenie jej nie zajęło więcej niż 1-2 h.

A kwestię języka zostaw, jakość oprogramowania nie zależy od wykorzystywanego języka, a od umiejętności programistów i zastosowanych technik i procesów. Widziałem świetne kody w PHPie i przerażające w Javie, jakość jest ponadjęzykowa :)

Temat: Kto płaci za dobry kod?

A kwestię języka zostaw, jakość oprogramowania nie zależy od wykorzystywanego języka, a od umiejętności programistów i zastosowanych technik i procesów. Widziałem świetne kody w PHPie i przerażające w Javie, jakość jest ponadjęzykowa :)

Tak, wiem. PHP przytoczyłem tylko dlatego że ten artykuł o tym był. Też wyznaję zasadę żeby nie przywiązywać się za bardzo do konkretnej technologii.

Temat: Kto płaci za dobry kod?

Problem w tym, że bardzo ciężko zmierzyć i ocenić postęp tej degradacji, ani określić kiedy i jak mocno to zaboli. Są systemy, które z różnych względów(małe skomplikowanie, stały zespół, mała ilość zmian, dobrze narzucona architektura etc...) pozostają w formie przez wiele lat, bez jakiejkolwiek kontroli kodu.
Przypuśćmy, że w dodatku do starego jest tworzony nowy system i po pierwszej zmianie programiści krzykną o x kasy na rewizje jego kodu. Kierownictwo najprawdopodobniej uzna to za ekstrawagancje działu IT. Przecież wszystko działa, jedyne co trzeba to "kilka małych poprawek". Ponadto jest stary system, który tego nie wymagał, więc wszystkie prezentowane dane nie będą przekonujące. Co gorsze, nawet jeśli kierownictwo będzie świadome problemu, to może się łudzić, że nie będzie potrzeba dużo więcej zmian, i że lepszym wyjściem będzie zostawienie syfu i "przeforsowanie" ostatnich zmian. Później okazuje się, że takie myślenie jest od pięciu wersji kodu, co dzieje się dalej dokładnie wiecie.
Z tego co doświadczyłem, najlepszym rozwiązaniem takiego błędnego koła, jest świadoma osoba pół-techniczna w kierownictwie.