Bygga om eller refaktorera när MVP:n inte räcker?

Tecken på att MVP:n är ansträngd

Ansträngning visar sig som affärssymtom före tekniska. Små ändringar tar oproportionerligt lång tid. Varje release går sönder på något orelaterat ställe. Samma bugg kommer tillbaka i ny skepnad. Bara en person vågar röra en viss del av koden. Svarstiderna stiger med antalet användare. Nya utvecklare behöver veckor för att bli produktiva. Skriv ner detta med exempel och datum, för nästa steg är att fråga var i systemet vart och ett uppstår, och vag smärta leder till vaga beslut.

Refaktorera: stegvis och säkert

Refaktorering betyder att förbättra kodens struktur utan att ändra vad den gör, i små steg, där varje steg driftsätts och verifieras. Det är oglamoröst och nästan alltid rätt första drag, eftersom det angriper den faktiska orsaken till varje symtom i stället för allt på en gång.

• Lägg till tester runt den del ni ska ändra, så att ni vet när ni har haft sönder den.
• Åtgärda bara det största symtomet: den långsamma frågan, den trassliga modulen, det saknade indexet. Mät före och efter.
• Bryt ut de delar som ändras oftast till rena moduler med tydliga gränssnitt; låt de stabila delarna vara.
• Uppgradera ramverk och beroenden i ett eget steg, inte blandat med funktionsarbete.

Några veckor av detta, gjort av någon som läser koden innan hen dömer den, löser de flesta ansträngda MVP:er. Systemet fortsätter tjäna pengar hela tiden, och stannar arbetet halvvägs är inget förlorat.

Bygga om: när det är motiverat

Det finns verkliga skäl att börja om, och de har en sak gemensamt: problemet sitter i en grund som inte går att byta ut bit för bit.

Den dolda kostnaden för omskrivningar

Det offererade priset för en ombyggnad är den minsta av dess kostnader. Medan den nya versionen skrivs behöver den gamla fortfarande buggfixar och de funktioner kunderna lovats, så ni betalar för två system. Det gamla systemet innehåller år av små beslut, specialfall och rättningar som ingen dokumenterade; ombyggnaden återupptäcker dem ett supportärende i taget. Funktionsparitet tar längre tid än beräknat eftersom beräkningen gjordes utifrån funktionerna folk minns, inte de som finns. Och dagen för bytet är en enda felpunkt för hela verksamheten.

Inget av detta betyder att man aldrig ska bygga om. Det betyder att argumenten måste vägas mot de kostnaderna, skriftligt, och att svaret måste överleva frågan om vad som händer om ombyggnaden tar dubbelt så lång tid.

En stegvis mellanväg

Angreppssättet som fungerar i praktiken är att bygga om på plats. Låt det gamla systemet fortsätta köra och betjäna kunderna. Lägg ett tunt routinglager framför. Bygg den nya versionen av ett avgränsat område, som inloggning, betalning eller rapporter, styr den trafiken till den nya koden och pensionera den gamla modulen. Upprepa med nästa område, värst först. I varje läge har ni ett fungerande system, och ni kan stanna efter vilket steg som helst med redan spenderade pengar omsatta i värde.

1. Skriv ner symtomen med belägg och spåra vart och ett till sitt ursprung.
2. Refaktorera de tre största ursprungen och mät effekten innan något större beslutas.
3. Kvarstår ett grundproblem, bygg om bara det området, bakom det körande systemet.
4. Utvärdera efter varje steg; att sluta tidigt är en framgång, inte ett misslyckande.

När ni inte behöver det här: en MVP med få användare och inget tillväxttryck bör behålla sina genvägar; putsning är inget affärsmål. När tillväxten är verklig och koden håller den tillbaka är den här stegvisa bedömningen det första vi gör i en skalning och systemuppgradering, och ett kostnadsfritt samtal räcker för att säga vilken av de tre vägarna era symtom pekar mot. Priserna finns på prissidan.

Vanliga frågor