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

Det er snart et år siden Dan North var i Bergen og snakket om Behaviour-Driven Development (BDD) – et besøk jeg bl.a. dokumenterte i the Contiki Strip #5. Det var et utrolig inspirerende møte, og Given-When-Then spesifikasjonformatet var noe vi prøvde å jobbe med i tiden etterpå. Men siden vi ikke hadde kommet orntlig igang med å skrive enhetstester, og var langt fra å praktisere TDD, glemte vi det raskt ut, og alt forble ved det gamle.

Nå som jeg har jobbet mer med testdreven utvikling er det på tide å ta dette opp igjen. Jeg vil derfor presentere hvordan man kan gå fra “vanlige” unit-tester til å implementere kjørbare spesifikasjoner (the BDD way), og snakke litt om hvilke fordeler dette gir oss.

Ta f.eks. denne enhetstesten, hentet fra Robert C. Martins bok Agile Principles, Patterns, and Practices in C#:

Denne koden har utstract bruk av COMMAND pattern. Testen oppretter først en Employee i databasen (line 5-7), og bekrefter at den ble opprettet (line 9-10). Deretter sender den en slette-komando (linje 11-12) og verifiserer at den nå ikke finnes i databasen lengre (linje 14-15). En helt normal enhetstest etter min mening.

Den uttrykker derimot ikke så mye om intensjonen bak testen – man må lese koden for å forstå hva som skjer, og strukturen er helt og holdent opp til utvikleren. En bedre måte å gjøre dette på er å sette opp et Given-When-Then-senario: Gitt at vi har en kunde, Når vi ber om å få den slettet, Så finnes den ikke lengre i databasen.

Implementert vha. TinyBDD, et rammeverkt for å lage BDD-spesifikasjoner under utvikling av Gjøran Hansen, forvandles enhetstesten til noe sånn som dette:

Om du ikke er vandt med lambda-uttrykk i C# er dette sikkert ganske gresk, men gi det en sjanse likevel. I linje 6 opprettes et nytt senarie. Så på linje 9 sier vi at hvis (Given) en bestemt Employee existerer, og (på linje 12) han finnes i databasen, når (When) man da eksekverer en slette-kommando (linje 15), så (Then) vil Employee’en ikke lenger finnes i basen (linje 18).

Lambda-uttrykkene på linje 10, 13, 16 og 19 utfører og/eller tester det vi har spesifisert i kallene til Given, When og Then. Og sammenligner du med den originale testen så ser du at de egentlig gjør akkurat det samme.

Forskjellen er at BDD-spesifikasjonen beskriver/dokumenterer i klartekst hva situasjonen er og hvilken adferd vi er ute etter. Og spesifikasjonen er så nær koden at det ikke vil være noe problem å holde dem og koden synkronisert om den skulle endres. Den er relativt oversiktelig, og følger et fast mønster.

Og den virkelige gevinsten oppdager du når du innser at disse spesifikasjonene kan skrives av eller i sammarbeid med testere, product owners og til og med kunden selv. Spranget fra kundens eller produktets krav til selve koden blir minimal. Utvikleren og kunden kan f.eks. sitte sammen og skrive spesifikasjonen rett inn i en .cs-fil.

Når spesifikasjonene er definert kan man så kjøre dem underveis i prosjektet, og ta ut rapporter som i klartekst beskriver senariene, og hvilke av dem som er ferdig implementert, hvilke som gjenstår, og eventuelt hvilke som feiler (TinyBDD støtter ikke dette enda såvidt meg bekjent).

BDD er mye mer enn det jeg har vist her. For en praktisk introduksjon til et annet BDD rammeverk som heter MSpec anbefaler jeg at du tar en titt på Rob Conery’s screencast om BDD – meget inspirerende. Og for mer informasjon om BDD generelt er behaviour-driven.org en bra ressurs. Det har vært mye forvirring rundt testdreven utvikling, og BDD gir en litt annen vinkling på problemet, og et sterkere fokus på adferd, noe som vil kunne øke kvaliteten på programvaren du produserer.

Knagger: BDD, Contiki, Dan North, TDD

Jeg leste nettopp en liten blogpost av Ron Jeffries hvor han sier at “story cost does matter”. Det er tydeligvis ikke mulig å kommentere på xprogramming-bloggen uten å være medlem, så da lager jeg min egen lille blogpost om temaet.

Poenget er at noen har foreslått at man ikke skal ta høyde for kostnad når man prioriterer historiene i backloggen. I stedet skal man bare se på verdi. Slik planlegging uten estimater kalles naked planning. Jeffries sier:

“Suppose without loss of generality that your highest value stories have value 100. Suppose that stories vary in cost between 1 and 3. And uppose we have time to do 30 points of work.”

“We can do 10 3-point stories and get value 1000. Or we can do 30 1-point stories and get value 3000. 3000 would be more. Story cost does matter.”

Dette angrepet er nokså naivt – det virker som om Ron har gått glipp av hele poenget. Saken er nemlig den at de ligger en skjult verdi i de oppgavene som har høy kostnad. Funksjonalitet med høy kostnad og høy verdi er langtidsinnvesteringer, og det er dem som vil skille deg fra dine konkurrenter. Ting som er raskt å implementere kan hvem som helst kopiere i løpet av kort tid, og vil ikke gjøre ditt produkt eller din løsning unik.

Problemet med estimater – i tillegg til den enorme usikkerheten og unøyaktigheten – er at de vil få deg til å favorisere korttidsinvesteringer fremfor langtidsinvesteringer. Du vil gjøre akkurat som Ron gjør – fokusere på at 3000 er et høyere tall enn 1000. Jeg er derimot overbevist om at det er viktig å fordele innsatsen gjevnt mellom oppgaver med lav kostnad og oppgaver med høy kostnad.., det vil man tjene på over tid. Og tanken er at om man ser helt bort fra estimater når man planlegger, så vil denne fordelingen skje helt naturlig.

Til slutt kommer Ron med et spørsmål til leseren:

“Suppose that, like most organizations, you don’t really know much about the value of your stories. Should you do high-cost ones, low-cost ones, or what?”

Hvabehager? Hvis du ikke vet noe om verdien bør du ikke gjøre noen av dem i det hele tatt!!! Du bør istedet finne ut hvilke stories som har verdi. Om du ikke vet noe om verdien så famler du rundt i blinde, og da spiller det liten rolle om kostnaden er høy eller lav.

I går hadde NNUG i Bergen besøk av Mary Poppendieck, og hennes mann Tom. Mary er kanskje den aller fremste foreleseren innen Lean softwareutvikling. Jeg må innrømme at jeg ble ganske engasjert av det hun hadde å fortelle. Gang på gang satte hun fingen på akkurat hva som er problemet for veldig mange softwareteam – jeg kjente meg i alle fall igjen i det aller meste. Her var det mye å ta tak i, og jeg vil anbefale alle som er interessert i mer effektivitet, mer fornøyde ansatte, og høyere verdiskapning å dra på et av Mary’s Lean kurs (som hun holder ved gjevne mellomrom i Oslo).

Vi hadde rundt 65 påmeldte til arrangemanget, og jeg tror de fleste delte min oppfatning av kvelden. Ta f.eks. oyvindfanebusts kommentar på Twitter:

“Back from tonights #nnug meeting with Mary Poppendiek on Lean. Possibly the best nnug session I have been to!”

Du finner Mary online på http://www.poppendieck.com/.

SOLID er benevnelsen på fem prisnipper innenfor objektorientert softwaredesign som vi har hørt mye om i løpet av den siste tiden. Blant annet holdt Mark Nijhof et innlegg på NNUG Bergen om SOLID i januar i år. Foredraget finnes også i blogpost-format her.

Siden det foredraget har jeg forsøkt å lære meg disse prinsippene, og brukt dem etter beste evne. Akkurat nå leser jeg Robert C. Martin’s Agile Prinsiples, Patterns, and Practices in C#, og da går det plutselig opp for meg at selv om mange har forsøkt å lære meg prinsippene, så er det ingen som sålangt har fortalt meg hvordan man skal bruke dem.

I boken sier Onkel Bob Martin at man skal bruke prinsippene når de trengs. Unødvendig bruk fører bare til unøvdendig kompleksitet. Jeg føler dette er et viktig poeng å få frem.

Ta for eksempel Single Responsibility Prinsiple (SRP). Dette prinsippet sier at en klasse kun skal ha ett ansvar, og ansvar defineres som én grunn til å endres. Men en grunn til å endres er kun en grunn til å endres om den endringen faktisk inntreffer. Onkel Bob sier at det er ikke lurt å innføre SRP – eller noe annet OO-prinsipp for den saks skyld – uten at man har symtomer som kan løses med prinsippet.

Dvs. at man ikke splitter opp en klasse i flere klasser basert på ansvarsområder før man får behov for å endre klassen. Når endringen kommer, og endringen kun gjelder for ett av ansvarsområdene, kan man bruke SRP og splitte ut det ansvarsområdet som endres til en ny klasse.

“Agile teams apply principles only to solve smells; they don’t apply principles when there are no smells. It would be a mistake to unconditionally confirm to a principle just because it is a principle. The principles are there to help us eliminate bad smells. They are not a perfume to be liberally scattered all over the system. Over-confirmance to the principles leads to the design smell of needless complexity.”

Knagger: Agile, SOLID, Robert C.+Martin, Pattern

En person som ønsker å bli en virkelig god programmerer må lære seg mye forskjellig. Jeg deler alle de ulike ferdighetene en må ha inn i fire kategorier. I denne artikkelen beskriver jeg disse kategoriene, og snakker litt om hvordan man kan bruke denne grupperingen til å diskutere ulike utviklerprofiler, og hvordan man bør fokusere sin egen utvikling.

Klikk på bildet for full størrelse

Kategori 1: Problemløsning

Tankekartet over forsøker å vise hvordan jeg tenker når jeg grupperer de ulike ferdighetene gode programmerere må ha. Den første kategorien er det man kan kalle generell programmeringskunnskap. Dette er blant annet det man fokuserer på under informatikk-utdannelsen på Universitetet (som er den utdanningen jeg kjenner til). Man må lære seg å bli en dyktig problemløser, lære teknikker man kan bruke mer eller mindre uavhengig av hvilken teknologi man benytter. Man må kunne bryte ned problemer, modellere, se mønstre, og sette kompleksitet i system.

Dette har mye med intelligens å gjøre, men ikke bare intelligens slik man tenker på det i tradisjonell sammenheng. Kreativitet og evnen til å “tenke utenfor boksen” er ting man kan trene opp. Gjennom å kultivere en evig nysgjerrighet på hvordan ting fungerer vil man etterhvert bli flinkere å flinkere til å se løsninger på problemene man møter som utvikler.

Kategori 2: Teknologi

Den neste kategorien omfatter alt man må lære seg for å beherske de spesielle teknologiene man behøver for å programmere. Dette er det mindre fokus på i Univeristetsutdannelsen – sansynligvis noe mer på høyskolene. En som ønsker å være en dyktig programmerer på f.eks. Microsoft .net plattformen har et hav av ting han må lære seg.

Kategori 3: Forretningsforståelse

For å bli en komplett utvikler må man også erværve seg forståelse for forretningsdomenet man jobber i. Det holder normalt ikke at noen andre utarbeider spesifikasjonen, og du som programmerer bare koder. En dyktig utvikler har forståelse for problemet som skal løses, og kan ta avgjørelser til beste for bedriften og sluttbrukerne.

Dessverre er dette et område mange utviklere er lite opptatt av. På den annen side finnes det mange utviklere som først og fremst har god domenekunnskap, og heller liten generell programmeringsbakrunn. De kan gjøre det like bra som utviklere innenfor sitt domene, fordi de kan levere det forretningen virkelig trenger.

Forretningsforståelse kommer først og fremst gjennom erfaring. Ved å jobbe lenge i et bestemt domene får man bedre forståelse for problemene og de potensielle løsningene som finnes. Og gjennom å erfare mange, ulike forretningsområder – slik som konsulenter som hyppig bytter oppdragsgiver får oppleve – kan man dra erfaring basert på likheter og ulikheter i de forskjellige områdene, og dermed få en bedre og bredere forståelse.

Kategori 4: Praktisk utvikling

Den siste kategorien omfatter en rekke andre ferdigheter som er viktig for at du som utvikler skal kunne bidra til å levere programvare av høy kvalitet. Software utvikles best gjennom sammarbeid i et team, og en utvikler må derfor kunne kommunisere med sine team-kamerater, og forstå betydningen av de ulike rollene som inngår der. For at det skal gå bra må utvikleren ha noen bestemte sosiale ferdigheter. Disse blir som regel sett på som utviklerens personlighetstype – noe man har fått med seg under oppveksten eller gjennom arv – og alt for lite blir desverre gjort for å trene på disse ferdighetene.

Man må også lære seg hvilke prosesser og metoder som fungerere til ulike ting. Det kan være formelle software engineering metoder, eller mindre formelle teknikker, slike som praktiseres i smidig utvikling. Teknikker som testdrevent design begrenser f.eks. behovet for modellering og kommunikasjon av spesifikasjoner i teamet, og er gunstig i mange prosjekter.

Det finnes mange kurs og mye litteratur, men det er egentlig kun erfaring som teller på dette området. Man lærer gjennom å sammarbeide, aller helst med dem som allerede har mer erfaring enn deg selv.

Utviklerprofiler

Alle de fire kategoriene jeg har beskrevet er viktige for å skape en komplett utvikler. Men som sakt får de forskjellige ferdighetene ulikt fokus hos programmerere. Jeg har eksperimentert med å sette opp ulike profiler, noe man kan gjøre blant annet for å bli klar over hva man bør bli bedre på.

I bildet over har jeg skissert en helt fersk juniorutvikler og en mer erfaren konsulent. Junioren har gått på Universitetet og lært mye om problemløsning, generelle algoritmer og datastrukturer osv., og skårer derfor relativt bra på den første søylen. Han har derimot begrenset erfaring med konkrete teknologi, noe han raskt må rette på når han blir kastet ut i arbeidslivet. Normalt har han også lite eller ingen forretningsforståelse, men han har tatt kurs i modellering, og en iterativ og inkrementell utviklingsprosess, så han har i alle fall litt balast på det området.

Seniorkonsulenten har vært på mange oppdrag, og har måttet lære seg en rekke teknologier nokså grundig, og gjennom flere år har han også blitt en dyktig problemløser. Oppdragene har gitt ham grunnleggende og bred forretningsforståelse, og gjennom å ha måttet sammarbeide med en rekke mennesker har han blitt en pragmatisk utvikler som vet en god del om hva som må til for å få et team til å fungere, slik at man kan levere det man skal til riktig tid og med riktig kvalitet.

Når man ser på dette og tenker seg om, er det ganske skremmende hvordan man tar inn ferske utviklere fra skolebenken og setter dem til å produsere fra dag en – ofte uten særlig gjennomgang av koden de leverer. Utviklere som mangler ferdigheter innen teknologi vil bruke unødvendig lang tid og levere lav kvalitet. Utviklere som mangler forretningsforståelse vil ikke kunne levere det brukerne trenger. Utviklere som mangler praktiske ferdigheter vil redusere hele teamets evne til å levere om de ikke får riktig oppfølging. Likevel hører mentor-programmer og intern skolering til sjeldenhetene i norske bedrifter. Det er viktig at arbeidsgivere forstår, og også at mer erfarne utviklere husker, at en nyutdannet informatiker eller IT-ingeniør ikke er en ferdigutdannet utvikler. Det krever også praktisk erfaring.

I de siste to grafene har jeg satt opp to profiler som jeg mener er idealer blant dagens utviklere. Den førset viser en erfaren utvikler som gjerne liker å kalle seg en software-ingeniør. Han har stort fokus på den teknologiske plattformen, og noe mindre på generelle problemløsningsteknikker. Han baserer seg på formelle utviklingsmetoder, hvor han bl.a. forventer at kravene fra forretningssiden i stor grad spesifiseres av andre, mens han leverer det de har bedt om på best mulig måte.

Som en kontrast til dette har du den smidige utvikleren, han som gjerne kaller seg selv en Software Craftsman. En slik utvikler tar i større grad en aktiv rolle i utformingen av løsningene, og ønsker et mye tettere sammarbeid med både andre utviklere og forretningssiden. Han er gjerne mer opptatt av velkonstruerte løsninger på problemer enn å utnytte mulighetene i og binde seg til en bestemt teknologi. Og han er opptatt av teknikker som han mener øker kvaliteten på leveransen, selv om de står i sterk kontrast til den formelle og aksepterte teorien.

Konklusjon

Tenk gjennom hvordan din egen utviklerprofil ser ut. I hvilken kategori er du sterk? Hvor har du mer å hente? Vil du bli bedre på generell problemløsning kan du for eksempel lese om domenedrevet design og trene på å løse ulike problemer (kanskje gjennom kode-kata). Vil du bli bedre på teknologi er det mange måter å gjøre det på, men vurder gjerne å lære deg en teknologi (f.eks. et nytt programmeringsspråk) du ikke har prøvd før – det vil øke din generelle forståelse. Mangler du forretningsforståelse bør du oppsøke dem som har det, og be dem om å opplyse deg, slik at du kan levere et bedre produkt til dem. Og mangler du kunnskap om praktisk gjennomføring bør du oppsøke andre utviklere, slik at dere kan dele erfaringer og vokse sammen. Kanskje du kan spørre noen med mer erfaring om de vil være din mentor for en periode?

De ulike kategoriene trekker til en viss grad i ulike retninger, men jeg tror det er kritisk at vi forsøker å balansere dem, og passer på å jobbe med å bli bedre innenfor alle fire. Det er kun da vi kan levere løsninger på de riktige problemene på en riktig måte, med best mulig teknologi, til riktig tid, og med nødvendig kvalitet – på en måte som vi kan leve med over tid.

Fakta #1: Den viktigste faktoren i utvikling av software er ikke verktøyene og teknikkene programmererne benytter, det er kvaliteten på programmererne selv.

Fakta #2: De beste programmererne er 28 ganger bedre enn de dårligste programmererne, ifølge forskning på “individuelle ulikheter”. Gitt at lønnen til utviklerne aldri reflekterer dette, så sier det seg selv hva som er det største “røverkjøpet” i softwarebransjen.

Nesten alle er enige i at på et overordnet nivå så er mennesker viktigere enn verktøy, teknikker og prosess. Og likevel fortsetter vi å oppføre oss som om dette ikke var tilfelle. Kanskje er dette fordi mennesker er et vanskeligere problem å addressere enn verktøy, teknikker og prosess. Vi i softwarebransjen, teknologer som vi er, foretrekker å finne opp nye teknologier som skal gjøre jobben vår enklere. Selv om vi innerst inne vet at det er langt viktigere å jobbe med å utvikle menneskene.

Påstanden over er fritt oversatt fra Robert L. Glass, 2003. Sitatet ble funnet i Object Thinking, en bok jeg akkurat har begynt å lese, og som lover å forvandle meg til en Ward Cunningham, Kent Beck, Ron Jeffries, Alister Cockburn eller Bob Martin.

Knagger: Bob+Martin

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

I dag kom jeg over en side som heter abetterteam (takk til Mark Nijhof for tipset). Siden er et verktøy for å måle et utviklingsteams kvaliteter og skape en diskusjon i teamet.

Spørsmålene skal besvares av hele teamet, men jeg kunne ikke dy meg, og forsøkte å besvare på teamets vegne – for å se hvordan det hele virket. Og her er resultatet:

I fire av de fem kategoriene ligger vi på det røde feltet, som betyr at øyeblikkelig forbedring er påkrevd. Kun i kategorien Releasing er vi såvidt inne på det gule feltet, som betyr at forbedringer er nødvendig (men ikke øyeblikkelig).

abetterteam forklarer at det er prosessen og diskusjonen som spørsmålene skaper som er det viktigste, og det er jeg nok enig i – det var mange, viktige spørsmål å diskutere der, og jeg håper vi kan ta oss tid til en sesjon rundt dette spørreskjemaet i teamet vårt. Men selve resultatet er også svært tydelig, og gir gode tips til hordan vi kan forbedre oss.

Jobber du for å gjøre teamet ditt smidig anbefaler jeg at du tar en titt abetterteam.

Å lese Code Complete har inspirert meg til å dele noen erfaringer, betraktninger og tips med resten av utviklerne i teamet. Så nå har jeg bestemt meg for å gå systematisk til verks og distribuere nye tips ukentlig – internt på Contiki. Vi bruker en MediaWiki jeg satte opp for snart to år siden (ContikiWiki) til å samle og dele kunnskap og informasjon, og der har jeg nå opprettet en egen side der hvor det skal dukke opp et tips hver uke.

Denne første uken er tipset mitt hvordan man kan ta en lang rutine og gjøre den om til en klasse for å gjøre koden enklere å lese og vedlikeholde. Jeg har tatt et reelt eksempel fra vår egen kode, valgt ut helt tilfeldig, og refakturert etter beste evne. Det var lærerikt for meg også – og det er litt av poenget med å gjøre det, selvfølgelig.

Jeg tenkte først at jeg også skulle poste tipsene mine her på bloggen. Men mengden Contiki-kode og formatet på tipset gjør at det ikke egner seg så godt denne gangen. Jeg tror jeg vil vurdere det fra gang til gang – hvis det er noe som er av allmenn interesse, og det ikke innebærer så mye ekstraarbeid, så legger jeg det nok ut her også.