programmering (IT)

Programmering er et eget fagfelt med tilhørende utdannelsestilbud på universiteter og høgskoler verden over.

Selve ordet «programmering» er et vidt begrep som rommer alt fra å programmere et vaskeprogram på en vaskemaskin, til å skrive komplekse dataprogrammer for finansielle systemer eller kunstig intelligens. Når vi innstiller en vaskemaskin på 60 °C, velger forvask, ekstra skylling og sentrifugeringshastighet på 1400 omdreininger per minutt, programmerer vi vaskemaskinen til å utføre det vaskeprogrammet vi ønsker.

Å programmere en datamaskin er i prinsippet det samme: vi gir datamaskinen detaljerte instruksjoner for hvordan den skal utføre en konkret oppgave. Men jo større og mer kompleks oppgaven som skal utføres er, desto mer kreves det av både kunnskap og ferdigheter fra programmererens side. For å kunne kommunisere med datamaskinen må vi skrive instruksjonene i et språk som datamaskinen er konstruert til å forstå. Det krever at vi behersker et programmeringsspråk som er egnet for oppgaven. Videre må vi ha grundig innsikt i oppgaven som skal utføres og forstå problemet som skal løses, slik at vi er i stand til å beskrive løsningen i detalj, instruksjon for instruksjon. Er oppgaven stor, vil det være nødvendig å dele programmet inn i mindre deler, såkalte moduler, der hver modul løser sin del av oppgaven.

Som programmerer er det imidlertid ikke nok å kunne programmere. Skal dataprogrammet fungere etter hensikten, må vi vite hvordan det skal brukes og ikke minst hvem som skal bruke det.

Datamaskinen forstår kun digital maskinkode, det vil si sekvenser av nuller og enere. I teorien lar det seg gjøre å programmere i maskinkode, men i praksis vil være umulig å holde oversikt over hva programmet gjør. Maskinkode er derfor ikke egnet til å lage reelle dataprogrammer.

Av denne grunn er det utviklet høynivå programmeringsspråk, som Java, C++, C#, Python og PHP. Disse ligger nærmere det menneskelige språk, og er dermed lettere å skrive instruksjoner i. Datamaskinen, som kun forstår maskinkode, kan imidlertid ikke utføre høynivå kildekode direkte. Kildekoden må først oversettes til maskinkode. Dette gjøres ved hjelp av et eget oversettelsesprogram, en såkalt kompilator. Først når kildekoden er kompilert (oversatt), kan datamaskinen utføre programmet.

Det finnes mange ulike programmeringsspråk. Den mest utbredte typen er de objektorienterte språkene som Java, C# og C++. Her er kildekoden organisert i logiske enheter, såkalte klasser og objekter, ikke ulikt slik vi oppfatter virkeligheten rundt oss.

Programmering krever solide kunnskaper og ferdigheter i programmeringsspråket dataprogrammet skal skrives i. Skal programmereren lykkes, er det imidlertid ikke nok å kjenne til språkets syntaktiske regler. Vi må også forstå hvordan maskinen tolker instruksjonene vi skriver. Forstår vi det, vil vi kunne følge programkontrollen og derved sikre oss at datamaskinen utfører det vi ønsker at den skal gjøre.

Styrken ved objektorienterte språk er at de legger til rette for gjenbruk av kode. Er en klasse først definert, kan den brukes om og om igjen i nye programmer.

I programutviklingsverktøyene for de ulike programmeringsspråkene følger det gjerne med såkalte klassebiblioteker som inneholder ferdige klasser som programmererne kan benytte seg av. Klassene fra bibliotekene kan enten brukes som de er, eller videreutvikles til nye klasser.

I tillegg til standardbibliotekene er det også utviklet en mengde spesialbiblioteker, såkalte rammeverk, som inneholder programvare for ulike fagfelt og spesialoppgaver.

Det at programmerere kan bygge videre på andres kode, har bidratt til en voldsom utvikling innen datateknologi.

Mange av dataprogrammene vi bruker i det daglig er svært store. Eksempelvis inneholder tekstbehandlingsprogrammet Word mange hundre tusen instruksjoner. Skal vi programmere programmer av denne størrelsesorden, sier det seg selv at vi må dele det opp på en fornuftig måte.

En velkjent problemløsningsteknikk er å dele et stort problem inn i mindre delproblemer, for så å løse hver del for seg. På samme måte kan vi dele programmet inn i flere moduler (delprogrammer) som hver tar seg av sin deloppgave.

Det er for eksempel vanlig å la brukergrensesnittet, som tar seg av kommunikasjonen med brukeren av programmet, utgjøre en modul, databasen, som sørger for nødvendig lagring av dataene, utgjøre en annen, mens programlogikken, som behandler dataene, utgjør en tredje.

Ikke sjeldent er de forskjellige modulene programmert i ulike programmeringsspråk, alt etter hvilket språk som er best egnet til å løse deloppgaven. Hvis så er tilfelle, vil kommunikasjonen mellom modulene foregå via ulike applikasjonsgrensesnitt (API), der reglene for hvordan kommunikasjonen mellom dem skal foregå, er fastsatt.

• Les mer om programvarearkitektur.

På samme måte som en husbygger stiller krav til hvilke funksjoner huset skal ivareta, vil en oppdragsgiver til et dataprogram stille krav til hva programmet skal utføre. Kravene er gjerne nedfelt i en kravspesifikasjon, som er utarbeidet i samarbeid mellom oppdragsgiveren og den eller de som skal programmere programmet. Hvor detaljert kravspesifikasjonen er, og hvordan programutviklerne forholder seg til den, vil avhenge av hva slags utviklingsmetodikk som er valgt. Vi kan skille mellom to hovedtyper:

1. I sekvensiell utviklingsmetodikk (fossefallsmetoden) planlegges programmet i detalj før programmeringen, kalt implementasjonen, finner sted.
2. I iterativ utviklingsmetodikk, ofte kalt smidige utviklingsmetoder, programmeres programmet i iterasjoner, det vil si leveranse for leveranse. Allerede fra første iterasjon vil man da ha et kjørbart program som kan testes. Deretter videreutvikles programmet, leveranse for leveranse, til det er ferdig.

Oppdragsgiveren til et program er ikke nødvendigvis den samme som sluttbrukeren av det. Selv om programmet innfrir kravene som er nedfelt i kravspesifikasjonen, er det ikke sikkert at det blir en suksess. Skal programmet fungere etter hensikten, må det også tilfredsstille sluttbrukerens behov og forventninger. Innen smidig utvikling er det derfor ikke uvanlig å la representanter for sluttbrukerne bidra med tilbakemeldinger og innspill under utviklingen av programmet.

I et digitalisert samfunn, der vi alle i økende grad er avhengig av ulike typer dataprogrammer, er det avgjørende at de fungerer som de skal. Enkelte feil skaper først og fremst irritasjon hos brukeren av programmet, men oppstår det for eksempel feil i et styringssystem til et tog eller fly, kan det få fatale konsekvenser, ja i verste fall med tap av liv. Å teste programvaren grundig før den tas i bruk, er følgelig helt avgjørende. For å sikre objektive vurderinger, brukes det ofte uavhengige testere som ikke selv har deltatt i utviklingen av programmet. Dette fratar imidlertid ikke programmereren ansvaret for kodens kvalitet.

På samme måte som vi har lett for å gjøre skrivefeil når vi skriver vanlig tekst, er det ikke til å unngå at vi gjør programmeringsfeil når vi programmerer. De syntaktiske feilene hjelper kompilatoren oss med. Verre er det med de logiske feilene. Oppdages ikke de i tide, vil ikke programmet fungere som det skal, noe som igjen kan få alvorlige konsekvenser. Ideelt sett bør programmereren teste koden fortløpende, det vil si for hver metode som programmeres bør det programmeres en tilhørende enhetstest (unit-test) som sjekker at metoden utfører det den skal. Enhetstestene utgjør grunnlaget for automatisk testing, som igjen gjør det mulig å effektivisere og øke omfanget av testingen. Etter hvert som dataprogrammene øker i kompleksitet og størrelse, øker også behovet for automatisert testing som en integrert del av utviklingsprosessen.

Testing av programvare, software testing, er et eget fagfelt som tar for seg hvordan testingen kan integreres gjennom hele programvarens livssyklus, fra planleggingsfasen, der vi sikrer oss at fundamentet programmet skal bygges på ikke inneholder feil og mangler, gjennom implementasjonsfasen, frem til ferdig produkt. Målet er å forebygge feil, og ikke minst luke dem ut så tidlig som mulig i utviklingsprosessen. Hvis en feil først har forplantet seg inn i koden, vil det koste det mangedobbelte å fjerne den i forhold til hva det ville kostet å luke den ut i en tidligere fase. Å starte testing tidlig i utviklingsprosessen er derfor en meget kostnadseffektiv teststrategi.

• dataprogram
• objektorientert programmering
• programvarearkitektur
• programvare
• programmeringsspråk
• systemutvikling