Poprzednia firma kończy współpracę, freelancer znika albo po prostu zmieniasz wykonawcę. Aplikacja działa, klienci z niej korzystają, a Ty masz w ręku coś, czego nie zbudowałeś i czego do końca nie znasz. Pierwszy tydzień po takim przejęciu decyduje o tym, czy za pół roku będziesz spokojnie rozwijać produkt, czy gasić pożary.
Przez ponad 5 lat pracowałem na jednej dużej platformie, którą rozwijało wiele osób naraz. Wiem, jak wygląda kod, który rośnie latami, i co trzeba ustalić, zanim zacznie się go zmieniać.
1. Dostępy i własność: wszystko na Ciebie
To najważniejszy punkt i trzeba go załatwić, póki poprzedni wykonawca jeszcze odbiera telefon. Sprawdź, czy na Ciebie albo na Twoją firmę są zapisane:
- kod źródłowy, czyli repozytorium na Twoim koncie, a nie na prywatnym koncie programisty;
- domena, zarejestrowana na Twoją firmę, z dostępem do panelu rejestratora;
- konta w App Store i Google Play, jeśli masz aplikację mobilną, razem z kluczami, którymi podpisuje się kolejne wersje (bez nich aktualizacja w sklepie potrafi się zamienić w długą przeprawę z obsługą sklepu);
- serwery i usługi w chmurze, z rachunkami wystawianymi na Ciebie;
- usługi zewnętrzne: płatności, wysyłka e-maili, mapy, analityka;
- hasła, przekazane przez menedżer haseł, a nie w mailu, i zmienione po przekazaniu.
Jeśli cokolwiek z tej listy jest na nazwisku poprzedniego wykonawcy, przenieś to w pierwszej kolejności. Aplikacja, której domena albo konto w sklepie należy do kogoś innego, w praktyce nie jest Twoja.
2. Czy da się to zbudować i wdrożyć od zera
Zbudować aplikację to zamienić kod w działającą wersję, którą da się opublikować. Wdrożyć to wypuścić tę wersję na serwer albo do sklepu.
Najprostszy test: niech nowa osoba na czystym komputerze, korzystając tylko z instrukcji w repozytorium, uruchomi aplikację i wypuści wersję testową. Jeśli po drodze trzeba dzwonić do poprzednika albo zgadywać, brakuje czegoś, bez czego nie wypuścisz żadnej poprawki. Lepiej dowiedzieć się o tym w spokojny wtorek niż w dniu awarii.
3. Kopie zapasowe
Pytanie „czy są kopie zapasowe?” to za mało. Zapytaj, kiedy ktoś ostatnio odtworzył dane z kopii i czy to się udało. Dopóki nikt nie przywrócił z niej danych, nie wiesz, czy kopia w ogóle działa. Sprawdź też, gdzie leży: kopia na tym samym serwerze co aplikacja nie pomoże, gdy padnie właśnie ten serwer.
4. Dokumentacja
Rzadko jest kompletna i nie oczekuj, że będzie. Szukaj kilku rzeczy: jak uruchomić projekt, jak wygląda wdrożenie, jakie usługi zewnętrzne są podpięte i dlaczego podjęto nietypowe decyzje. Jeśli dokumentacji nie ma wcale, zapisuj wszystko, czego się dowiadujesz w pierwszym tygodniu. To najlepszy moment, bo wszystko jest dla Ciebie nowe.
5. Zależności i aktualizacje bezpieczeństwa
Każda aplikacja składa się w dużej części z gotowych klocków pisanych przez innych: bibliotek do logowania, płatności, obsługi formularzy. Te klocki się starzeją, a w starych wersjach wykrywa się luki bezpieczeństwa. Poproś o zestawienie, jak bardzo są nieaktualne i czy któreś mają znane luki. Kilka miesięcy opóźnienia to norma. Kilka lat oznacza, że aktualizacja będzie osobnym projektem.
6. Kto wie, jak to działa
Najcenniejsza dokumentacja często siedzi w głowie jednej osoby. Jeśli poprzedni wykonawca jest gotów na rozmowę przekazania, umów ją od razu, najlepiej z nagraniem. Przygotuj pytania: co się najczęściej psuje, czego lepiej nie ruszać i dlaczego, co planował poprawić, ale nie zdążył.
Czerwone flagi
Jeśli zobaczysz któreś z poniższych, zaplanuj czas na porządki, zanim zaczniesz dokładać funkcje:
- poprzedni wykonawca nie chce przekazać dostępów albo uzależnia to od dodatkowych opłat;
- kod istnieje tylko na serwerze albo na czyimś komputerze, bez historii zmian;
- nowe wersje wypuszcza się ręcznie, kopiując pliki na serwer;
- hasła do bazy danych i usług zapisane są wprost w kodzie;
- nie ma żadnych testów automatycznych, które sprawdzałyby, czy zmiana niczego nie zepsuła;
- nikt nie potrafi powiedzieć, kiedy ostatnio robiono kopię zapasową.
Żadna z tych rzeczy nie przekreśla aplikacji, ale każda pokazuje, gdzie jest ryzyko.
Łatać czy przepisać od zera
Po tygodniu z cudzym kodem pokusa jest duża: „lepiej napisać to od nowa”. Uczciwie: rzadko się to opłaca.
Przepisanie oznacza miesiące, w których płacisz za budowę czegoś, co już masz, i nie dostajesz nowych funkcji. Stara aplikacja zawiera też setki drobnych zachowań i poprawek, których nikt nigdy nie spisał, a które klienci uważają za oczywiste. Nowa wersja musi je wszystkie odtworzyć, zanim w ogóle dogoni starą.
Zwykle lepiej działa porządkowanie kawałek po kawałku: najpierw dostępy, wdrożenie i kopie zapasowe, potem najbardziej bolesne miejsca w kodzie, przy okazji normalnej pracy nad funkcjami. Tak latami porządkowałem od środka platformę Sinum, aż czas jej wczytywania skrócił się o 70%.
| Sytuacja | Łatać i porządkować | Rozważyć przepisanie |
|---|---|---|
| Aplikacja działa, klienci z niej korzystają | tak | nie |
| Kod jest chaotyczny, ale da się go zbudować i wdrożyć | tak | nie |
| Technologia nie ma już wsparcia ani aktualizacji bezpieczeństwa | częściowo | tak, etapami |
| Aplikacja jest mała, a zmienia się jej przeznaczenie | rzadko | tak |
Nawet gdy przepisanie ma sens, rzadko warto robić je naraz. Bezpieczniej wymieniać aplikację częściami, tak żeby przez cały czas działała.
Jak mogę pomóc
Przy takim przejęciu najbardziej przydaje się druga para oczu, która nie jest związana ani z poprzednim wykonawcą, ani z nowym. W ramach doradztwa technicznego robię przegląd przejętego kodu i dostępów: dostajesz listę ryzyk z priorytetami i plan, co naprawić najpierw. Jeśli potem potrzebujesz kogoś, kto aplikację przejmie i będzie rozwijać, zobacz, jak pracuję przy aplikacjach webowych.
Właśnie przejmujesz aplikację albo masz to przed sobą? Umów bezpłatną rozmowę. Przejdziemy razem przez tę listę na Twoim przypadku, a Ty wyjdziesz z wiedzą, od czego zacząć.