Jak převzít zděděný kód po jiném dodavateli

Tohle řeším poměrně často. Firma má rozdělanou nebo běžící aplikaci, dodavatel skončil a nikdo přesně neví, jak to uvnitř funguje. Panika vede k jednomu ze dvou extrémů: buď se toho nikdo nechce dotknout, nebo padne rozhodnutí přepsat všechno od nuly. Oba jsou většinou špatně. V tomhle článku projdu celý postup, jak zděděnou aplikaci převzít: od prvního auditu přístupů přes orientaci v cizím kódu a uzavření bezpečnostních děr až po rozhodnutí, jestli refaktorovat, nebo výjimečně přepsat.

Proč nepřepisovat od nuly

Přepis zní lákavě, protože nový kód je „čistý". Jenže ten starý, jakkoliv ošklivý, nese roky znalostí: výjimky, okrajové případy, věci, na které někdo přišel až v provozu. Když přepíšete od nuly, zahodíte to všechno a budete na stejné chyby narážet znovu. Přepis navíc trvá měsíce, během kterých firma stojí na starém systému, který se mezitím neopravuje.

Přepis dává smysl jen výjimečně: když je technologie opravdu mrtvá (například jazyk nebo framework, který už nikdo neudržuje), nebo když je kódu málo a je beznadějný. Ve většině případů se vyplatí navázat. K rozhodnutí refaktor versus přepis se ještě vrátím níž, ale platí jednoduché pravidlo: dokud aplikaci pořádně neznám, na přepis nesahám.

První audit: co vlastně máte

Než se začnu dívat do kódu, musím vědět, z čeho se celý projekt skládá. U zděděné aplikace bývá první problém ten, že nikdo nemá kompletní obrázek o tom, kde co běží a kdo k čemu má přístup. Proto si na začátku projdu inventuru. Tady je checklist, který procházím u každého převzatého projektu:

Repozitář a zdrojový kód. Existuje Git? Kde je hostovaný a kdo do něj má přístup? Pokud Git neexistuje, kde je poslední aktuální verze kódu (často přímo na serveru)?
Hosting a server. U koho běží web nebo aplikace, jaký je to typ hostingu (sdílený, VPS, cloud) a jaké jsou přihlašovací údaje do administrace.
Databáze. Kde leží, jaký je to systém a verze, kdo má přístup a kde jsou přihlašovací údaje, které aplikace používá.
Domény a DNS. Kdo je vlastník domény, u koho je registrovaná a kde se spravují DNS záznamy. Tohle se podceňuje a přitom ztráta kontroly nad doménou umí položit celou firmu.
Zálohy. Existují vůbec? Jak často se dělají, kde se ukládají a hlavně: vyzkoušel je někdy někdo obnovit? Záloha, kterou nikdo netestoval, není záloha.
Napojené služby. Platební brány, e-maily, SMS, fakturační nebo skladové systémy, API třetích stran. U každého potřebuju vědět, kde jsou klíče a na koho je účet vedený.

Výstupem prvního auditu je jednoduchý seznam: co máme, kdo k čemu má přístup a kde jsou bílá místa. Bílá místa jsou ta nejdůležitější část, protože přesně tam vzniká riziko, že vás něco zaskočí.

Získání všech přístupů a práv

Tohle je často nepříjemnější část, protože se musí komunikovat s odcházejícím dodavatelem nebo dohledávat staré účty. Vyplatí se to udělat hned a důsledně, dokud je původní dodavatel ještě zastižitelný. Co si vyžádat:

Přístup do repozitáře nebo kompletní zdrojový kód v aktuální verzi.
Administrátorské přístupy k hostingu a serveru (FTP, SSH, panel hostingu).
Přístup k databázi a možnost stáhnout si její zálohu.
Správu domény a DNS, ideálně převedenou na účet firmy, ne dodavatele.
Účty k napojeným službám a API klíče, převedené nebo přegenerované na firmu.
Přístupy k e-mailům a notifikacím, které aplikace odesílá.

Důležité je, aby klíčové účty (doména, hosting, platební brána) byly vedené na firmu, ne na osobní účet bývalého dodavatele. Pokud to tak není, je převedení vlastnictví první věc, kterou řeším. Po převzetí navíc projdu hesla a klíče a ty citlivé přegeneruju, protože nikdy nevím, kdo všechno je za roky viděl.

Jak se zorientovat v cizím kódu

Když mám přístupy, jdu do kódu. Cizí projekt se nedá číst odshora dolů jako kniha. Postupuju cíleně a hledám orientační body:

Začnu od vstupních bodů. Kde aplikace přijímá požadavky: routy, kontrolery, hlavní soubor, který se spustí jako první. Odtud se dá sledovat, kudy data tečou dál.
Zmapuju datový model. Databázové tabulky a vazby mezi nimi řeknou o aplikaci nejvíc. Struktura dat obvykle prozradí, co aplikace ve skutečnosti dělá, líp než samotný kód.
Najdu konfiguraci a závislosti. Kde jsou uložené přístupové údaje, nastavení prostředí a seznam knihoven, na kterých projekt stojí. To ukáže, jak je projekt napojený na okolí a jak je starý.
Projdu reálnou cestu uživatele. Vezmu jednu typickou akci (třeba vytvoření objednávky) a projdu ji kódem od kliknutí až po zápis do databáze. Tím pochopím jeden celý tok a zbytek pak jde rychleji.

Cílem téhle fáze není pochopit každý řádek. Cílem je vědět dost na to, abych mohl bezpečně sahat do kódu, aniž bych něco nečekaně rozbil. Tohle je každodenní práce při údržbě a rozvoji webových aplikací na míru a po pár projektech získáte cit pro to, kde v cizím kódu hledat.

Bezpečnostní rizika u zděděných projektů

Starší aplikace, kterou roky nikdo neaktualizoval, je z bezpečnostního hlediska skoro vždy problém. Co kontroluju jako první:

Zastaralé knihovny a frameworky. Staré verze mívají známé a veřejně popsané zranitelnosti. Projdu seznam závislostí a zjistím, co je po datu spotřeby.
Nezáplatovaný systém na serveru. Operační systém, PHP nebo databáze v dávno nepodporované verzi je otevřená brána.
Hardcoded hesla a klíče. Přístupové údaje napsané přímo v kódu, často ještě uložené v repozitáři. Tohle přesouvám do konfigurace mimo verzování a citlivé údaje přegeneruju.
Neošetřené vstupy. U starších PHP aplikací bývá klasika SQL dotaz skládaný přímo ze vstupu formuláře. Tohle přepíšu na prepared statements a vstupy ošetřím. Stejně tak hlídám výpisy uživatelského obsahu kvůli XSS.
Chybějící HTTPS nebo špatně nastavené certifikáty. Dnes základ, u starších webů ale zdaleka ne samozřejmost.

Bezpečnost není volitelná a neřeší se „někdy potom". Otevřená díra je riziko každý den, co aplikace běží.

Stabilizace před rozvojem

Než cokoliv vylepšuju nebo dopisuju, dostanu aplikaci do stabilního a kontrolovaného stavu. Pořadí kroků:

Zprovozním projekt lokálně a založím Git. Hodně zděděných projektů jede stylem „zdroják přes FTP" a záloha je ZIP na ploše. Verzování je základ, abych mohl bezpečně zkoušet a vracet změny.
Oddělím staging od produkce. Potřebuju místo, kde můžu zkoušet bez rizika, že shodím ostrý provoz. Bez tohohle se nedá bezpečně dělat nic.
Zastavím krvácení. Izoluju příčiny pádů a opravím je. Stabilní základ je podmínka pro všechno další.
Zavřu bezpečnostní díry. To nejakutnější z předchozí kapitoly vyřeším ještě před tím, než přidám cokoliv nového.
Nastavím nasazení a zálohy. Aby každá změna šla do produkce předvídatelně a dala se vrátit, a aby existovaly zálohy, které jsou otestované a opravdu se z nich dá obnovit.

Pořadí je důležité: nejdřív stabilita, pak bezpečnost, až potom nové funkce. Kdo začne novými funkcemi na nestabilním základu, staví na písku.

Refaktor, nebo přepis?

Tohle rozhodnutí dělám až ve chvíli, kdy aplikaci znám a běží stabilně, ne dřív. Refaktor (postupné vylepšování stávajícího kódu) se vyplatí ve většině případů: aplikace dál funguje, riziko je rozložené do malých kroků a roky znalostí v kódu zůstávají zachované. Nejproblematičtější části přepisuju po jedné, ne všechno najednou.

Kompletní přepis zvažuju jen tehdy, když je technologie opravdu mrtvá a neudržovatelná, když je bezpečnostních a strukturálních problémů tolik, že oprava trvá déle než nová verze, nebo když je kódu málo a stejně se musí celý předělat. I tak se snažím přepisovat po částech a starou verzi nechat běžet, dokud nová není ověřená. Když mám projít cizí projekt a říct na rovinu, co dává smysl, je to součást toho, jak přistupuju k softwaru na míru: technologii volím podle toho, co problém reálně potřebuje.

Nasazení a zálohy na závěr

Když aplikace stojí na nohou, doladím provozní základy, aby se s ní dalo dlouhodobě pracovat:

Předvídatelné nasazení. Změna jde nejdřív do stagingu, otestuje se a pak teprve do produkce, ideálně tak, aby se dala v případě problému rychle vrátit.
Automatické a testované zálohy. Kódu i databáze, na místě odděleném od produkčního serveru. A pravidelně ověřené, že se z nich dá skutečně obnovit.
Základní monitoring. Abych se o pádu nebo chybě dozvěděl dřív než zákazník, ne až když si přestane fungovat objednávkový formulář.

Teprve na tomhle základu má smysl dopisovat, co chybělo, a aplikaci postupně rozvíjet. Stejný přístup používám i u webů a e-shopů, které přebírám po jiném dodavateli.

Jak dlouho to trvá

Záleží na stavu, ale není to nikdy „roky". Nedávno jsem takhle převzal opuštěnou objednávkovou a fakturační aplikaci, která padala několikrát týdně. Za zhruba šest týdnů byla stabilní, bez otevřených bezpečnostních děr, pod Gitem a s dopsanými funkcemi, které chyběly. Firma ji mohla nasadit do ostrého provozu místo toho, aby projekt zahodila. Příklady dalších převzatých a dokončených projektů najdete v referencích.

Co potřebuju od vás

Ideálně přístupy (kód, hosting, databáze) a kontakt na někoho, kdo aplikaci používá a řekne mi, co má dělat. Dokumentaci nečekám, tu skoro nikdo nemá. Zorientuju se i bez ní.

Časté otázky

Co když k aplikaci nemám zdrojový kód?

Bez zdrojového kódu se navázat nedá, ale skoro vždy se dá získat. Bývá na hostingu nebo serveru, kde aplikace běží, a často ho lze stáhnout přes FTP, SSH nebo z administrace hostingu. Pokud kód není nikde k dispozici, vyžádejte si ho od původního dodavatele písemně, většinou na něj máte nárok podle smlouvy. Když ani to nepomůže, dá se z běžící aplikace alespoň zachránit databáze a obsah a postavit nad nimi novou verzi.

Jde převzít web nebo aplikaci bez původního dodavatele?

Ano. Dokumentaci skoro nikdo nemá a počítám s tím, že nebude. Pokud mám přístup ke kódu, hostingu a databázi a kontakt na někoho, kdo aplikaci používá a řekne mi, co má dělat, dokážu se v ní zorientovat i bez původního vývojáře. Většina projektů, které přebírám, je přesně v tomhle stavu.

Jak dlouho trvá zorientovat se v cizím kódu?

Základní orientaci, tedy co aplikace dělá, kde běží a kde leží největší rizika, zvládnu obvykle během prvních dnů práce. Hlubší pochopení přichází postupně, jak procházím vstupní body, datový model a konfiguraci. Není to ale otázka měsíců. Cílem prvního auditu není pochopit každý řádek, ale vědět dost na to, abych mohl bezpečně začít stabilizovat.

Je lepší zděděnou aplikaci opravit, nebo přepsat?

Ve většině případů opravit a navázat. Starý kód, jakkoliv ošklivý, nese roky znalostí o okrajových případech, na které se přišlo až v provozu. Přepis dává smysl jen výjimečně: když je technologie opravdu mrtvá, nebo když je kódu málo a je beznadějný. Přepis navíc trvá měsíce, během kterých firma stojí na starém systému, který se mezitím neopravuje.

Co když je zděděný kód ve špatném stavu?

Špatný stav kódu sám o sobě není důvod ho zahodit. Nejdřív aplikaci stabilizuji, dostanu pod verzování, oddělím staging od produkce a zavřu bezpečnostní díry. Teprve na stabilním základu má smysl postupně refaktorovat nejproblematičtější části. Když projdu kód, řeknu na rovinu, jestli se vyplatí navázat, nebo je výjimečně lepší postavit znovu.

Pokud řešíte zděděný projekt a nevíte, jestli má cenu pokračovat, napište mi. Projdu kód, udělám první audit a řeknu vám na rovinu, v jakém je stavu a jestli se vyplatí navázat, nebo ne. Víc o tom, jak přebírám a rozvíjím webové aplikace na míru, najdete na samostatné stránce.