Code Complete  
- håndbog i programudvikling

Af Wilfred Gluud

Bogen Code Complete er den bedste guide til at skrive håndværksmæssige og professionelle  programmer. Den dækker alle aspekter af programudvikling fra design til test, med hovedvægt på teknikker til at skrive solid og læselig kode. Det erklærede mål for bogen er at mindske forskellen mellem ledende teknikker udviklet af IT-guruer og akademikere og praksis i IT-industrien.
Den 2. udgave er både omskrevet og ajourført, og omfatter kapitel om objektorienteret programmering samt klasser.

Code Complete 2: A Practical Handbook of Software Construction. Af Steve McConnell. 800 sider. Pris £21,07 på www.amazon.co.uk (eller køb den brugt).

Forfatteren Steve McConnell er utrolig belæst og har samlet viden og teknikker fra et enormt antal artikler, bøger samt erfaringer fra praksis. Uanset om man er ny eller erfaren programudvikler, kan man lære de bedste metoder. Alle aspekter af programudvikling fra navngivning af variabler diskuteres i detaljer. Når en problemstilling har flere løsningsmetoder lægges det åbent frem, med diskussion af argumenter for og imod.

Selvom bogens størrelse kan virke afskrækkede, er den alligevel relativt let at læse, og der er ingen, der siger, man skal læse hele bogen på én gang. Brug bogen som opslagsværk, eller læs de kapitler hvor du føler du bør/vil vide mere. 500 eksempler på god og dårlig kode (”code horror”) vises i C++, Java og Visual Basic.

Første udgave af bogen udkom i 1993, og en og revideret 2. udgave i 2004, og ifølge forfatterens hjemmesiden holder 95% af første udgave fra 1993, men ”terminologien er ændret, programmeringssprogene er udviklet og min (forfatterens) tænkning er udviklet”. Samtidig har bogen fået tilføjet nyt indhold. og en stor del er omskrevet. Bogen omhandler nu også objektorienteret programmering, herunder klasser. Desuden indeholder hvert kapitel en checkliste og en opsummering af nøglepunkter, så man hurtigt kan se, om der er afsnit, man bør læse.

Da jeg omtale første udgave af bogen på et kursus, fortalte en af kursusdeltagerne at han var datamatiker og kom fra et lille firma med kun to programmører. Den anden programmør kom fra USA og havde medbragt ”Code Complete”, som han foreslog som firmaets standard for programmering, og det fungerede meget fint.

For nye programmører er bogen fuld af erfaringer, om hvordan man bliver en mere professionel programmør, og også lærer at blive en god programudvikler. Og det gælder som bekendt om at udvikle sig, inden ens job outsources til Indien eller Østeuropa. Men også for erfarne programudviklere er der meget viden at hente i denne bog. Og hvis nogen skulle være så kloge at de ved det hele, kan de jo bruge bogen til at henvise til eller undervise ud fra. Bogen er nærmest uundværlig for programudviklere, der arbejder alene, og en god lærebog og referencepunkt for programmører der arbejder sammen i grupper.

Vandfaldsmodel contra Extreme Programming
Om udviklingsmodeller siger Steve McConnell: ”Det er ikke praktisk at specificere 100% af forudsætninger og design på forhånd, men de fleste projekter finder det værdifuldt at identificere de mest kritiske forudsætninger og arkitektoniske elementer tidligt. En god tommelfingerregel er at planlægge at specificere 80% på forhånd…”, mens ”Et alternativ er at kun specificere de 20% vigtigste forudsætninger på forhånd, og planlægge at udvikle resten i små udvidelser .. ” (Measure Twice, Cut Once: Upstream Prerequisites, side 34)

Bogen tager ikke stilling til om man skal benytte ‘vandfaldsmodellen’ (Software Engineering, hvor man i princippet færdiggør hver fase inden man går videre med den næste), eller Agile metoder som Extreme Programming, hvor man på forhånd forudsætter at brugerkrav ændres undervejs og arbejder med gentagne korte systemudviklingsforløb, som tilføjer flere og flere faciliteter til systemet. Der citeres undersøgelser der viser at gennemsnitligt ændres projekter med 25% i løbet af udviklingsprocessen (hvilket er 70 til 85% af ændringerne på et typisk projekt) (se side 40).

Så uanset om man arbejder på et stort eller lille projekt, med BDUF (Big Design Up Front, lig ‘vandfaldsmodellen’) eller LDUF (Little Design Up Front, f.eks. Extreme Programming) eller måske ENUF (Enough Design Up Front), er det vigtigt, at man bliver bedre til at designe, det der skal konstrueres (eller vurdere de dokumenter man modtager).

Programdesign og konstruktion
Kapitlet ”Design in Construction” opsummerer og formidler en guldgrube af viden, om hvordan man designer systemer og eller programmer, hvordan man angriber kompleksitet og opdeler i byggeblokke. Uanset om man anvender objekter og klasser eller moduler, rutiner og makroer, er principperne for programdesign det samme, og her er alle de råd, man har brug for.

Der er både et kapitel om ”Working Classes”, som fortæller hvordan man opbygger klasser, og et kapitel om hvordan man bygger ”High-Quality Routines”.

Et kapitel beskriver ”The Pseudocode Programming Process”, hvor man først beskriver hvordan en klasse, rutine eller program skal fungere i ’struktureret’ engelsk (dansk) så det kan forstås af andre IT-folk og gerne også super-brugere. Ved at gøre pseudokoden til programkommentarer, kan man så afsnit for afsnit udarbejde koden. Så skal man heller ikke til at skrive kommentarer, når programmet er færdigt. Jeg kombinerer denne metode med at teste hvert afsnit af programmet så tidligt som muligt.

Så følger 4 kapitler om variabler fra generelt, navngivning, datatyper og særlige datatyper. Næste afsnit indeholder 6 kapitler om programstatements. Så følger 7 kapitler om ”Code improvement” fra software-kvalitet, samarbejde om udvikling, testeksempler, debugging og refaktorering (forbedring/videreudvikling). Afsnittet om debugging er langt og godt, men jeg savner en bedre prioritering af oplysningerne. David J. Agans har en fremragende 9 punkts liste om hvordan man skal tænke når man debugger, på sin hjemmeside www.debuggingrules.com, hvor jeg vil anbefale alle at downloade plakaten og overveje at anskaffe sig bogen "Debugging".

Kode tuning samt system overvejelser
Kapitlet Code-tuning er også vigtigt, fordi 90% af tuning for de fleste systemer ligger i læs/skriv af filer eller database SQL! Jeg har selv oplevet et eksempel hvor daglig opdatering startede med at køre 36 timer, bl.a. fordi brugertabellen blev læst fra disk for hvert eneste felt. I sådanne kald skal man spørge på identen, på den rekord/række, man skal bruge, allerede er indlæst. Programmer dobbelte DO loop med store indeksværdier, hvor jeg tunede et program med 80 %.

Afsnittet ”System Consideration” fortæller hvordan programstørrelse påvirker konstruktion, styring og estimering af konstruktion, integration og daglig systemtest. Desuden om værktøjer der hjælper programmøren med source-koden, test og meget andet der forbedrer produktiviteten.

Afsnittet om integration gennemgår glimrende forskellige metoder. Efter min perosnlige mening bør man fremhæve "test-først", hvor man laver testmateriale før man programmerer, og ideen om daglig integration-test. Det er ideer som fremhæves stærkt i Extreme programming, men som også kan bruges til at forbedre nuværende udviklingsmetoder.

Under ”Managing Contruction” er der mange kloge råd, og under ’Estimating a Construction Schedule’, at man skal få ansatte l at estimere deres egne opgaver. Der mangler oplysninger om hvordan en programudvikler skal estimere udvikling af et program. Det første råd er at skaffe mere tid til foretage estimeringen, dernæst at vurdere opgave-formuleringen for kendte og ukendte faktorer. Jeg var tvunget til at estimere mine opgaver, og kun ved at have erfaringer og ved at kende forbruget på tidligere opgaver, kan man estimere nye opgaver.

”Software Craftmanship” indeholder kapitler om layout og stil, selv-dokumenterende kode og om personlig stil og om man som professionel ”skriver programmer først og fremmest for mennesker, og dernæst for computere”.

Der er også et glimrende kapitel for managers/gruppeledere som har brug for bedre at forstå systemudviklere, måske skulle du få din leder til at læse det!

En uundværlig bog for alle programmør og systemudviklere, og også for alle der er ledere for programmører. Husk at IT er et af de fag, hvor man især kan lære fra bøger. Få dit firma til at anskaffe bogen, eller køb den selv!  

Steve McConnell er Chief Software Engineer i sit eget firma Construx Software Builders, hvor han deler tiden mellem at at holde seminarer, skrive artikler til sit website, udvikle Elearning om sine metoder samt at  være  konsulent for andre firmaers projekter.
Hans første bog var “Code Complete” (udkom første gang 1993) og “Rapid Development, Taming Wild Software Schedules” (857 sider, 1996) om samtlige udviklingsmodeller, og at vælge den rigtige model til det rigtige projekt.
In 1998 udgav hanSoftware Project Survival Guide: How to Be Sure Your First Important Project Isn't Your Last” (288 sider). Dernæst kom “After the Gold Rush” (1999), som omarbejdet og udvidet blev genudgivet i 2003 som “Professional Software Development”, essays om professionel Software Engineering. I 2006 udkom "Software Estimation: The Black Art Demystified".
Det kan anbefales at besøge både hans personlige hjemmeside samt hjemmesiden for hans firma Construx

WWW: http://cc2e.com og www.stevemcconnell.com


Links - Litteratur - Etik - Copyright Wilfred Gluud Programmering

Wilfred Gluud Senior Programmør -  Kontakt via e-mail wilfred@gluud.net 
Revideret 14-06-2016 12:40

Retur: Kursus-Program - Kursus-IT-ansatte / forside www.gluud.net