Hogyan kezdünk neki dokumentáció nélkül?
Nem a teljes kód elolvasásával — az egy nagyobb rendszernél nem is lenne gazdaságos. A hibás folyamattól indulunk visszafelé: megnézzük, mit hív meg a felület, az mit ér el a szerveren, és az hova ír vagy honnan olvas.
Ez a szűk metszet jellemzően a kód néhány százalékát érinti, viszont pontosan azt, ami a hibáért felel. A feltérképezés eredményét írásban is átadjuk, így a következő javításnál már nem nulláról indul senki.
Ha van verziótörténet, az külön segít: megmutatja, mikor és milyen változtatás után jelent meg a hiba.
Függőségfrissítés: mikor kockázat és mikor kötelező?
Az elavult csomagok két irányból jelentenek problémát: biztonsági résekkel, és azzal, hogy a hozzájuk kapcsolódó ökoszisztéma tovább lép, így egyre nehezebb bármit hozzáépíteni.
A frissítés viszont nem kockázatmentes, főleg tesztek nélkül. Ezért lépésenként haladunk: először a biztonsági szempontból kritikus csomagokat, egyesével, ellenőrzéssel. A nagy verzióugrásokat külön kezeljük, mert azok jellemzően kódmódosítást is igényelnek.
Ha egy frissítés kockázata meghaladja a hasznát, azt megmondjuk — a mindent frissítsünk fel nem mindig jó tanács.
Mikor javítás, és mikor átvétel a helyes szolgáltatás?
Ha körülhatárolható hibáid vannak, amelyeket ki szeretnél javíttatni, a javítás a megfelelő út: egy vagy néhány konkrét probléma, fix áron.
Ha viszont az a helyzet, hogy senki nem gondozza a rendszert, és folyamatos fejlesztésre, üzemeltetésre és felelősre van szükség, akkor az egyedi fejlesztés átvétele a megfelelő szolgáltatás. Az kockázati felméréssel és tudásátadással indul, nem egyetlen hiba javításával.