Mam tę skłonność — zarówno jako developer, jak i w życiu. Lubię reorganizować, katalogować, restrukturyzować i przesuwać elementy, aż wszystko wydaje się ergonomiczne i uporządkowane. Przez długi czas mówiłem sobie, że to moja mocna strona. Nie zauważałem jednak, że robię porządki, zanim zdążyłem w ogóle narobić bałaganu.
Żaden system nie jest naprawdę idealny, wolny od błędów i gotowy na każdą przyszłą funkcję. Mój lęk przed długiem technicznym popychał mnie jednak do wielotygodniowego analizowania architektury prostego projektu. Logika wydawała się rozsądna: zbuduj od razu skalowalny fundament, a później oszczędzisz sobie bólu. Nadal wierzę, że struktura ma znaczenie, także w małych i średnich systemach.
Ale za każdym razem, gdy kończyłem refaktoryzację i zaczynałem implementować nową funkcję, dostrzegałem sposób, w jaki poprzedni projekt można ulepszyć pod konkretny przypadek. Zmieniałem więc klasy bazowe. Potem model bazy danych. I wkrótce prawie każda nowa funkcja była w jakiś sposób „zablokowana” przez kolejną refaktoryzację.
W pewnym momencie musiałem przyznać, że coś w moim procesie nie działa.
Nie narzędzia. Nie język. Nie framework. Sposób, w jaki pracowałem. Optymalizowałem pod kątem poprawności i elegancji zamiast postępu. A to postęp naprawdę ujawnia złe decyzje. Bez niego dyskutowałem jedynie z wyobrażonymi problemami przyszłości.
Zmieniłem więc zasady, które sobie narzucałem.
Oddzieliłem czas na refaktoryzację od czasu na dostarczanie. Refaktoryzacja stała się zaplanowanym działaniem. Wszystko inne dotyczyło wdrażania: nowych funkcji, drobnych ulepszeń, naprawiania błędów i zamykania zadań.
Stworzyłem plik TECHNICAL_DEBT.md. Gdy coś wydawało się niewłaściwe lub brzydkie, zapisywałem to zamiast od razu naprawiać. Co boli? Dlaczego boli? Co zmieniłbym, gdybym miał czas? Zaplanowałem w kalendarzu powtarzający się blok czasu na zajęcie się tym.
To zmieniło wszystko.
Praca stała się spokojniejsza. Decyzje — lżejsze. Przestałem walczyć z samym sobą podczas pisania kodu. Mogłem iść do przodu, nie udając, że każdy wybór musi być perfekcyjny. Dłużej zajęło mi zrozumienie, dlaczego ten schemat w ogóle powstawał. Znałem teorię. Wszyscy ją znają. Nadmierne komplikowanie projektu na początku jest błędem. Przedwczesna abstrakcja jest niebezpieczna. Należy pozwolić systemowi rosnąć.
Ale sama wiedza nie wystarczyła.
Mój perfekcjonizm robił coś bardziej toksycznego. Nie pozwalał mi w ogóle uznać istnienia długu technicznego. Zapisanie czegoś jako „niedoskonałego” wydawało się przyznaniem do porażki. Dowodem na to, że nie jestem dobrym developerem. Brak postępów w projektach prowadził mnie coraz głębiej w tę spiralę.
Uczę się teraz, że dobre systemy nie rodzą się czyste. Stają się takie dzięki użyciu. Dzięki błędom. Pod wpływem realnych użytkowników i prawdziwych ograniczeń. Kończenie rzeczy okazało się bardziej satysfakcjonujące niż projektowanie idealnych systemów. A akceptacja długu technicznego okazała się oznaką dojrzałości, a nie porażki.