Utvecklaren försvann – vad händer med systemet nu?

En dag slutar utvecklaren svara på mejl. Eller så meddelar byrån att den lägger ner. Eller så går den enda person som förstod systemet i pension eller byter jobb. Applikationen fungerar än så länge – fakturor skickas, beställningar kommer in – men ingen vet längre hur den fungerar på insidan eller vad som händer när något går sönder.

Det är vanligare än man tror, och oftast är det ingen katastrof. Det blir en när fel beslut fattas under de första veckorna. Nedan är den ordning jag själv rekommenderar.

Steg ett: säkra åtkomsten

Den största risken är inte att koden är dålig. Den största risken är att du inte har kontroll över den. Innan du gör något annat, gör en lista och kontrollera att du har detta i dina händer:

• Kodförrådet (GitHub, GitLab, Bitbucket eller liknande) – vems konto ligger det på, och har du ägar- eller administratörsrättigheter?
• Servern eller webbhotellet – vems namn står på avtalet, vem betalar fakturorna, har du SSH- eller kontrollpanelsåtkomst?
• Domänen – vem är registrerad som innehavare och när löper den ut? En utgången domän är det snabbaste sättet att få en tjänst att sluta fungera.
• Databasen – var finns den, och har du användarnamn och lösenord?
• Externa tjänster – e-postutskick, betallösning, molnlagring, API-nycklar. Många av dem är registrerade på utvecklarens privata e-postadress.

Om du fortfarande når utvecklaren, be att få all åtkomst överlämnad nu, inte "när det finns tid". Om du inte gör det, börja med det som står i ditt företags namn – domänregistrarer och webbhotell återställer i regel åtkomsten till ägaren när ägandet kan styrkas.

Steg två: ta en säkerhetskopia innan du rör något

När du har åtkomst, ta en fullständig säkerhetskopia: kod, databas, uppladdade filer och serverkonfiguration. Inte för att något är trasigt just nu, utan för att någon under de kommande veckorna kommer att börja arbeta i systemet – och då måste man veta hur det såg ut innan.

Kontrollera också om automatiska säkerhetskopior görs över huvud taget, och vart de går. Ofta visar det sig att de hamnade på utvecklarens egen dator eller tyst slutade fungera för några månader sedan.

Steg tre: bygg inte nytt i panik

Den första reaktionen är ofta: "Vi skriver om alltihop från början, då har vi åtminstone kontroll." Det är nästan alltid fel första drag.

Ett fungerande system innehåller affärsregler, undantag och rättelser som samlats under flera år och som ingen specifikation beskriver. En omskrivning innebär att allt detta måste upptäckas på nytt – oftast först när något redan har gått fel. Samtidigt måste det gamla systemet fortsätta gå utan att någon tar hand om det.

En klokare ordning är en annan: gör först det befintliga systemet stabilt och begripligt, och bestäm sedan om det är värt att vidareutveckla eller byta ut del för del.

Hur jag tar över en okänd kodbas

Jag har arbetat med webbprojekt sedan 2014 och återställt mer än tio år gamla applikationer i både offentlig och privat sektor, där de ursprungliga utvecklarna sedan länge var borta. Arbetet följer alltid samma ordning.

1. Granskning. Jag går igenom vad systemet består av: språk och ramverk, deras versioner, databas, serverkonfiguration och externa beroenden. Jag tar reda på vad som är föråldrat, vad som är en säkerhetsrisk och vad som fungerar bra.

2. Dokumentation. Jag skriver ner hur systemet är uppbyggt, hur det startas och var allt finns. Dokumentet stannar hos dig – nästa gång behöver ingen börja från noll.

3. Igång i en separat miljö. Innan jag ändrar något får jag systemet att köra i en separat miljö som inte rör riktiga användare. Bara så kan ändringar provas säkert.

4. Små, säkra rättelser först. De första ändringarna är medvetet små: säkerhetsuppdateringar, de mest akuta felen, ordning på säkerhetskopieringen. Varje ändring går att spåra och kan rullas tillbaka.

5. Först därefter de större stegen. När systemet är stabilt och förstått kan vi prata om att flytta komponenter till nya versioner och lägga till ny funktionalitet. I tidigare projekt är det just den ordningen som gjort att affärsfunktionaliteten kunnat bevaras helt och ny funktionalitet byggas ovanpå.

Om applikationen körs på en Linux-server kan jag också ta över serverdriften – serverns konfiguration är ofta lika odokumenterad som koden. Om själva servern behöver bytas finns ett separat inlägg om servermigrering utan driftstopp.

Varningssignaler: när det inte kan vänta

Ibland går det inte att vänta. Låt någon titta på systemet snabbt om:

• serverns operativsystem eller ramverket saknar support och inte längre får säkerhetsuppdateringar;
• domänen eller certifikatet löper ut inom de närmaste veckorna;
• det saknas säkerhetskopior, eller en återställning har aldrig testats;
• systemet har börjat gå långsamt eller stannar ibland "av sig självt";
• ingen vet var källkoden finns – det finns bara versionen som körs på servern.

Det sista är svårare, men även därifrån finns en väg framåt. Om riskerna med föråldrade komponenter i stort skriver jag i inlägget riskerna med ett ouppdaterat WordPress – principen gäller alla plattformar.

Så undviker du samma läge nästa gång

När systemet är under kontroll igen lönar det sig att ordna tre saker: all åtkomst står i företagets namn, inte en persons; koden ligger i ett förråd som minst två personer har åtkomst till; och det finns ett kort dokument om hur systemet startas och återställs. Det kostar lite, och nästa byte av utvecklare blir ingen kris.

Skriv till mig

Om din utvecklare är borta och systemet fortfarande fungerar men ingen vågar röra det, beskriv din situation med ett par meningar här – jag svarar inom en arbetsdag och säger ärligt om och hur jag kan hjälpa till. Ett sekretessavtal är vardag för mig, så du kan visa kod och data utan oro. Om du hellre vill prata finns andra sätt att nå mig på kontaktsidan.

Kan du ta över systemet om källkoden saknas?

Ofta ja, men det beror på tekniken. Vissa applikationer (till exempel PHP-baserade) körs på servern som källkod, så koden finns i praktiken. Kompilerade applikationer kräver mer arbete. Det kontrollerar jag under granskningen.

Måste jag genast bestämma om systemet ska skrivas om?

Nej. Först måste systemet bli stabilt och begripligt. Valet mellan vidareutveckling och ersättning blir mycket enklare när man vet vad som finns inuti.