Artikel top billede

10 ting som enhver softwareudvikler skal undgå

Se de største forhindringer for effektiv udvikling af software.

Computerworld News Service: Så svært er det heller ikke at udvikle rigtig god software. Men softwareudvikleren kan være sin egen værste fjende på grund af sjuskede eller hovedløse tilgange.

Den bagvedliggende årsag til, når der ikke leveres software i ordentlig kvalitet, udgøres dog oftest af lidt for ivrige tekniske ledere, der forsøger at få projekter færdiggjort hurtigere, end det i praksis kan lade sig gøre, og som derfor presser udviklerne ud i dårlige vaner.

Især i forhold til de rigtigt store projekter kan dette virkelig få katastrofale følger.

Ikke desto mindre er disse faldgruber vældig udbredte.

Derfor vil vi her gennemgå de 10 største fejl, der står i vejen for effektiv udvikling af software af høj kvalitet.

1. Gå blot en enkelt dag uden test

Udviklere elsker at hænge sig i detaljer, såsom hvad forskellen er mellem en enhedstest og en funktionel test.

Det korrekte svar er: Det er lige meget.

Det afgørende er, om man har mulighed for at se, om koden virker, som den skal.

Det er vigtigt, at man har et godt udgangspunkt til at køre koden, og at man definerer et brudpunkt i fejlfindingsværktøjet.

Derfor er man nødt til hele tiden at teste.

Test er også gode udtryk for, om kravene overholdes.

På trods af et bjerg af beviser hører man stadig i ny og næ:
"Du er nødt til at bevise overfor ledelsen, at det kan betale sig at lave enhedstest."

Disse ledere er it-branchens svar på folk, der benægter den globale opvarmning, de såkaldte klimabenægtere.

For dem vil beviserne aldrig være tilstrækkelige.

De vil altid levere fejlfyldte og kraftigt forsinkede projekter, der ikke lever op til brugernes forventninger.

2. Gå blot en enkelt dag uden en build

Med værktøjer såsom Jenkins CI findes der ingen undskyldning.

Det tager kun få timer og en virtuel maskine for at sætte en instance af Jenkins op, der er egnet til de fleste projekter.

Dette værktøj kan endda konfigureres til at køre, hver gang der tjekkes kode ind i et system til såkaldt versionsstyring eller versionskontrol såsom SVN eller Git.

Det er muligt at køre enhedstest, indsamle måledata og sende e-mail, når der konstateres fejl.

Gentagne builds er ligesom hjerterytmen i et sundt udviklingsprojekt.

Og man kan altså ikke leve, hvis ikke hjertet slår.

Sådan mister du mange timers arbejde

3. Brug ClearCase (eller lignende langsomme værktøjer)

ClearCase er langsomt - det er indiskutabelt. Og ClearCase er ikke det eneste frygteligt langsomme versionsstyrings-system.

Hvad som helst, der tvinger udviklerne til at "vente" for at tjekke deres kode ind eller ud, dræner produktiviteten enormt.

Det medfører også andre ulemper.

Selv med en fast rutine med gentagne builds vil hver ny build allerede næsten være forældet, hvis udviklerne tvinges til at vente, indtil de har tid til at tjekke koden ind.

Hvad værre er, så kan det betyde, at en given maskine måske opbevarer den eneste kopi af længere tids arbejde fra en udvikler.

Det repræsenterer en ikke uvæsentlig risiko for at miste mange timers arbejde.

Et versionsstyrings-system, der benytter såkaldt pessimistisk låsning er ikke kun en katastrofe, hvis en udvikler for eksempel glemte at tjekke sin kode ind før ferien.

Det lægger også en konstant dæmper på ethvert projekt.

Jeg kan ikke forstå, hvorfor der stadig er folk, der mener, at det er acceptabelt, at halvdelen af et team sidder og venter på, at en fil bliver låst op, frem for at man potentielt har to udviklere til at arbejde på den samme fil (og sandsynligvis forskellige dele af filen, som derfor automatisk kan blive flettet sammen).

4. Lever koden til produktion uden forgrening

Mange organisationer har endnu ikke regnet ud, hvordan man skaber en forgrening.

Forgrening gør det muligt at levere en udgivelse og rette fejl i denne udgivne kode, men undgå at udgive halvfærdig, ny kode.

Det er faktisk ikke svært at lave forgrening. Der findes adskillige effektive strategier.

Faktisk understøttes det i hvert eneste system til versionsstyring, jeg er stødt på i løbet af de sidste par år.

Det kræver dog, at udviklerne sætter sig grundigt ind i deres versionsstyrings-system.

Når du skal til at teste

5. Udskyd at load-teste til allersidst

Selv nogle af de mest effektive organisationer jeg har set, tror stadig, at load-test er noget, man først foretager i slutningen af et projekt.

Denne forestilling bygger på antagelsen, at det er roden til alt ondt at begynde for tidligt med at optimere.

Det er heller ikke helt forkert.

Men man er nødt til at holde øje med, om man tager grundlæggende beslutninger, der afskærer projektet fra at imødekomme krav til ydelse eller skalerbarhed.

Det billigste tidspunkt ændre sådanne beslutninger er tidligt i projektet.

Her taler vi om at vælge det forkerte datalager, den forkerte algoritme, den forkerte regelmotor med forfærdelige concurrency-problemer til følge.

Sådanne problemer kan kræve en enorm mængde omskrivning af koden, hvis de opdages for sent.

6. Udvikling uden krav til kapacitet / ydelse

Når jeg hjælper folk med problemer med ydelse eller skalerbarhed, er det første, jeg spørger om: Hvad er det forventede antal brugere?

Uanset de tekniske aspekter af et problem så kan den dybereliggende årsag tilskrives det skuldertræk, jeg ofte får som svar.

Et succesfuldt projekt har altid i det mindste et overslag af et forventet antal brugere.

Det handler ikke kun om god skik i forhold til softwareudvikling.

Det drejer sig mindst lige så meget om en grundlæggende forretningsmæssig prognose.

For at udvikle en fornuftig load-test er man nødt til at have klare ydelsesmæssige forventninger.

Man er nødt til at vide, hvor mange brugere systemet bør forventes at kunne håndtere.

Brugernes dom

7. Udskyd at inddrage brugerne indtil allersidst

Inden for markedsføring har man brugt fokusgrupper i årtier.

Nogen er nødt til at bekræfte, at produktudviklerne har ramt plet, og at et produkt kan sælges.

Det samme gælder for softwareudvikling.

Hvad enten det drejer sig om en intern eller ekstern kunde, så er nogen nødt til så tidligt som muligt i et projekt at kontrollere, om slutproduktet vil blive godkendt af brugerne.

Det kan være forbundet med visse problemer at vise sin software frem, før den er nogenlunde færdig, men hvis man ikke gør det, er det virkelig ikke til at sige, om den vil leve op til brugernes forventninger.

8. Forsøg at betale dig ud af softwareudvikling

Spørgsmålet, om man skal købe eller udvikle selv, er et af de mest grundlæggende i it-afdelingen.

Selvfølgelig giver det i visse tilfælde bedre mening, at man køber kommercielle apps frem for at udvikle sine egne, ligesom man ikke i visse tilfælde kan vælge at integrere kommercielle eller open source-programmer i større projekter.

Men man kan også ende med at købe licens til for eksempel hele Oracle- eller WebSphere-stack'en uden at levere noget som helst.

Der er grænser for, hvor meget dit udviklings-team kan absorbere og anvende, før kompleksiteten overstiger de formodede tekniske fordele.

9. Insister på at genopfinde den dybe tallerken

Lad være med at forsøge at udvikle din egen cache, database, thread pool, connection pool, transaction manager og så videre.

Hvis ikke du arbejder for et selskab eller med et open source-projekt, der er dedikeret til at udvikle en af disse teknologier, så er der stort set aldrig nogen god grund til, at du kaster dig over det, heller ikke selvom du "ved, hvad du gør."

Så lad være med at bruge tid på noget, der er unødvendigt, når der findes pålidelige løsninger, der i forvejen er blevet kvalitetssikret af masserne.

I mindst 99 procent af tilfældene vil denne validering veje tungere end dine grunde til at "udvikle noget bedre."

10. Skriv kode direkte til RDBMS

Der skrives for tiden en forbløffende mængde sludder om systemer til såkaldt object-relational mapping.

Faktisk er der altid blevet skrevet en masse sludder om dette emne.

Typisk bruges der et eller to grænsetilfælde til at retfærdiggøre, at man helt skrotter ORM og i stedet skriver "direkte" til JDBC eller OleDB eller hvad det nu end kan være.

Sandheden er, at ingen har ressourcer til at foretage fejlfinding af al den CRUD-kode.

Med alle de ORM-systemer, jeg nogensinde har brugt, er det muligt at håndtere disse et eller to grænsetilfælde direkte, uden at man er tvunget til helt at gå uden om systemet.

Oversat af Thomas Bøndergaard




Brancheguiden
Brancheguide logo
Opdateres dagligt:
Den største og
mest komplette
oversigt
over danske
it-virksomheder
Hvad kan de? Hvor store er de? Hvor bor de?
Advania Danmark A/S
Hardware, licenser, konsulentydelser

Nøgletal og mere info om virksomheden
Skal din virksomhed med i Guiden? Klik her

Kommende events
Vælg den rigtige infrastruktur og it-arkitektur

Få indblik i, hvordan du kan sikre sammenhæng og overblik i et it-landksab, der konstant ændres. Dette kan blandt andet gøres med de rette strategisk og teknologiske vlag, så effektiviteten, stabiliteten og sikkerheden opretholdes. Den rigtige infrastruktur og it-arkitektur kan uden tvivl hjælpe dig med at skabe overblikket over dit it-landskab.

18. maj 2021 | Læs mere


Digital transformation og innovation: Inspiration til digitale succeshistorier

Kom ind bag facaden hos nogle af Danmarks bedste it-folk, og lær hvordan de arbejder med digital transformation og innovation. Du får muligheden for at høre, hvordan du kan bruge den nye teknologi til at få etableret det mest effektive udviklings- og innovationsmilø.

19. maj 2021 | Læs mere


Internationale dataoverførsler: Bananrepublikker og spionage

Det er nu lovpligtigt at dokumentere beskyttelsesniveauet af persondata, når de overføres til tredjelande. Vi sætter derfor fokus på, hvordan virksomhederne styrer deres internationale dataoverførsler fri af tredjelandes overvågning. Vi dykker samtidig ned i hele det spegede kompleks omkring Schrems II, FISA 702 og EO 12.333, og hvordan det spiller sammen med dansk fortolkning og praksis.

25. maj 2021 | Læs mere






Premium
Skal du rejse til sommer? Sådan kommer det europæiske coronapas til at fungere
Et nyt cornapas er på vej fra EU, der skal sikre at unionen igen skal kunne lukke op for landegrænser mellem de 27 medlemslande. Sådan fungerer teknologien - og sikkerheden - bag passet.
Computerworld
Apple pumper milliarder ind i optisk laser-selskab - rygterne tager til om nye planer
Apple smider nu 2,5 millarder kroner efter Apple-partneren II-VI der fremstiller optiske lasere. Og det kunne sætte skub i en VR-udvikling.
CIO
Har du rost din mellemleder i dag? Snart er de uddøde - og det er et tab
Computerworld mener: Mellemledere lever livet farligt: Topledelsen får konstant ideer med skiftende hold i virkeligheden, og moden går mod flade agile organisationer. Men mellemlederen er en overset hverdagens helt med et kæmpe ansvar. Her er min hyldest til den ofte latterliggjorte mellemleder.
Job & Karriere
Eva Berneke stopper som topchef i KMD og flytter til Paris: Her er KMD's nye topchef
Efter syv år på posten som topchef for KMD forlader Eva Berneke selskabet. Nu flytter hun med familien til Paris, hvor hun vil fortsætte sit bestyrelsesarbejde. KMD har allerede afløser på plads.
White paper
Er de cyberkriminelle allerede trængt ind – uden at du har opdaget det?
Optimér din sikkerhed ved at kombinere indsatsen for at holde IT-kriminelle ude med en konstant antagelse om, at de muligvis allerede er trængt ind på dit netværk.