Czy nie ma czasu na utrzymywanie dobrego kodu?

@ehhhhh: No nie bardzo będziesz w stanie wycenić, bo możesz nawet do końca nie wiedzieć co masz wycenić. Nie wiesz też czy masz wyceniać wg. godzin aktualnego super Chad deva, czy jakiegoś randoma, który przyjdzie na jego miejsce. Oczywiście możesz zidentyfikować całą pracę, podzielić ją na kawałki, zacząć od początku i sprawdzić ile udało się zrobić przez np. 2 tygodnie. Ale nadal, odpowiedź "będzie w kwietniu 2024" jest jedynie aktualnym, rozumieniem złożoności i objętości problemu.

Żeby było chociaż trochę on topic, mając projekt tej objętości, nie da się go poprowadzić mając wywalone na jakość kodu, bo po kilku tygodniach, dokonanie jakiejkolwiek zmiany będzie skrajnie trudne, a całe to rozważanie "ile się da zrobić" roztrzaska się o spadek prędkości wykonywania kolejnych zadań, bo ktoś wcześniejsze zadanie dopchnął kolanem, a później jeszcze posadził na nim SM i PO, żeby weszło do sprintu.

Trzeba pamiętać, że każdy zatęchły projekt, w którym przychodzi nam się mierzyć, był u swojego zarania piękną zieloną łączką, na której "tym razem zrobimy dobrze, a nie tak jak poprzednio".

Sztuka programowania to też umiejętność podejmowania decyzji kiedy można sobie pozwolić na:

1. pisanie kodu byle jakiego, bo kod tworzony jest na chwilę;
2. pisanie kodu byle jakiego, bo kod tworzony jest na lata ale na 100% nie będzie rozwijany ani modyfikowany;
3. pisanie kodu "wypieszczonego" bo ten ma służyć przez lata i może być podstawą do dalszego rozwoju.

Jasne, że najlepiej by było gdyby każdy kod można było pisać jako ten "wypieszczony" tylko problem polega na tym, że koszt i czas napisania dobrego kodu jest zwykle wyższy niż koszt napisania kodu byle jakiego, który z punku widzenia klienta robi dokładnie to samo. Na ten dodatkowy czas składa się głównie proces analityczno-projektowy a na koszt zwykle konieczność wykorzystania lepszego programisty. Nie ma co ukrywać, że nie każdy programista nadaje się do pisania kodu na wysokim poziomie abstrakcji.

Jak widać prosta ekonomia i zdrowy rozsądek podpowiadają, że pisanie dobrego kodu nie zawsze ma sens.
Naprawdę do zaimportowania danych z jakiegoś starego systemu do nowego nie trzeba budować pięknych klas ani tworzyć cudownych struktur. Tu trzeba "przewalić" dane z lewa w prawo i można zapomnieć bo ten program ani nawet podobny już nigdy nie zostanie użyty. Dodam, że takie importy danych czasem osiągają rozmiary sporych aplikacji nawet z okienkami.

katakrowa napisał(a):

Sztuka programowania to też umiejętność podejmowania decyzji kiedy można sobie pozwolić na:

1. pisanie kodu byle jakiego, bo kod tworzony jest na chwilę;
2. pisanie kodu byle jakiego, bo kod tworzony jest na lata ale na 100% nie będzie rozwijany ani modyfikowany;
3. pisanie kodu "wypieszczonego" bo ten ma służyć przez lata i może być podstawą do dalszego rozwoju.

Jasne, że najlepiej by było gdyby każdy kod można było pisać jako ten "wypieszczony" tylko problem polega na tym, że koszt i czas napisania dobrego kodu jest zwykle wyższy niż koszt napisania kodu byle jakiego, który z punku widzenia klienta robi dokładnie to samo. Na ten dodatkowy czas składa się głównie proces analityczno-projektowy a na koszt zwykle konieczność wykorzystania lepszego programisty. Nie ma co ukrywać, że nie każdy programista nadaje się do pisania kodu na wysokim poziomie abstrakcji.

Jak widać prosta ekonomia i zdrowy rozsądek podpowiadają, że pisanie dobrego kodu nie zawsze ma sens.
Naprawdę do zaimportowania danych z jakiegoś starego systemu do nowego nie trzeba budować pięknych klas ani tworzyć cudownych struktur. Tu trzeba "przewalić" dane z lewa w prawo i można zapomnieć bo ten program ani nawet podobny już nigdy nie zostanie użyty. Dodam, że takie importy danych czasem osiągają rozmiary sporych aplikacji nawet z okienkami.

Podpisałbym się pod tym co napisał @katakrowa

Ale dodałbym tez jeszcze punkt:

1. różni programiści mają rozwinięte różne umiejętności, i różne czynności wykonują w różnych długościach czasu. Dany spaghetti kod jeden programista zrefaktoruje w 10 minut, inny będzie refaktorował 3h i narzekał że "nie ma czasu na pisanie dobrego kodu", bo jeszcze nie rozwinął umiejętnego refaktorowania.

Z tego wynika też dużo niedomówień - taka osoba która nie włożyła żadnych punków umiejętności (RPG wink ;) ) w ulepszanie kodu, zobaczy potem PR'a gracza który włożył expił swój level w Refactor: 100, TDD: 95 i będzie narzekał że "ten to nic nie robi tylko refaktoruje" (bo jemu samemu zajęło by to bardzo długo), podczas gdy autor PR'a pewnie wyczyścił kod w pare minut.

Można by się pokusić o stworzenie takiego drzewa umiejętności programistów (w który mogłoby być POC, initial dev, delivery, estimate, tdd, refactor, naming, performance, threads, libraries, docs, vcs, maintanence etc.) i jakoś obiektywnie punktować konkretną ścieżkę umiejętności jak w prawdziwm RPG. Pomysł szalony, ale gdyby coś takiego istniało, wiele konfliktów możnaby uniknąć. + Pewnie każdy by sobie wpisał że ma 100 wszędzie :D

@katakrowa: A w tym kodzie, do przewalenia danych to co sprawia, że nie jest on "piękny"?

• Nie wiadomo co ma robić (no raczej nie...)
• Nie wiadomo jak to robi (też raczej nie)
• Nie wiadomo czy to robi (pracowałem w paru przewrażliwionych na punkcie poprawności danych branżach i też mi się nie wydaje)

Jeżeli wiadomo co robi, jak robi i że robi, to zmiana (np. rozbudowa) jest możliwa, czyli kod jest piękny, chociaż nikt nie miał takiego zamiaru. Paradoksalnie znacznie większe problemy może sprawić kod, który powstał po tym jak jeden z członków zespołu przeczytał akurat clean code, był na prezentacji o dobrych praktykach tworzenia kodu i teraz na siłę próbuje wszędzie stosować CQS, albo przeczytał, ze bez interface'ów nie ma prawdziwego dependency injection. W wersji ekstremalnej zaczął od napisania autorskiego frameworku...

Riddle napisał(a):

1. różni programiści mają rozwinięte różne umiejętności, i różne czynności wykonują w różnych długościach czasu. Dany spaghetti kod jeden programista zrefaktoruje w 10 minut, inny będzie refaktorował 3h i narzekał że "nie ma czasu na pisanie dobrego kodu", bo jeszcze nie rozwinął umiejętnego refaktorowania.

a może nie rozwijać umiejętności pisania na odwal i potem poprawiania tylko umiejętność pisania dobrze od razu

Z tego wynika też dużo niedomówień - taka osoba która nie włożyła żadnych punków umiejętności (RPG wink ;) ) w ulepszanie kodu, zobaczy potem PR'a gracza który włożył cały swój level w Refactor: 100, TDD: 95 i będzie narzekał że "ten to nic nie robi tylko refaktoruje" (bo jemu samemu zajęło by to bardzo długo), podczas gdy autor PR'a pewnie wyczyścił kod w pare minut.

czy traktowanie pisania jako gry i zabawy to ta słynna "grywalność" którą pokolenie Z potrzebuje w pracy?

@piotrpo: strasznie mieszasz. Nigdy nie wyceniam jeśli nie mam specyfikacji więc cały twój post można wywalić.

Do standardowego "brakuje czasu bo terminy gonią" i "firma nie zarabia na pięknym kodzie, ale na działających programach" - z którymi się zgadzam - dorzucę jeszcze coś, o czym niewiele osób wspomina. Chodzi o to, że dużo programistów i ludzi od tworzenia oprogramowania mentalnie zatrzymało się w czasach, gdy kod pisało się w ogóle inaczej. Efekt jest taki, że nie ważne, ile takim ludziom dałbyś czasu do napisania aplikacji bo te aplikacje i tak będą skopane.

Ot, przykład - całkiem niedawno robiłem review aplikacji napisanej "reaktywnie", tj. vert.x. Aplikacja ważna.
Kod w większości miejsc wyglądał tak:

Future<MyObject> doSomething() {
  Promise<MyObject> result = Promise.promise();
  callOtherFuture()
    .map(e -> doSomeMapping())
    .onSuccess(v -> result.complete(v))
    .onFailure(e -> result.fail(e));

 return result;
}

A to jest taki dosyć cywilizowany przykład (w końcu i tak będzie asynchronicznie :D), bo nierzadko zdarzało się blokowanie wątków przez Future.result() po to tylko, żeby później opakować wynik w Future lub Promise. I teraz - czy gdyby ludzie odpowiedzialni za ów projekt dostali np. 1/3 więcej czasu to napisali by to porządnie? No nie.

Oczywiście jest to bardzo jaskrawy przykład, ale też istnieją łagodniejsze przypadki. Np. jak ktoś zamiast wydzielać kod robi copy/paste to raczej nie robi tego, bo go terminy gonią, ale dlatego, że ma złe nawyki (pomijam skrajne przypadki, gdzie faktycznie tępe kopiowanie mogłoby mieć sens). Więc jeśli w firmie zastaniesz jakiś tragiczny kod to nie znaczy jeszcze, że firma dała zbyt mało czasu. Jest jeszcze opcja, że ktoś po prostu spieprzył po całości.

Riddle napisał(a):

Potat0x napisał(a):

Dlaczego, w imię szybszego dowożenia, tworzony jest marnej jakości kod - skoro przecież wiadomo, że w przyszłości będą z tego problemy?

Na dłuższą metę firmom to się opłaca patrząc jedynie na rachunek zysków i strat? Czy może działa tu zasada "jakoś to będzie"?

Mało programistów wie, że na deadline można się niezgodzić.

• Manager: "potrzebujemy paginację dla czterech widoków za 4 dni"
• Programista: (myśli...) "4 widoki... logika, front, testy, refactor, to będzię jakieś 7 dni"
• Programista: (na głos): będzie gotowe tak za 7-8 dni.
• Manager: "ale ja to potrzebuję za 4 dni".

I teraz uwaga.

• Co robi większość programistów: "dobra, to skipnę refactor i testy"
• Co powinna robić większość programistów: to trzeba było przyjść trzy dni temu, teraz to będzie za 7 dni.

dodatkowo może wyjść taka sytuacja:

• Manager: "ale ja to potrzebuję za 4 dni, TO JEST DEADLINE".
  • Dobry programista: "ale to po prostu nie będzie gotowe za 4 dni, będzie za 7 dni".
  • Zły programista: "dobra, to się zrobi" # i tutaj powstaje shitcode

Ewentualnie: "poprawimy przy najbliższej okazji" - a potem różnie może z tym być.

katakrowa napisał(a):

Sztuka programowania to też umiejętność podejmowania decyzji kiedy można sobie pozwolić na:

1. pisanie kodu byle jakiego, bo kod tworzony jest na chwilę;
2. pisanie kodu byle jakiego, bo kod tworzony jest na lata ale na 100% nie będzie rozwijany ani modyfikowany;
3. pisanie kodu "wypieszczonego" bo ten ma służyć przez lata i może być podstawą do dalszego rozwoju.

Jasne, że najlepiej by było gdyby każdy kod można było pisać jako ten "wypieszczony" tylko problem polega na tym, że koszt i czas napisania dobrego kodu jest zwykle wyższy niż koszt napisania kodu byle jakiego, który z punku widzenia klienta robi dokładnie to samo. Na ten dodatkowy czas składa się głównie proces analityczno-projektowy a na koszt zwykle konieczność wykorzystania lepszego programisty. Nie ma co ukrywać, że nie każdy programista nadaje się do pisania kodu na wysokim poziomie abstrakcji.

Jak widać prosta ekonomia i zdrowy rozsądek podpowiadają, że pisanie dobrego kodu nie zawsze ma sens.
Naprawdę do zaimportowania danych z jakiegoś starego systemu do nowego nie trzeba budować pięknych klas ani tworzyć cudownych struktur. Tu trzeba "przewalić" dane z lewa w prawo i można zapomnieć bo ten program ani nawet podobny już nigdy nie zostanie użyty. Dodam, że takie importy danych czasem osiągają rozmiary sporych aplikacji nawet z okienkami.

Z tego co napisałeś wygląda trochę na to, że te "piękne klasy i cudowne struktury" być może są całkowicie zbędne, a więc taki kod wcale by nie był lepszy. Chociaż mógłby być - np. zamiast robić skomplikowane zagnieżdżone tuple wolałbym stworzyć dodatkowe klasy - i w tym przypadku nie powiedziałbym, że jest to przesadne "wypieszczenie" :)

Jakość kodu jest pojęciem WZGLĘDNYM i uważam w pewnym sensie podrzędnym w stosunku do głównego kryterium - utylitartności. Czasami wystarczy napisanie wszystkiego w jednym index.php, czasem trzeba stworzyć całą Javovą "kafeterię klas", która później trafia do memów. Ja nigdy nie byłem wybitnym programistą, ale zaczynałem zawsze od najprostszego rozwiązania problemu biznesowego (już w sumie na studiach miałem takie podejście), a później jak mi się coś nie podobało w moim rozwiązaniu - poprawiałem / refaktorowałem. W robocie - podobnie - pierwsza wersja działająca i w miarę OK w kodzie, pewnie z mniej lub bardziej licznymi tradeoff'ami w zależności od pilności i opisane, co można by w przyszłości (przy okazji kolejnych Change Requestów) poprawić.

Z refaktorami w zespołach, w których już nie programowałem podchodziłem róznie:

• czasami jw. - wycenione w ramach kolejnego CR
• jak błąd był upierdliwy i generował masę zgłoszeń i fixowanie każdorazowo jego wystąpienia było kosztowne (wybicie z rytmu prac nad nowymi rzeczami, wizerunek) - to robiliśmy bez wyceny i rozliczania dodatkowo klienta (po to, żeby obniżyć w longterm koszty utrzymania i zarządzać wku*wem klienta).

A jeszcze z tym dobrym kodem taka anegdotka - robiliśmy soft na zamówienie, który miał szansę dawać nam dużo pracy (system sprzedażowy w punktach, często zmienny u innych klientów tego typu). Zrobiliśmy go tak dobrze, że klient przez rok nie zgłosił się z żadnym CRem, bo system był konfigurowalny, dobrze napisany (brak błędów przy eksploatacji), skalowalny (a przy okazji wszystkie testy były robione manualnie przed wdrożeniem w zaplanowanym etapie QA). Z perspektywy właściciela / accounta - najgorszy system jaki można było zrobić ;)

Chyba opowiadasz jakieś bajki. Brak testów automatycznych świadczy o tym, że firma to januszex, kod jest do niczego a system ma pełno błędów. Branża wymaga pisania dobrych testów automatycznych, to jest podstawa.

brzezmac napisał(a):

Jakość kodu jest pojęciem WZGLĘDNYM i uważam w pewnym sensie podrzędnym w stosunku do głównego kryterium - utylitartności.

Zgoda.

Tylko że tematem rozmowy nie jest czy kod z else czy bez jest wyższej jakości czy nie. Rozmowa się wzięła stąd że @_13th_Dragon zasugerował, że ten else jest redundant (czyli możnaby go było usunąć bez uszczerbku na działaniu kod), a @zkubinski odpowiedział że nie da się, i zaczął listować przykłady czemu "return tak nie działa".