Målet är inte att förstå varje rad. Målet är att kunna säga vad varje fil är till för. Det är en helt annan och mycket lägre ribba — och den räcker för att upptäcka de flesta problem i tid. Om du inte kan säga vad en fil gör har du ingen aning om ifall den borde finnas.
Fem saker som finns i all kod
Programmeringsspråk ser olika ut, men de bygger på samma handfull idéer. Känner du igen de här fem kan du följa vad som händer i en fil utan att kunna språket.
epost eller antalAnmalda innehåller precis det namnet säger. Om namnet är begripligt kan du läsa raden.function eller ett namn följt av parentes betyder "här görs en sak, och den heter det här". sparaAnmalan(...) sparar en anmälan.if betyder "bara om". Läs vad som står i parentesen — det är förutsättningen — och sedan vad som händer när den stämmer.for, while eller map betyder "gör det här en gång per sak i listan". Nästan alltid en lista som visas på skärmen.fetch, await eller en adress som börjar med https:// betyder att koden pratar med något utanför appen. Här hamnar data hos någon annan, så här är det värt att titta noga.Läsa en fil på en minut
Du behöver inte läsa uppifrån och ned. Gör så här i stället, i den här ordningen.
function och läs bara namnen. Nu har du en innehållsförteckning över filen.http, på key och på token. Det som ligger här ska du förstå. Mer i guide 7.Det räcker. Du vet nu vad filen är till för, vad den pratar med och om den innehåller något du inte bett om. Det är hela poängen.
Förklaringsprompten som faktiskt avslöjar något
"Förklara den här koden" ger en artig sammanfattning som bekräftar det du redan trodde. De här frågorna gör inte det.
Förklara den här filen för någon som inte kan programmera. Använd inga tekniska termer utan att förklara dem i samma mening.
Svara sedan på: Vad händer om någon fyller i något oväntat? Skickas något härifrån till en annan tjänst, och i så fall vad? Vad i den här filen skulle du själv ha gjort annorlunda?
Sist: vad i det här är du osäker på?
Sista frågan är den mest användbara i hela guiden. Modeller är formulerade för att låta säkra, men de svarar ärligt på en direkt fråga om osäkerhet — och svaret pekar nästan alltid på det som senare går sönder.
Fler frågor som ger konkreta svar
- "Vilken rad avgör vad som händer när formuläret skickas?"
- "Vad går sönder om jag byter ut det här fältet mot ett annat?"
- "Finns det något här som bara fungerar på min dator?"
- "Vad händer med data om två personer skickar formuläret samtidigt?"
- "Vilken del av appen är mest känslig för ändringar?"
Fyra varningstecken du kan se utan förkunskaper
Tecken på problem
- En fil som är mycket längre än de andra, utan att du bett om något stort.
- Samma kod upprepad flera gånger med små skillnader.
- Långa slumpmässiga teckensträngar mitt i koden.
- Kommentarer som säger
TODO,placeholdereller "ersätt detta".
Vad du gör åt det
- Fråga: "Varför blev den här filen så stor? Kan den delas?"
- Fråga: "Det här ser upprepat ut. Är det avsiktligt?"
- Fråga: "Vad är det här för sträng, och ska den ligga i koden?"
- Sök igenom hela projektet efter dem innan du publicerar. Ett kvarglömt
TODOär ofta ett halvfärdigt säkerhetssteg.
Att inte förstå är inte samma sak som att det är fel
Det är lätt att fastna i motsatt fälla: att bli rädd för all kod man inte kan läsa och därför aldrig gå vidare. Kod du inte förstår är inte automatiskt dålig. Den är bara okontrollerad.
Dra gränsen så här: du behöver förstå vad varje del gör och vart data tar vägen. Du behöver inte förstå hur det är gjort. Om en sorteringsfunktion sorterar rätt varje gång du provar är det inte din uppgift att granska algoritmen.
- Allt som rör inloggning. Vem som får se vad, och hur det avgörs.
- Allt som rör pengar. Belopp, avrundning, vad som händer vid avbrutet köp.
- Allt som skickar data någon annanstans. Vad som skickas och vart.
- Allt som raderar något. Vad som försvinner, och om det går att få tillbaka.
Nästa steg
Du kan nu läsa det du fått och ställa frågor som ger svar. Nästa guide handlar om det som händer när appen slutar fungera — och varför den första reflexen ska vara att backa, inte att fråga om en fix.