Modernizacja starego oprogramowania firmowego: poprawić czy przepisać
Stary program działa, więc nikt go nie rusza. Aż do dnia, gdy odszedł jego autor, zmienił się system operacyjny albo trzeba coś dopisać, a nikt nie wie jak.
Autor: Szymon Łakomy. Aktualizacja:
Najpierw audyt, potem decyzja
- Spisuję, co program robi naprawdę, także rzeczy, o których nikt nie pamięta, jak comiesięczny eksport do księgowości.
- Sprawdzam, na czym działa: system operacyjny, baza, biblioteki i czy w ogóle jest kod źródłowy.
- Ustalam, kto go zna i co się dzieje, gdy tej osoby zabraknie.
- Oceniam ryzyka: bezpieczeństwo, kopie danych, zależność od jednego komputera.
- Przedstawiam warianty z kosztem i konsekwencjami każdego z nich.
Poprawić czy przepisać
| Sytuacja | Zwykle lepsza modernizacja | Zwykle lepsze przepisanie |
|---|---|---|
| Kod źródłowy | jest i da się go uruchomić oraz zbudować | brak albo niekompletny |
| Logika biznesowa | poprawna, brakuje tylko nowych funkcji | zagmatwana, każda zmiana psuje coś innego |
| Technologia | ma jeszcze wsparcie i ludzi do pracy | porzucona, brak bibliotek i dokumentacji |
| Bezpieczeństwo | da się załatać punktowo | wymaga zmiany architektury |
| Interfejs | zespół jest do niego przyzwyczajony | blokuje pracę zdalną i z telefonu |
To uogólnienie. Każdy przypadek oceniam po przejrzeniu kodu i danych.
Typowe przypadki
Baza w Accessie
Formularze i raporty w jednym pliku, który kilka osób otwiera przez sieć. Dane przenoszę do bazy serwerowej, a interfejs odtwarzam w przeglądarce.
Program w Delphi
Często stabilny, ale trudny do rozwoju. Zwykle udostępniam jego dane przez API i buduję nowe moduły obok, a stary interfejs wygaszam stopniowo.
Makra VBA w Excelu
Narzędzie, które urosło ponad arkusz. Spisuję jego reguły i przenoszę je do aplikacji, o czym więcej jest na stronie z Excela do aplikacji webowej.
Stare PHP
Bywa działające, ale bez aktualizacji i testów. Przeglądam bezpieczeństwo, a potem decyduję, czy opłaca się łatać, czy przenosić.
Etapy i przenoszenie danych
Wymiana całego systemu naraz to największe ryzyko, więc dzielę ją na etapy, w których stary i nowy program działają równolegle.
- najpierw dane: kopia bezpieczeństwa, porządkowanie i próbny import,
- potem moduł o najmniejszej liczbie powiązań, żeby sprawdzić proces,
- stary program zostaje do odczytu, dopóki ostatnia funkcja nie zostanie przeniesiona,
- dla każdego etapu jest plan powrotu, gdy coś pójdzie nie tak.
Dokumentacja i prawa do kodu
Po modernizacji powinieneś mieć opis działania, schemat bazy i instrukcję uruchomienia, bez których system znów stanie się czarną skrzynką. Jeśli starego programu nie napisała Twoja firma, ustal, kto ma prawa do kodu i czy wolno go zmieniać. To nie jest porada prawna, tylko pytanie do prawnika, a zasady umów opisuję na stronie umowa na wykonanie oprogramowania. Ogólne podejście do systemów na miarę znajdziesz na stronie dedykowane oprogramowanie.
Najczęstsze pytania
Czy da się zmodernizować program, którego kodu nie mam?
Bywa to bardzo trudne. Bez kodu zwykle odtwarza się działanie programu z danych i interfejsu, a potem buduje nową aplikację. Dlatego już przy audycie sprawdzam, co jest faktycznie dostępne.
Czy firma musi przerwać pracę na czas wymiany?
Nie powinna. Zmiany wprowadzam etapami, a stary program działa równolegle, aż nowy przejmie dany proces. Przełączenie planuję na moment, w którym przerwa jest najmniej uciążliwa.
Co z danymi historycznymi?
Przenoszę to, co jest potrzebne na bieżąco, a resztę zostawiam w archiwum do odczytu. Dzięki temu nowy system jest szybki, a stare dane nie przepadają.
Czy po modernizacji mogę rozwijać system z innym wykonawcą?
Tak, dlatego tak ważna jest dokumentacja. Kod, instrukcje i dostępy przekazuję tak, żeby inny programista mógł pracować dalej bez zgadywania.
Powiązane strony
Masz program, którego nikt nie chce ruszać?
Napisz, w czym jest napisany i co robi. Zaproponuję audyt i warianty dalszych kroków.