Programmering handler ikke om at trykke på tastaturet og skrive så hurtigt som muligt. Det handler ikke om religiøst at lære tastaturgenveje udenad og i sidste ende gøre musen overflødig. Det handler ikke om at lære hvert eneste programmeringssprog der findes, hvis det overhovedet er muligt i første omgang. En god programmør defineres ikke af computerens mærke, pris, ydeevne og styresystem, ej heller af deres præference for kodeeditorer og IDE’er – VS Code, Atom, IntelliJ IDEA, Vim, Notepad++ eller andet. I modsætning til den populære opfattelse takket være mange Hollywood-film er programmering bestemt ikke lig med hacking.
Dertil kommer, at det går ud over at lære syntaksen og de indbyggede funktioner i et programmeringssprog udenad. Logik, betingelser, if statements og algoritmer – især sorteringsalgoritmer – tegner ikke et fuldstændigt billede af, hvad programmering virkelig er. Matematik, rekursion, datalogi og designmønstre gør det heller ikke retfærdighed til det. Selv om de udgør en stor del af det, programmering er, er de kun en del af puslespillet.
Design og planlægning
Hvor der skrives en eneste linje kode, planlægges et projekts design og arkitektur grundigt for at sikre eller i det mindste øge sandsynligheden for at få en gnidningsløs udviklingscyklus. Det er her, at softwaredesign kommer i spil. Værktøjskæder, pipelines, abstraktionslag for offentlige og interne API’er, modularisering, objektrelationer og databasestrukturering planlægges alle i denne udviklingsfase.
Vi er levende, åndende debuggere
Kunsten at programmere kræver, at vi tænker ud af boksen og løser problemer med de mest pragmatiske, effektive og gennemførlige løsninger. Det er sandsynligvis derfor, at vi oftest er husstandens “I.T.-fyr” eller “kundeservice”. Det er praktisk talt vores opgave at reparere det, der er i stykker. Det er som om “programmering” er en forherliget måde at sige “problemløsning” på.
Med andre ord er vi levende, åndende fejlsøgere på og uden for vores computere, og derfor er det vigtigt, at vi ved, hvordan man læser og skriver dokumentation. Korrekt dokumentation – som kommer i form af egentlige sider med detaljeret dokumentation eller så simpelt som at strø værdifulde kommentarer til kodebasen – fungerer som en af de vigtigste livliner for en programmør. Uden den er vi tabt i mørket og ude af stand til at opfylde vores opgaver som debuggere. Der kan kun gøres få eller ingen fremskridt, fordi det meste af vores tid vil blive brugt på at eksperimentere og undersøge, hvordan en ramme eller en ældre kodebase fungerer. Alt i alt ville det resultere i en frygtelig forfærdelig udvikleroplevelse.
Overvej alle mulige scenarier
Debugging er allerede svært nok som det er. For at gøre tingene endnu værre, er udførelsen af kode normalt ikke lineær. Store projekter medfører flere “grene” af mulige udførelsesveje på grund af programlogik med if-angivelsen. Vi er nødt til at tage højde for alle mulige scenarier og fejl, især hvis det involverer brugerinput. Den kognitive belastning, der kræves for at holde styr på alle mulige udførelsesveje, gør programmeringen endnu vanskeligere.
Brugeroplevelse
Går vi uden for udviklingsverdenen, sætter vi os i en gennemsnitlig brugers sted. Ud over at levere funktionalitet, tilføje nye funktioner, rette fejl og dokumentere vores kodebase, fokuserer vi også på, hvordan en gennemsnitlig bruger interagerer med vores app eller software. Vi overvejer flere faktorer, der fører til en god brugeroplevelse, såsom (men ikke begrænset til) tilgængelighed, brugervenlighed, brugervenlighed og -opdagelighed, UI-design, farvetemaer, funktionelle animationer og ydeevne.
Ydeevne og optimering
Apropos det, så er ydeevne en stor facet af programmering i sig selv. Vi, især dem med en baggrund i datalogi, stræber efter at bruge og skrive de mest tids- og pladsbesparende algoritmer. Vi er besat af den uudgrundelige tidsskala på mikrosekunder for at få mest muligt ud af vores tilgængelige hukommelse, CPU’er og GPU’er.
I forbindelse med webudvikling er netværksoptimering et vigtigt begreb at forstå. Vi hopper gennem alle mulige forhindringer for at minificere og komprimere vores HTML, CSS og JavaScript, blot for at minimere nyttelasten i et svar fra serveren. Billeder og andre diverse ressourcer komprimeres og lazy-loades også for at minimere den mængde data, som brugeren skal downloade, før en side bliver meningsfuld og brugbar.
Der er dog tidspunkter, hvor vi bliver for besatte af ydeevne. For tidlig optimering bliver et problem, når vi unødigt optager os selv med at optimere visse dele af en kodebase i stedet for at fokusere på det, der skal gøres for at opnå faktiske fremskridt og produktivitet. I det tilfælde skal vi have visdom til at vurdere, hvilke dele af kodebasen der virkelig har brug for optimering.
Sikkerhed
Bortset fra brugergrænsefladen og logikken i vores software er vi som programmører ansvarlige for vores brugeres sikkerhed. I vores tid, hvor data er meget eftertragtede og stærkt monetariseret, er det vigtigere end nogensinde før at sikre, at vores brugeres personlige oplysninger er sikre. Vi tager ekstra skridt til at beskytte private data, fordi vores brugere stoler på vores software. Hvis vi ikke lever op til dette ansvar, er vi bestemt ikke rigtige programmører, ikke engang i det mindste.
Vi kan aldrig være for sikre, når vi nærmer os sikkerhed. Som en generel tommelfingerregel gælder det, at vi “aldrig stoler på brugerinput”. Det kan endda betragtes som en “bedste praksis” at gøre sig store anstrengelser for at rense data og brugerinput. Ikke alene udsætter vi vores software og infrastruktur for stor risiko, hvis vi ikke er forsigtige med dem, vi risikerer også at kompromittere følsomme brugerdata – de samme data, som vi lover at beskytte som programmører.
Sikkerhed er dog ikke begrænset til brugerdata og input. Virus, orme, trojanske heste, adware, key loggers, ransomware og andre former for computer malware fortsætter med at sprede sig og plager millioner og atter millioner og atter millioner af computere og enheder rundt om i verden. Selv efter årtiers teknologiske forbedringer inden for hardware og software findes der ikke noget usårligt system. Sikkerhed er simpelthen et håndværk, der hele tiden finpudset, men som aldrig vil blive fuldendt, for der vil altid være nogle få nysgerrige mennesker, der undersøger og leder efter alle mulige måder at “hacke” et system på.
Af den grund designer vi vores software uanset brugssituation og brugergruppe med sikkerhed i tankerne som en af de højeste prioriteter, hvis ikke den højeste prioritet. Det gør vi for at beskytte vores brugere mod de førnævnte trusler, der kan forårsage ulemper som datatab, filkorruption og systemnedbrud for blot at nævne nogle få.
Teamwork makes the dream work
Selv om det ikke nødvendigvis vedrører programmering, spiller teamwork en yderst integreret rolle i softwareudvikling. Med al den kompleksitet og alle de bevægelige dele i et stort projekt er det umuligt for kun én person at udvikle kvalitetssoftware i det hurtige tempo med regelmæssig iteration eller under de strenge tidsfrister og tidsbegrænsninger fra en kunde eller en tilsynsførende enhed.
Det er derfor, vi har forskellige teams af mennesker, der specialiserer sig i en af de mange facetter af programmering. Én person vil aldrig have alle de færdigheder og den viden, der er nødvendig for effektivt og sammenhængende at klistre alle facetter sammen på en effektiv og sammenhængende måde. Et team kan være ansvarlig for UI-design og tilgængelighed, mens et andet team kan arbejde på selve softwarens funktionalitet. Hvis alle kompetencerne hos de forskellige specialiserede teams kombineres, vil den resulterende software have den bedste funktionalitet, brugeroplevelse, ydeevne og sikkerhed, som den overhovedet kan have inden for de økonomiske og praktiske begrænsninger.
For tidsstyring og overholdelse af deadlines er arbejdsgangsorganisering og automatisering af største betydning. Vi tager os tid til at konfigurere vores build-værktøjer og pipelines korrekt, fordi det vil spare os en masse tid i fremtiden. Generelt øges afkastet af investeringen, efterhånden som tiden går.
At arbejde godt sammen med andre
For at uddybe idéen om teamwork og samarbejde etablerer vi sunde relationer med vores kolleger, fordi et projekts succes i sidste ende i høj grad afhænger af succesen for det team, der står bag det. Vi gør en indsats for at skabe et støttende arbejdsmiljø, hvor erfarne seniorer omhyggeligt vejleder nyankomne.
Da vi udvikler software som et team, skal vi være opmærksomme på, at andre læser vores kode. For at holde udviklingscyklussen bæredygtig på lang sigt anses læsbarhed og vedligeholdbarhed for at være lige så vigtige som logikken og funktionaliteten i et projekt. Vi skriver konsekvent god, læsbar kode, samtidig med at vi leverer informative commit-meddelelser og dokumentation, fordi disse helt sikkert vil hjælpe os og andre til at forstå vores kode bedre.
Apropos andre, der læser vores kode, er en kodegennemgang en god mulighed for at lære mere om bedste praksis inden for programmering. Det er også en anden måde at gøre os bekendt med en kodebase og dens underliggende design og arkitektur. Selv om konstruktiv kritik er ubehagelig og vanskelig at håndtere i den modtagende ende, er det vigtigt at tage den som et godt råd, så vi kan forbedre os som programmører.
Programmering er svært
Programmering omfatter mange aspekter ud over funktionalitet, f.eks. brugeroplevelse, ydeevne, sikkerhed og teamwork. Det er ikke nok at fokusere strengt på ét aspekt alene og samtidig udelade de andre. For projekter af bemærkelsesværdig størrelse og betydning er det ikke så simpelt som at skrive et par linjer kode. Det kræver en masse omhyggelig planlægning, udformning, overvejelser og samarbejde i teamet for at blive en succes. Faktisk bruges der mere tid på at tænke end på at skrive, når man programmerer, især under lange debugging-sessioner.
I sidste ende handler programmering i virkeligheden om kontinuerlig, uafbrudt læring. Tilpasningsevne og konstant læring er nøglen til at overleve i denne branche. Vi kan ikke forvente at forblive relevante, hvis vi ikke gør vores del for at blive ved med at lære. I en så omskiftelig branche med eksponentielle teknologiske forbedringer er vi nødt til at følge med det høje tempo, så vi ikke ender i støvet.
Jeg vil gerne afslutte denne artikel med at anerkende det hårde arbejde, som alle udviklere verden over udfører. For at skrive denne artikel var jeg nødt til at reflektere over den daglige arbejdsgang for et team af udviklere. Jeg var nødt til at se på de mange aspekter af programmering og softwareudvikling, som normalt går ubemærket hen. Siden da har jeg fået en større forståelse for al den software, der er installeret på min computer. Derfor vil jeg opfordre alle til at takke en programmør i dag, uanset erfaring. Hvor ville vi være uden dem?
Tag aldrig deres hårde arbejde for givet.