Podczas rozmowy o zaletach czystego kodu, poprawianiu po innych (czasem sobie) nazw zmiennych, unikania warunkowych drabinek, ujednolicenia systemu komentarzy (o ile są potrzebne / wymagane) usłyszałem od przełożonego coś w stylu "jak się wyrobisz i jeszcze znajdziesz na to czas to ok", każda zmiana i tak musi być zacommitowana, więc dodatkowa robota"i na końcu "klienta nie obchodzą nazwy zmiennych, ma działać w odpowiednim czasie i tyle, nikt nie płaci za jednolite zasady stawiania średników, nowych linii i odstępów, to tylko nasza sprawa byśmy się połapali w tym co robimy". Brutalne, ale teraz dochodzę do wniosku, że prawdziwe.Czy dbanie o czytelny, dobry kod jest tak ważne by spowalniać proces developmentu jeżeli nie ma się do czynienia z kodem obliczonym na kilkanaście czy 20 albo więcej lat działania?
Jakie 20 lat... Za 2 miesiące już nie będziesz wiedział o co Ci chodziło w kodzie z wczoraj. Czysty kod wydłuża czas nowych ficzerów 2-krotnie ale za to skraca czas poprawek 4-krotnie (liczby wyssane z dupeczki)
No nie od dzisiaj wiadomo, że klienta g**no obchodzi to jak wygląda kod :D Rób tyle czystego ile Ci się uda/zdążysz, dokładnie tak jak powiedział przełożony.
Rób tak, żeby od razu był kod czysty, a nie, żebyś potem poprawiał. To się tyczy też kolegów z zespołu.
Nie bardzo rozumiem, szef stoi nad Tobą i mówi "za dużo tych literek w tej nazwie, skróć to, to będziesz szybciej pisał" albo "o, kompiluje się - na produkcję z tym"?
Kto określa ile zajmie jakaś część pracy (naprawienie buga, czy coś)? Szef przychodzi i mówi "ten tu defekt z jiry ma mi zniknąć za pół godziny, i nie waż mi się tylko dodać żadnego testu"?
Wiadomo, że nikt nie zapłaci za przepisanie całego istniejącego kodu wg Twojego widzimisię, niemniej pewnie ktoś płaci za naprawianie błędów, może zmiany funkcjonalności - wtedy w granicach rozsądku i możliwości stosuje się zasadę skautów (nie wiem czy harcerze też taką mają) - zostawiasz kod w lepszym stanie niż go znalazłeś. Czasem to tylko zmiana nazwy prywatnej zmiennej, czasem przesunięcie statycznych odwołań do metod, żeby dało się dodać testy. Im bardziej się oswoisz z takim kodem i więcej tych testów dopiszesz, tym grubsze zmiany możesz wprowadzać.
wszystko zależy od przeznaczaniu, w projektach "zrób, oddaj, zapomnij' sens wielkiej pracy nad czystością nie ma sensu, tzn czysty na tyle, żeby móc zrobić całość naprawić bugi i tyle. w kodzie który będzie się wspierać długi czas, podchodzi się bardziej restrykcyjnie.
"klienta nie obchodzą nazwy zmiennych,
I to jest prawda. Klienta nie obchodzą nazwy zmiennych, więc to twoją odpowiedzialnością jest to, czy zrobisz "tablicę mendelejewa" (jak ktoś to określił niedawno w jakimś poście), czy ładne czytelne zmienne.
to tylko nasza sprawa byśmy się połapali w tym co robimy"
I to jest dobry argument. Mając brzydki kod i nieczytelne zmienne, nie połapiecie się za chwilę, i to będzie powodowało opóźnienia w projekcie. I klient będzie niezadowolony. Czyli dla dobra klienta jest to, żeby nazwy zmiennych były odpowiednie.
unikania warunkowych drabinek,
Powstawanie takich drabinek jest zwykle spowodowane brakiem przemyślenia i programowaniem na zasadzie "hakowania" istniejącego rozwiązania.
Więc to, czego potrzebujecie to nie żaden mityczny "czysty kod", a raczej czas na pracę koncepcyjną, a nie tylko bezmyślne klepanie (ew. bardziej kompetentnych programistów, którzy będą umieli pisać inaczej niż tylko drabinki ifów).
Implementacja odpowiednich abstrakcji, jeśli wiesz, jakie to powinny być abstrakcje, to chwila. Problemem jest to, żeby się zastanowić, co można dać zamiast kolejnego ifa.
nikt nie płaci za jednolite zasady stawiania średników, nowych linii i odstępów,
można ustawić linter, ale tego typu szczegółowe zasady co do średników i tego, że np. bloki kodu mają być oddzielone tylko jednym enterem (i jak będzie oddzielone dwoma to się wywali), to jak dla mnie przegięcie i to psuje produktywność, bo zamiast robić ficzery, to trzeba poprawiać wszystkie kilkadziesiąt błędów lintera.
Jak klientowi dobrze sprzedasz poprawki w kodzie, to zapłaci. Tylko, że wtedy się będzie zastanawiał, dlaczego kod poprzednich programistów jest kiepski...
Oczywiście ze klient płaci :) za jakiś czas, jak siądzie do inny programista i zamiast dokładać nowe rzeczy to próbuje sie połapać co ten legacy code robi, bo z nazw
nazw funkcji czy zmiennych to wcale nie wynika. Płaci potem za serwis tego jeżeli przesiądzie sie do innego partnera, na inny zespół itp. Tylko ze to sa koszta ukryte, nie widoczne przy wycenie projektu czy podpisywaniu umowy. Klient zadowolony bo zapłacił mniej, a potem zostaje z długiem technologicznym i płaci 4x tyle za serwis ile powinien.
Klient nie płaci za kod, nazwy zmiennych, choinki ifów, wzorce, dobre czyste praktyki.
Klient płaci jak najmniej, ocenia jak grafik przygotował projekt, w przyszłym roku na nowy design znajdzie nowego i tańszego wykonawcę.
Tak to działa w małych firmach typu front-end. Kod jest jednorazowy. Ma być szybko i tanio.
Raz że się nie zna, więc nie może ocenić jakości kodu. Dwa że to co jest czystym kodem to raczej sprawa względna, zwłaszcza że i frameworki to mają różnie rozwiązane pewne rzeczy. W niektórych, tych starszych to jest np. konwencja _underscore, w innych to już camelCase. Kiedyś pracowałem przy projekcie, gdzie nazwy zmiennych były według notacji węgierskiej, była to praca przy rozbudowie projektu, więc chyba z tych względów nie było sensu mieszać, tylko nadal wszystko pisać zgodnie z tą notacją. Mieszanie camleCase z _underscore też chyba nie jest dobrym pomysłem, tak samo jak mieszanie polskiego nazewnictwa z angielskim. Ciężko jest o tym pisać mając na względzie realia ale to co względnie przyspiesza pisanie (względnie bo potem to się może odbijać w perspektywie poprawiania błędów) to Ctrl+C - Ctrl+V, Ctrl+C - Ctrl+V, Ctrl+C - Ctrl+V itd. czyli kopiowanie i wklejanie nie tylko ze znalezionych na SO kodów ale i innych części kodów w projekcie.
Klient chce mieć szybko napisany startup, są frameworki które to umożliwiają, oczywiście to pewne kompromisy. Szybko napisany startup, klient szybko startuje z biznesem. A potem jak ma z tego kolosalne zyski, to chyba nie problem żeby przepisać na nowo, na frameworku uznawanym za najlepszy pod względem dobrych praktyk. A jak startup padnie po roku to gdzie z biznesowego punktu widzenia jest sens płacić 2 - 3x drożej za realizację na najlepszym na rynku frameworku który choć co prawda ma najlepsze praktyki to nie jest stworzony po to żeby coś napisać na szybko? No i jakie to trzeba mieć doświadczenie żeby ocenić co jest tym czystym kodem a co nie? Pisaliście kolejne projekty na tym samym frameworku? Porównajcie sobie kody poprzednich projektów i to jak zrealizowaliście powiedzmy podobne rzeczy. Mogę się założyć, że z każdym kolejnym projektem coraz to lepiej, z wiadomych względów.
@Czekoladowy Miś: jeśli kod o którym mowa ma być napisany raz i nikt do niego nie będzie zaglądał, to Twój szef ma jak najbardziej rację.
Jeśli będzie do niego zaglądał tylko klient - to zależy (od tego czy mu zależy na jakości za dodatkowy koszt).
Jeśli będzie zaglądał do niego głównie inny zespół - to zależy od tego czy zależy Ci na opinii innych.
Natomiast jeśli Ty będziesz do tego kodu czasem zaglądał to albo go piszesz poprawnie od razu, albo refaktorujesz później, jednak w każdym z tych dwóch przypadków szef nie powinien Ci się wtrącać. Jeśli się wtrąca i narzeka, że robisz za wolno bo dbasz o jakość, to zmień pracę.
- Jasne że klient nie płaci za jakość kodu. Klient chce ficzery i za to płaci.
- Wszystko rozbija się tutaj o
definition of done, czyli o to co uważacie w zesple zaskończone. U janusza to będzie pierwszy działajacy prototyp, a w innej firmie to będzie kod po review z dobrym pokryciem testami. - Z jednej strony takie olewackie podjeście lubi się mścić w przyszłości kosztami maintenance, a z drugiej strony nie ma też często sensu robić overengineeringu i pastwić sie 3 tygodnie nad pięcioma linijkami kodu żeby było "idealnie". Trzeba używać głowy :)
Czekoladowy Miś napisał(a):
"jak się wyrobisz i jeszcze znajdziesz na to czas to ok"
„Jak się wyrobisz” to już będzie za późno, bo refactoring trzeba robić przed napisaniem nowego kodu w danym miejscu - inaczej brniesz po prostu głębiej i wykopać się z tego będzie jeszcze trudniej.
I tak przy każdym tasku…
Z jednej strony takie olewackie podjeście lubi się mścić w przyszłości kosztami maintenance
Czyli w sumie znów szef może mieć rację (w zależności od umowy z klientem), bo część tych kosztów utrzymania jest płacona właśnie firmie.
Jak to jest -tak wygląda z opisu- mała firma/agencja, szef chodzi po pokoju, patrzy zza pleców co robią graficy i koderzy to tam nie ma utrzymania kodu, co najwyżej jest utrzymanie klienta, najczęściej jest praca jednorazowa od a do z nad jednym projektem dla nowo-pozyskanego klienta, od kodera więcej znaczenia/do powiedzenia ma grafik z fajnymi pomysłami.
baant napisał(a):
Czysty kod wydłuża czas nowych ficzerów 2-krotnie
No właśnie nie wydłuża tylko skraca, bo w ładnym kodzie już od początku spędza się mniej czasu na debugowaniu i poprawianiu błędów. A jak się napisze testy (te za które klient nie płaci, więc nie ma czasu na ich pisanie), to nie trzeba nawet tracić czasu na uruchamianie aplikacji podczas regularnej pracy.
Polecam eksperyment. Zrobic sobie projekt poboczny i pisac aplikacje na zasadzie byle szybko i do przodu, absolutnie nie przejmujac sie jakoscia (z innej strony: takie podejscie czesto sprawdza sie przy automatyzacji czegos nowego, przy czym jak tylko pojawiaja sie powtarzalne patterny trzeba je od razu juz ladnie przepisywac, ew robic prototypy ktore sie pozniej wyrzuca).
W zaleznosci od tego jak sie szybko koduje pierwsze kilka godzin/dni wszystko bedzie szlo blyskawicznie, ale nagle pojawi sie sciana. Zwlaszcza jak trzeba bedzie cos dodac, zminiec, znajdziemy blad w zalozeniach itp.
Radzę zmienić miejsce pracy. Człowiek, który zatrudnia słabych ludzi każe brnąć przez słaby kod widzi, że da się i myśli, że nie może być lepiej. To jest samospełniająca się przepowiednia. Są projekty w których dba się o jakość kodu, poszukaj a znajdziesz (no i podność kwalifikacje, bo byle kogo do dobrego projektu nie biorą, bo wszystko by popsuł).
WhiteLightning napisał(a):
Polecam eksperyment. Zrobic sobie projekt poboczny i pisac aplikacje na zasadzie byle szybko i do przodu, absolutnie nie przejmujac sie jakoscia (z innej strony: takie podejscie czesto sprawdza sie przy automatyzacji czegos nowego, przy czym jak tylko pojawiaja sie powtarzalne patterny trzeba je od razu juz ladnie przepisywac, ew robic prototypy ktore sie pozniej wyrzuca).
W zaleznosci od tego jak sie szybko koduje pierwsze kilka godzin/dni wszystko bedzie szlo blyskawicznie, ale nagle pojawi sie sciana. Zwlaszcza jak trzeba bedzie cos dodac, zminiec, znajdziemy blad w zalozeniach itp.
Ale OP nie mówił o pisaniu byle szybko i do przodu, a o poprawianiu innych. Trzeba przejmować się jakością podczas implementacji taska. Jak jest potrzebny jakiś refactor to trzeba to robić na bieżąco w ramach taska. Robienie sobie pauzy w środku sprintu, bo coś gdzieś się komuś nie podoba, więc sobie poprawiam jest bez sensu. Trzeba niedopuszczać do czegoś takiego już na starcie. Jak się nazbiera to trzeba pomyśleć wcześniej kiedy znajdzie się czas na dług techniczny, czy warto czy nie. Lub tak jak szef powiedział, jak będzie czas na koniec sprintu to się za to zabrać.
WhiteLightning napisał(a):
Polecam eksperyment. Zrobic sobie projekt poboczny i pisac aplikacje na zasadzie byle szybko i do przodu, absolutnie nie przejmujac sie jakoscia (z innej strony: takie podejscie czesto sprawdza sie przy automatyzacji czegos nowego, przy czym jak tylko pojawiaja sie powtarzalne patterny trzeba je od razu juz ladnie przepisywac, ew robic prototypy ktore sie pozniej wyrzuca).
W zaleznosci od tego jak sie szybko koduje pierwsze kilka godzin/dni wszystko bedzie szlo blyskawicznie, ale nagle pojawi sie sciana. Zwlaszcza jak trzeba bedzie cos dodac, zminiec, znajdziemy blad w zalozeniach itp.
A i tak ten olewający jakość kodu na starcie będzie o krok do przodu przed tym, który na ścianę natrafił już przed rozpoczęciem pisania, bo postawił sobie zawyżone wymagania odnośnie jakości. Ten, który coś już zaczął, przynajmniej ma już wiedze, jakie rzeczywiste problemy spotkał, a nie musi ich sobie wyobrażać. Jeśli struktura kodu okazała się kompletnie zła, to może zbudować nową od początku, ale praktycznie zawsze w starym będzie miał kawałki, które dadzą się wykorzystać dzięki metodzie kopiuj-wklej.
Widzę tu w wątku ludzie bardzo nisko szacują różnicę w czasie wykonania byle jak, od czasu wykonania, by być w pełni usatysfakcjonowanym w jakości. Bo równie dobrze ta różnica może nie być 2-krotna, a 20-krotna. I tylko w nielicznych częściach programu może być warto tę 20-krotność czasu zrobienia byle jak poświęcić. Jeśli wszystkie części mają priorytet (co do jakości kodu), to żadna nie ma priorytetu.
Widzę jeszcze inny problem z dbaniem o jakość kodu, gdy robiony jest przez zwykłą firmę, ze zmieniającymi się pracownikami. Niezależnie jak dobrze by nie był zrobiony, to za 5 lat potencjalnie nowi pracownicy, ale także ci już zatrudnieni uznają ten kod za "legacy", bo rozwijanie go nie będzie odpowiednio poprawiało wartości ich CV, ponieważ w kodzie zastosowane będą rozwiązania, które ostatecznie można uznać za nowe w roku 2018, ale już w 2023 zdecydowanie nie. Chyba żeby od razu zacząć projekt w takim stylu, żeby tych z awersją do "legacy" a gigantycznym pociągiem do rozwiązań zgodnych z najnowszą modą, wygoniło z projektu na samym starcie.
A dla mnie ten problem wydaje się dość abstrakcyjny. Przecież pisanie dobrego kodu jest często szybsze niż pisanie kodu byle jak. Tak samo jeżeli chodzi o testy. Więc albo pracujecie w jakimś dziwnym miejscu gdzie wymaga się od Was klepania crudow na czas, albo wymyślanie dobrej nazwy zmiennej zajmuje Wam pół dnia, ale wtedy to już problem nie leży po stronie klienta.
WyjmijKija napisał(a):
Robienie sobie pauzy w środku sprintu, bo coś gdzieś się komuś nie podoba, więc sobie poprawiam jest bez sensu.
No ja tak robię.
A jak się komuś nie podoba, to nic prostszego - przecież mają 100 bootcampowców i 200 Ukraińców na moje miejsce.
Task na niezrefaktoryzowanym kodzie zazwyczaj zajmuje więcej czasu niż refaktoryzacja i późniejsza implementacja taska.
pisanie dobrego kodu jest często szybsze niż pisanie kodu byle jak
No tutaj się nie zgodzę. Jednak pisząc byle-jak, żeby tylko działało, jest (oczywiście - na początku, do czasu poprawek czy zmian) szybsze. I ta zasada dotyczy wszystkich prowizorek - tak samo jak remontując mieszkanie, szybciej będzie po prostu zaszpachlować większe dziury i całość pomalować, niż bawić się w gruntowanie, szpachlowanie, szlifowanie i ponowne gruntowanie ścian. W dłuższej perspektywie prowizorka jest gorszą opcją, ale doraźnie daje szybsze i wymagające mniej wysiłku efekty.
Troll anty OOP napisał(a):
Widzę tu w wątku ludzie bardzo nisko szacują różnicę w czasie wykonania byle jak, od czasu wykonania, by być w pełni usatysfakcjonowanym w jakości. Bo równie dobrze ta różnica może nie być 2-krotna, a 20-krotna. I tylko w nielicznych częściach programu może być warto tę 20-krotność czasu zrobienia byle jak poświęcić.
Czemu nie 200 albo 2000?
To jest problem cieniasów, którzy nie znają wzorców, idiomów i często podstawowych konstrukcji języka, i nie potrafią wystarczająco szybko projektować.
Widzę jeszcze inny problem z dbaniem o jakość kodu, gdy robiony jest przez zwykłą firmę, ze zmieniającymi się pracownikami. Niezależnie jak dobrze by nie był zrobiony, to za 5 lat potencjalnie nowi pracownicy, ale także ci już zatrudnieni uznają ten kod za "legacy", bo rozwijanie go nie będzie odpowiednio poprawiało wartości ich CV, ponieważ w kodzie zastosowane będą rozwiązania, które ostatecznie można uznać za nowe w roku 2018, ale już w 2023 zdecydowanie nie. Chyba żeby od razu zacząć projekt w takim stylu, żeby tych z awersją do "legacy" a gigantycznym pociągiem do rozwiązań zgodnych z najnowszą modą, wygoniło z projektu na samym starcie.
Zamiłowanie do Fashion Driven Development i nieumiejętność odnalezienia się w dobrze napisanym kodzie sprzed paru lat, bo nie jest "wystarczająco nowoczesny" (czyli jak sądzę niezgody z tym, co pokazują aktualnie tutoriale) to też domena cieniasów.
Kiedyś zdarzył mi się klient, który miał już przygotowany kod przez jakiegoś studenta, i chciał żebyśmy tylko skończyli ten projekt, bo w różnych miejscach słabo działał. Po przejrzeniu kodu, poprawki zostały wycenione na kwotę X, a napisanie od zera na 1/4 X (nie pamiętam dokładnej kwoty X, ale mała nie była). Klient się oburzył, nie mógł zrozumieć, czemu tak drogo, skoro to jest prawie gotowe :D Niestety musiał ostatecznie skorzystać z opcji napisania od zera, bo 3 różne firmy odmówiły mu w ogóle robienia poprawek do istniejącego kodu.
Także nieprawdą jest, że klient nie płaci za czysty kod ;) Albo inaczej to ujmę - za brzydki kod klient często zapłaci dwa razy. Tylko jeszcze tego nie wie i nie rozumie, więc jak się nie ma jakichś zasad etycznych to można go kosić...
somekind napisał(a):
WyjmijKija napisał(a):
Robienie sobie pauzy w środku sprintu, bo coś gdzieś się komuś nie podoba, więc sobie poprawiam jest bez sensu.
No ja tak robię. [...] Task na niezrefaktoryzowanym kodzie zazwyczaj zajmuje więcej czasu niż refaktoryzacja i późniejsza implementacja taska.
Moim zdaniem to robisz to co napisałem wcześniej: "Jak jest potrzebny jakiś refactor to trzeba to robić na bieżąco w ramach taska". Robisz refactor, bo zabierasz się za moment za taska. W zasadzie dla mnie to jest część taska. OP brzmi tak jakby chciał się zatrzymać i nagle zacząć poprawiać coś co już powinno być poprawne.
Wszystko zależy od rodzaju klienta i rodzaju aplikacji.
Jeśli aplikacja jest typu "napisz i zapomnij" to strategia pisania na szybkiego, byle jako tako działało, jest finansowo uzasadniona.
Jednak jeśli produkt, ma przynosić długo dochody, być utrzymywany, rozbudowywany, zdobywać nowych klientów, to dbanie o jakość kodu na dłuższą metę bardzo się opłaca.
Może na początki featury wolniej się będą pojawiać, ale potem naprawianie bugów dodawanie nowych featerów będzie szybsza i mniej błędogenne jeśli kod napisany jest zgodnie z prawidłami sztuki.
Uncule Bob (Rober C Martin) na jednym ze swoich filmików, opowiada jak crap code doprowadził firmę do bankructwa. Jeśli dobrze pamiętam firma napisała pierwsze IDE z prawdziwego zdarzenia do C i szybko zdobyła dużą grupę klientów. Potem pojawiło się zapotrzebowanie na C++ i z powodu crap code nie byli w stanie zrobić tego bez irytujących błędów. Tak długo się z tym chrzanili, że w końcu pojawiła się konkurencja i wszyscy stracili zainteresowanie produktem.
Nie czytałem całej Waszej debaty, ale polecam sobie przeczytać wprowadzenie do "Czystego Kodu" przed zakładaniem takich wątków. "Brudny" kod może położyć cały projekt, przez co można stracić klientów i pieniądze. Nie stanie się to z dnia na dzień, ale w końcu się stanie. Dodatkowo, utrzymanie i rozwój "brudnego" kodu zajmie więcej czasu i mniej osób będzie chciało to robić, więc w ostatecznym rozrachunku będzie to więcej kosztowało i dłużej trwało, co działa na niekorzyść projektu.
PS. Średniki i odstępy załatwia CheckStyle i CI. Czysty kod to trochę więcej, niż napisał OP.
Nie rozumiem tej debaty? Jak można się zastanawiać nad tym, czy opłaca się pisać "dobry kod"?
Takie niechlujstwo kończy się tym, że klient dzwoni po dwóch miesiącach i mówi, że jest bug a ty masz za darmo to poprawić, bo on za płacił za produkt, który miał działać. No i wtedy jest o ja perpole co teraz zrobić z tym spaghetti.