Da jeg i fjor hadde lyst å fordype meg i C#’s mer intrikate deler bestemte jeg meg for å kjøpe Bill Wagner’s More Effective C#: 50 Specific Ways to Improve your C#. Boken forsøker å vise hvordan man best kan utnytte det som var nyheter i C# 3.0 og .Net Framework 3.5: LINQ, Lambda-uttrykk, extension methods.., og hvordan dette kombineres best mulig med ting som generics, nullable types, m.m. Den inneholder også en del generelle design-tips, samt endel om multithreading.

Boken har mye bra innhold, men du bør ha jobbet litt med C# 3.0 før du leser den – er du helt fersk på Lambda vil stoffet trolig bli litt for vanskelig. Jeg måtte selv legge fra meg boken en tid, og eksperimentere i kode, før jeg kunne gå tilbake til den et par måneder senere.

Jeg lærte en håndfull svært interessante ting av More Effective C# – spesielt påpeker Wagner noen typiske feller man bør unngå – men boken inneholdt også enkelte råd jeg ikke var enig i. Det var ikke bortkastet tid å lese den, og den vil fungere som et greit oppslagsverk, men når alt kommer til alt tror jeg at jeg valgte feil bok.., Jon Skeets C# in Depth har fått veldig gode tilbakemeldinger, tilhører samme sjanger, og hadde jeg kunne valgt om igjen hadde jeg valgt den.

Om du likevel er interessert så har jeg funnet boken tilgjengelig online her: http://www.diranieh.com/NETCSharp/EffectiveCSMore.htm. Forord, copyrights og alle referanser til Bill Wagner er fjernet, men inneholdet er omtrent identisk med boken, så jeg antar dette er en ikke-lovlig publisering som utgir seg for å være orginal. Tar du en titt på innholdsfortegnelsen vil du få et ganske bra innblikk i hva boken vil gi deg. Virker det spennende foreslår jeg at du kjøper den lovlig :)

Michael C. Feathers’ Working Effectively with Legacy Code er en ikke direkte ukjent bok. Jeg leste den i sommer, som en slags forberedelse til å begynne i ny jobb. Den hjalp meg til å hoppe uredd og med stor iver inn en voksende kodebase med varierende kvalitet. For dem som ikke kjenner Michaels mesterverket fra før, her er en kort beskrivelse:

Uttrykket “Legacy Code” brukes i utgangspunktet om gammel kode, kode som man arver fra andre. Benevnelsen innebærer at det er vanskelig å forså hvordan koden fungerer, og det er vanskelig å gjøre endringer. Michael Fethers definisjon på Legacy Code er kode uten automatiserte tester, fordi slik kode nettopp er vanskelig å forstå og å endre. Kode med tester derimot vil gi deg øyeblikkelig tilbakemelding på om du har ødelagt noe, og om endringene du har gjor fungerer som forventet.

Working Effectively with Legacy Code handler i bunn og grunn kun om én ting; nemlig hvordan man får på plass automatiserte tester rundt kode som i utgangspunktet ikke er designet for det, slik at man kan jobbe videre med koden uten å være redd. Gjennom kapitler som I Don’t Have Much Time and I Have to Change It og I Don’t Understand the Code Well Enough to Change It lærer Michael oss pragmatiske og presise teknikker som gjør oss mere komfortable med å ta i “drittkode”.

Kapitler som I Can’t Get This Class into a Test Harness, med avsnitt som The Case of the Irritating Parameter og The Case of the Hidden Dependency er gull verdt, og åpner øynene dine for hvordan det som ser helt håpløst ut faktisk kan løses. Dette er en oppskriftsbok, med en lang liste teknikker Feathers har funnet effektive i sin praksis. Mange av teknikkene er fokusert rundt det å bryte avhengigheter, som for eksempel Break Out Method Object, Expose Static Method, Extract and Override Call, Extract Implementer, Pull Up Feature og Push Down Dependency.

Hvem som bør lese denne boken, og hvorfor..

Denne boken har gitt meg en helt ny holdning til “dårlig kode”. Kode som er vanskelig å endre og som ikke har enhetstester er ikke lenger noe jeg gruer meg til å ta i – jeg ser nå på det som en spennende utfordring. Jeg gleder meg til å sette tenna i metoder på over tusen linjer og ekstremt høy kompleksitet. Helt seriøst, denne boken har tatt noe av det jeg likte minst ved yrket mitt, og gjort det om til noe av det jeg liker mest!

Hvis du kun jobber i perfekte softwareprosjekter, med elegant kode og høy test coverage, så har du ikke bruk for Michaels bok.

Ikke særlig mange sliker jobber, er det vel?

Hvis du derimot er på et team som sliter med en stor og uregjerlig kodebase.., hvis dere har problemer med å få laget gode enhetstester – eller å komme i gang med automatisert testing i det hele tatt.., hvis dere ikke er fornøyd med kvaliteten på koden dere jobber med, og den er vanskelig å forstå.., ja, da er Working Effectively with Legacy Code et uvurderlig hjepemiddel som dere bare må lese med en eneste gang. Legg ned utviklingen et par-tre dager, det er det faktisk verdt om utviklerne lærer seg disse teknikkene og lar seg inspirere til å bruke dem.

Jeg hørte om nevrolingvistisk programmering (NLP) for første gang da vi var så heldige å få besøk av Dan North i Bergen i august 2008. Men NLP har ingen ting med å programmere datamaskiner å gjøre, her snakker vi om å programmere oss selv, om å endre vår egen adferd gjennom systematiske metoder som inkluderer aktiv bruk av sansene våre (nevro) og av språk (lingvistisk).

Det var Dan som anbefalte boken Thorsons WAY of NLP av Joseph O’Conner og Ian McDermott. Vi utviklere, eller i alle fall en del av oss, er flinke til å lese programmeringsbøker. Noen leser også bøker om smidig utvikling o.l., men flere burde lese bøker om personlig utvikling – vi burde lese bøker som forteller oss hvordan vi kan bli bedre mennesker, generelt flinkere og mere tilfreds. For den viktigste faktoren i utvikling av software er ikke verktøyene og teknikkene programmererne benytter, det er kvaliteten på menneskene som driver med det.

Jeg kjøpte boken for en knapp og litt lummerusk fra Amazon UK, og leste den nå i høst. Og det er jeg veldig glad for at jeg gjorde – den er veldig lærerik. NLP er moderne og praktisk anvendelig psykologi i en form som gir fullstendig mening for en realist som meg selv. Mye av det virker faktisk opplagt etter å ha lest det – om hvordan vi tenker og hvorfor vi gjør det – men det er ting som vi desverre ikke er oppmerksomme på til vanlig.

“The starting-point of NLP is curiosity and fascination about people. It is the study of the structure of subjective experience. How do we do what we do? How do we think? How do we learn? How do we get angry? And how do outstanding people in any field get their results?”

Jeg vet at om jeg tar dette jeg nå har lest om seriøst, og jobber litt med det og med meg selv, så vil det kunne forvandle måten jeg forholder meg til verden på. Jeg vil kunne mestre ting jeg i dag ikke våger, jeg vil kunne gjøre det jeg vet er riktig, selv under tidspress eller i andre, svake øyeblikk. Jeg vil kunne lære å motivere meg selv og andre enda mere, utnytte tiden, kommunisere bedre, og rett og slett oppnå bedre resultater.

Ja, det høres fantastisk ut, ikke sant? Omtrent som de epostene spamfilteret ditt normalt hjelper deg å unngå. NLP er ikke pensum på psykologilinja, og tilhører i stedet “life coaching”-kategorien. Det er f.eks. mangle likheter mellom NLP og det man lærer på the Lightning Process-kursene man har hørt så mye om den siste tiden, hvor ME-pasienter som har vært kasteballer i helsevesenet i årevis blir “kurert” på et par dager.

Men måten man ser på mennesket i NLP er mektig – gjennom språk og kropp kan man påvirke ens egne tankemønstre og ubevisste handlinger. Thorsons WAY of NLP er både en billig og relativt tynn bok, så du taper ikke så mye på å gi det en sjanse. Tar du utfordringen?

Jeg skal i alle fall jobbe videre med dette, og det vil nok også komme et par NLP-inspirerte blogposter etterhvert.

Les gjerne mer om NLP på Wikipedia.

Robert C. Martins Clean Code: A Handbook of Agile Software Craftsmanship er en viktig og spennende bok. Mange mener mye om hva ren kode er for noe, men det har vært vanskelig å finne konkrete og komplette kilder. Her har Uncle Bob samlet og forklart motivasjonen bak et godt sett med regler for hvordan man skriver kode med høy kvalitet i de små detaljene.

Så hvorfor skal vi skrive ren kode? Er det ikke nok at programvaren gjør det den skal? Jo, kanskje, hvis det er 100% bugfritt, og aldri skal endres på noen som helst måte. Og hvor sansynlig er det? Ufattelig mye energi brukes på å forstå og navigere i dårlig skrevet kode, og utviklingsteam som jobber i slike systemer er langt fra så effektive som de kunne ha vært. Ren kode kan endre dette ganske drastisk.

Boken har tre deler: Første del beskriver prinsipper og praksiser for å skrive kode som kommuniserer godt, og argumenterer for hvorfor en profesjonell utvikler skriver ren kode. Andre del inneholder en rekke studier av eksisterende kode, som Uncle Bob fikser på for å gjøre den bedre. Og siste del er mer eller mindre en liste over “regler” som ren kode ifølge forfatteren skal følge.

Clean Code er en bok som fungerer både for ferske og erfarne utviklere. Folk med flere års erfaring vil tenke at de kjenner alle disse prinsippene fra før, men min erfaring tilsier at de fleset av oss ikke følger så mange av dem likevel. Alle har godt av å minnes på hva ren kode er for noe, og hvor viktig det er – og tradisjonelt har det vært alt for lite fokus på dette i bransjen. Får du hele teamet ditt til å lese boken, og så følge prinsippene i den, vil kvaliteten på det dere produserer garantert øke, noe dere vil nyte godt av i hele levetiden til produktet/produktene.

Uncle Bob advarer at boken er krevende, men jeg synes i grunnen den var ganske lettlest. Den inneholder ganske mye kode, men det leser vi jo hver dag likevel. Han har derimot rett i at det vil kreve noe av deg å lære deg å følge prinsippene i boken – det holder ikke bare å lese den, for så å gjøre som du vanligvis gjør. Du må øve på disse tingene, og praktisere dem hver dag.

Boken vil ikke lære deg alt det du trenger for å lage bra software – langt der i fra – men er en fin liten byggekloss på veien til å bli en Drivende Dyktig Utvikler. Jeg ble litt skuffet over noen av de refaktureringene Bob gjorde i del 2, jeg tror koden kunne ha blitt enda renere. Men jeg anbefaler gjerne denne boken likevel!

PS: Kodeekksemplene i boken er hentet fra Java, men det bør ikke være noe problem for en seriøs utvikler, samme hvilket språk du jobber i til vanlig – og spesielt ikke om du er en C#-utvikler som meg. Prinsippene Uncle Bob presenterer er universelle.

Knagger: Agile, Craftsmanship, Java, Robert C. Martin

Robert C. Martin’s Agile Principles, Patterns, and Practices in C# er DEN BESTE programmeringsboken jeg noen gang har lest!!!

Det er ikke så ofte man kan begynne en blogpost med en setning som det der, og bruke både all-CAPS og tre utropstegn uten å få en flau smak i munnen. Men denne boken fortjener det virkelig. Den gir deg både lyst og kunnskapen du behøver for å omforme deg selv til en ideell, smidig systemutvikler.

Boken er full av anekdoter som virkelig får deg til å fortså hva som er galt med mange prosesser i dag, og hva som kan gjøres bedre. Og den utgjør bortimot et komplett sett med teknologi-uavhengig kunnskap om hvordan du skal gå fra en diffus problemstilling til et fungerende produkt.

Section I: Agile development

Den første delen av boken handler om smidig utvikling. Bob presenterer hovedtrekkene i eXtreme Programming, og går spesielt i dybden på planlgging, testing og refakturering. Han presenterer også en veldig bra historie som viser hvordan parprogrammering kan fungere i praksis:

“In order to demonstrate XP practices, Bob Koss and Bob Martin will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob’s actually did.”

Historien er også tilgjengelig online, riktignok implementert med Java-kode – du kan lese den her.

Section II: Agile design

Her begynner boken virkelig å ta av. Bob snakker først om hvorfor design “rotner” over tid, og bruker resten av del 2 til å forklare hvordan man skal unngå at dette skjer. Han går i dybden på en rekke prinsipper innen objektorientert design, de såkalte SOLID prinsippene, og selv om jeg hadde hørt og lest en god del om dem fra før var det først med denne boken at jeg virkelig begynte å forstå.

Han forklarer hvorfor prinsippene er viktige, hvordan man skal kode for å innfri dem, og ikke minst hvilken tradeoff det innebærer å følge dem. Dette siste inpirerte meg til å skrive en liten blogpost jeg kalte når skal man følge SOLID prinsippene.

Bob bruker også mye av del 2 til å snakke om UML, og bruk av design-diagrammer innenfor smidig utvikling. Mange er av den oppfatning at modellering er noe man ikke skal gjøre når man er agile, men det kan være både feil og farlig. Bob lærer deg all den UML’en som er nødvendig for en smidig utvikler, og mener mye om hvordan man skal bruke dette “verktøyet”.

Section III: The Payroll case study

I del 3 demonstrerer Bob hvordan man går fra noen diffuse krav til et komplett program. Han bruker TDD, og viser deg all koden han produserer – inkludert testene. Han forteller grundig hvordan han tenker, og vi får se hvordan han følger OO-prinsippene og hvordan koden utvikler seg over tid.

I denne delen presenteres et hav av design patterns / mønstre, den mest forståelige forklaringen av design patterns jeg har vært borti faktisk, og vi lærer hvordan de brukes for å tilfredstille de grunnleggende prinsipene. Med fare for at den som leser boken blir pattern happy lærer han bort Command, Template Method, Strategy, Adapter, Monostate, Null object, Visitor, Decorator, Gateway, Proxy, State, osv., osv.

Denne delen av boken inspirerte meg til å skrive om hvordan man bryter avhengigheter mellom klasser, hvor jeg benyttet Strategy og Adapter.

Section IV: Packaging the Payroll System

I del 4 fortsetter man med applikasjonen fra del 3. Bob forteller oss om hvordan man bryter opp et prosjekt i moduler basert på Cohesion og Coupling. Han presenterer flere prinsipper, og patterns for å understøtte disse prinsippene. Og han fortsetter å presentere enhetstester og kode.

Denne delen inpirerte meg til å kode og blogge om hvordan man kan bruke en tilstandsmaskin til å gjøre kode mer presis og fleksibel: En generisk state machine i C#.

Mot slutten implementerer han også et grafisk brukergrensesnitt, og bruker da WinForms og Model View Presenter-mønsteret (MVP). Dette er det grundigste og mest forståelige eksempelet på MVP jeg noen gang har sett.

Det kan tenkes at jeg leste denne boken på akkurat det riktige tidspunktet i min egen utvikling, og at den ikke vil passe like godt for alle. Jeg tør likevel å anbefale den på det sterkeste til alle utviklere som ikke allerede praktiserer best practices innen smidig utvikling (TDD, parprogrammering, etc.) og som ikke allerede er guruer innen objektorientert design og vedlikeholdbar kode.

Andre Uncle Bob-relaterte blogposter: En karriære innen programmering | For mange utviklere som ikke bryr seg

Object Thinking er en bok skrevet av forfatter Dr. David West i 2004. Den er overraskende nok utgitt av Microsoft, men hører egentlig hjemme i eXtreme programming / Domain-Driven Design / Smalltalk-universet, og har potensiale til å totalt endre ditt syn på softwareutvikling.

Dette er en historiebok om utviklingen innen programmeringsspråk. Det er også en politisk diskusjon, og ikke minst et filosofisk studie av hva programmering er, og hvordan det bør gjøres. Hovedtemaet er objektorientering, og forfatteren hevder at på tross av at mange sier at de driver med OO, så gjør de langt fra akkurat det. Han sier at vi har misforstått, eller eventuelt glemt, bakgrunnen for objektorientering. For å få til alt det som OO gjør tilgjengelig for oss så må vi tenke objekter på den riktige måten.

Nesten med en gang jeg startet å lese merket jeg at boken provoserte meg. Den grep tak i noen av mine fundamentale oppfatninger – ikke bare rundt programmering, men i verden generelt – og snudde dem på hodet. Og så merket jeg hvordan teksten begynte å forandre mine egne meninger…!

Det var faktisk ganske skummelt. Men også veldig spennende. Noe av det mest besynderlige var hvordan han klarte å introdusere meg til smidig utviklingsfilosofi på en helt ny måte. Han presenterer en lang avhandling om den skarpe kontrasten mellom Formalisme og Hermeneutikk.

Formalisme er sterkt knyttet til rasjonalisme, et mekanisk og deterministisk verdensbilde. Her følge man formelle metoder og teknikker. Hermeneutikk i den motsatte enden av skalaen er et ikke-deterministisk verdensbilde, og i følge Dr. West i samsvar med ting som eXtreme programming og objekt-tenking. TDD er for eksempel et glimrende eksempel på ikke-formalisme. TDD er en praktisk metode som det viser seg kan gi et veldig bra resultat, uten at det kan bevises rasjonelt.

Desverre, sier han, er det få XP/agile-praktikanter som er klar over dette filosofiske skillet. Og han har helt rett; selv har jeg blitt presentert smidig utvikling i veldig formelle rammer, og det er først nå, etter å ha lest Object Thinking, at jeg begynner å forstå det jeg tidligere bare glimtvis har sett – at smidig utvikling helt grunnleggende er en annen filosofi enn det som råder i softwarebransjen i dag.

Ken Auer sier det slik:

“Too many software professionals who use object-oriented tools aren’t object thinkers. Every developer Dave West reaches with this book takes us a step closer to improving software – and the industry.”

Jeg merker at det er vanskelig, eller snarere umulig, å formidle denne oppdagelsen på en god måte. Jeg tror dette er en oppdagelse hver og en må gjøre i sitt eget tempo. La meg i stedet fortelle litt mer om boken..

Objekt-tenking går rett og slett ut på å tenke som et objekt. Tradisjonelle utviklere tenker som datamaskiner. De konsentrerer seg om den tekniske løsningen, om implementasjon. OO-programmerere må lære seg å tenke mer som objekter – vi må tenke på problemet, og modellere det i stedet.

Nøkkelordet fra boken for meg er Behaviour – adferd! Vi må designe programvaren vår rundt objekter, som igjen er definert i form av adferd. Dette i sterk kontrast til den data-sentriske modelleringen de fleste normalt bedriver. Rockford Lhotka, utvikleren bak CSLA.NET, anbefaler også Object Thinking, og sier det på denne måten:

“To me that’s the value in West’s book. The philosophy of each object having a single, clear responsibility. Of objects collaborating with other objects to perform complex tasks, without being complex themselves.”

Den andre delen av boken..

Object Thinking har også en praktisk del. Mens den første halvdelen fokuserer på historie, filosofi, og hvordan man skal tenke, presenterer Dr. West i den andre halvdelen en del teknikker – modelleringsteknikker – som er i samsvar med objekt-tenking. Dette falt ikke så godt i smak for meg. Jeg vil foreslå at man hopper over noen av de mest praktiske delene, og i stedet leser noe sånt som Agile Principles, Patterns, and Practices in C# av Robert C. Martin, som har en litt annen tilnærming som er mer kjent for meg, men som fortsatt er i samsvar med det Dr. West sier.

Til slutt et par linker: Boken kan du selvsagt få tak i hos Amazon. Det finnes også et intervju med Dr. West på PolymorphicPodcast.

Knagger: Agile, DDD, eXtreme programming, Objektorientering, Smidig

Kent Beck er en legende innen smidig softwareutvikling: Han er opphavsmannen til Extreme Programming (XP). Han var en av 17 personer som utformet og signerte the Agile Manifesto. Sammen med Ward Cunningham gjorde han CRC-kort populært, og han lagde testrammeverket JUnit sammen med Erich Gamma. Og han er en av de mest sentrale personene innen testdreven utvikling (TDD).

Kent har skrevet mange bøker, og en av dem er Test-Driven Development: By Example, utgitt i 2002.

Denne boken har et uvanlig format. Den er delt inn i tre deler, og i stedet for å fortelle om TDD og argumentere for hvorfor det er en bra teknikk, så tar forfatteren deg i de to første delene av boken med på et par programmeringsøkter. Hver del har rett og slett et problem som skal løses, og Kent koder og forklarer underveis hva han tenker og hvordan han går frem.

I den første delen implementerer han penger som støtter flere valuta, og han bruker Java som programmeringspråk (Java er så likt C# at det er lett å ta feil av og til). Målet er å illustrere rytmen i testdreven utvikling.

Og i den andre delen skrur Kent opp vanskelighetsgraden et par hakk og implementerer faktisk et rammeverk for enhetstesting. Han lærer oss altså om slike rammeverk gjennom å implementere det, og han bruker testdreven utvikling for å gjøre det. Han tester faktisk koden sin med rammeverket som han koder, hvilket jo er ganske snedig. Han gjør dette eksempelet i programmeringspråket Phython – og selv om du ikke har noen erfaring med det språket så klarer du å henge med, for han forklarer det du trenger underveis.

Etter å ha lest de to første tredjedelene av boken føler du at du har fått bra tak på TDD. Og da går Kent endelig over til å ”snakke” litt også. Del tre handler om patterns i TDD, dvs en litt mer formell forklaring av hvordan man går frem, og hva som er viktig å tenke på. Han går også inn på enkelte design-patterns og refaktureringsteknikker – refakturering er tross alt en meget sentral del av testdrevet utvikling.

Det aller siste kapittelet handler om å mestre TDD. Her stiller han en del spørsmål som får leseren til å tenke. Av og til hinter han til hva svaret kan være, andre ganger lar han spørsmålet henge der. Han knytter også TDD opp mot Extreme Programming, men boken snakker generelt lite om dette.

Jeg har gjort noe TDD fra tid til annen, men er langt fra erfaren – og Test-Driven Development: By Example gav meg mye god kunnskap og forståelse – både om hvorfor TDD fungerer, og hva jeg har gjort “galt” i min egen praktisering. Å lese boken er ingen erstatning for å øve, øve, øve – for det er kun slik man kan lære det orntlig. Men den fungerer ypperlig som en introduksjon og inspirasjon til testdreven utvikling for utviklere som allerede har noen års erfaring og som er interessert i TDD, men enten aldri har forsøkt det selv eller ikke helt har fått det til.

Du kan se en smakebit av boken på Google Books om du vil. Og hvis du allerede har lest den, eller en annen god bok om TDD, er det veldig kjekt om du legger igjen en liten kommentar.

Knagger: TDD, Kent Beck, Agile, Smidig, Patterns, Refakturering, Enhetstest

De siste par månedene har jeg lest Code Complete (Second Edition). Håndboken i “konstruksjon av software” skrevet av Steve McConnell er meget populær, og mange har skrytt mye av dem. Code Complete er f.eks. den første på Jeff Atwoods liste over anbefalte bøker for utviklere. Jeff sier:

“Do yourself a favor. Make this the first book you read, and the first book you recommend to your fellow developers.”

Boken gav meg mye, men jeg skulle ha lest den noen år tidligere i min karriære. Den gav meg ikke så mye nå som den ville ha gjort for 6-7 år siden.., men den var likevel inpirerende, og dekker veldig mange ulike deler av det å være en utvikler. Den er også ganske nøytral i forhold til ting som Agile og TDD – den baserer seg på 40 års erfaring fra software-bransjen, og poengterer at ulike metoder passer for ulike prosjekter, at det ikke finnes én sannhet som passer for alt.

Part I og II handler mye om det å forstå software-faget, og om å gjøre et godt design-arbeid før man begynner å kode. Dette var inspirerende, og fikk meg til å se at vi gjør alt for lite av dette nå som vi har blitt så smidige. Selv om man tillater endringer er det mye godt som kan komme ut av fornuftig designarbeid.

De to neste delene handler om kvalitet på det laveste nivået i kode. Part III inneholder 110 sider dedikert til bruk av variabler: Om viktigheten av varabelnavn, om ulike datatyper, osv. PART IV handler om statements: Hvordan kode organiseres, bruk av if og switch .. case, bruk av looper, andre kontroll-strukturer, tabelldreven logikk/metoder m.m.

Part V handlet om forbedring av kode, og her var det mye bra. Forfatteren snakket om hva kvalitet er for noe, og hvorfor vi trenger det. Det handlet om testing, om debugging, code-tuning, og sist men ikke minst refakturering – boken har en meget god liste over refaktureringsteknikker.

Part VI har tittelen “System Considerations”, og handler bl.a. om ting som hvordan størrelse påvirker ulike aspekter under utvikling, om endringshåndtering, om team-arbeid, og om estimering og måling. Det var også et kapittel om hvordan man som utvikler skal administrere sin manager – dette var veldig morsomt. Videre er det kapitler om integrasjon og om ulike verktøy for utviklere.

Part VII, den siste delen, handler om Software Craftmanship. Her tar forfatteren oss ett hakk videre opp på kvalitets-stigen og snakker om layout, kodestil og selvdokumenterende kode. Han snakker om hvilke egenskaper som gjør en utvikler dyktig (som inspirerte meg til å skrive om en utviklers karakter), og om en rekke andre “craftmanship-tema”.

Code Complete er veldig grundig, og refererer veldig mye til andre, kjente publikasjoner, og til undersøkelser og forskning som underbygger forfatterens påstander. Du finner for eksempel konkrete tall som forteller hvor mye du kan tjene på å bruke teknikker som code reviews og parprogrammering. Deler av boken var mindre interessante fordi jeg allerede har mye erfaring, men jeg leste likevel alt, for innimellom kom det alltid noen gullkorn det er verdt å ta med seg. Andre deler av boken var helt uforglemmelige, og gav meg et nytt perspektiv på utviklingsprosessen. Code Complete anbefales derfor på det varmeste.

Knagger: Code+Complete