Måske er jeg ved at blive gammel, eller måske er jeg blot kommet til den indsigt, at bliver man længe nok på samme arbejdsplads, så er så godt som alle nye og spændende projekter også ensbetydende med endnu et projekt, der skal vedligeholdes over tid. Selv projekter, der blot skal skydes af en enkelt gang, har en tendens til med jævne mellemrum at dukke frem til en ny omgang. Hvad enten det skyldes det ene eller det andet, så er ord som standardisering, genkendelse, testbar begyndt at fylde mere og mere når nye projekter angribes - der er jo stor sandsynlighed for at jeg selv ender med aben, når min egen kode på sigt skal vedligeholdes :-)

 Jeg har noget tid anvendt StyleCop til at forcere en ensartethed ned over min kode. Ja, det kan være mega-irriterende at være tvunget til at skrive kommentarer og flytte rundt på metoder og properties for at tilfredsstille StyleCop, men i sidste ende bliver koden lettere at læse, når man gør det på samme måde på tværs af projekter. For at komme lidt videre i samme spor købte jeg Robert C. Martins Clean Code: A Handbook of Agile Software Craftsmanship

Mine forventninger til bogen var lidt de samme som da jeg i sin tid tog StyleCop i brug, nemlig at det kan godt være at man ved hvordan det skal gøres, men nogle gange kan det være en fordel at blive mindet om det endnu engang. De forventninger lever bogen til fulde op til, men meget mere synes jeg heller ikke der er at hente, hvis man programmeret i nogle år. Bogen anvender eksempler i Java, men kan sagtens læses med tanke på C# eller VB.Net.

En af de ting, jeg har taget til mig fra bogen finder man allerede i første kapitel. Martins kalder den "The Boy Scout Rule" og går i sin enkelhed ud på, at man skal efterlade sin kode pænere end da man fandt den. Med andre ord; hver gang man er i et hjørne af sin kode, man ikke har været i længe, så brug lige et øjeblik på at gøre koden lidt pænere. På den måde bliver hele projektets kode gradvis bedre med tiden.

Andre udsagn finder jeg knapt så logiske. Eksempelvis argumenterer han under navnekonventioner for, at et interface ikke skal prefixes med stort I. Det distraherer er argumentet, men her vil jeg nok fortsætte med at følge StyleCops regler, der netop påtvinger I som prefix. De fleste regler er dog gode at få genopfrisket, og meget praktisk er disse regler samlet i kapitel 17 - Smells and Heuristics. Langt de fleste, der har programmeret nogle år vil formodentlig kunne nøjes med de 30 sider som dette kapitel udgør, og disse 30 sider kan med fordel skimmes med jævne mellemrum. 

Det virker som om forfatteren har haft lidt svært ved at beslutte sig for hvem bogen skal skrives til. På den ene side genopfriskes helt basal viden som at navnet "modificationTimestamp" er bedre end "modymdhms" (selvom ymdhms afledt af formatet - yy/mm-dd hh:mm:ss). På den anden side forventes en grad af indsigt, når der pludselig introduceres en stump unit test kode ca. 20 sider før kapitlet om unit tests. Ca. 150 sider af bogens 400 sider er to marathon eksempler, hvor bogens regler og refaktoreringsmetoder hældes ned over to rigtige cases. Sider, der i bedste fald blot ender med at blive skimmet - selv hvis man uøvet ud i at vedligeholde kode.

Alt i alt en udmærket, men lidt kedelig bog, til at minde én om at gøre al kode lidt bedre, og ikke blot opfylde kravsspec på kort sigt. Hvis jeg var chef ville jeg tvinge mine medarbejdere til at læse den - jeg tror mange, ville have gavn af en opfrisker. Vi ender på 4 små ninjastjerner pga. value-for-money. Set til kr. 243,-