Skoro kod działa i na siebie zarabia to jeżeli nie ma testów, nie jest super czysty tylko był zrobiony na szybko aby jakoś działało to może testy, wzorce projektowe itd. których jestem takim zwolennikiem nie są takie super? Czy nie doprowadzanie do momentu gdy mamy tz. big ball of mud jest faktycznie takie ważne?
Chyba każdy inżynier w pewnym momencie uświadamia sobie, że jaranie się czystym kodem i innymi technicznymi rzeczami nie ma takiego znaczenia, jak zarabianie kasy przez produkt. Wzorce, dobre praktyki, konferencyjne gadki i reszta mają pomóc w rozwiązywaniu problemów biznesowych, a nie w pisaniu czystego kodu jako sztuka dla sztuki.
Tylko że nigdy się tego nie przepisze bo nigdy nie będzie na to pieniędzy
Kasa się znajdzie, jeżeli pokażesz wyliczenia, że przepisanie przyniesie zysk. Bo po co płacić masę kasy, jeżeli potem to się nie zwróci?
Po co refaktoryzować jak można od razu pisać dobry kod?
Pisanie dobrego kodu jest najprostszą częścią inżynierii oprogramowania. Trudne jest ustalanie, które problemy rozwiązywać i w jaki sposób. Złożone projekty są kijowe niekoniecznie dlatego, że zostały napisane syfiasto, często jest to połączenie wielu czynników, jak bardzo krótki termin na wdrożenie (czyli na produkcję leci prototyp), architektura wspierająca rozwiązania, które ostatecznie nie są potrzebne (i nikt ich nie używa), rotacje w projekcie (bo każdy ma inną wizję czystości kodu, więc jak pierwotny autor odchodzi, to następny chce przerabiać na swoją modłę i robi niespójnie), zmiana wymagań na każdym kroku, haki wynikające z niedojrzałości platformy czy tam bibliotek i wiele innych rzeczy. Programowanie jest proste, inżyniera oprogramowania jest trudna, a najtrudniejsze (i najbardziej wartościowe) jest dostarczenie rozwiązania, które działa i spełnia potrzebę biznesową, ale w ogóle nie wymaga programowania.