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
