Modernizacja starej aplikacji PHP zaczyna się od zrozumienia działania firmy, a nie od samej listy bibliotek. Program może zawierać reguły, na których opierają się zamówienia, uprawnienia i raporty. Przepisanie formularzy bez rozpoznania tych zależności nie gwarantuje, że użytkownicy będą mogli dokończyć te same zadania po zmianie. Zakres powinien być powiązany z konkretnym rezultatem.
Rozważmy fikcyjny system serwisowy, w którym pracownicy przyjmują zgłoszenia i przygotowują zestawienia. Firma chce udostępnić klientom aktualny stan sprawy w nowym portalu. Pierwszym etapem może być bezpieczny odczyt jednego procesu, podczas gdy dotychczasowa aplikacja nadal nim zarządza. Ta granica pozwala ocenić integrację bez zakładania, że wszystkie funkcje trzeba wymienić w pierwszej dostawie.
Odtwórz proces wraz z wyjątkami
Prześledź zgłoszenie od utworzenia do zamknięcia. Zapisz ekrany, zmiany danych, zadania wykonywane później i ręczne decyzje pracowników. Zapytaj o sytuacje, których nie widać podczas zwykłej demonstracji, takie jak cofnięcie zamknięcia lub zmiana właściciela. Oprogramowanie może obsługiwać je w sposób nieudokumentowany, który trzeba najpierw zrozumieć i świadomie ocenić.
Oddziel ustalone reguły od założeń. Jeśli znaczenie pola nie jest znane, nie należy automatycznie nadawać mu nowej roli w interfejsie API. Porównaj kod z przykładami używanymi przez zespół. Właściciel procesu powinien potwierdzić, jakie zachowanie ma zostać zachowane, a które rzeczywiście wymaga zmiany. Pozwala to przygotować zakres, który użytkownicy będą mogli później odebrać.
Wyznacz pierwszą granicę wymiany
Ustal, czy nowa część tylko czyta dane, czy może je również zmieniać. To różne zobowiązania dotyczące uprawnień i spójności. Określ odpowiedzialność za każdy ważny zapis. Dwa systemy nie powinny bez wspólnej reguły nadpisywać tego samego stanu, licząc na to, że kolejność połączeń przypadkiem zachowa intencję pracownika obsługującego zgłoszenie.
Podejście etapowe opisuje między innymi wzorzec Strangler Fig w dokumentacji Microsoft. Nie narzuca ono konkretnego języka nowej aplikacji ani nie potwierdza wykonalności wybranego zakresu w Twoim systemie. Wymagana jest analiza rzeczywistych zależności, źródeł i sposobu wdrażania. Propozycja techniczna powinna jasno wskazywać te informacje, które dopiero trzeba ustalić.
Zaprojektuj przejście i warunek powrotu
Przygotuj oddzielne środowisko i dane testowe. Zapisz kombinację wersji, która będzie oceniana, oraz warunki zgody na dalszy etap. Uwzględnij zadania wykonywane w tle i pliki powiązane z rekordami. Nowa strona może poprawnie otwierać zgłoszenie, a mimo to nie uruchamiać procesu, którego oczekuje administracja po jego zakończeniu.
Powrót powinien uwzględniać nowe dane powstałe po przełączeniu. Przywrócenie starego adresu nie rozwiązuje automatycznie różnic między zapisami. Ustal, kto podejmuje decyzję o zatrzymaniu zmiany, jakie informacje zachowuje i jak uzgadnia dalsze działania. Jest to część przygotowania operacyjnego, a nie zadanie, które warto pozostawić do improwizacji podczas rzeczywistej awarii.
Odbierz jeden kompletny rezultat
Utwórz testowe zgłoszenie w dotychczasowym systemie i sprawdź je w nowym portalu. Zmień stan, ogranicz uprawnienia i przerwij połączenie, a potem prześledź wznowienie pracy. Porównaj końcowe dane i widoki. Odbiór powinien wykazać zachowanie uzgodnionej granicy, zamiast opierać się wyłącznie na pomyślnej odpowiedzi jednego endpointu.
Brainbaby Labs może pomóc ocenić aplikację i przygotować pierwszy etap modernizacji. Przynieś opis kluczowego zadania, dostępne źródła oraz znane ograniczenia. Wersje środowiska i zależności należy sprawdzić w konkretnym projekcie. Propozycja może wtedy określić wykonalny rezultat, sposób jego sprawdzenia i odpowiedzialność za przejście do dalszych części systemu.