Spaghetti code

Cześć

Wiem że najlepiej unikać Spaghetti Code, ale co zrobić jak już mamy z takim doczynienia?
Na początku swojej kariery myślałem że "Spaghetti Code" to zapomniana legenda, mająca nas programistów ostrzec przed takim "zjawiskiem" - dawno zapomniane, lecz może powrócić jak za dużo ifów zrobisz w kodzie :)
Lecz nie. ..wa nie... Dowiaduje się że spaghetti code jest na porządku dziennym. Co więcej, szefowie Janusz softów pośpieszają w pracy biednych programistów z takim spaghetti. Tylko najgorsze jest to, że to na nas spoczywa później odpowiedzialność za ten kod :

• nie umiesz tego wprowadzić? przecież to proste! to tylko jeden button
• jak nie przyśpieszysz, to będe zmuszony Cie zwolnić
• przepisać? przecież ta aplikacja jest rozwijana przez 20lat, za dużo czasu zajmie przepisywanie jej a klienta to nie obchodzi że ten kod to syf
• testy jednostkowe? jak będzie czas to sobie tam pisz (ale czasu nigdy nie ma :) ) ogolnie szkoda czasu na testy.
• musisz zrobić to, to i to a wszystko na wczoraj

I nie. to nie jest domena Janusz softów. Ze słyszenia powiedziałbym ze to domena większości firm informatycznych. Więc tu pytanie do was - jak sobie radzić z takim kodem żeby i szefu był zadowolony i żeby jakoś ogarnać ten bajzel?

Pisz kod spaghetti, i powiedz współpracownikom, że stosujesz się do konwencji przyjętej w projekcie :D

Jest prosta zasada. To Ty odpowiadasz za kod jaki tworzysz. Pushując coś do repo podpisujesz się pod tym. Nie obchodzi mnie co twój szef janusz Ci kazał. To on Cie zatrudnił, żebyś ten kod zrobił dobrze. Jeśli nie możesz się z dogadać to zmieniasz szefa na innego. Łatwo teraz znaleźć pracę jako programista. A inaczej januszy nie nauczysz.

Są oczywiście momenty, że możesz dopuścić wrzucenie syfu - aplikacja jest na wymarciu (zaraz wejdzie zupełnie nowa wersja).Albo robisz hotfixa i wiesz, że jutro kod poprawisz(tylko zrób to!).

Mam taką regułę 2 miesięcy. Jeśli kod ma żyć dłużej niż 2 miesiące - to powinien być zrobiony jak najlepiej (z testami na przykład) - bo się to zwróci.
Wiec zawsze może spytać jak ktoś Ci każe na skróty iść - czy wyrzucacie soft za 2 miesiące (weź to na piśmie).

Gorszy problem jest jeśli masz współpracowników którzy tworzą syf i są jeszcze do tego przekonani, że to jest dobre. W jednej z pierwszych firm jakich pracowałem (ubiegły wiek) miałem "kolegę", który wprost uznawał COPY PASTE za opus magnum computer science....i wkurzał się, że wywołujemy metody z innych klas zamiast kopiowac potrzebne kawałki kodu.... (Bo przecież jak ktoś te metody zmieni to nasz kod się wysypie. Przyznam, żelazna logika nie do pobicia.).

W praktyce praca programisty polega głównie na utrzymywaniu starego kodu. Przepisywanie aplikacji to głupota bo wywalasz do kosza wiedzę, doświadczenie i rozwiązania niektórych problemów, które ten "śmieciowy kod" pewnie rozwiązuje.

Wygląda na to, że nie pisałeś nigdy większego systemu bo inaczej byś wiedział że w takim syfie mała zmiana może nieść ogromnie nieprzewidziane konsekwencje - stąd często najbezpieczniej jest dopisać kawałek śmieciowego kodu niż zrobić refaktoryzację i rozpieprzyć całą resztę.

A przyczyny są proste. Programistów jest bardzo dużo co sprawiło, że poziom zaczął spadać do średniej. Języki programowania również stały się mniej wymagające. Dawniej żeby pisać w C trzeba było rozumieć jak działa aplikacja, jak się wykonuje kod bo inaczej kończyło się na niedziałającym zakalcu. Teraz jest C#, Java + CTRL-C Stackoverflow + jakieś historyjki jak się powinno programować. Jedną z nich jest że wszędzie trzeba wciskać testy jednostkowe i koniecznie w każdej metodzie trzeba mieć kod do łapania wyjątków (C#).

Skromny Samiec napisał(a):

I nie. to nie jest domena Janusz softów. Ze słyszenia powiedziałbym ze to domena większości firm informatycznych. Więc tu pytanie do was - jak sobie radzić z takim kodem żeby i szefu był zadowolony i żeby jakoś ogarnać ten bajzel?

Szukać, szukać, szukać - aż znajdzie się firmę, w której dba się o kod.
Tylko to nie będzie software house, agencja interaktywna ani inna firma projektowa - bo jeśli coś ma się sprzedać raz, to o jakość się nie dba. Sugeruję szukać pracy w firmach, które mają swoje produkty i mają zamiar je wiele lat utrzymywać. Oczywiście to niczego nie gwarantuje, ale myślę, że to dobry kierunek działań.

A jeśli chodzi o syf w projekcie - próbować po prostu w ramach zadań zawsze coś poprawić. Wiele to nie naprawi, ale przynajmniej samopoczucie będzie lepsze.

Radzicie żeby porzucać Janusz-Softy, ale niestety w przypadku początkujących programistów nie jest to takie bezproblemowe. Dużo osób boi się problemów ze znalezieniem nowego zatrudnienia, w związku z czym (moje domysły) zostają w takiej firmie, piszą lipny kod (bo za mało potrafią żeby sobie z nim poradzić - więc powielają) i koło się zamyka.
Chyba najlepszym pomysłem było to co napisał somekind => najlepiej znaleźć firmę która wspiera (i rozwija) swoje produkty przez dłuższy czas.

Boją się, bo się nie rozwijają. Umieją napisać klasę, jakąś metodę i wystarczy do programowania. Później jadą w firmie przez 10 lat ze swoim kodem a jak przychodzi moment zmiany to nie mają nic do zaoferowania. Rekrutowałem takich gości, co kilka lat pracowali w innych firmach. Niewiele wiedzieli ale w sumie to nie jest najgorsze. Najgorsze to, że nie chcieli wiedzieć.

Dużo osób boi się problemów ze znalezieniem nowego zatrudnienia

Oczywiście każdy musi podjąć własną decyzję na temat tego, jak chce by wyglądało jego życie zawodowe. Można już do samej śmierci bredzić w spaghetti, jeśli ktoś naprawdę woli się bać jakichś abstrakcyjnych problemów, zamiast skupić się na tych realnych, które właśnie go bezpośrednio dotykają...

Ale jeśli nie chcesz bredzić w spaghetti to innej drogi nie ma. No, możesz próbować swojego Janusza wychowasz, ale ja tam cuda nie wierzę ;)
To prawda, że znaczna część rynku to utrzymanie starego kodu, ale podejście do tego przełożonych różni się między sobą skrajnie. U mnie np. jest sporo badziewia, ale jest pełne zrozumienie i przyzwolenie na refaktoring. Wręcz w wytycznych mam zalecenie, by jakiś tam procent czasu poświęcać na usuwanie długu technologicznego. Dzięki temu w miarę upływu lat badziewia jest coraz to mniej i mniej. Niedawno właśnie złapałam się na tym, że od miesiąca nie napisałam ani linijki w VBA ;)

no więc ja będę miał teraz robotę ze spaghetti code (nie jest to czyn chwalebny, ale co zrobić):

1. projekt zdalny (w 100%), a więc nikt się z nikim nie spotyka
2. komunikacja pomiędzy developerami, delikatnie mówiąc, jest "taka średnia" (często jej brak)
3. przewinęło się przez projekt kilkanaście osób, nikt się nie przejmował jakimkolwiek porządkiem
4. nie ma dokumentacji
5. właściciel projektu nie jest specjalnie techniczny
6. dla właściciela liczy się tylko i wyłącznie "funkcjonalność", np. "zrób upload plików z telefonu dowolną technologią, byleby działało"

dlaczego będzie spaghetti code:

• nikt mi nie płaci za porządek, refactoring
• liczy się tylko zaimplementowanie funkcjonalności w określonym czasie
• właściciel nie jest programistą i nie ma sensu mu tłumaczyć jakichkolwiek zawiłości technologicznych
  (liczą się 2 wartości: budżet i czas)
• nie za bardzo mam pomysł jak to uporządkować
• za dużo "niezależnych developerów" podpinających się w wolnej chwili i każdy z nich utrzymuje swój porządek

dlaczego można się w to pobawić i zostawić swój makaron:

• 100 % zdalnie, wygodnie w domku, godziny dowolne
• 100% dowolny wybór technologii, byleby nie kolidowało z innymi developerami
• liczy się tylko zaimplementowanie funkcjonalności
• właściciel ma fajny budżet na to
• można się dogadać i jest w sumie luz
• skończę parę funkcji i sobie pójdę, a jak będe chciał zostać na dłużej to pomyślę nad uporządkowaniem

reasumując: w niektórych przypadkach spaghetti code ("byleby działało i było tanie i szybkie w implementacji") po prostu ma sens.

Natomiast ten przypadek to jest projekt niewielki, ale żeby było śmieszniej to według mnie właściciel na tym zarobi spokojnie parę ładnych tysięcy.
Ale nie sądzę, że przejdzie to w jakieś big data.

śmieszek napisał(a):

W praktyce praca programisty polega głównie na utrzymywaniu starego kodu. Przepisywanie aplikacji to głupota bo wywalasz do kosza wiedzę, doświadczenie i rozwiązania niektórych problemów, które ten "śmieciowy kod" pewnie rozwiązuje.

Nawet się z tym zdaniem zgadzam, choć nie wiem czego ono dotyczy, bo nigdzie w poprzednich wpisach nie było nic o przepisywaniu aplikacji. (Czytasz ten wątek?).

Wygląda na to, że nie pisałeś nigdy większego systemu bo inaczej byś wiedział że w takim syfie mała zmiana może nieść ogromnie nieprzewidziane konsekwencje - stąd często najbezpieczniej jest dopisać kawałek śmieciowego kodu niż zrobić refaktoryzację i rozpieprzyć całą resztę.

Strzelam, że to do mnie przytyk - gratuluję dobrego samopoczucia w pisaniu większych systemów. I masz rację - ja piszę tylko małe. I dokładnie tego staram się innych uczyć.
Tak poza tym podoba mi sie twój boy scout rule - już jest syf - więc zróbmy jeszcze większy. Jeśli was zastanawia skąd się biorą takie koszmary programistyczne - to właśnie z tego: -wspólnego, zespołowego, wieloletniego srania sobie w kod. Usprawiedliwionego tym, że przecież już tam śmierdzi.

Doskonale działa zasada przeciwna (czyli zwykłe boy scout) - nawet jesli system jest syfny to dorabiajac jeden mały ficzer albo poprawiając buga zawsze jest miejsce, żeby posprzątać choć minimalnie w okolicy. Czasem przy takich starych kobyłach podpinam metryki na CI - i daję ostrzeżenia przy pogorszeniu (możesz wrzucić kod syfny, ale nie może być gorszy niż był (CC, LOC, Coverage , duplikacje itp).).To robi cuda!

A przyczyny są proste. Programistów jest bardzo dużo co sprawiło, że poziom zaczął spadać do średniej. Języki programowania również stały się mniej wymagające. Dawniej żeby pisać w C trzeba było rozumieć jak działa aplikacja, jak się wykonuje kod bo inaczej kończyło się na niedziałającym zakalcu. Teraz jest C#, Java + CTRL-C Stackoverflow + jakieś historyjki jak się powinno programować. Jedną z nich jest że wszędzie trzeba wciskać testy jednostkowe i koniecznie w każdej metodzie trzeba mieć kod do łapania wyjątków (C#).

Cieszy mnie twoja wiara, że dawniej zimy były ostrzejsze, ale jakbyś zobaczył co się robiło w latach 90 i to co wtedy był clean code to mógłbyś się troszkę rozczarować. Powiem tak: nigdy nie poznałem gorszych sabotażystów niż programiści C - przekwalifikowani na Javę. Chłopaki potrafili pisać własne tokenizery, skrajnie nieczytelne, o złożoności kwadratowej (albo gorszej) i jeszcze podpisywać w komentarzach jacy są cool - bo do dzielenia przez dwa używają przesunięcia bitowego (autentyk - przy okazji to dzielenie do niczego innego nie było potrzebne, jak do tego żeby pokazać to przesunięcie). W tej firmie (co już o niej pisałem), jak przyszedłem to chłopcy mieli już dwie własne implementacje klasy Stack (oczywiście dużo lesze niż oryginał z JDK :-) ). Dwie, bo tylko dwóch umiało to jakoś napisać - i każdy z nich skorzystanie z klasy w JDK, albo od kolegi uważał za hańbę (wiem, że nie uwierzycie w to - trudno) .

jarekr000000 napisał(a):

Nawet się z tym zdaniem zgadzam, choć nie wiem czego ono dotyczy, bo nigdzie w poprzednich wpisach nie było nic o przepisywaniu aplikacji. (Czytasz ten wątek?).

Dosyć zabawne, bo przeczytałem to w Twoim poście w tym temacie:

Są oczywiście momenty, że możesz dopuścić wrzucenie syfu - aplikacja jest na wymarciu (zaraz wejdzie zupełnie nowa wersja).Albo robisz hotfixa i wiesz, że jutro kod poprawisz(tylko zrób to!).

Oczywiście zaraz usłyszę że aplikacja na wymarciu -> nowa wersja to nie jest jej przepisywanie i zacznie się kolejna dyskusja w stylu "gdzie tak napisałem, nie masz racji".

jarekr000000 napisał(a):

Strzelam, że to do mnie przytyk - gratuluję dobrego samopoczucia w pisaniu większych systemów.

To nie strzelaj, bo głupoty wypisujesz. Świat się nie kręci wokół Ciebie i żadnego przytyku tam nie było - po prostu prosta obserwacja. Być może jesteś jednym z tych programistów co uważają, że im większy system tym jestem ważniejszy - ja tak nie uważam.

jarekr000000 napisał(a):

I masz rację - ja piszę tylko małe. I dokładnie tego staram się innych uczyć.

Na tym polega problem z teoretykami. Mają oni swoje założenia w głowie i uważają, że będą one przekładać się na rzeczywistość. Sam fakt stwierdzenia, że system będzie mały nie oznacza że ostatecznie taki będzie. Bardzo rzadko zdarza się, że klient wie czego chce albo że analityce zrozumieli o co chodzi. W efekcie przerabiasz kod setki razy i piszesz wiele rzeczy, których nie planowałeś.

jarekr000000 napisał(a):

Doskonale działa zasada przeciwna (czyli zwykłe boy scout) - nawet jesli system jest syfny to dorabiajac jeden mały ficzer albo poprawiając buga zawsze jest miejsce, żeby posprzątać choć minimalnie w okolicy.

Doskonały pomysł. Po czym okaże się po Twoich wspaniałych zmianach że gdzieś system się wypieprza a klient jest zły, bo to co działało nagle przestało. Nie usprawiedliwiam syfu i staram się pisać dobry kod ale realia są takie, że syfnego ale działającego kodu lepiej czasem nie ruszać w dużych systemach bo może to mieć dziwne konsekwencje.

jarekr000000 napisał(a):

Cieszy mnie twoja wiara, że dawniej zimy były ostrzejsze, ale jakbyś zobaczył co się robiło w latach 90 i to co wtedy był clean code to mógłbyś się troszkę rozczarować.

Dobry kod to niekoniecznie dobrze nazwane zmienne, ładna hierarchia i atomizacja. To przede wszystkim minimalizm i inteligencja. Z punktu widzenia programistów OOP języki funkcyjne są paskudne i pisze się w nich bardzo brzydki kod a pozwalają one napisać znacznie bardziej inteligentny i minimalistyczny kod.

śmieszek napisał(a):

. Nie usprawiedliwiam syfu i staram się pisać dobry kod ale realia są takie, że syfnego ale działającego kodu lepiej czasem nie ruszać w dużych systemach bo może to mieć dziwne konsekwencje.

Mam tylko jedno pytanie : długo tą politykę stosujesz?

Zresztą polecam pewną książkę - wybitnego teoretyka :-)
https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

##Update

Ponieważ w innym wątku dostałem ochrzan za "nie tłumaczenie" - więc zmniejszę poziom trollowania i postaram się wytłumaczyć : "gdzie Ci się wydaje".

Otóż zachodzi pytanie: co robisz jeśli masz coś zmienić w starym kodzie, który jest krytyczny dla biznesu, ale niezrozumiały, stary i bez testów.

Mamy trzy możliwości (tyle widzę):

1. Zgodnie z twoją definicją nie ruszasz i zostawiasz ? - no to wspaniałe będą rezultaty - chyba pozwolę sobie odpuścić tą możliwość.
2. Robisz minimum zmian - bo nie kumasz jak działa - ale wydaje Ci się, że wrzucenie if w lini 77 rozwiąże problem.
3. Starasz się kod zrozumieć. Dopisać testy, (na ile się da), poprawić, dorobić wymaganą funkcjonalnośc i może jeszcze troszkę poprawić.

Rozumiem, że raczej zwykle wybierasz opcję 2. Powiększasz chaos, ale przy odrobinie szczęścia masz problem z głowy.
No, ale co jesli nie zrozumiałeś i okazało się, że linia 77 jest efektywnie zakomentowana od 2 lat - tylko tego nie widać ? (przy okazji: normalka).

Dlatego ja polecam wersje 3:
Kod i tak musisz ogarnąc i zrozumieć, zajmuje to czas ale daje szansę na poprawne wykonanie zadania.
**Najlepszym sprawdzianem tego, że kod ogarnąłeś jest jego poprawienie! **
Jeśli dorobisz najpierw testy to zmniejszasz ryzyko (to zresztą najtrudniejsza część sztuki - (i najsłabszy punkt tej pięknej teorii :-) ) bo najczęściej zrobienie testów już wymaga ingerencji..).

No, ale po co do cholery tak się męczyć?

**Bo jest duże prawdopodobieństwo, że do tego kodu Ty, albo ktoś inny wróci ** (hotspoty ).

Za kolejnym razem ogarnięcie tego kodu będzie łatwiejsze.. bo jest trochę poprawiony, ma już jakieś testy.
W przeciwnym razie: jeśli poświęcisz dwa dni na zrozumienie jakiejś kupy, a potem ją tak zostawisz to za dwa miesiące będziesz Ty albo twój kolega w tym samym miejscu i przeprowadzi tą analizę od nowa :-). Gorzej: będzie miał o jeszcze jeden if (ten z linii 77) więcej. I tak się właśnie palą osobomiesiące.

No i najważniejsze - bez przesady z tym strachem:
**Jeśli produkt jest tak ważny, że nie można zwałki ryzykować... to (do diaska!) firma powinna mieć jakiś proces testowania. ** Nawet manualny... To się robi - opłaca się. Można tanio Polaków wynająć (to był trolling oczywiście, sorry).

Tak, że te wszystkie bajki z nienaruszalnym kodem proponuję włożyć tam gdzie ich miejsce.

A tak przy okazji oczywiście wielokrotnie robiąc w ten sposób zwaliłem! i bug po refaktoringu poszedł na produkcję... i co - no cóż naprawiliśmy w kolejnym hotfixie. Dodatkowa godzina nerwów, a mamy lepszy kod na lata. Skoro bug nie wyszedł na testach to nie było to w tak krytycznej funkcjonalności, firma nie zginęła, galaktyka nie zapadła się.

Czasami jest zabawnie:
Kiedyś raz (przy tzw. okazji ) poprawiłem jednego ewidentnego copy -paste buga w kodzie. (W query SQL zamiast **like **było **< ** co powodowało totalnie absurdalne działanie wyszukiwarki faktur po nazwie). Naprawiłem znany i zraportowany od lat bug (niskiego priorytetu). Ale okazało, się że ten ficzer był w międzyczasie cudownie exploitowany przez klientów (i była cofka) :-).

śmieszek napisał(a):

Doskonały pomysł. Po czym okaże się po Twoich wspaniałych zmianach że gdzieś system się wypieprza a klient jest zły, bo to co działało nagle przestało. Nie usprawiedliwiam syfu i staram się pisać dobry kod ale realia są takie, że syfnego ale działającego kodu lepiej czasem nie ruszać w dużych systemach bo może to mieć dziwne konsekwencje.

Oj tam, oj tam, nie ma co dramatyzować. Z resztą są sposoby na to, żeby takie miejsca ogarnąć. Jeśli takie krytyczne jest, by klient nie dostał buga, to wystarczy tylko czas. Ja np. jak mam kod, który naprawdę nic sensownego sobą nie prezentuje, to loguje sobie wejście i wyjście metody i wgrywam to użytkownikom. Po miesiącu mam piękny zbiór danych do testów jednostkowych i jadę z koksem :D Potem dajesz to jeszcze testerom z prośbą, by bardzo dokładnie przyjrzeli się tej a tej opcji. I już, po bólu. IMHO lepiej tak, niż mieć syfny kod już na zawsze ;)

aurel napisał(a):

Ja np. jak mam kod, który naprawdę nic sensownego sobą nie prezentuje, to loguje sobie wejście i wyjście metody i wgrywam to użytkownikom. Po miesiącu mam piękny zbiór danych do testów jednostkowych i jadę z koksem :D

LOL - żeby takie coś działało chyba musiała byś mieć czystko funkcyjny kod. Albo prosty batchowy system - wrzucasz dane na wejscie i zawsze wypluwa te same wyjscie.
Systemów reaktywnych, których stan zmienia się pod wpływem zewnętrznych sygnałów (np. serwer http) nie da się tak przetestować.

Dopisuje w poscie bo nie ma miejsca w komentarzu masz klase:

class A
{
   private int x;
   private int A(int x)
   {
      this.x = x;
   }

   int func(int b)
   {
      x += b;
      return x;
   }
}

No i teraz logujesz wejscie metody func i jej wyjscie. Za kazdym wywolaniem metody func wewnetrzny stan sie zmienia wiec dla tych samych danych na wejsciu dostajesz inne dane na wyjsciu. Zeby to dzialalo jeszcze musialabys zalogowac wewnetrzny stan od ktorego zalezy wyjscie metody. W duzych aplikacjach zazwyczaj nie jest to jedna zmienna tylko masa zmiennych, ktore moga takze zalezec od stanu systemu operacyjnego oraz kilka watkow ktore uzywaja tej klasy.
Zeby twoja testowania dziala func musiala by nie miec zadnych side effectow - czyli de facto musiala byc czysta funkcja.
Ja wiem ze do tej klasy da sie napisac unit testy - ale ty mowisz wylacznie o zbierania logow z wejscia i wyjscia metod od uzytkownikow. To jak sobie radzisz ze stanem wewnetrznym w takim razie?

@jarekr000000 wydaje mi się że śmieszkowi chodziło trochę o coś innego, mianowicie o podejście niektórych koderów (szczególnie juniorów) z serii uuu ale gówniany kod, napisałbym to lepiej!, które często źle się kończy. Czasem (optymistycznie) po spędzeniu 3 dni nad nową wersją okazuje się że ta nowa wersja w sumie wygląda tak samo jak ta stara, bo pewne ograniczenia sprawiają że się inaczej nie da. A czasem jest gorzej, bo ktoś naklepie to swoje, niby lepsze rozwiązanie, które działa źle, mimo że wygląda trochę lepiej. Wynika to zwyczajnie z faktu, że istniejący kod zawiera różne dziwne fixy na nietypowe sytuacje, zmiany wymagań itd i jeśli ktoś refaktorując nie przeanalizuje tego dokładnie, albo nie ma wyczerpujących testów, to najpewniej usunie część tych fixów, bo są brzydkie. Joel o tym kiedyś pisał https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ;)

Shalom napisał(a):

albo nie ma wyczerpujących testów, to najpewniej usunie część tych fixów, bo są brzydkie. Joel o tym kiedyś pisał https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ;)

Joel dawał przykłady z GUI i tam takie rzeczy to duży problem. Kod serwerowy w praktyce da się nieźle pokryć testami - tak, że każdy głupi case/if w kodzie pokryjemy. (Czasem naprawdę nie wiedząc po co to jest - niestety mam trochę takich testów - z bardzo głupimi nazwami :-( ). Potencjalny problem to ewentualne fixy na kontener (ileż ja mam dziwnych linii na głupoty wesbphere) albo concurrency issues - ale to zwykle nawet w strasznym spaghetti jest jakoś udokumentowane..

Przy okazji nie trzeba tego robić "all in" - możemy zacząć od kilku testów - upewniając się, że zmieniane linijki w kodzie są akurat nimi pokryte. Super gwarancji to nie daje - ale zwykle jest good enough.

Na początku swojej kariery myślałem że "Spaghetti Code" to zapomniana legenda, mająca nas programistów ostrzec przed takim "zjawiskiem" -
dawno zapomniane, lecz może powrócić jak za dużo ifów zrobisz w kodzie

To znaczy, że sam nigdy nie pisałeś spaghetti kodu? Wydaje mi się, że każdy pisze spaghetti kod, przynajmniej na początku (chociaż mi też się zdarza do dzisiaj pisać, jak robię exploratory code. Ew. jak coś pójdzie nie tak - i kod, który na początku ładny, zaczyna poddawać się entropii i wychodzi spaghetti kod. Wtedy refaktoruję albo przepisuję od nowa, jeśli mogę).

Z drugiej strony często ludzie, którzy dowiadują się, że spaghetti kod jest brzydki mogą popaść w drugą skrajność i będą starać się pisać kod na pokaz "elegancki", z mnóstwem niepotrzebnych wzorców, z niesamowitymi abstrakcjami, mnóstwem dziwnych klas, taki kod w stylu enterprise (co może przy projektach klasy enterprise z mnóstwem wymagań biznesowych to ma jakiś sens - ale jeśli ktoś pisze prosty projekt tak, jakby pisał drugiego SAPa to nie jest to raczej dobra droga)

Potem dopiero człowiek się opanowuje, i widzi się, że najważniejsze, żeby kodzik był prosty. Spaghetti kod jest zły, ale przeinżynierowanie jest równie złe, a nawet gorsze (w przypadku spaghetti kodu, możesz przynajmniej pierdyknąć i powiedzieć "kod to syf", w przypadku przeinżynierowania widzisz, że jest to syf, ale jednak jest to syf jakoś uporządkowany, zrobiony wg jakichś wzorców, nawet jeśli zaimplementowanych od czapy... w przypadku przeinżynierowania ciężej przekonać innych, że syf to syf, i że trzeba coś z tym zrobić)

testy jednostkowe? jak będzie czas to sobie tam pisz (ale czasu nigdy nie ma :) ) ogolnie szkoda czasu na testy.

Testy są tym bardziej potrzebne, im większy jest projekt. Przy małych projektach brak testów nie jest aż taką tragedią, ale przy dużych projektach brak testów to proszenie się o problemy, i jeśli ktoś ma podejście, że szkoda czasu na testy, to ja bym się zastanowił, czy z taką osobą, chciałbym współpracować w ogóle.

somekind:

Tylko to nie będzie software house, agencja interaktywna ani inna firma projektowa - bo jeśli coś ma się sprzedać raz, to o jakość się nie dba.
Sugeruję szukać pracy w firmach, które mają swoje produkty i mają zamiar je wiele lat utrzymywać.

Myślę, że zależy też jak wielka jest rotacja programistów w firmie. Jak za mała to niezbyt dobrze - programista, który siedzi w jednym projekcie przez kilka lat, poznaje go na wylot, co niestety sprawia, że taki programista przestaje dostrzegać problemy z architekturą czy kodem projektu, przyzwyczaja się, ponieważ zna kod na pamięć i jest w stanie się poruszać w spaghetti ze sprawnością widelca. A potem wynikają teksty o których OP wspomniał typu "nie umiesz tego wprowadzić? przecież to proste! to tylko jeden button" (gdzie dla osoby, która siedzi w projekcie i go pisała coś jest proste, jednak osoba nowa w projekcie ma problemy z ogarnięciem tego, ponieważ kod wcale obiektywnie prosty ani ładny nie jest, a jedynie się taki wydaje osobom, które go pisały).

Aha - jak za duża rotacja programistów to też jest niedobrze - bo jest wielki chaos, brak standardów w projekcie. Każdy nowy programista narzuca swój styl pisania, a w razie potrzeby kopiuje/wkleja coś z innego modułu, bo mu tak wygodnie. Plus to, że nie ma do kogo się zwrócić o pomoc, bo "autor tego modułu już tu nie pracuje" itp.

Są aplikacje których się nie refaktoruje, kto twierdzi inaczej po prostu nie trafił jeszcze na taką aplikacje ;)
Kiedyś pracowałem nad aplikacją, która była rozwijana na całym świecie przez ponad 20 lat, miała parę milionów linii kodu. W sumie to był cały system operacyjny, wgrywali go jako obraz na system docelowy.
Do tego miała parę branchy produkcyjnych każdy działający oddzielony na różnym etapie, jeżeli robiłeś poprawkę w jednej wersji musiałeś nanieść zmianę na pozostałe systemy o ile ich zmiana dotyczyła. Każda zmiana w kodzie nawet linijki musiała być poprzedzona zgłoszeniem "z góry" i później analizowana przez parę osób.
Kod bardzo słabej jakości(jak to 20 lat wytwarzania) i do tego w C, dużo synchronizacji opartej na sleep... zmieniając coś w kodzie mogłeś spowodować że gdzieś ten sleep nie pyknął ;)
Ja na szczęście szybko wylądowałem w projekcie pisania tej aplikacji od początku, ruszyła taka wersja 2.0 :)