5.7 Styresystemer og regulering

Fra biter til et helt program

Gjennom denne delen har du lært variabler, kontrollstrukturer, funksjoner, lister, filhåndtering og visualisering -- hver bit for seg. Nå skal vi sette dem sammen til et prosjekt.

Men et programmeringsprosjekt er mer enn bare koding. Det handler like mye om å planlegge, teste, feilsøke og dokumentere -- nettopp slik profesjonelle utviklere og forskere jobber. I dette kapittelet lærer du å planlegge med pseudokode, teste og debugge systematisk, og dokumentere koden din. Etterpå har du verktøyene til å gjennomføre et helt programmeringsprosjekt fra start til slutt.

Planlegg før du koder

Den vanligste begynnerfeilen er å hoppe rett til tastaturet. Et godt prosjekt starter derimot med en plan. Et nyttig verktøy er pseudokode -- en uformell beskrivelse av algoritmen i vanlig språk, et mellomsteg mellom ideen i hodet og den ferdige koden. Et analyseprogram kan for eksempel skisseres slik: «les data fra fil, for hver måling legg til i liste, beregn gjennomsnitt, hvis snittet er over grensen skriv advarsel, lag graf, lagre rapport». Et alternativ er flytskjema, en visuell fremstilling med faste symboler -- oval for start og slutt, rektangel for handling, og rombe for beslutninger. Fordelen med å planlegge er at du oppdager logiske feil før du koder, og lett kan dele opp arbeidet i funksjoner.

Et godt prosjekt følger fire faser med en grov tidsfordeling. Planlegging tar rundt 20 prosent: definer problemet, skisser løsningen, finn ut hvilke funksjoner og bibliotek du trenger. Koding tar mest, rundt 40 prosent: skriv én funksjon om gangen, test hver for seg, og bruk beskrivende navn. Testing tar rundt 25 prosent, og dokumentasjon rundt 15.

Når du oversetter pseudokoden til kode, lønner det seg å bygge programmet av funksjoner med tydelig ansvar. Et temperaturanalyseprogram kan deles i les_data(filnavn), beregn_statistikk(temperaturer), lag_graf(...) og skriv_rapport(...). Da blir selve hovedprogrammet på slutten utrolig lesbart -- hver linje beskriver ett steg i analysen, og du ser med ett øyekast hva programmet gjør.

Test og finn feilene

Et program som kjører, er ikke nødvendigvis et program som virker riktig. Derfor trenger vi testing -- å sjekke at koden gjør det den skal -- og debugging, å finne og rette feil. Det finnes tre slags tester du bør gjøre. Først tester du med kjente data der du vet svaret på forhånd, for eksempel at snittet av 2, 4 og 6 skal bli 4,0. Så tester du grensetilfeller -- en tom liste, ett enkelt element, negative tall. Og til slutt tester du med ugyldig inndata, som tekst der det forventes et tall, og sjekker at programmet ikke krasjer, gjerne med en try/except. Et lite tips: når du sammenligner desimaltall, bruk abs(resultat - forventet) < 0.01 i stedet for ==, fordi avrunding kan gi små forskjeller.

Når noe går galt, er feilmeldingen din beste venn. Les den nøye -- Python forteller deg både type feil og linjenummer. De vanligste typene er verdt å kjenne igjen. En SyntaxError er en skrivefeil, som et glemt kolon etter en if-setning. En IndentationError betyr feil innrykk. En NameError kommer av en skrivefeil i et variabelnavn, så variabelen «finnes ikke». En TypeError oppstår når du blander datatyper, som å legge et tall til en streng. Og en IndexError betyr at du ber om en indeks som ikke finnes i listen.

For å finne feil finnes flere teknikker. Print-debugging -- å legge inn print() for å se verdier underveis -- er enkelt og effektivt. Du kan også kommentere ut deler av koden for å isolere problemet. Og den klassiske «gummiand-metoden» går ut på å forklare koden høyt, linje for linje, for en gummiand eller en medelev -- ofte oppdager du feilen bare ved å sette ord på den.

Dokumenter for fremtiden

Den siste, og ofte mest forsømte, fasen er dokumentasjon. Et nyttig perspektiv: kode leses langt oftere enn den skrives, og «fremtidens deg» om noen uker husker ikke hva du tenkte i dag. God dokumentasjon er derfor en investering i forståelse.

Det finnes tre nivåer. Kommentarer med # bør forklare hvorfor du gjør noe, ikke hva -- for hva-et ser man av koden selv. «Øker x med 1» er en dårlig kommentar; «kompenser for 0-indeksering i utskriften» er en god. Docstrings dokumenterer funksjoner: en streng med trippel-anførselstegn rett etter def-linjen, som forteller hva funksjonen gjør, hvilke parametre den tar, og hva den returnerer. Den kan til og med hentes fram med help(funksjon). Og et filhode øverst i programmet -- også med trippel-anførselstegn -- beskriver hele programmet, gjerne med forfatter og dato.

Setter vi alt sammen, ser et godt miniprosjekt slik ut: det starter med et filhode, deler logikken i små funksjoner med hver sin docstring og ett tydelig ansvar, håndterer ugyldig inndata med try/except, og avsluttes med en kort, lesbar hovedprogramdel. Et BMI-program kan for eksempel ha funksjonene beregn_bmi, bmi_kategori, les_inn_data, vis_statistikk og lag_diagram -- hver liten og forståelig. Nøkkelprinsippene gjelder hele veien: planlegg før du koder, skriv og test én funksjon om gangen, les feilmeldinger nøye, og hold funksjonene små med ett formål. Med disse ferdighetene -- og alt det andre fra programmeringsdelen -- har du et solid grunnlag for å bruke programmering som verktøy i teknologi og forskningslære.

Oppsummering

Vi har sett at et programmeringsprosjekt er mer enn koding. Det starter med planlegging -- pseudokode eller flytskjema -- og følger fire faser: planlegging, koding, testing og dokumentasjon. Selve programmet bygges best av små funksjoner med tydelig ansvar, så hovedprogrammet blir lesbart.

Testing sjekker programmet mot kjente data, grensetilfeller og ugyldig inndata, og debugging løser de vanlige feilene -- SyntaxError, NameError, TypeError og flere -- ved å lese feilmeldingen nøye. Til slutt gjør dokumentasjon med kommentarer, docstrings og filhode koden forståelig for fremtiden. Med dette, og resten av programmeringsdelen, har du verktøyene til å bruke programmering som et ekte verktøy i forskning og teknologi.