Ta över en kodbas från en tidigare utvecklare
Av CodexierPublicerad 4 min läsning
Förr eller senare byter de flesta mjukvaruprodukter händer: en frilansare går vidare, ett byråsamarbete tar slut eller en medgrundare lämnar. Koden är oftast den enkla delen. Skadan uppstår i allt runt omkring: domäner och molnkonton i någon annans namn, lösenord som ingen skrev ner, en driftsättning som bara en person förstod. Här får du ordningen att arbeta i, oavsett om du är ägaren som lämnar över eller utvecklaren som tar över.
Åtkomst du måste säkra först
| Konto | Varför det spelar roll | Kontrollera |
|---|---|---|
| Domänregistrar och DNS | Styr om produkten alls går att nå | Registrerad på företaget, giltigt kort för förnyelse |
| Kodförråd | Sanningen om koden | Ägs av företagets organisation, inte ett privat konto |
| Molndrift och databas | Systemet i drift och kunddata | Fakturering på företaget, ägarbehörighet för dig |
| App Store och Google Play | Möjligheten att publicera appuppdateringar | Utvecklarkonton i företagets namn |
| Betalleverantör, mejltjänst, statistik | Pengar, kundkommunikation, data | Adminbehörighet överförd, gamla användare borttagna |
Konton som står på en tidigare utvecklare privat kan ta veckor att flytta. Börja med det första dagen.
Få igång systemet lokalt
Det snabbaste sättet att lära sig en kodbas är att få den att köra på en ny dator. Varje steg som inte står nedskrivet är en lucka i dokumentationen, så anteckna alla.
- Klona kodförrådet och kontrollera vilken gren som faktiskt ligger i produktion.
- Hitta miljövariablerna och hemligheterna appen behöver, och var de finns i dag.
- Installera beroenden med versionerna i låsfilen, inte de senaste.
- Sätt upp en lokal databas eller testdatabas med realistisk men avidentifierad data, aldrig en kopia av produktionens personuppgifter på en laptop.
- Kör testerna, om det finns några, och notera vilka som fallerar.
- Driftsätt en obetydlig ändring, som en textändring, via den vanliga publiceringsvägen för att bekräfta att allt fungerar hela vägen.
En snabb riskgranskning
Innan någon bygger nya funktioner, lägg några dagar på att ta reda på vad som kan skada er. Målet är en prioriterad lista, inte en omskrivning.
| Område | Frågor att besvara |
|---|---|
| Säkerhet | Ligger hemligheter i koden? Är inloggningen hemmabygd? Är adminvägarna skyddade? |
| Säkerhetskopior | Finns det säkerhetskopior, var, och har någon provat en återläsning? |
| Beroenden | Hur gamla är ramverk och bibliotek? Finns kända sårbarheter? |
| Data och GDPR | Var lagras personuppgifter, och finns biträdesavtal med leverantörerna? |
| Kostnader | Vad kostar drift och varje tjänst per månad, och vem betalar? |
| Övervakning | Märker någon om systemet går ner eller börjar ge fel? |
Dokumentation att skapa
- En arkitekturöversikt på en sida: huvuddelarna, var de körs och hur de pratar med varandra.
- En installationsguide som får en ny utvecklare igång lokalt på under en dag.
- En checklista för publicering: hur man driftsätter, hur man backar och vem som informeras.
- Ett kontoregister: varje tjänst, dess ägare, fakturering och vem som har åtkomst.
- En risklista från granskningen, med föreslagen ordning för åtgärderna.
Lägg dokumentationen i kodförrådet bredvid koden, så att den versionshanteras och följer med projektet.
Varningssignaler första veckan
- Ändringar i produktion gjorda direkt på servern, med kod på servern som inte finns i kodförrådet.
- Det går inte att driftsätta utan den tidigare utvecklarens egen dator eller inloggning.
- Lösenord eller API-nycklar som ligger i kodhistoriken.
- Kunddata på ställen ingen har listat, som kalkylblad eller en bortglömd testdatabas.
- Licenser eller avtal som säger att koden tillhör den tidigare leverantören; kontrollera immaterialrättsklausulerna i avtalet.
Tumregel: hittar granskningen problem som går att åtgärda ett i taget, stabilisera och förbättra det befintliga systemet. Överväg att bygga om bara om grundstrukturen blockerar varje ändring ni behöver; bygga om eller refaktorera förklarar avvägningen. När du inte ska köpa av oss: går den tidigare utvecklaren att nå och vill hjälpa till är en betald överlämningsvecka med hen ofta billigast. Går det inte börjar vår tjänst för skalning och uppgradering med just den här granskningen. Boka ett kort samtal så går vi igenom er situation.
Vanliga frågor
Vad gör vi om den tidigare utvecklaren inte lämnar ifrån sig åtkomsten?
Börja med det företaget äger: domänregistrar, betalleverantör och appbutikskonton i företagets namn kan oftast återställas via leverantörens support med bevis på ägandet. Avtalet avgör vem som äger koden; ta juridisk hjälp om det är omstritt.
Hur lång tid tar ett övertagande?
Att säkra åtkomst och få igång systemet tar oftast några dagar till ett par veckor, beroende på hur mycket som var dokumenterat. Riskgranskningen lägger till några dagar. Nya funktioner bör vänta tills båda är klara.
Ska vi skriva om koden när vi tar över den?
Sällan som första steg. En omskrivning kastar bort beteende som fungerar och tar månader. Stabilisera, granska och åtgärda de värsta riskerna först, och bestäm sedan med verklig kunskap om systemet.
Behöver vi den tidigare utvecklarens hjälp alls?
Det hjälper mycket. Några betalda timmars genomgång, gärna inspelad, kan spara dagar av gissningar. Be om det som en del av avslutet.
Ärver du ett system du inte byggt?
På ett kostnadsfritt 15-minuterssamtal går vi igenom vad ni har åtkomst till, vad som oroar er och vad en övertagandegranskning skulle omfatta. Du får veta de tre första sakerna att säkra.
Boka ett kostnadsfritt 15-minuterssamtal