Code Complete: A practical handbook of software construction

Steve McConnells ”Code Complete: A practical handbook of software construction” (Microsoft Press, 1993) har länge tillhört programmeringslitteraturens klassiker. Den anses av många vara den definitiva guiden till mjukvarukonstruktion och har kallats för både programmerarens bibel och programmeringsmetodikens heliga graal. Trots de fantastiska lovords som östs över boken har jag länge tvekat att läsa den eftersom den är så pass gammal för ett sådant snabbföränderligt område som programmering. Den utkom förvisso i en andra utgåva häromåret (Microsoft Press, 2004), men jag var osäker på om den verkligen skulle vara väsentligt uppdaterad. Denna farhåga verkar jag för övrigt vara långt i från ensam att hysa angående denna bok; kanske bidrar bokens sidantal (960 sidor) till att man inte gärna chansar.

Vad som ändå gjorde att jag slutligen läste boken var en kort, men initierad, användarrecension på Amazon.com som menade att andra utgåvan faktiskt är en rejält genom- och omarbetad sådan. Nu har jag inte möjlighet att jämföra med den första utgåvan (eftersom jag inte läst den), men jag kan däremot till fullo hålla med om att boken helt klart är mycket väl värd att läsa även i dag.

Code Complete har enligt McConnell själv tillkommit för att överbrygga klyftan mellan den kunskap om mjukvarukonstruktion som finns bland professorer och ”industry gurus” å ena sidan och vanliga kommersiella utövare å den andra. Han citerar vetenskapliga studier som menar att det tar mellan 5 och 15 år för kunskapen hos den förra gruppen att nå fram till den senare – Code Complete är tänkt som en genväg som gör denna kunskap tillgänglig för programmerare här och nu. Boken är också full av hänvisningar till vetenskapliga studier och undersökningar av alla de slag. Jag tycker detta är en av bokens styrkor: välkända programmeringsprinciper får här förklaringar och uppbackning i hårda data. Dessutom strör McConnell små guldkorn av forskningsresultat genom hela boken, t.ex. att ett idealiskt variabelnamn ligger på någonstans mellan 10-16, eller i alla fall 8-20, tecken.

Eftersom 50 till 65 procent av ett mjukvaruprojekt handlar om den aktivitet som kallas konstruktion och detta område trots detta är underrepresenterat i litteraturen har McConnell valt att låta detta ämne spela huvudrollen i Code Complete. Trots att detta syfte varit tydligt uttalat har en del av den kritik som ändå riktats mot boken gått ut på att den för ensidigt fokuserat på detta område. Jag tycker personligen absolut inte att det är en brist, men oavsett vad man tycker om detta kan man knappast undgå att imponeras av hur uttömmande McConnell lyckas beskriva ämnet för sin studie – en mer komplett bok om mjukvarukonstruktion och programmeringsmetodik är svår att föreställa sig om man vill att den ska vara heltäckande och samtidigt detaljrik.

På de drygt 860 sidor av boken som återstår sedan man räknat bort index och den omfattande bibliografin, kan man läsa om allt från generella principer och grundfilosofi för mjukvarukonstruktion till konkreta riktlinjer för hur man bäst skriver en for-loop; från integrationsstrategier och systematisk uppföljning av testning till hur du bör utforma dina kommentarer och var du bu bör placera blanka rader mellan kodblocken; från statistiska bevis för vikten av ordentligt utformade krav och för hur programstorlek påverkar konstruktion till personliga resonemang om mjukvarukonstruktion som ett hantverk snarare än en ingenjörskonst och om vilka egenskaper en programmerare bör besitta för att bli framstående inom sitt förvärv. Så länge det gäller konstruktion finns det kort sagt inget ämne som är för stort eller för litet för att McConnell ska behandla det och oavsett storlek behandlar han dem med stor omsorg och har alltid personliga erfarenheter, vetenskapliga studier eller välgrundade argument att bidra med för att förtydliga, bevisa och övertyga.

En kort genomgång av bokens beståndsdelar kan vara på sin plats. Code Complete är indelad i sju delar:

1. Laying the Foundation (ca 70 sidor)
De inledande kapitlen handlar om den grund som enligt McConnell måste vara på plats innan man kan börja med konstruktionen: framför allt problemformulering/vision, krav och arkitektur, men även val av programmeringsspråk, programmeringskonventioner/kodstandard och konstruktionspraxis (integrationsmetod, parprogrammering, obligatoriska enhetstester, verktyg för source control o.s.v.).

2. Creating High Quality Code (160 s.)
McConnell börjar med att slå fast det för resten av boken helt centrala “Software’s Primary Technical Imperative”: Managing Complexity. Med detta imperativ i bakhuvudet går han sedan igenom en rad välbekanta grundprinciper för mjukvarudesign, såsom enkelt, återanvändbart, löst kopplat, utbyggbart, lätt att förvalta. Från denna abstraktionsnivå fortsätter detaljerandet via klassiska byggstenar för design som ”real world objects”, abstraktion, inkapsling och arv, via designmönster ner till grunderna för klasser, riktlinjer för bra klassinterface och konstruktordesign. Slutligen landar vi i ett kapitel om rutiner; rutindesign, bra rutinnamn, hur lång en rutin får vara, hur rutinparametrar bör användas och vilken ordning de ska ha m.m. Ett kapitel om defensiv programmering (validering, felhantering, exceptions) och ett kapitel om Pseudocode Programming Process (PPP), lågnivådesign i form av pseudokod som sedan tjänar som kommentarer till koden, avslutar denna del av boken.

3. Variables (110 s.)
Här tar McConnell upp allt man behöver tänka på när det gäller variabler: hur och när de bäst initieras, hur länge de bör leva, hur ett bra namn ser ut beroende på typ och hur långt det ska vara, hur olika datatyper bör användas, när man ska använda arrays, varför man ska undvika globala variabler etcetera, etcetera.

4. Statements (110 s.)
Hur strukturerar du bäst dina koddeklarationer? I vilken ordning ska villkoren testas i if-satser med flera villkor? I case-satser? När bör du använda en while-loop och när passar en for-loop bättre? Hur och när ska loopens villkor kontrolleras? Hur får man lämna en loop? Hur och när använder man tabelldrivna metoder istället för komplicerade if-satser? När ska man använda parenteser? Ingenting får lämnas åt slumpen när det gäller att organisera och strukturera sin kod, enligt McConnell som här delger oss sina synpunkter på hur dessa och många andra liknande frågor bör besvaras. Avsnittet innehåller också ett referat av den klassiska debatten för och emot ”goto”.

5. Code Improvements (190 s.)
Denna del av boken handlar om hur man (fortfarande i konstruktionsfasen) kan förbättra kodens kvalitet genom utvecklartestning (och uppföljning av denna), ”collaborative construction” (parprogrammering, kodgranskning, kodinspektioner), debugging, refactoring och code-tuning. Särskilt avsnittet om ”collaborative construction” är intressant; även om jag läst en del XP-litteratur (eXtreme Programming) och därigenom tilltalats av parprogrammering, hade jag ingen aning om hur enig forskningen är om dessa teknikers (särskilt formella kodinspektioner) effektivitet när det gäller att kvalitetssäkra och undvika defekter i kod.

6. System Considerations (180 s.)
Programmets storlek, projektledning och projektmetod, integrationsmetod och utvecklingsverktyg är externa faktorer som i allra högsta grad påverkar konstruktionen. Här går McConnell igenom denna påverkan och kommer med förslag på hur man hanterar detta, t.ex. olika angreppssätt för integration, hur projektledare och ledning bör behandla utvecklare och hur ”managing your manager” ibland kan vara en nödvändighet.

7. Craftsmanship (130 s.)
Den avslutande delen av boken upptas till största delen av rekommendationer för layout, kodningsstil och hur man skriver självdokumenterande kod. Det handlar dels om vikten av gemensamma konventioner, dels om personliga åsikter i (ofta med en väl underbyggd argumentation så klart!) sådana gamla olösliga religiösa strider som på vilken rad den inledande måsvingen ska vara placerad. McConnell lyfter här också fram ett antal egenskaper han anser utmärker en god mjukvarukonstruktör (bl.a. ödmjukhet, nyfikenhet, intellektuell hederlighet, samarbetsvilja, kreativitet och disciplin). Bokens sista kapitel innehåller en rad tips på var man kan hitta mer information i såväl litteratur och tidskrifter som på nätet och genom användargrupper.

Varje kapitel avslutas med listor med titlar och korta beskrivningar av böcker som fördjupar sig i ämnet för kapitlet i fråga. I slutet av många kapitel finns också ämnesindelade checklistor som man kan använda för att testa sin design/kod/layout mot de principer kapitlet redogjort för.

För den som läst så här långt kommer det väl knappast som en överraskning att jag tycker att Code Complete är en mycket läsvärd bok. Faktum är att det kanske är en av de bästa, eller i alla fall för min vardag mest givande, böcker jag någonsin läst. Den har, om inte förändrat, i alla fall starkt påverkat det sätt jag vardagligen arbetar med och tänker på programmering. Väldigt många designprinciper och praktiska råd har jag kunnat tillämpa direkt i mitt dagliga kodningsarbete och för många saker jag ”alltid” tänkt på har jag nu fått en förklaring till varför jag gjort det och varför det är bra (jag har även fått veta att visa saker är dåliga och tvingats ändra mig ;-)). McConnells uppfordrande och auktoritativa tonläge har också inspirerat mig att ännu mer oförtrutet stå upp för genomtänkt design och noggrann kodning när deadlines kryper allt närmare och röster höjs för quick-and-dirty-lösningar som i slutändan ändå alltid straffar sig i form av fler defekter och svårare vidareutveckling och förvaltning.

Naturligtvis har boken även ett par svagheter. Bland annat kan detaljrikedomen vara kvävande för vissa med rad efter rad med resonemang om parentesers placeringar, olika förslag på förkortningsregler, parametrars ordningsföljd etc. Jag vill dock gärna tro att många programmerare, likt jag själv, är intresserade av sådana detaljer; de starka känslor en diskussion om måsvingens placering brukar kunna väcka tyder i alla fall på det.

Samtidigt som jag verkligen uppskattar all statistik och de flitiga citeringarna av vetenskapliga studierna är de också ett av bokens problem, om än ett mindre sådant. Ett antal hänvisningar är till studier utförda under tidigt 90-tal eller till och med 80- och 70-tal. Vid denna tid gav t.ex. utvecklingsmiljöerna inte utvecklaren samma stöd som i dag med färgkodning av syntax, automatisk komplettering av variabel- och typnamn m.m. Detta gör att en studie från 1990 om optimal längd på ett variabelnamn kanske inte äger samma värde som om den varit utförd på 2000-talet. Till McConnells försvar bör man dock tillägga att han, med goda skäl, är en stark förespråkare av kodgranskning, formella kodinspektioner och andra former av ”collaborative construction” där kodutskrifter förstås är av central betydelse.

Sammanfattningsvis är Code Complete en modern klassiker inom programmeringslitteraturen som innehåller mycket matnyttigt för såväl erfarna utvecklare som nybörjare, ja för alla som på allvar är intresserade av att bli en bättre programmerare eller mjukvarukpnstruktör. Jag kan varmt rekommendera boken och hoppas att den har en lika positiv och inspirerande effekt på ditt yrkesliv som den redan haft på mitt.