Boken är såklart fylld med intressanta anekdoter och citat, men det som jag fann mest intressant var att många av dem som gjort saker som mer eller mindre förändrat världen var sådan utstuderade pragmatiker. Många utvecklare idag, inte minst jag själv, tenderar att vara purister till viss del, må det gälla TDD, S.O.L.I.D., dynamisk typning, statisk typning, graceful degradation, progressive enhancement etc. etc. Flertalet av de intervjuade i denna boken gav dock intrycket av att till viss del tillåta sig skjuta från höften, bara så länge fungerande mjukvara levererades. Väldigt uppfriskande läsning.
Coders at Work var överhuvudtaget väldigt rolig och underhållande, den innehåller flera riktigt sköna berättelser om debugging från den tiden ett program bestod av en samling papper med hål i.

Boken är, som titeln antyder, inriktad på enhetstestning i .NET men kan säkert tilltala utvecklare i andra språk också. Den går genom enhetstestning hela vägen från vilka testramverk man kan använda och hur man installerar dem och kör sitt första test, till hur man integrerar enhetstestning i utvecklingsprocessen på sin arbetsplats med automatiserad testning och testprocesser.

Det är gott om kodexempel i boken, en fiktiv logganalyseringsapplikation används för att demonstrera aspekter av enhetstestning. Det ges ofta kodexempel både innan och efter refaktorering, ett bra sätt att demonstrera hur en design ofta förändras (och förhoppningsvis blir bättre) av att koden testas med enhetstester.

En av de saker jag uppskattade mest var de avsnitt som visar skillnader mellan stub och mock objects, när man ska använda det ena eller andra och, framförallt, varför. Jag kan ärligt erkänna att det där alltid varit lite luddigt för mig men efter att ha läst de kapitlen har det klarnat avsevärt. Det finns också mängder av bra småtips, som namngivningskonventioner och mönster man kan använda vid enhetstestning.

Det som kan dra ner upplevelsen lite är att boken tyvärr är dåligt redigerad och formgiven på sina ställen. Ett typsnitt som är misstänkt likt Comic Sans används frekvent och indenteringen i kodexemplen följer inga konventioner, ibland verkar rentav kod saknas. Detaljer måhända men ändå lite irriterande. Jag rekommenderar ändå utan tvekan boken till alla som vill börja med enhetstestning, framförallt om man ska göra det i .NET. Har man hållt på med enhetstestning ett tag kanske den första halvan är repetition, men det kan vara värt att läsa boken ändå då den är fylld med bra tips och idéer.

Boken är uppdelad i tre delar: Agile Development, Agile Design och The Payroll Case Study. Den första delen behandlar de olika delarna som utgör lättrörlig utveckling; parprogrammering, testdriven utveckling, användarfall, refaktorering och projektplanering. I detta avsnittet fanns en del partier jag kunde gå snabbt genom, det var inga djuplodande analyser.
Det jag uppskattade mest var sista avsnittet som är en återskapad dialog mellan författaren Robert Martin och Bob Koss när de löser ett till synes enkelt programmeringsproblem, att räkna poäng i bowling. Koden samt testkod är bifogad, steg för steg medan den växer fram under deras parprogrammering. Här visas på ett roligt och effektivt vis hur testdriven utveckling tillsammans med parprogrammering driver fram en elegant lösning på problemet.

Den andra delen, Agile Design, är större och mycket tyngre. Här går författarna, förutom ”Code Smells”, grundligt genom de fem principerna i S.O.L.I.D. samt ägnar en stort antal sidor åt UML. Även om jag i kapitlen om de olika principerna kände igen mycket av de artiklar Robert Martin tidigare publicerat, upplevde jag det som bättre förklart och lättare att förstå. Exempelvis ”The Liskov Substitution Principle”, som i originaldefinitionen är något svårsmält, tyckte jag var mycket lättare att förstå efter att ha läst det kapitlet. Avsnitten om UML skummade jag faktiskt genom, det är något som jag och antagligen de flesta utvecklare redan fått repetera någon gång för mycket under sin utbildning. Författarna påpekar också redan tidigt i boken att den går utmärkt att läsa utvalda delar ur, och strunta i det man finner mindre intressant.

I den sista delen utvecklar författarna ett fiktivt löneutbetalningssystem, från första kundmötet till hur mjukvaran slutligen paketeras och levereras. Precis som i bowlingsexemplet finns det mängder med kodexempel och testkod, de är heller inte rädda för att ge exempel på kod på en sida för att de efterföljande sidorna bryta ner och i små steg förbättra koden.
Denna delen har flertalet kapitel som vart och ett ägnas åt ett specifikt designmönster, författarna visar hur ett visst designmönster löser ett problem i löneutbetalningssystemet. Det är både välkända och välanvända mönster (Singleton, Strategy, Template Method, Adapter, Decorator, Null Object) och kanske mindre vanliga mönster (Observer, Visitor, State, Bridge) som tas upp och exemplifieras. Författarna har lyckats bra med att inte få exemplen att kännas sökta, i några fall presenteras exempel där de använder ett mönster för att sedan omedelbart förkasta lösningen för att den blir för komplicerad.
Den sista delen innehåller också det kapitel som jag tyckte var mest intressant och lärorikt; kapitlet om paketering av komponenter i ett system. Även i detta området har Robert C. Martin definierat några principer och alla gås grundligt genom. Framförallt avsnittet om beroenden mellan olika komponenter i ett system var väldigt upplysande och gav nya idéer om hur man borde strukturera projekt.

De flesta utvecklare som jobbar med objektorienterade och lättrörliga har något att hämta i denna boken. Den är väldigt komplett vad gäller de olika aspekterna i ett utvecklingsprojekt, från processer och filosofier till specifika implementationer. Den ska dock inte misstas för en bok för att lära sig C#, det är mer eller mindre bara språket som används i exemplen. Boken ger nog mest om läsaren redan har en del erfarenhet av objektorienterad utveckling, men vill utöka sina kunskaper bortom rena algoritmer.
Mycket rekommenderad läsning, och jag passar på att slå ett slag för Clean Code här också, läs den också.