Så fungerar webbutveckling i praktiken
Utifrån ser utveckling ut som en svart låda: du godkänner designen, väntar några veckor, en webbplats dyker upp. Att förstå vad som händer inuti hjälper dig ställa rätt frågor och tidigt känna igen varningstecken.
Den här guiden förklarar det praktiska arbetet, för den som beställer snarare än den som programmerar.
Miljöer: där arbetet sker#
Ett seriöst projekt har minst två miljöer, ofta tre. Finns bara en är det i sig ett tecken.
| Miljö | Vad den är till för | Vem har åtkomst |
|---|---|---|
| Lokal | Utvecklarens egen dator | Teamet |
| Test | Delad version för granskning | Team och kund |
| Förproduktion | Kopia identisk med produktion | Teamet, före driftsättning |
| Produktion | Den publika webbplatsen | Alla |
Ändringar direkt i produktion är den vanligaste källan till oväntade fel. Om du får höra att det inte finns någon testmiljö, fråga varför.
Arbetscykeln#
De flesta team arbetar i korta cykler, med något granskningsbart i slutet av varje.
- Arbetet delas i små uppgifter, var och en med ett kontrollerbart resultat.
- Varje uppgift utvecklas separat, med versionshantering.
- Någon annan granskar koden innan den integreras, när teamet är stort nog.
- Resultatet går till testmiljön, där det går att se.
- Du granskar och ger konkret återkoppling, med adress och skärmbild.
- Rättningar går in i nästa cykel, om de inte är blockerande.
- Varannan vecka finns en version att granska, inte bara i slutet.
Ett projekt där du ser resultatet först i slutet är ett riskprojekt. Be om åtkomst till testmiljön från första veckan.
Tester före driftsättning#
Vad som bör vara kontrollerat före varje driftsättning, oavsett projektstorlek.
- Funktion: varje formulär, varje flöde, varje knapp som gör något.
- Webbläsare: de dina besökare faktiskt använder, enligt analysen.
- Enheter: riktiga mobiler, inklusive en gammal och långsam.
- Prestanda: uppmätt, inte uppskattad, på huvudmallarna.
- Tillgänglighet: tangentbord, kontrast, etiketter, rubrikstruktur.
- Innehåll: ingen platshållartext, inga länkar till testdomänen.
- Regression: det som fungerade fungerar fortfarande.
- Säkerhet: validering av indata, behörigheter, HTTPS.
Driftsättning och återställning#
Driftsättning ska vara rutin och tråkig. När den är en spänd händelse är det ett tecken på en skör process.
| Praxis | Varför det spelar roll |
|---|---|
| Automatiserad driftsättning | Eliminerar bortglömda manuella steg |
| Återställning på minuter | Gör ett allvarligt fel till en liten incident |
| Säkerhetskopia före driftsättning | Skyddsnät för databasen |
| Versionshanterade datamigreringar | Reproducerbara databasändringar |
| Verifiering efter driftsättning | Fångar det som bara fallerar i produktion |
| Driftsätt vid lugn tidpunkt | Färre drabbade användare, mer uppmärksamhet |
| Logg över driftsättningar | Gör det möjligt att koppla problem till ändringar |
Fråga hur lång tid en återställning tar. Är svaret «det beror på» eller «vi har aldrig behövt» finns ingen återställningsplan.
Vanliga frågor
Hur ofta ska jag se framsteg?
Varje eller varannan vecka, med något synligt i testmiljön. Längre cykler ökar risken att sent upptäcka ett missförstånd. Mycket korta cykler med ständig återkoppling har också en kostnad, eftersom avbrutet arbete är ineffektivt. En takt på varannan vecka fungerar bra i de flesta projekt.
Vad gör jag om projektet blir försenat?
Ta först reda på orsaken: saknat innehåll, växande omfattning eller optimistisk uppskattning. De tre löses på olika sätt, och den första ligger ofta på kundsidan. Välj sedan mellan att skära i omfattning eller flytta datumet — att lägga till personer mitt i ett försenat projekt försenar det oftast ytterligare.
Måste jag kunna kod för att leda detta?
Nej. Du behöver veta vilka frågor du ska ställa: finns testmiljö, hur driftsätts det, hur lång tid tar en återställning, vad är testat, vem har åtkomst till koden. Svaren säger mycket om processens soliditet utan att du läser en rad kod.
Vad är versionshantering och varför spelar det roll?
Det är systemet — nästan alltid Git — som sparar historiken över alla kodändringar och gör det möjligt att gå tillbaka. Det spelar roll av tre skäl: det möjliggör återställning av ett fel, det låter flera arbeta parallellt, och det är beviset på att koden är din och överförbar. Ett projekt utan versionshantering är ett projekt utan historik.
hur webbutveckling fungerartestmiljöversionshanteringdriftsätta webbplatsutvecklingsprocessleda webbprojekt
