Modernizacja systemów legacy
23Minds ocenia system legacy i modernizuje go etapami. Każda faza ma własny zakres i budżet, nowe komponenty wchodzą na produkcję obok starego systemu, a refaktoryzację wspiera AI pod przeglądem inżyniera.
Pakiet wejściowyOcena systemu legacy i mapa drogowaod 26 000 PLN1 system · do 4 tygodni od ustalenia zakresuCo zawieraWymiana komponentów etapami
Nowe komponenty pracują obok starego systemu za warstwą przekierowań, aż stary przestanie być potrzebny.
Budżet na każdą fazę
Mapa drogowa wycenia każdą fazę osobno, więc decyzję o kontynuacji podejmujecie z liczbami w ręku.
Testy współpracy nowego i starego kodu
Granica między nowym a starym kodem dostaje testy i dokumentację, żeby nic nie pękło niezauważone.
23Minds modernizuje systemy legacy, które blokują rozwój produktu.
Rozwiń podsumowanie
Usługa zaczyna się od oceny systemu: architektura, zależności, punkty ryzyka. Potem powstaje mapa drogowa w modelu strangler fig, czyli plan wymiany komponentów po kolei, z budżetem na każdą fazę. Nowe komponenty wchodzą na produkcję obok starego systemu za warstwą przekierowań, a stara ścieżka jest wygaszana dopiero po ustabilizowaniu nowej. Refaktoryzację przyspiesza AI, a każdą zmianę sprawdza inżynier. Typowe systemy: monolity w PHP, Perlu i starszym .NET, Java EE, aplikacje z HTML generowanym na serwerze i interfejsem na jQuery, nietypowany JavaScript, stary Python.
Dowody, które możecie sprawdzić.
- Ocena systemu przed pierwszą linią kodu
Architektura, zależności i punkty ryzyka spisane w pierwszym pakiecie, zanim zapadnie decyzja o czymkolwiek.
- Refaktoryzacja z AI, odbiór przez inżyniera
Każdy przeniesiony komponent przechodzi te same bramki co nowy kod, a za odbiór odpowiada inżynier, który czyta pełny diff.
- Ocena i mapa drogowa w cztery tygodnie
Jeden system, cena stała po ustaleniu zakresu, fazy ułożone według ryzyka, każda z własnym budżetem.
- Wiedza zostaje u was
Sesje w parach i spisana architektura, żeby wasz zespół rozumiał nowy kształt systemu.
Proces, faza po fazie.
Sposoby rozpoczęcia współpracy, od bezpłatnego do pełnego projektu.
Każda usługa ma bezpłatny pierwszy krok, pakiet wejściowy z pisemnym rezultatem i ceną podaną tutaj oraz pełny projekt albo stałą współpracę, wyceniane po rozmowie wstępnej. Po ustaleniu zakresu cena jest stała, bez ukrytych kosztów.
- 1Krok 1 · Bezpłatnie
Rozmowa wstępna z inżynierem
do 60 minut · z inżynierem · bez zobowiązań
BezpłatniePorozmawiajcie z inżynieremPokaż szczegóły
- Rozmowa wstępna z inżynierem, a jeśli wolicie zacząć sami: samoocena online
- Pisemne podsumowanie rozmowy z propozycją następnego kroku w ciągu jednego dnia roboczego
- Bez zobowiązań i bez prezentacji sprzedażowej
- Polecany2Krok 2 · Pakiet wejściowy
Ocena systemu legacy i mapa drogowa
1 system · do 4 tygodni od ustalenia zakresu
od 26 000 PLN nettoCena stała po ustaleniu zakresu na rozmowie wstępnej, bez ukrytych kosztów; dopłaty tylko za pozycje z listy Poza zakresem.
Zapytajcie o ten pakietPokaż szczegóły
- Ocena jednego systemu legacy: architektura, zależności, punkty ryzyka
- Mapa modernizacji w modelu strangler fig
- Budżet na każdą fazę
- Sesja omówienia z waszym zespołem
- Poza zakresem: Same prace modernizacyjne, migracja danych, uzupełnianie testów, wygaszanie systemu legacy.
- 3Krok 3 · Projekt albo stała współpraca
Pełny zakres, wycena po rozmowie wstępnej
Zakres ustalony po rozmowie · praca w etapach · osobna wycena każdego etapu
od 120 000 PLN netto, wycena po rozmowie wstępnejPorozmawiajcie o projekciePokaż szczegóły
- Sprinty modernizacyjne w fazach
- Komponenty działające na produkcji obok systemu legacy
- Budżet i zakres potwierdzane przed każdą fazą
Problemy, które rozwiązuje ta usługa.
- System legacy nie ma testów; każda zmiana to ryzyko dla produkcji
- Dokumentacji nie ma albo jest nieaktualna, a wiedza o systemie siedzi w głowach jednej lub dwóch osób
- Pełne przepisanie jest za drogie, a każdy kwartał ze starym systemem kosztuje coraz więcej
Pokaż pozostałe problemy (1)
- Trudno zatrudniać, bo nowi inżynierowie nie chcą utrzymywać starej technologii
- CTO, których plan produktowy blokuje system, którego zespół boi się dotknąć
- Szefowie inżynierii, którzy porównują koszt modernizacji z kosztem nowego systemu i z kosztem zostawienia wszystkiego po staremu
- Firmy, w których nikt z obecnego zespołu nie chce ani nie umie utrzymywać kodu pierwszego produktu
- Spółki po przejęciu, które muszą połączyć własny system z wyraźnie starszym systemem przejętej firmy
Co może pójść nie tak i co z tym robimy.
1. Wygenerowane testy zamrażają błędyCo zostaje u was: lista zachowań potwierdzonych jako zamierzone i zachowań zgłoszonych jako defekty oraz zestaw testów z tym podziałem
Co się dziejeAsystent w kilka minut pisze testy dla kodu, który nigdy ich nie miał. Testy utrwalają obecne zachowanie, razem z defektami, które siedzą w nim od lat. Refaktoryzacja przechodzi na zielono, a defekt jest teraz chroniony testem i ma o jedną warstwę więcej do usunięcia.
Co z tym robimyTesty charakteryzujące oznaczamy jako takie. Przed refaktoryzacją przechodzimy utrwalone zachowania z ludźmi, którzy utrzymują system: zamierzone czy przypadkowe. Niezamierzone zapisujemy osobno i uzgadniamy z wami, które poprawić, a które zostawić, bo ktoś już na nich polega. Zestaw testów dzielimy na część opisującą specyfikację i część opisującą tylko obecny stan.
2. Przekład zachowuje kształt starego koduCo zostaje u was: kontrakt interfejsu dla każdego wymienionego komponentu oraz pomiar sprzężeń i duplikacji przed i po
Co się dziejeAsystent przenoszący kod z callbacków na async albo z PHP na TypeScript tłumaczy idiom za idiomem. Nowy komponent ma nowy język i stare sprzężenia, więc modernizacja kończy się tym samym monolitem w innej składni. Zmiana języka sama z siebie nie zdejmuje ani jednej zależności.
Co z tym robimyZanim cokolwiek przeniesiemy, definiujemy docelowy interfejs komponentu i dostosowujemy kod do niego, zamiast przenosić linia po linii. Sprzężenia i duplikację mierzymy przed każdą fazą i po niej. Różnicę pokazujemy, zanim komponent zostanie uznany za zmodernizowany.
3. Warstwa przekierowań staje się nowym legacyCo zostaje u was: zapis przełączenia dla każdego komponentu z udziałem ruchu i datą usunięcia starej ścieżki
Co się dziejeWarstwa, która kieruje ruch do starej albo nowej ścieżki, jest wygodna, więc zostaje. Komponenty są wymieniane, ale stara ścieżka nigdy nie jest wygaszana, bo wygaszenie nie ma właściciela ani daty. Bez terminu wyłączenia starych ścieżek w warstwie rośnie liczba wyjątków i coraz trudniej ustalić, który kod obsługuje ruch.
Co z tym robimyWygaszenie jest osobną fazą z właścicielem i datą dla każdego komponentu. Śledzimy udział ruchu na starej i nowej ścieżce. Komponent liczy się jako skończony dopiero wtedy, gdy dane i zależności są przeniesione, a stara ścieżka jest usunięta z repozytorium, a nie tylko wyłączona.
Rezultaty, które zostają u was.
- Po ocenie: raport o systemie (architektura, zależności, punkty ryzyka, warianty modernizacji) i mapa drogowa z fazami ułożonymi według ryzyka i budżetem na każdą
- Po pracach modernizacyjnych: zmodernizowane komponenty działające na produkcji obok systemu legacy, z zapisem przełączenia każdego z nich
- Testy i dokumentacja granicy między nowym a starym kodem
- Przekazanie wiedzy waszemu zespołowi: sesje w parach, spisana architektura
Pytania przed rozpoczęciem współpracy.
Porozmawiajmy o AI w waszej firmie.
Napiszcie, na jakim etapie jesteście. Temat: Modernizacja systemów legacy. Odpowiedź w ciągu jednego dnia roboczego.