Import przestał działać, formularz zgłasza błąd albo potrzebujesz zmienić jedną funkcję. Jeśli zadanie ma jasne granice i można sprawdzić jego wynik, uzgadniamy zakres naprawy. Osobna diagnoza całej aplikacji nie jest wtedy automatycznie potrzebna.
System jest potrzebny firmie, ale rozwój się zatrzymał lub każda poprawka wywołuje kolejne problemy. Sprawdzamy dostępne materiały i sposób działania aplikacji, aby zaplanować pierwszy etap oraz dalszą współpracę.
Hosting wymaga zmiany wersji PHP albo zależności blokują aktualizację. Rozpoznajemy zgodność aplikacji, potrzebne poprawki i procesy, które trzeba sprawdzić przed przełączeniem środowiska.
W aplikacji wykonanej wcześniej przez innego dostawcę naprawiliśmy import dużych plików CSV, poprawiliśmy interfejs i działanie na urządzeniach mobilnych. Dopiero po poznaniu procesu klienta przebudowaliśmy katalog książek w Laravelu. Naprawa bieżącego problemu i pełna przebudowa były osobnymi etapami.
Po przejęciu projektu stan aplikacji przemawiał za zastąpieniem starego kodu. Napisaliśmy serwis od podstaw w Laravelu, zachowując i rozwijając kierunek wizualny właściciela. Prace objęły również dane ofert, wyszukiwanie, opinie, wiadomości i moderację.
Zaczynamy od ustalenia, do czego firma używa systemu i jakie działanie ma zostać przywrócone lub rozwinięte. Sprawdzamy, gdzie znajduje się kod, czy odpowiada działającej wersji oraz kto kontroluje repozytorium, hosting i powiązane usługi. Braki w materiałach zapisujemy jako ograniczenia dalszych prac.
W uzgodnionym zakresie analizujemy framework i biblioteki, konfigurację, bazę danych, integracje oraz zadania wykonywane w tle. Sprawdzamy możliwość uruchomienia projektu w środowisku testowym i odtworzenia najważniejszych czynności użytkowników. Na tej podstawie ustalamy, które zmiany można wprowadzić najpierw.
Przykładowo: poprawka importu mogła trafić bezpośrednio na serwer, bez zapisania jej w repozytorium. Wtedy pobranie samego repozytorium nie odtworzy obecnego działania. Przed rozwojem porównujemy dostępne wersje i ustalamy, która będzie podstawą testów oraz wdrożenia.
Porządkowanie przekazania szerzej opisujemy w poradniku o zmianie programisty w istniejącej aplikacji.
Przy ustalonej naprawie przekazujemy poprawkę w uzgodnionym środowisku, wynik sprawdzenia jej działania i informacje potrzebne do wdrożenia lub dalszej pracy. Kryteria odbioru określamy przed rozpoczęciem.
Jeśli najpierw potrzebna jest diagnoza, jej uzgodniony wynik może obejmować:
Sam wiek aplikacji nie rozstrzyga o jej wymianie. Decyzję wiążemy z konkretnymi ograniczeniami kodu, danych i środowiska. Różnice między tymi wariantami opisujemy w artykule o modernizacji systemu i budowie od zera.
Bezpłatna rozmowa do 20 minut służy określeniu problemu, celu i materiałów potrzebnych do kolejnego kroku. Nie obejmuje analizy kodu ani raportu technicznego.
Gdy zakresu prac nie da się rzetelnie określić na podstawie dostępnych informacji, proponujemy osobną płatną diagnozę. Przed jej rozpoczęciem potwierdzamy zakres, rezultat, termin i koszt. Na wycenę wpływają stan kodu, kompletność materiałów, integracje oraz znaczenie zmienianego procesu dla pracy firmy.
Materiały z diagnozy możesz wykorzystać również z innym wykonawcą, z zachowaniem poufności. Jeżeli później realizujemy wynikające z niej prace, zapłacony koszt diagnozy wliczamy w całkowity koszt projektu.
Sprawdzamy wsparcie używanej wersji PHP oraz zgodność frameworka i bibliotek z wersją docelową. Przed zmianą ustalamy sposób wykonania kopii, testowania i powrotu do poprzedniego wydania. Odbiór powinien objąć ważne procesy, integracje i zadania w tle; samo otwarcie strony nie potwierdza działania całej aplikacji.
Jeśli zgłoszenie dotyczy krytycznej luki PHP, pilną poprawkę środowiska trzeba uzgodnić z administratorem lub hostingiem. Przepisanie aplikacji nie zastępuje tej poprawki. Szczegóły wyjaśniamy w poradniku o aktualizacji PHP i ocenie starszej aplikacji. Ta oferta nie oznacza całodobowej obsługi incydentów.
Szerszy audyt bezpieczeństwa, migracja danych i późniejsze utrzymanie aplikacji wymagają własnego, uzgodnionego zakresu. Nie stają się automatycznie częścią przejęcia projektu.
Podaj adres systemu, opisz problem i pierwszy oczekiwany efekt. Jeśli znasz technologię lub ważny termin, dodaj tę informację. Odpowiemy pytaniami albo propozycją następnego kroku.
Nie przesyłaj haseł, kluczy API, kopii bazy ani danych klientów. Jeśli do prac będą potrzebne dostępy, sposób ich przekazania ustalimy po uzgodnieniu zakresu.
Wolisz inny kontakt? Napisz e-mail lub zadzwoń.
