Piszesz kod, który działa. Potem dokładane są kolejne wymagania. Jeden IF, potem drugi, trzeci… aż w końcu debugowanie zaczyna boleć bardziej niż samo pisanie nowych feature’ów.
Ten wpis jest o momencie, w którym „jakoś działa” przestaje być wystarczające, a dług technologiczny upomina się o swoje. O refactorze nie jako estetycznej fanaberii, tylko decyzji biznesowej obniżającej koszt przyszłych zmian.
I trochę off-topu o tym, jak Nowy Rok potrafi rozbić rutynę.
#programowanie
Jak już do tego doszło to przejebane.
Mówimy pięknymi slowkami o refaktorze tylko jak wytłumaczyć to biznesowi który za to płaci a jeszcze dochodzą testy regresji.
Ja bym tu dodal że problemem złego kodu jest przede wszystkim pośpiech a czemu pośpiech? W bo niedoświadczony student chce się popisać, bo biznes chce rozwiązania na nowo itd.
Ja teraz przebywam coś odwrotnego. Architekt jest tak najarany na refaktor że już 5 raz zmieniamy koncepcję budowy i nie można się przyzwyczaić co jest gdzie a do tego dochodzi jeszcze brak kontroli nad tym co wymyślają w devie, czy wręcz sabotowanie zmian na "później"
@kodyak tak, to prawda, W moim przypadku akurat biznes nie gra aż tak dużej roli, ALE to absolutna prawda, że przekonanie biznesu, że programista potrzebuje X czasu na poprawianie rzeczy, które są dawno zapłacone może być drogą przez mękę.
Ciągły refactor to też nic dobrego, bo później ciężko się przyzwyczaić i wprowadzać nowe rzeczy do takiego kodu, nad którym powiedzmy nie masz pełnej kontroli, nie znasz go na pamięć.
O tak, uczucie bardzo znane. Najgorsze gdy bardzo długo to odkładasz i w końcu przychodzi moment jak musisz się tym zająć. Chociaż z drugiej strony po ogarnięciu takiego syfu zawsze czuje dużą satysfakcje.
@Catharsis zdecydowanie! Debugowanie jest już do tego stopnia frustrujące, że potem każda mała zmiana w kierunku porządku daje radość i taki spokój na bani....
Zaloguj się aby komentować