Dårlige vaner er svære at bryde og endnu sværere, hvis du ikke er klar over, at det, du gør, undergraver dit arbejde. Hvis du ved det, men er ligeglad – det ville være det værste. Men du er her jo, ikke sandt?
Som programmør har jeg set en masse dårlig praksis, ikke kun omkring kode, men også omkring teamworkfærdigheder. Jeg har selv været skyldig i at praktisere mange af disse dårlige vaner. Her er mine 35 bedste dårlige programmeringsvaner, inddelt i fire kategorier: kodeorganisering, teamwork, kodeskrivning samt test og vedligeholdelse.
Kodeorganisering
1. At sige: “Jeg retter det senere”
Vanen med at udskyde rettelser af kode er ikke kun et problem med prioriteringer. Organisering af din problemtracker kan skabe visse fremskridt, men du skal også have en måde at spore mindre problemer, der dukker op. Tilføjelse af “TODO”-kommentarer er en hurtig måde at sikre, at du ikke overser noget.
2. Insistere på en one-liner-løsning
At være besat af at skrive effektive, elegante stykker kode er et almindeligt træk hos programmører. Det er som at løse et puslespil – du finder en kombination af funktioner og regulære udtryk, der forvandler 20 kodelinjer til 2 eller 3. Desværre resulterer det ikke altid i læsbar kode, og det er generelt det langt vigtigere resultat. Gør først din kode tilgængelig og derefter smart.
3. Foretag meningsløse optimeringer
Et andet sted, hvor vi ofte misbruger vores indsats, er optimeringer. Det lyder godt at reducere størrelsen af dit websted med et par bytes, men vil gzip ikke alligevel gøre det ud for det? Og er requests ikke vigtigere? Tag optimeringer op i slutningen af et projekt, for oftest vil kravene ændre sig, og din tid vil være spildt.”
“For tidlig optimering er roden til alt ondt.”
-Donald Knuth
4. Overbevis dig selv om, at stilproblemer ikke er så vigtige
Hvis jeg har lært noget i årenes løb ved at kigge på andres kode, så er det, at håndtering af problemer med kodningsstil er det, som udviklere er mest tilbøjelige til at udskyde. Måske er det svært for uerfarne kodere at se, hvad godt der vil komme ud af at tage fat på stilproblemer, men med tiden vil det vise sig, at når først kodekvaliteten afspores, vil en sneboldeffekt forvandle ethvert projekt til et komplet rod. Vær streng med hensyn til bedste praksis, selv om de synes ubetydelige. Opsæt kodekontrol- og linting-værktøjer for at give dig selv plads til at bekymre dig om de vigtigere ting.
5. Fejning af ting under gulvtæppet
Enten ved at fange og ignorere undtagelser eller ved at bruge biblioteker, der ikke rapporterer fejl (som f.eks. jQuery), er der mange måder at feje ting under gulvtæppet på. Men når en af disse fejl bliver en prioritet, vil udfordringen med at rette den være mange gange større, i betragtning af at du ikke aner, hvor du skal begynde. En nem måde at afværge dette på er ved at logge disse ignorerede fejl, så du kan studere dem senere.
6. Brug af navne, der ikke tilføjer information
Navnegivning er svært, men der er en nem måde at sikre, at dine variabel- og funktionsnavne i det mindste er af anstændig kvalitet. Så længe navnene tilføjer en eller anden form for information, som resten af koden ikke formidler, vil andre udviklere have lettere ved at læse din kode. Grunden til, at navngivning er så vigtig, er, at navne kan give en generel idé om, hvad koden gør. Det tager mere tid, hvis du skal grave i beregningerne for at finde ud af, hvad et stykke kode gør, men et godt navn kan hjælpe dig med at forstå, hvad koden gør, på få sekunder.
7. Ignorerer gennemprøvede bedste praksis
Kodegennemgange, testdrevet udvikling, kvalitetssikring, automatiseret implementering – disse og flere andre praksisser har bevist deres værdi i utallige projekter, og det er derfor, at udviklere blogger om dem konstant. En god reference for disse bedste praksis er bogen Making Software: What Really Works, and Why We Believe It (Hvad der virkelig virker, og hvorfor vi tror på det). Tag dig tid til at lære at udføre dem korrekt, og din udviklingsproces vil blive forbedret i alle dine projekter på måder, der vil overraske dig.
Teamwork
8. Opgivelse af planer for tidligt
En sikker måde at gøre dit system uigennemskueligt på er ikke at lægge sig fast på en plan. Du kan altid sige, når din kode bliver kritiseret, at planen ikke er komplet. Men at have halvfærdige moduler vil føre til stramt koblet kode, så snart du forsøger at få disse ufærdige moduler til at arbejde sammen. Denne form for komplikation opstår også, når ledelsesrollerne i et projekt skifter, og de nye ledere beslutter, at det er vigtigere at have det på deres måde end arkitektonisk konsistens.
9. At insistere på en plan, der har ringe chance for at virke
Såvel som det kan give problemer at opgive sine planer, kan det også give problemer at holde fast i en plan, der ikke virker. Derfor bør du dele dine idéer med dit team for at få feedback og råd, når tingene bliver vanskelige. Nogle gange kan et andet perspektiv gøre hele forskellen.
10. Arbejder alene hele tiden
Du bør bestræbe dig på at dele dine fremskridt og idéer med teamet. Nogle gange tror du, at du bygger noget på den rigtige måde, men det gør du ikke, så konstant kommunikation er meget værdifuld. Det er også gavnligt for andre mennesker, når du arbejder sammen med dem. Deres arbejde bliver ofte bedre, når du diskuterer idéer med dem og er mentor for de mindre erfarne medlemmer af dit team, som er mere tilbøjelige til at gå i stå.
11. Nægt at skrive dårlig kode
Der kommer et tidspunkt i enhver udviklers liv, hvor deadlines vil tvinge dig til at skrive forfærdelig kode, og det er helt okay. Du har prøvet at advare din kunde eller chef om konsekvenserne, men de insisterer på at overholde deadline, så nu er det tid til at kode. Eller måske er der en hastende fejl, som ikke kan vente på, at du kommer med en ren løsning. Derfor er det vigtigt at være alsidig som programmør og være i stand til at skrive dårlig kode meget hurtigt såvel som god kode. Forhåbentlig kan du gense koden og betale den tekniske gæld tilbage.
12. At give andre skylden
Det er ingen hemmelighed, at arrogance er et alt for almindeligt træk blandt udviklere og andre tekniske fagfolk. At tage ansvar for dine fejl er en dyd, som vil få dig til at skinne blandt dine kolleger. Du skal ikke være bange for at indrømme, at du har begået en fejl. Når du er okay med det, kan du frit fokusere på at lære, hvorfor du har begået den fejl, og hvordan du undgår den. Hvis du ikke indrømmer det, bliver det umuligt at lære.
13. Du deler ikke med dit team, hvad du har lært
Din værdi som udvikler er ikke kun placeret på den kode, du skriver, men også på det, du lærer, når du skriver den. Del dine erfaringer, skriv kommentarer om det, lad andre vide, hvorfor tingene er, som de er, og hjælp dem med at lære nye ting om projektet og dets snørklede detaljer.
14. At være for langsom til at give feedback til ledere/kunder
Et af de mest værdifulde karaktertræk hos enhver håndværker ligger i at sørge for, at alle er på samme side om arbejdet, så meget som muligt. Grunden til dette er ikke, at din chef kan udfylde regneark. Det er også for din egen skyld: Du vil have mindre usikkerhed og mindske usikkerheden om projektets levetid og fremtid.
15. Du bruger ikke Google nok
Den bedste måde at løse et komplekst problem hurtigt på er ikke at skulle løse det overhovedet. Når du er i tvivl, så google det. Du kan selvfølgelig spørge ingeniøren ved siden af dig i stedet, men han vil sjældent være i stand til at give et så detaljeret svar som Stack Overflow, for ikke at nævne at du også afbryder hans arbejde.
16. Overvurdering af din personlige stil
Søg altid at koordinere din arbejdsstil og miljøopsætning med dit team. Ideelt set bør alle på dit team arbejde under lignende forhold og følge den samme kodningsstil. Det kan være sjovere at gøre tingene på din måde, men kollegaerne er måske ikke vant til din kodningsstil, og hvis den er usædvanlig, vil det være sværere for den næste udvikler at arbejde videre med det, du har bygget.
17. At have en personlig tilknytning til din kode
Når nogen kommenterer på din kode, skal du ikke tage det personligt. Din kode skal stå på et solidt grundlag; det vil sige, at du skal kunne forklare, hvorfor du har skrevet den på den måde. Hvis den skal forbedres, er det kun en afspejling af kodens korrekthed, ikke af dig selv.
Skrivning af kode
18. Ikke at vide, hvordan man optimerer
En god optimeringsstrategi kræver en del erfaring at få den rigtige strategi. Det kræver udforskning, analyse og kendskab til alle de systemer, der er involveret i en proces. Informer dig selv om disse ting. Lær om algoritmisk kompleksitet, evaluering af databaseforespørgsler, protokoller, og hvordan man måler ydeevne generelt.
19. Brug af det forkerte værktøj til opgaven
Du kan kun vide så meget, men grunden til, at du skal blive ved med at lære, er, at hvert nyt problem giver en anden kontekst og kræver et andet værktøj – et værktøj, der er mere anvendeligt til den pågældende opgave. Vær åben over for nye biblioteker og sprog. Træf ikke beslutninger udelukkende på grundlag af det, du ved.
20. Ikke at gide at beherske dine værktøjer og IDE
Hver ny genvejstast, genvej eller parameter, du lærer, mens du bruger de værktøjer, du arbejder med hver dag, vil have en mere positiv effekt på din kodningshastighed, end du er klar over. Det handler ikke om at spare et par sekunder ved at bruge en genvejstast; det handler om at reducere kontekstskiftet. Jo mere tid du bruger på hver enkelt lille handling, jo mindre tid har du til rådighed til at tænke over, hvorfor du gør det, og over hvad der kommer bagefter. Når du mestrer genveje, får du friere tanker.
21. Ignorering af fejlmeddelelser
Du skal ikke antage, at du ved, hvad der er galt med din kode, uden at du overhovedet har læst en fejlmeddelelse, eller at du vil finde ud af det hurtigt nok. Det er altid bedre at have flere oplysninger om et problem, og hvis du tager dig tid til at indsamle disse oplysninger, vil du spare mere tid i det lange løb.
22. Romantizing your developer toolkit
Sommetider er din foretrukne editor eller dit foretrukne kommandolinjeværktøj ikke det bedste værktøj til det pågældende job. Visual Studio er fantastisk til at skrive IDE’er, Sublime er fantastisk til dynamiske sprog, Eclipse er fantastisk til Java og så videre. Du elsker måske vim eller emacs, men det betyder ikke, at det er det rigtige værktøj til alle opgaver.
23. Hardcoding af værdier i stedet for at gøre dem konfigurerbare
Tænk altid på, hvilke ændringer der kan komme, og hvordan du skal håndtere dem. Teknisk gæld vil vokse med en monstrøs hastighed, hvis du ikke adskiller de bevægelige dele fra resten af dit arbejde. Brug konstanter og konfigurationsfiler, hvor det er hensigtsmæssigt.
24. Genopfinde hjulet hele tiden
Skriv ikke kode, som du ikke behøver at skrive. Måske har en anden person allerede brugt en god del tid på dit problem, og han eller hun har måske en velafprøvet løsning, som du kan genbruge. Spar dig selv for besværet.
25. Blindt kopiere/indsætte kode
Forstå kode, før du genbruger den. Nogle gange opdager man ikke umiddelbart alt det, som koden gør, ved første øjekast. Du vil også lære mere om et problem, når du tager dig tid til at læse koden i detaljer.
26. Ikke at tage sig tid til at lære, hvordan tingene egentlig fungerer
Grib altid muligheden for at udvide din viden ved at tænke over, hvordan tingene fungerer, og læse om deres bagvedliggende problemer. Du sparer måske tid ved ikke at gøre dig den ulejlighed lige nu, men det, du lærer i forbindelse med et projekt, vil på lang sigt være vigtigere end det, du rent faktisk får udført.
27. At have overdreven tillid til din egen kode
Det er farligt at antage, at bare fordi du har skrevet noget, må det være godt. Du lærer mere om programmering, efterhånden som du arbejder med nye ting og får erfaring, så tag et kig på din gamle kode fra tid til anden og reflekter over, hvordan du har udviklet dig.
28. Ikke at tænke over kompromiserne ved hvert design, hver løsning eller bibliotek
Alle produkter har deres finesser, som du kun lærer at kende ved at bruge og analysere dem. Når du ser nogle få eksempler på brugen af et bibliotek, bliver du ikke en mester i det, og det betyder heller ikke, at det passer perfekt til alle de situationer, der vil opstå i dit projekt. Vær hele tiden kritisk over for alt, hvad du bruger.
29. Ikke at få hjælp, når du er gået i stå
Det vil altid være mindre smertefuldt for dig at holde et kort feedback loop. At bede om hjælp betyder ikke, at du er inkompetent. De rigtige mennesker vil se din indsats og din indrømmelse af uvidenhed som en drivkraft til at lære, og det er en stor dyd at have.
Test og vedligeholdelse
30. At skrive tests, der skal bestå
Det er nødvendigt at skrive tests, som du ved vil bestå. De vil gøre refaktorering og omorganisering af et projekt meget mere sikkert. På den anden side er du også nødt til at skrive tests, som du ved ikke vil bestå. De er nødvendige for at få projektet fremad og holde styr på problemer.
31. Undlad at se bort fra ydelsestestning i kritiske tilfælde
Forbered en opsætning af automatiseret ydelsestestning omkring midtpunktet i et projekts udviklingsproces, så du kan sikre dig, at du ikke har eskalerende ydelsesproblemer.
32. Ikke at kontrollere, at dit build virker
Det er sjældent, at et build godkendes, men ikke rigtig virker, men det kan ske, og det kan være besværligt at løse problemet, jo længere du venter med at se på det. Hurtigt at teste hvert build er en vigtig vane at have.
33. Skubbe store ændringer sent, eller gå efter at have lavet et stort push
Det er her, hvor overmodig selvtillid vil få dig, og det kan kræve at blive brændt flere gange for at lære, hvorfor du ikke skal gøre dette, så følg mit råd nu og sørg for, at du altid er der, når dit build til sidst går i stykker.
34. Afvisning af kode, du har skrevet
Vær villig til at støtte kode, du har skrevet. Du er den bedst egnede person til at hjælpe andre med at forstå den. Du bør stræbe efter at få din kode til at forblive læsbar for dig selv og andre mange år frem i tiden.
35. Ignorering af de ikke-funktionelle krav
Når du forsøger at levere noget, kan det være let at glemme nogle vigtige områder som f.eks. ydeevne og sikkerhed. Hold en tjekliste for disse. Du ønsker ikke, at de ødelægger din fest, fordi du udarbejdede dine deadlines uden at tænke på disse ikke-funktionelle bekymringer.
Hvad er dine værste programmeringsvaner?
Som det ofte siges, er vi vanens skabninger. At forbedre din måde at arbejde på gennem vaner er en god måde at undgå at skulle tænke for meget over hver eneste situation. Når man først har tilegnet sig en god måde at gøre noget på, bliver det ubesværet.