Et korrekt fungerende program

1. Jobben til en programmerer

Svært ofte tenker nybegynnere programmerere på arbeidet til en programmerer helt annerledes enn hvordan erfarne programmerere tenker på det.

Nybegynnere som ofte sier noe sånt som "Programmet fungerer, hva mer trenger du?" En erfaren programmerer vet at "fungerer riktig" bare er ett av kravene til et program , og det er ikke engang det viktigste !

Kode lesbarhet

Det viktigste er at programkoden er forståelig for andre programmerere . Dette er viktigere enn et korrekt fungerende program. Mye mer.

Hvis du har et program som ikke fungerer som det skal, kan du fikse det. Men hvis du har et program der koden er uforståelig, kan du ikke gjøre noe med det.

Bare ta et hvilket som helst kompilert program, for eksempel notisblokk, og endre bakgrunnsfargen til rød. Du har et fungerende program, men du har ikke forståelig kildekode: det er umulig å gjøre endringer i et program som dette.

Et lærebokeksempel er da Microsoft-utviklere fjernet Pinball-spillet fra Windows fordi de ikke kunne portere det til 64-bits arkitektur. Og de hadde til og med kildekoden. De kunne rett og slett ikke forstå hvordan koden fungerte .

Regnskap for hvert brukstilfelle

Det nest viktigste kravet for et program er å gjøre rede for hvert scenario. Ofte er ting litt mer komplisert enn det ser ut til.

Hvordan en nybegynner programmerer ser på å sende SMS-meldinger:

Slik ser en profesjonell programmerer det:

Scenarioet "fungerer riktig" er vanligvis bare ett mange mulige. Og det er derfor mange nybegynnere klager over CodeGyms oppgavevalidator: bare ett scenario av 10 fungerer, og nybegynnerprogrammereren mener det er nok.

2. Unormale situasjoner

Unormale situasjoner kan oppstå under kjøringen av ethvert program.

For eksempel bestemmer du deg for å lagre en fil, men det er ingen diskplass. Eller programmet prøver å skrive data til minnet, men det er lite ledig minne. Eller du laster ned et bilde fra Internett, men forbindelsen blir brutt under nedlastingsprosessen.

For hver unormal situasjon må programmereren (forfatteren av programmet) a) forutse det, b) bestemme nøyaktig hvordan programmet skal håndtere det , og c) skrive en løsning som er så nær den ønskede som mulig.

Det er derfor programmer hadde veldig enkel oppførsel i ganske lang tid: hvis det oppstod en feil i programmet, ble programmet avsluttet. Og det var en ganske god tilnærming.

La oss si at du vil lagre et dokument på disk, under lagringsprosessen oppdager du at det ikke er nok diskplass. Hvilken oppførsel vil du helst ha:

• Programmet avsluttes
• Programmet fortsetter å kjøre, men lagrer ikke filen.

En nybegynner programmerer kan tro at det andre alternativet er bedre, fordi programmet fortsatt kjører. Men i virkeligheten er det ikke slik.

Tenk deg at du skrev ut et dokument i Word i 3 timer, men to minutter inn i skriveprosessen ble det klart at programmet ikke ville kunne lagre dokumentet på disk. Er det bedre å miste to minutters arbeid eller tre timer?

Hvis programmet ikke kan gjøre det det skal, er det bedre å la det lukke enn å fortsette å late som om alt er i orden. Det beste et program kan gjøre når det støter på en feil som det ikke kan fikse på egen hånd, er å umiddelbart rapportere problemet til brukeren.

3. Bakgrunn om unntak

Programmer er ikke de eneste som møter unormale situasjoner. De forekommer også i programmer - i metoder. For eksempel:

• En metode ønsker å skrive en fil til disk, men det er ikke plass.
• En metode ønsker å kalle en funksjon på en variabel, men variabelen er lik null.
• Divisjon med 0 skjer i en metode.

I dette tilfellet kan anropsmetoden muligens korrigere situasjonen (utføre et alternativt scenario) hvis den vet hva slags problem som oppstod i den kalte metoden.

Hvis vi prøver å lagre en fil på disk og en slik fil allerede eksisterer, kan vi ganske enkelt be brukeren bekrefte at vi bør overskrive filen. Hvis det ikke er ledig diskplass, kan vi vise en melding til brukeren og be brukeren velge en annen disk. Men hvis programmet går tom for minne, vil det krasje.

En gang i tiden tenkte programmerere på dette spørsmålet og kom opp med følgende løsning: alle metoder/funksjoner må returnere en feilkode som indikerer resultatet av deres utførelse. Hvis en funksjon fungerte perfekt, returnerte den 0 . Hvis ikke, returnerte den en feilkode (ikke null).

Med denne tilnærmingen til feil, etter nesten hvert funksjonskall, måtte programmerere legge til en sjekk for å se om funksjonen avsluttet med en feil. Koden ble ballongert i størrelse og kom til å se slik ut:

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)
{
   ...
}

Dessuten visste ganske ofte en funksjon som oppdaget at en feil oppsto ikke hva de skulle gjøre med den: den som ringte måtte returnere feilen, og den som ringte tilbake til den som ringte, og så videre.

I et stort program er en kjede med dusinvis av funksjonsanrop normen: noen ganger kan du til og med finne en samtaledybde på hundrevis av funksjoner. Og nå må du sende feilkoden fra bunnen til toppen. Og hvis et sted underveis en funksjon ikke håndterer utgangskoden, vil feilen gå tapt.

En annen ulempe med denne tilnærmingen er at hvis funksjoner returnerte en feilkode, kunne de ikke lenger returnere resultatene av sitt eget arbeid. Resultatet av beregninger måtte sendes via referanseparametere. Dette gjorde koden enda mer tungvint og økte antallet feil ytterligere.