Idegen kódbázis átvétele — mit nézz meg először?
Nem a kódot. Az örökölt rendszernél a legnagyobb kockázat nem az, hogy rosszul van megírva, hanem hogy nem tudod visszacsinálni, amit elrontasz benne.
Egy átvételnél az ember első ösztöne az, hogy megnézi a kódot. Ez érthető, és rossz sorrend. A kód minősége szakmai kellemetlenség; a hiányzó mentés viszont üzleti kockázat, méghozzá azonnal a tiéd, amint hozzányúltál.
- 01 1 · visszaállítható-e
- 02 2 · minden hozzáférés megvan-e
- 03 3 · mi fut, és milyen verzión
- 04 4 · van-e egyedi kód, és ki érti
5 · és csak ezután: milyen a kód
Egy — visszaállítható-e
Az első kérdés nem az, hogy van-e mentés, hanem hogy lehet-e belőle helyreállítani. A kettő nem ugyanaz: a tárhelyek nagy részén fut valamilyen automatikus mentés, amit soha senki nem próbált ki.
Amíg erre nincs válasz, minden módosítás visszafordíthatatlan. Ezért az első lépés mindig ugyanaz: saját mentés, saját helyre, fájl és adatbázis külön — és lehetőleg egy másolat, amin ki is lehet próbálni, hogy működik-e.
Kettő — megvan-e minden hozzáférés
Nem az adminfelület a lényeg, hanem a teljes lista: tárhely, adatbázis, domain kezelőfelület, a levelezés beállításai, és a fizetős bővítmények licencei.
A licenc a leggyakoribb rejtett hiányzó. Egy bővítmény működik anélkül, hogy bárki észrevenné a hiányát — egészen addig, amíg jön egy biztonsági frissítés, amit érvényes licenc nélkül nem lehet letölteni. Ilyenkor derül ki, hogy a kulcs az előző fejlesztő fiókjához tartozott.
Ez ugyanaz a lista, amit megbízói oldalról érdemes végigmenni; arról az írás szól, hogy kihez van kötve a weboldalad. Átvevőként annyi a különbség, hogy itt nekem kell hiányt jelentenem, mielőtt elvállalom.
Három — mi fut, és milyen verzión
A kiszolgálón futó programnyelv verziója, a rendszer verziója, a bővítmények verziója, és ami a legfontosabb: mennyire vannak lemaradva.
A lemaradás mértéke határozza meg a munka kockázatát. Egy-két kihagyott verzió rutinfeladat. Sok kihagyott verzió viszont már nem frissítés, hanem migráció, mert közben a bővítmények egymással is összeakadhatnak.
Amit ilyenkor nem szabad: frissíteni az átvétel első napján. Ha ekkor tör el valami, azt az új üzemeltetőre írják, akkor is, ha a hiba két éve érett. Előbb mentés és másolat, aztán frissítés a másolaton, és csak utána élesben.
Négy — van-e egyedi kód, és érti-e valaki
A legtöbb örökölt oldalon van néhány egyedi részlet: egy űrlap-kiegészítés, egy árszámító, egy összekötés valamilyen külső rendszerrel. Ezek nem eleve rosszak — a kérdés az, hogy érthetők-e.
Három dolgot nézek: hol van (a témában vagy külön kiegészítésben), mi hívja meg, és mi történik, ha nem fut le. Ha ezekre a helyszínen nem derül fény, akkor nem kód van előttem, hanem fekete doboz — és a fekete dobozt nem lehet karbantartani, csak reménykedni benne.
Öt — és csak most: a kód minősége
Ez az, amivel a legtöbben kezdenék, és ami a legkevésbé fontos. A csúnya kód dolgozható, ha érthető és visszaállítható. A szép kód sem ér semmit, ha nincs mentés és hiányzik a fele hozzáférés.
Egyetlen dolgot érdemes itt komolyan venni: van-e nyoma annak, hogy valaki már belenyúlt a rendszer magjába — a keretrendszer saját fájljaiba. Ha igen, akkor a következő frissítés felülírja, és a hiba a frissítés után jelentkezik, látszólag ok nélkül.
Mikor kell nemet mondani
Három eset van, amikor nem vállalom. Ha nem szerezhető meg a teljes hozzáférés — ilyenkor a felelősség az enyém lenne, az eszközök nem. Ha nincs és nem is készíthető mentés. És ha a rendszer olyan egyedi kódra épül, amit senki nem tud elmagyarázni, a szerzője pedig elérhetetlen.
Ez nem finnyásság. Aki ezek nélkül vállal el egy oldalt, az nem karbantartást ad el, hanem felelősséget valamiért, amit nem lát — és az első komoly hibánál mindkét fél rosszul jár.
Az első hét: dokumentálni, nem javítani
Ha a felmérés rendben van, a következő csábítás a rendrakás. Ezt érdemes elhalasztani. Az átvétel első hetében a javítási kedv a legnagyobb, és a tudás a legkevesebb — ez a kettő együtt okozza a legtöbb kárt.
Helyette: leírni, mi hol van, mi mit csinál, és mi az, ami gyanús. Ez a jegyzet lesz az, amiből három hónap múlva öt perc alatt megvan a válasz arra, ami egyébként fél nap nyomozás lenne.
Kérdések a témáról
Mi az első dolog, amit meg kell nézni egy átvett oldalon?
Nem a kód, hanem a visszaállíthatóság. Van-e mentés, és lehet-e belőle helyreállítani. Amíg erre nincs válasz, minden módosítás visszafordíthatatlan — és egy idegen rendszerben az első módosítás mindig hoz meglepetést.
Érdemes-e azonnal frissíteni egy elhanyagolt oldalt?
Nem, először fel kell mérni. Egy sok kihagyott verzión átugró frissítés gyakran tör, és ha ez az átvétel első napján történik, a hibát az új üzemeltetőre írják. Előbb mentés és másolat, aztán frissítés a másolaton.
Mikor kell nemet mondani egy átvételre?
Ha nem szerezhető meg a teljes hozzáférés, ha nincs és nem is készíthető mentés, vagy ha a rendszer olyan egyedi kódra épül, amit senki nem tud elmagyarázni és a szerzője elérhetetlen. Ezekben az esetekben nem karbantartást vállalna az ember, hanem felelősséget valamiért, amit nem lát.
Mit érdemes csinálni az átvétel első hetében?
Dokumentálni, nem javítani. Leírni, mi hol van, mi mit csinál, és mi az, ami gyanús. A javítási kedv az első héten a legnagyobb, és a tudás akkor a legkevesebb — ez a kettő együtt okozza a legtöbb kárt.