Ett korrekt fungerande program

1. Jobbet som programmerare

Mycket ofta tänker nybörjare på en programmerares arbete helt annorlunda än hur erfarna programmerare tänker på det.

Nybörjare som ofta säger något i stil med "Programmet fungerar, vad mer behöver du?" En erfaren programmerare vet att "fungerar korrekt" bara är ett av kraven för ett program , och det är inte ens det viktigaste !

Kodens läsbarhet

Det viktigaste är att programkoden är begriplig för andra programmerare . Detta är viktigare än ett korrekt fungerande program. Mycket mer.

Om du har ett program som inte fungerar korrekt kan du fixa det. Men om du har ett program vars kod är obegriplig kan du inte göra något med det.

Ta bara valfritt kompilerat program, såsom anteckningsblock, och ändra dess bakgrundsfärg till röd. Du har ett fungerande program, men du har ingen förståelig källkod: det är omöjligt att göra ändringar i ett sådant program.

Ett läroboksexempel är när Microsoft-utvecklare tog bort Pinball-spelet från Windows eftersom de inte kunde porta det till 64-bitars arkitektur. Och de hade till och med dess källkod. De kunde helt enkelt inte förstå hur koden fungerade .

Redovisning för varje användningsfall

Det näst viktigaste kravet för ett program är att ta hänsyn till varje scenario. Ofta är saker lite mer komplicerade än de verkar.

Så här ser en nybörjare på att skicka SMS:

Hur en professionell programmerare ser det:

Scenariot "fungerar korrekt" är vanligtvis bara ett många möjliga. Och det är därför många nybörjare klagar på CodeGyms uppgiftsvalidering: bara ett scenario av 10 fungerar, och nybörjarprogrammeraren tycker att det räcker.

2. Onormala situationer

Onormala situationer kan uppstå vid körning av vilket program som helst.

Du bestämmer dig till exempel för att spara en fil men det finns inget diskutrymme. Eller så försöker programmet skriva data till minnet, men det är lite ledigt minne. Eller så laddar du ner en bild från Internet, men anslutningen bryts under nedladdningsprocessen.

För varje onormal situation måste programmeraren (författaren till programmet) a) förutse det, b) bestämma exakt hur programmet ska hantera det och c) skriva en lösning som ligger så nära den önskade som möjligt.

Det är därför program hade väldigt enkelt beteende under ganska lång tid: om ett fel uppstod i programmet avslutades programmet. Och det var ett ganska bra tillvägagångssätt.

Låt oss säga att du vill spara ett dokument på disk, under sparprocessen upptäcker du att det inte finns tillräckligt med diskutrymme. Vilket beteende skulle du helst vilja ha:

• Programmet avslutas
• Programmet fortsätter att köras, men sparar inte filen.

En nybörjare kan tycka att det andra alternativet är bättre, eftersom programmet fortfarande körs. Men i verkligheten är det inte så.

Föreställ dig att du skrev ut ett dokument i Word i 3 timmar, men två minuter in i din skrivprocess stod det klart att programmet inte skulle kunna spara dokumentet på disk. Är det bättre att förlora två minuters arbete eller tre timmar?

Om programmet inte kan göra vad det behöver är det bättre att låta det stängas än att fortsätta låtsas att allt är okej. Det bästa som ett program kan göra när det stöter på ett fel som det inte kan åtgärda på egen hand är att omedelbart rapportera problemet till användaren.

3. Bakgrund om undantag

Program är inte de enda som möter onormala situationer. De förekommer också i program - i metoder. Till exempel:

• En metod vill skriva en fil till disk, men det finns inget utrymme.
• En metod vill anropa en funktion på en variabel, men variabeln är lika med null.
• Division med 0 sker i en metod.

I det här fallet kan anropsmetoden möjligen korrigera situationen (exekvera ett alternativt scenario) om den vet vilken typ av problem som uppstod i den anropade metoden.

Om vi ​​försöker spara en fil på disken och en sådan fil redan finns, kan vi helt enkelt be användaren att bekräfta att vi ska skriva över filen. Om det inte finns något ledigt diskutrymme kan vi visa ett meddelande för användaren och be användaren att välja en annan disk. Men om programmet tar slut på minne kommer det att krascha.

En gång i tiden funderade programmerare på denna fråga och kom på följande lösning: alla metoder/funktioner måste returnera en felkod som indikerar resultatet av deras exekvering. Om en funktion fungerade perfekt gav den 0 . Om inte, returnerade den en felkod (inte noll).

Med denna metod för fel, efter nästan varje funktionsanrop, var programmerare tvungna att lägga till en kontroll för att se om funktionen slutade med ett fel. Koden blev ballong i storlek och kom att se ut så här:

File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

Dessutom visste ganska ofta en funktion som upptäckte att ett fel inträffade inte vad den skulle göra med det: uppringaren var tvungen att returnera felet, och uppringaren till den som ringde returnerade det till sin uppringare, och så vidare.

I ett stort program är en kedja av dussintals funktionsanrop normen: ibland kan du till och med hitta ett anropsdjup med hundratals funktioner. Och nu måste du skicka felkoden från botten till toppen. Och om någonstans på vägen någon funktion inte hanterar utgångskoden, så kommer felet att gå förlorat.

En annan nackdel med detta tillvägagångssätt är att om funktioner returnerade en felkod kunde de inte längre returnera resultatet av sitt eget arbete. Resultatet av beräkningarna måste skickas via referensparametrar. Detta gjorde koden ännu krångligare och ökade antalet fel ytterligare.