Najbardziej bolesna wiadomość, jaką dostaje się po udanej kampanii to nie bug report – to mail od klienta z tytułem „super wyniki, chcemy dodać kolejne mechaniki”. W tym momencie orientujesz się, że system zbudowany w 14 dni pod konkretną kampanię ma teraz służyć jako platforma do dalszego rozwoju. I tu zaczyna się prawdziwy problem, bo MVP napisane pod presją czasu to zupełnie inna bestia niż kod przygotowany na iteracyjny rozwój.
Znam to z autopsji. Przejąłem kiedyś projekt gry webowej po innym wykonawcy – kampania B2B, osiem mechanik, panel CMS, integracja z QR kodami. Wszystko działało, klient był zadowolony. Problemem było że każda próba dodania nowej funkcji kończyła się trzydniowym debugowaniem, bo system był architektonicznie zamknięty. Hardkodowane wartości, brak separation of concerns, logika biznesowa rozlana po kontrolerach. Klasyczny tech debt stworzony nie przez niekompetencję, tylko przez realne ograniczenia czasowe.
I teraz stoisz przed pytaniem: refaktoryzować czy przepisać od nowa? To decyzja, która kosztuje. Źle podjęta może zabić projekt albo zamrozić rozwój na miesiące.
Kiedy MVP przestaje być MVP
Symptomy że system dojrzał do poważnej decyzji pojawiają się stopniowo, ale da się je wyłapać wcześnie. Pierwszy znak to velocity – każda kolejna zmiana trwa dłużej niż poprzednia. Feature, który na początku zajmował dwa dni, po trzech miesiącach wymaga tygodnia. To nie jest kwestia kompetencji developerów. To matematyka – każda nowa funkcja musi współdziałać ze wszystkimi poprzednimi, a w systemie bez przemyślanej architektury liczba interakcji rośnie wykładniczo.
Drugi symptom to bug whack-a-mole. Naprawiasz problem w mechanice A, pojawia się nowy w mechanice B. Dodajesz walidację w jednym miejscu, psuje się flow w innym. To oznaka że system ma zbyt wiele implicit dependencies – rzeczy które są ze sobą powiązane, ale nikt tego nie zapisał, nie zadokumentował, nie wyabstrahował. Każda zmiana to rosyjska ruletka.
Trzeci objaw, najbardziej podstępny: fear-driven development. Zespół boi się dotykać pewnych części kodu. „To działa, nie ruszajmy tego” staje się mantrą. Pojawia się workaround culture – zamiast naprawić źródło problemu, dopisujemy kolejny if statement, kolejny edge case handler, kolejną łatkę na łatce. W końcu masz system gdzie 80% logiki to obsługa wyjątków od wyjątków.
I wreszcie onboarding – nowy developer potrzebuje tygodni żeby zrozumieć jak system działa. Nie dlatego że jest skomplikowany funkcjonalnie, tylko dlatego że logika jest nieoczywista. Dokumentacji nie ma albo jest przestarzała, więc nauka polega na czytaniu kodu i zadawaniu pytań. Albo gorzej – na trial and error na stagingu.
Wszystkie te objawy widziałem w projekcie, o którym wspomniałem. Po trzech miesiącach rozwoju velocity spadło o połowę. Developerzy zaczęli unikać pewnych części kodu. QA krzyczało że każdy fix tworzy dwa nowe bugi. I pojawił się głos: „może przepiszmy to od nowa?”.
"W pewnym momencie przestajesz zastanawiać się, dlaczego dodanie jednej funkcji zajmuje tydzień. Zaczynasz się zastanawiać, które trzy rzeczy zepsują się przy okazji. "
Framework decyzyjny zamiast emocjonalnego wyboru
Decyzja refactor vs rewrite prawie zawsze pada pod wpływem frustracji. Zespół męczy się z legacy code, ktoś na retrospektywie mówi „kurde, gdybyśmy to pisali dziś, zrobilibyśmy to lepiej” i nagle jest momentum żeby wszystko wyrzucić i zacząć od czystej karty. To bardzo zły moment na podejmowanie decyzji architektonicznych.
Joel Spolsky w swoim słynnym tekście „Things You Should Never Do” przytacza Netscape jako ostrzeżenie. Netscape 4 był kodem z problemami, więc zespół zdecydował się przepisać go całkowicie. Zajęło to trzy lata. W tym czasie konkurencja (Internet Explorer) przejęła rynek. Gdy Netscape 6 w końcu wyszedł, było za późno. Rewrite zabił firmę nie dlatego że nowa wersja była słaba – tylko dlatego że trzy lata bez nowych features to wieczność w dynamicznym rynku.
Argument Spolsky”ego brzmi: nie wyrzucaj działającego kodu, bo nawet brzydki kod zawiera lata domain knowledge, edge case”ów, bugfixów. Przepisując od nowa tracisz to wszystko i będziesz odkrywać te same problemy ponownie.
Ale to nie jest uniwersalna prawda. Są sytuacje gdzie rewrite ma sens mimo wszystko. Kluczowe pytanie nie brzmi „czy kod jest brzydki”, tylko „czy obecna architektura pozwala osiągnąć cele biznesowe przy akceptowalnym koszcie”. Jeśli odpowiedź to nie, i refactoring nie zmieni fundamentalnych ograniczeń systemu – rewrite może być dobrym ruchem.
Konkretnie: jeśli MVP zostało napisane na WordPressie z custom pluginami, a teraz potrzebujesz realtime interactions, rozbudowanego API dla mobilnej apki i integracji z zewnętrznymi systemami – refactoring WordPressa nie pomoże. To są architektoniczne limity platformy. Możesz poświęcić miesiące na obejścia i hacki, albo przepisać core na technologię zaprojektowaną pod twoje wymagania.
Z drugiej strony, jeśli problem to źle zorganizowany kod w dobrym stacku – refactoring jest lepszy. Przepisywanie działającego Node.js na inny Node.js tylko dlatego że obecny jest spaghetti to strata czasu. Można przeprowadzić stopniowy refactoring bez zamrażania rozwoju.
Matryca decyzyjna którą stosuję:
Refactoring jeśli:
- Stack technologiczny jest adekwatny do wymagań
- Problemy są organizacyjne (struktura kodu, brak wzorców), nie fundamentalne
- Masz dobry test coverage albo możesz go szybko dodać
- Business może poczekać z częścią nowych features
Rewrite jeśli:
- Fundamentalne ograniczenia technologii (performance, concurrency model, ecosystem)
- Kod jest na tyle splątany że refactoring wymaga przepisania 70%+ systemu
- Masz budżet i czas na parallel development
- Można zdefiniować jasną feature parity bez scope creep
Ani jedno ani drugie jeśli:
- Problemem nie jest kod tylko organizacja/procesy (wtedy najpierw napraw to)
- Decyzja wynika z chęci "pobawienia się nową technologią"
- Nie ma jasnego sponsora biznesowego dla kosztów przestoju
Cost of delay to kolejny czynnik który trzeba uwzględnić. Jeśli jesteś w szybko zmieniającym się rynku, każdy tydzień bez nowych features to stracone możliwości. Refactoring pozwala na ciągłe dostarczanie wartości mniejszym kosztem. Rewrite zamraża development na tygodnie lub miesiące, ale potencjalnie odblokowuje większy przyszły velocity.
Refactoring pod presją: strategia dla MVP w produkcji
Załóżmy że decyzja pada na refactoring. Masz działający system, użytkownicy z niego korzystają, klient chce nowych features. Nie możesz powiedzieć „stop, teraz dwa miesiące refactorujemy”. Musisz operować na żywym organizmie.
Strangler fig pattern to jedyna strategia która działa w takich warunkach. Nazwa pochodzi od rośliny która obrasta drzewo, przejmuje jego funkcje, a następnie oryginalny pień obumiera. W kontekście kodu: piszesz nową implementację obok starej, stopniowo przekierowujesz ruch, a gdy nowa wersja obsługuje wszystko – usuwasz starą.
Praktycznie wygląda to tak: identyfikujesz moduł który jest biggest pain point – powiedzmy mechanika scoringu w grze. Zamiast refaktoryzować istniejący kod w miejscu, piszesz nowy moduł z czystą architekturą. Dodajesz abstrakcję (interface) nad scoring systemem. Stara implementacja siedzi za tym interface. Piszesz testy dla nowego modułu. Zmieniasz interface żeby wskazywał na nową implementację. Feature flag pozwala łatwo wrócić do starej wersji jeśli coś wybuchnie. Po tygodniu obserwacji na produkcji usuwasz stary kod.
To jest wolniejsze niż big bang refactor, ale bezpieczniejsze. Każdy krok jest deliverable. Możesz równolegle dodawać nowe features – część idzie do starego kodu (będzie przepisana później), część od razu w nowej architekturze.
Priorytetyzacja której części refaktoryzować najpierw jest krytyczna. Intuicja mówi „zacznij od najbardziej problematycznego kodu”. To często zła intuicja. Najbardziej problematyczny kod jest też najbardziej ryzykowny – dużo zależności, edge case”ów, potencjalnie dużo bugów czekających na odkrycie.
Lepsza strategia: zacznij od modułu który:
- Jest relatywnie izolowany (mało zależności)
- Ma jasno zdefiniowane inputs i outputs
- Jest często modyfikowany (duży ROI z refactoringu)
- Nie jest biznesowo krytyczny w sensie awarii (niskie ryzyko)
W projekcie gry webowej dobrym kandydatem był system logowania eventów. Używany wszędzie, prosty interface, niskie ryzyko biznesowe. Zrefaktorowanie go było łatwe, dało quick win (lepsze logi = łatwiejszy debugging), i pozwoliło zespołowi przećwiczyć proces strangler fig na małym przykładzie.
Test coverage jako prerequisite to nie negocjowalne. Nie da się bezpiecznie refaktoryzować bez testów. Ale tu jest pułapka – pisanie testów do legacy code jest trudniejsze niż do nowego. Legacy często ma tight coupling, zależności od globalnego state, brak dependency injection. Żeby przetestować funkcję musisz zmockować pół systemu.
Dlatego kolejność jest ważna: najpierw dodaj testy end-to-end dla kluczowych flow (takie które user by zauważył gdyby się zepsuły). Potem zacznij refactoring od modułów które da się wyabstrahować i przetestować unit testami. Stopniowo test coverage rośnie i możesz atakować coraz bardziej problematyczne części systemu.
Branch by abstraction to technika dla dużych zmian które wymagają tygodni pracy. Zamiast robić long-lived feature branch (który co merge to konflikt), wprowadzasz abstrakcję w main branch. Przykład: chcesz zmienić storage z prostego file-based na bazę danych. Zamiast brancha:
- 1. Dodajesz interface StorageProvider
- 2. Implementujesz FileStorage jako implementację tego interface
- 3. Refactoring całego kodu żeby używał interface zamiast bezpośredniego dostępu do plików (to może być rozłożone na wiele commitów)
- 4. Piszesz DatabaseStorage jako drugą implementację
- 5. Feature flag przełącza między implementacjami
- 6. Po walidacji na produkcji usuwasz FileStorage
To wszystko dzieje się na main branch, w małych incrementach. Żadnych mega merge”y. Żadnego „oby działało po zmergowaniu”.
"Legacy code ma ciekawą właściwość. Im dłużej działa na produkcji, tym mniej jesteś pewien, które fragmenty są faktycznie potrzebne, a które po prostu nikt nie miał odwagi usunąć."
Przepisywanie bez zamrażania rozwoju
Jeśli decyzja pada na rewrite – musisz mieć strategię żeby nie powtórzyć błędu Netscape. Parallel development to jedyne rozsądne podejście: stary system żyje i jest rozwijany, nowy powstaje równolegle. To jest drogie (dwa zespoły albo jeden zespół split między dwie bazy kodu), ale alternatywa – zamrożenie rozwoju na miesiące – jest droższa.
Problem z parallel development: jak długo utrzymujesz dwa systemy? Pokusa jest żeby powiedzieć „nowy system będzie miał feature parity ze starym, potem przełączymy”. To prawie nigdy nie działa, bo w czasie gdy piszesz nowy system, stary jest rozwijany. Moving target. Gonisz własny ogon.
Mądrzejsze podejście: zdefiniuj feature parity jako „80% najczęściej używanych funkcji plus wszystko co nowe”. Reszta nie zostanie przepisana, zostanie wyłączona. Brzmi brutalnie, ale gdy spojrzysz na analytics większości systemów, okazuje się że 20% features generuje 80% value. Reszta to legacy którym nikt nie używa, ale „zawsze było”.
To wymaga rozmowy z klientem. W projekcie gry webowej klient chciał zachować wszystkie osiem mechanik z MVP plus dodać cztery nowe. Analiza pokazała że dwie z oryginalnych mechanik miały combined usage poniżej 5%. Zaproponowałem: nowy system dostanie sześć mechanik z MVP plus cztery nowe, czyli dziesięć total – więcej niż było. Ale te dwie mało używane odpadają. Klient po obejrzeniu danych się zgodził. To zaoszczędziło dwa tygodnie development time.
Ten typ decyzji to moment gdzie technical reality spotyka się z business expectations. Klient nie widzi architektury, widzi features. Jego perspektywa: „po co przepisujecie jeśli nie dostanę wszystkiego co było plus więcej?”. Developer widzi tech debt i wie że przepisanie rzadko używanego feature to strata czasu. Trzeba pokazać dane – usage metrics, cost of maintenance, development time estimates. Bez tego rozmowa schodzi na emocje i „tak zawsze było”.
Migration strategy: big bang vs gradual. Big bang to przełącznik: stary system działa do dnia X, nowy system startuje dzień X+1. Gradual to stopniowe przełączanie użytkowników/features. Big bang jest prostszy do zarządzania (jeden deploy, jedna data), ale ryzykowny. Gradual jest bezpieczniejszy, ale wymaga że oba systemy współdzielą część infrastruktury (na przykład database, auth).
Przy grze webowej użyliśmy hybrid approach: nowy system został wdrożony na subdomain (play-new.example.com), dostępny dla internal testing i chętnych early adopters. Feature flag w starym systemie pokazywał banner „wypróbuj nową wersję”. Przez dwa tygodnie oba systemy działały równolegle. Monitorowaliśmy error rates, performance, user feedback. Gdy byliśmy pewni – przełączyliśmy główny domain na nowy system. Stary został jako fallback przez kolejne dwa tygodnie, potem wyłączony.
Rollback plan to rzecz o której wszyscy wiedzą że trzeba ją mieć, i nikt nie chce o niej myśleć bo „a jeśli będziemy musieli cofnąć to porażka projektu”. To myślenie jest błędne. Rollback to nie porażka, to safety net. I wcale nie jest oczywiste jak go zrobić.
Jeśli nowy system używa tej samej bazy danych co stary, rollback wymaga schema migration backward compatibility. Każda migracja musi być reversible, a to często oznacza że nie możesz usuwać kolumn, tylko je deprecated. Jeśli nowy system wprowadza breaking changes w formacie danych – rollback oznacza data loss albo skomplikowaną konwersję z powrotem.
Bezpieczniejsze: nowy system ma własną bazę danych, replika starych danych. Rollback to zmiana DNS + wyłączenie nowego systemu. Minus: synchronizacja danych między systemami podczas migration window. Plus: zero ryzyka dla starych danych.
Rzeczy których nie widać w dokumentacji
Największy problem z rewrite vs refactor to presja zewnętrzna której nie da się zaplanować. Klient widzi że development się przedłuża. Zaczyna się niecierpliwić. Pojawia się pytanie „dlaczego to trwa tak długo skoro poprzedni system zrobiliście w dwa tygodnie”. No właśnie – poprzedni system był MVP pod konkretny scope, nowy ma być platformą. To zupełnie inna skala złożoności.
I tu się okazuje czy masz dobrego product ownera po stronie klienta. Jeśli tak – rozumie trade-offy i broni decyzji technicznej przed wewnętrzną presją. Jeśli nie – każde daily standup to „kiedy będzie gotowe” i „czy możemy dodać jeszcze tę jedną małą rzecz”.
Parallel development to też problem dla zespołu. Developer musi switchować kontekst między starym a nowym systemem. Stary jest brzydki ale znany. Nowy jest czysty ale wymaga więcej myślenia. Naturalnie ludzie wolą pracować przy nowym – tam kod jest przyjemny. Ale stary też wymaga bugfixów i maintenance. Pojawia się tension: kto ma robić co. Młodsi developerzy dostają stary system bo „prosta robota”, seniorzy piszą nowy. To buduje frustrację.
Lepiej: rotacja. Każdy spędza tydzień przy starym, tydzień przy nowym. Wszyscy rozumieją oba systemy. Nikt nie jest „legacy developer”.
Second system effect to pułapka przy rewrite. Opisał ją Fred Brooks w „The Mythical Man-Month”. Brzmi tak: programiści którzy piszą system po raz drugi mają tendencję do over-engineering. Przy pierwszym systemie robili pragmatyczne decyzje pod presją. Przy drugim mają czas i chcą zrobić „idealnie”. Dodają abstrakcje na abstrakcje, frameworks, patterns. W efekcie nowy system jest bardziej skomplikowany niż stary – tylko w inny sposób.
Widziałem to wielokrotnie. Team dostaje drugą szansę i projektuje system z wszystkimi bells and whistles których brakowało w MVP. Plugin architecture żeby „łatwo dodawać nowe mechaniki”. Event sourcing żeby „mieć pełną historię zmian”. Microservices bo „będzie skalowalne”. Każda z tych decyzji indywidualnie może być rozsądna. Razem tworzą complexity budget który przekracza faktyczne potrzeby projektu.
Antidotum: jawne ograniczenie complexity. „Nowy system może być co najwyżej 2x bardziej złożony niż stary, mierzony w liczbie abstrakcji/komponentów”. Forced simplicity. Każda nowa warstwa musi być uzasadniona konkretnym wymaganiem, nie teoretyczną przyszłą potrzebą.
"Rewrite ma dziwną właściwość. Im dłużej trwa, tym więcej osób zaczyna tęsknić za systemem, który jeszcze kilka miesięcy wcześniej wszyscy chcieli jak najszybciej wyrzucić."
Symptomy że idziesz w złą stronę
Rewrite jako ucieczka od problemu organizacyjnego to red flag którego nie zauważasz dopóki nie jest za późno. Symptom: zespół narzeka że kod jest zły, ale konkretne problemy są vague. „Ciężko się w tym pracuje”. „Za dużo boilerplate”. „Nie da się tego utrzymać”. Gdy pytasz o konkretny przykład – pokazują pojedyncze brzydkie funkcje. Ale to nie uzasadnia rewrite całego systemu.
Głębszy problem może być gdzie indziej. Niejasne requirements które zmieniają się co sprint. Brak code review więc każdy pisze w swoim stylu. Brak time na dokumentację więc nikt nie wie co robi cudzy kod. To są problemy procesowe, nie architektoniczne. Rewrite ich nie naprawi – nowy system będzie miał te same problemy za pół roku.
Sposób żeby to zdiagnozować: zapytaj „co konkretnie będzie lepsze w nowym systemie i dlaczego nie możemy tego naprawić w starym”. Jeśli odpowiedź brzmi „bo stary jest już za bardzo zepsuty” – to dodge. Dopytuj o konkretne architektoniczne ograniczenia. Jeśli nie potrafią ich nazwać – problem nie jest w kodzie.
„Nowa technologia rozwiąże wszystkie problemy” to kolejna iluzja. Node.js jest wolny? Przejdźmy na Go. React jest zbyt skomplikowany? Piszmy w Vue. PostgreSQL nie skaluje? Weźmy MongoDB. Te decyzje prawie nigdy nie są o prawdziwych limitach technologii – są o grass-is-greener thinking.
Każdy stack ma swoje wady. Przeskakujesz z jednego na drugi i wymieniasz znane problemy na nieznane. Plus tracisz ecosystem knowledge – narzędzia, biblioteki, community solutions do typowych problemów. Zespół musi uczyć się od nowa. First month w nowej technologii zawsze wygląda pięknie bo robisz hello world. Prawdziwe problemy widzisz po trzech miesiącach, gdy wchodzisz w edge case”y i okazuje się że „prosta” technologia ma swoje pułapki.
Wyjątek: fundamentalne ograniczenia. Python z GIL nie da ci prawdziwego multi-threading, nieważne jak dobry kod. PHP w starszych wersjach nie ma async. Ruby jest wolny przy CPU-intensive tasks. To są realne technical constraints które uzasadniają zmianę. Ale „wolniej się pisze w X” albo „framework Y ma brzydką składnię” – to nie są powody do rewrite.
Co robić gdy decyzja już została podjęta
Załóżmy że decyzja była zła. Zaczęliście rewrite, minęły dwa miesiące, nowy system ma 30% feature parity, a klient krzyczy że konkurencja wypuściła nową funkcję i wy nie możecie bo „przepisujecie”. Co teraz?
Sunk cost fallacy jest potężna. „Już włożyliśmy tyle pracy w rewrite, nie możemy teraz tego porzucić”. Możecie. Jeśli kontynuowanie prowadzi do większej straty niż abort – abortujecie. To boli, szczególnie jak trzeba wrócić do brzydkiego starego kodu, ale to pragmatyzm.
Pivot strategy: zamiast full rewrite robimy targeted extraction. Nowy system który piszemy staje się modułem w starym. Przykład z gry webowej: przepisaliśmy scoring engine jako standalone service z REST API. Stary system wywołuje nowy scoring service zamiast własnej logiki. To dało nam benefity nowej architektury (czysty kod, łatwe testowanie, lepszy performance) bez ryzyka big-bang migration. Reszta starego systemu została.
To wymaga zmiany narracji wobec stakeholders. „Przepisujemy system” brzmi jak project z konkretnym end date. „Modernizujemy architekturę modułami” brzmi jak continuous improvement bez ostrego deadline. Biznes łatwiej to akceptuje.
Monitoring i metrics są kluczowe przy migration. Musisz wiedzieć czy nowy system jest faktycznie lepszy. „Czystszy kod” nie jest metryką. Metryki to: response time, error rate, deployment frequency, time to implement new feature. Jeśli refactoring albo rewrite nie poprawia tych liczb – coś robisz źle.
Praktycznie: postaw baseline metrics przed rozpoczęciem. „Obecnie dodanie nowej game mechanic zajmuje średnio 5 dni i wprowadza średnio 2 bugi”. Po refactoringu/rewrite mierzysz to samo. Jeśli liczby się nie poprawiły albo pogorszyły – masz objective proof że coś poszło nie tak.
Refleksja po faktach
Każdy MVP który odniesie sukces stanie przed tym samym pytaniem. System który miał służyć trzy miesiące nagle ma być fundamentem długoterminowego produktu. To nie jest failure w planowaniu – to efekt uncertainty. Nie wiesz czy produkt strzeli dopóki nie wypuścisz go na rynek. Więc budujesz pragmatycznie pod znane wymagania. A potem reality hits i okazuje się że to co było dobre dla MVP jest w koszmarze dla scale.
Nie ma uniwersalnej odpowiedzi refactor vs rewrite. Każdy projekt ma inny kontekst, inne constraints, inny technical debt profile. Ale są pytania które zawsze trzeba zadać: czy problem jest architektoniczny czy procesowy? Czy mamy budżet na parallel development? Czy zespół ma doświadczenie z tym typem migracji? Czy business rozumie że przez jakiś czas velocity spadnie?
I najważniejsze pytanie którego nikt nie chce słyszeć: czy na pewno musimy to robić teraz? Może da się jeszcze pół roku pokopać w starym systemie, dostarczyć wartość biznesową, a refactoring/rewrite zrobić gdy będzie więcej resources i mniej pressure? Czasem najlepsza decyzja architektoniczna to odłożyć architektoniczną decyzję.
Bo prawda jest taka że większość systemów nie umiera z powodu złej architektury. Umierają bo przestają dostarczać wartość albo konkurencja je wyprzedza. Piękny, czysty kod który dostarczasz za późno jest bezużyteczny. Brzydki kod który shipped i zarabia jest lepsza. To boli w sensie estetycznym, ale inżynieria nie jest sztuką dla sztuki – jest narzędziem do rozwiązywania problemów.
Więc następnym razem gdy zespół zaproponuje „przepiszmy to od nowa”, zastanów się dwa razy. Albo dziesięć. Może faktycznie jest to jedyne wyjście. Albo może jest sposób żeby dostarczyć 80% wartości przy 20% ryzyka. Produkcja bardzo szybko weryfikuje która opcja była słuszna – zwykle nie ta która wyglądała najładniej na diagramie architektonicznym.
Podsumowanie
Największa ironia większości udanych MVP polega na tym, że problemy zaczynają się dokładnie wtedy, gdy wszystko poszło zgodnie z planem. System miał obsłużyć kampanię, pilotaż albo pierwszych klientów. Miał przetrwać kilka miesięcy i dać odpowiedź na jedno pytanie: czy ktoś w ogóle tego potrzebuje. Potem przychodzi sukces, kolejne wymagania, nowe integracje, dodatkowi użytkownicy i nagle okazuje się, że tymczasowe decyzje architektoniczne stały się stałymi elementami produktu. Kod nie jest zły. Po prostu został napisany dla zupełnie innej rzeczywistości niż ta, w której przyszło mu działać.
W takich momentach łatwo uwierzyć, że refactoring albo rewrite jest rozwiązaniem problemu. Z perspektywy diagramów często wygląda to logicznie. Stary system wydaje się ograniczeniem, nowy ma być czystszy, szybszy i bardziej przyszłościowy. Produkcja bardzo szybko przypomina jednak, że żadna migracja nie zatrzymuje biznesu, użytkowników ani rynku. W czasie gdy zespół poprawia architekturę, ktoś nadal zgłasza błędy, oczekuje nowych funkcji i porównuje tempo rozwoju z konkurencją. Technologia daje komfort myślenia o idealnym rozwiązaniu. Produkcja wymusza myślenie o kosztach każdej decyzji.
Po pewnym czasie większość zespołów dochodzi do podobnego wniosku. Rzadko istnieje moment, w którym można wszystko zatrzymać i spokojnie zbudować system od nowa. Znacznie częściej wybiera się między różnymi rodzajami kompromisów, które mają własne koszty, ryzyka i konsekwencje. I być może właśnie dlatego najlepsze systemy nie są tymi, które wyglądają najładniej na diagramach architektonicznych. Są tymi, które potrafią przetrwać wystarczająco długo, żeby biznes zdążył wykorzystać ich wartość, zanim pojawi się kolejny powód, by przebudować je od nowa.
Zobacz powiązane case studies i analizy
Procesy, architektura i workflow powiązane z tematami poruszanymi w tym materiale – od integracji i realtime systems po automatyzacje operacyjne.