Wątek przeniesiony 2021-10-09 12:07 z Flame przez Shalom.

Dlaczego programy "enterprise" muszą być tak kosmicznie przekombinowane?

0

Jak jestem w projekcie od początku, to robię review i pytam dlaczego tak, jeśli mam tego typu wątpliwości, ale w starym projekcie, do którego wpadłem miesiąc temu, a duża część autorów już dawno nie pracuje w tej firmie ta opcja nie istnieje.

4

ta opcja nie istnieje

Niekoniecznie.

  1. Jest historia commitów i bardzo często zawiera odnośniki do jakiejś JIRY. Sprawdź skad się wziął ten "dziwny kod", kto i kiedy go dodał i co jest w commit msg
  2. Są testy. Zobacz co się stanie jak spróbujesz "uprościć" kawałek kodu - ile testów akceptacyjnych się wysypie bo usunąłeś krytyczną funkcje systemu o której istnieniu nie masz pojęcia
1

Może faktycznie się w ten sposób z tym pobawię. W sumie dziś trochę też pogadałem z tech leadem projektu, i o ile sam przyznaje, że sam niektórych rozwiązań nie uważa za idealne, to trzyma się tego, co zastał, żeby była spójność (jestem w stanie to uszanować), to sens paru rzeczy był w stanie mi wyjaśnić. Ogólnie założyłem temat jako taki "rant", ale trochę spostrzeżeń forumowiczów, oderwanie się od kodu na weekend i pogadanie na spokojnie z leadem i już jestem do tego projektu nastawiony nieco bardziej optymistycznie. Także dzięki wszystkim, którzy zabrali głos :)

2

Ktoś tutaj fajnie to opisał wcześniej - ludzie trafiają do już istniejącego projektu, czasem long life. Taka osoba nie zna kontekstu powstawania takiego systemu, nie wie co się działo i jak powstawało.
Łatwo jest oceniać coś z boku po pewnym czasie. Pytanie czy mając tamte wymagania nie zrobilibyście inaczej?

Więcej dystansu w ocenie tego co zastajecie, bo często nie ma cie pojęcia w jakich warunkach kod powstawał i z czym się borykali ;)

8

To wszystko prawda, ale przekombinowanie bierze się też stąd że zwykli programiści:

  • Nie umieją wcale pisać prostego kodu. I to nawet nie chodzi o brak YAGNI i cięcia funkcjonalności, tylko często ten sam kod potrafią napisać w sposób 3x bardziej skomplikowany niż mógłby być, zwykle przez niedostateczną znajomość języka, bibliotek lub zwyczajny brak zastanowienia się tylko klepanie pierwszego lepszego rozwiązania które przyszło im do głowy. Ostatnio np. gostek napisał kilkaset linii kodu parsujacego wyrażenia z OR i AND ręcznie ze stosem bo w projekcie w którym jest już ANTLR nie umiał zrobić gramatyki tak aby ANTLR parsował wszystko z dobrą precedencją operatorów. Ot, wolał napisać kilkaset linii niż doczytać jak zdefiniować kilka linii w ANTLR żeby wygenerować drzewko od razu z ANTLR. Innym razem inny senior zrobił drabinkę ifów na 6 przypadków, z czego dwa brzegowe niechcący pominął, a potem okazało się że wprowadzajac jedna zmiena pomocnicza można było to zredukować do bodajże jednego ifa, który był od razu poprawny.

  • Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

0
Krolik napisał(a):
  • Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

Niestety tak jest a w wykręcaniu się niektórzy są bardzo kreatywni.

0

@Krolik:

Nie umieją wcale pisać prostego kodu. I to nawet nie chodzi o brak YAGNI i cięcia funkcjonalności, tylko często ten sam kod potrafią napisać w sposób 3x bardziej skomplikowany niż mógłby być, zwykle przez niedostateczną znajomość języka, bibliotek lub zwyczajny brak zastanowienia się tylko klepanie pierwszego lepszego rozwiązania które przyszło im do głowy.

No ale przecież po to jest CR. Takie rzeczy powinny właśnie na nim wychodzić.

Ostatnio np. gostek napisał kilkaset linii kodu parsujacego wyrażenia z OR i AND ręcznie ze stosem bo w projekcie w którym jest już ANTLR nie umiał zrobić gramatyki tak aby ANTLR parsował wszystko z dobrą precedencją operatorów. Ot, wolał napisać kilkaset linii niż doczytać jak zdefiniować kilka linii w ANTLR żeby wygenerować drzewko od razu z ANTLR. Innym razem inny senior zrobił drabinkę ifów na 6 przypadków, z czego dwa brzegowe niechcący pominął, a potem okazało się że wprowadzajac jedna zmiena pomocnicza można było to zredukować do bodajże jednego ifa, który był od razu poprawny.

j.w. CR. PO to właśnie to jest aby unikać takich sytuacji.

Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

To też nie jest takie proste. Z jednej strony powinno się zostawić kod przynajmniej taki jaki zastaliśmy ale z drugiej strony jest ciśnięcie na terminy i często brakuje czasu...

Może trzeba być przypisane jakieś dodatkowe godziny na refactor? Np. na jakiś sprint wpada zadanie aby poprawić najbardziej śmierdzące kawałki kodu?

1
.andy napisał(a):

j.w. CR. PO to właśnie to jest aby unikać takich sytuacji.

Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

To też nie jest takie proste. Z jednej strony powinno się zostawić kod przynajmniej taki jaki zastaliśmy ale z drugiej strony jest ciśnięcie na terminy i często brakuje czasu...

Nie ma czegoś takiego jak brak czasu. Istnieje natomiast brak organizacji, lenistwo, brak potrzeby sprzątania, umiejętność spychania projektów na innych pracowników, etc.

3
.andy napisał(a):

Może trzeba być przypisane jakieś dodatkowe godziny na refactor? Np. na jakiś sprint wpada zadanie aby poprawić najbardziej śmierdzące kawałki kodu?

Sprinty naprawcze, refaktorowe, stabilizacyjne itp. Widziałem, przerabiałem, nie polecam. To jest takie zalegalizowanie syfu - robimy cały czas syf, a raz na jakiś czas poprawiamy - jeden ze sposobów jak wprowadzić projekt w bagno.
Prostsza metoda, która mi działała - przekonuje programistów, że zawsze przy szacowania mają podawać takie liczy, że uzwględniają:

  • zrobienie dobrze zadania, z testami i review,
  • z lekkim poprawieniem kodu dookoła - jak wiesz, że kod obok to syf to dajesz więcej

Jak prawie wszyscy w zespole mamy takie podejście, to się daje robić dobrze.
Brak czasu to raczej wymówka programistów. Wystarczy spytać projekt managera, PO czy kogoś tam czy chce aby zadanie było zrobione byle jak...

2

za y = a + b nikomu nie zapłacą 15k

za buildery z 10 warstwami abstrakcji już tak

2 użytkowników online, w tym zalogowanych: 0, gości: 0, botów: 2

Robot: Bingbot (2x)