Har tilbragt den første dag på GOTOcph med at se en masse spændende præsentationer.
Havde på forhånd givet mig selv det lille benspænd, at fokusere på hvad der kunne give mig ideer og inspiration til at lave kode af bedre kvalitet.
Første dag fandt jeg sporet om testing interessant.
Egentlig synes jeg udvikling og testing er to sider af samme sag, men det er jo et område der, måske grundet den lave “sex-appeal”, har plads til forbedring.
Code as a crime scene
Første præsentation havde titlen “code as a crime scene” og var et særdeles interessant og anderledes perspektiv på kode, og på den information vores versions-system giver os af historisk data om udviklingsprocessen.
Kort fortalt gennemgik han nye måder at se på den kode et udviklerteam producerer, blandt andet kan man finde hvad han kalde “hot spots” dvs steder i en kode-base der ofte bliver ændret og ofte indeholder “bugs”. Som han sagde “bugs likes each other” og dukker ofte op de samme steder. Typisk peger disse “hot spots” på kode der er for kompleks eller bare gør for mange ting.
Det næste han kom ind på var, at hvis man kobler informationen med hvem der ændrer hvad, får man konkret information om hvordan systemet og udviklingsteamet er opdelt. Finder man komponenter mange forskellige udviklere har fingrene i, er det måske et tegn på at ens arkitektur ikke matcher uddelingen af ansvarsområder godt nok, og det var hans erfaring at des flere udviklere der havde fingrene i det samme stykke kode des lavere kvalitet.
Det adresseret han med dette citat:
“Align your Architecture and your Organisation”.
Det var med andre ord hans råd at tage den famøse “Convay’s law” og vende den på hovedet. (i øvrigt en artikel man bør læse )
Den korte version af Convay er at, det software et team udvikler vil tage form efter den struktur teamet har.
En mere simple anvendelse af den type viden kan også være at man bruger viden om kodens “hot spots” til at prioritere sin test indsats.
Unselfish testing
Det næste i testsporet var “unselfish testing”. Det var meget “hands on” og pointerne blev presenteret med konkrete kode eksempler. Essensen var at testkode, også er kode man bør sikre er læsbar og nem at forstå. Når en test der ikke umiddelbart er relateret til det man laver pludselig fejler, skal det være nemt at finde ud af hvorfor.
Konsekvensen af det er at test kode skal frem for alt gå efter at være meget nemt at læse, og hvis genbrug af kode, gør man ikke nemt kan få overblik over hvad en test gør, så laver.
Følgende citat taget fra hans præsentation, siger det meget godt:
“Any fool can write a test that helps them today. Good programmers write tests that help the entire team in the future.”
Et yderst interessant aspekt han også kort kom ind på var, at tests der er nyttige i en fase af projektet, måske ikke er en god ide at beholde.
Indlægget havde mange flere konkrete råd, til hvordan man kan forbedre kvaliteten af sines test, han tillod sig at være direkte og have klare holdinger og anbefalinger som man så kan være enige med eller ej. Synes selv jeg er bevist om hvordan jeg skriver mine test men tror bestemt Hr Jay Fields kan et par tricks jeg bør lære, måske gå så langt som at læse hans bog “Working Effectively with Unit tests.”
Sidst synes jeg følge af hans citater siger kort hvad det hele handler om når man skriver testkode:
“The tests you own end up owning you”
Dag to, taklede jeg mit eget benspænd fra en anden vinkel, ved at se en række indlæg om “Reactive Architectures”, men det må blive emnet for et andet indlæg.