Boek review

Er ontstaat steeds meer software om ons heen, waardoor uiteraard ook de hoeveelheid legacy code toeneemt. Het logisch gevolg hiervan is dat je als Java developer steeds vaker met legacy code te maken krijgt. Het boek “Your Code as a crime scene” haakt hier uitstekend op in. De in het boek beschreven methoden helpen je om snel inzicht te krijgen in de code base van grote softwareprojecten, zonder dat je zelf de code in details hoeft door te nemen. Zo heb ik het boek gebruikt om enkele projecten te analyseren, waaronder een project met een grootte van zo’n 800.000 regels code.

Forensisch onderzoek

In het boek worden forensische technieken gebruikt om bijvoorbeeld een daderprofiel te creëren, waarmee hotspots in je project aan het licht worden gebracht. Ook beschrijft het boek hoe je de kwaliteit van je code kunt bewaken. Deze analyses worden gedaan met behulp van informatie uit je versiebeheersysteem. Je versiebeheersyteem is een goudmijn van historische data, waaruit allerlei waardevolle informatie te extraheren is, die voor nadere analyse gebruikt kan worden. De auteur refereert naar diverse onderzoeksinstrumenten (tools) en stelt zelf ook een aantal Python tools online beschikbaar om data te kunnen analyseren. D3.js is een veelgebruikte library om reportages te visualiseren.

Met de code base van Hibernate als voorbeeld beschrijft het boek hoe je stap voor stap informatie uit het versiebeheersysteem kunt extraheren en de analyses kunt uitvoeren. Hierbij legt de auteur telkens de relatie met de forensische opsporingsmethodiek.

Het boek

Het boek is opgedeeld in drie delen: Evolving Software, Dissect your Architecture en Master the Social Aspects of Code.

Zoals we inmiddels weten is het complex en kostbaar om software te onderhouden. Het is dus van belang om software zo eenvoudig mogelijk te houden. In het eerste deel van “Your Code as a crime scene” wordt stap voor stap beschreven hoe je de hotspots binnen je code kunt vinden. De hotspots zijn de files/classes, die complex zijn en waarin recentelijk nog veel wijzigingen hebben plaatsgevonden. In feite wordt in het begin een top x gecreëerd, die door middel van steeds meer analyses wordt uitgedund, totdat alleen de echte hotspots overblijven. Bij deze analyses wordt ook de factor tijd mee gewogen, wat zeker belangrijk is bij legacy systemen, die al vele jaren worden beheerd.

Het tweede deel van het boek focust zich op de architectuur van je software. Door bijvoorbeeld te analyseren welke files regelmatig parallel in een enkele commit verbonden zijn, kunnen verkeerde afhankelijkheden in de code aan het licht komen. Ook is deze methodiek bruikbaar om een safety net te creëren voor je testcode. Unit tests zullen bijvoorbeeld een hoge mate van cohesie met je code moeten bevatten, terwijl je dat weer niet wil bij integratietests. Dit geeft namelijk aan dat je integratietests teveel details bevatten.

In het laatste deel van het boek wordt ingegaan op diverse sociale aspecten van software. Eén aspect hiervan is de balans in ownership van de software. Wanneer de ownership van bepaalde modules erg gefragmenteerd is, kan dit de kwaliteit in gevaar brengen. Developers zullen zich minder verantwoordelijk voelen. Anderzijds wanneer een developer aan een module heeft gewerkt, zal de kwaliteit erg afhankelijk zijn van de kwaliteit van die developer.

 

Bruikbaarheid boek

“Your Code as a crime scene” neemt je bij de hand en legt duidelijk en stap voor stap uit hoe je tot een bepaalde analyse komt en welke conclusies je hieruit kunt trekken. Veel analyses worden voorafgegaan door een stuk theorie uit de forensische wereld, waarna het parallel wordt getrokken met de te analyseren code. Helaas bevat het boek regelmatig wat herhaling door eerst uitleg te geven over het uitvoeren van een bepaalde analyse en daarna deze uitleg te herhalen aan de hand van het voorbeeld met de code base van Hibernate.

Een hotspot analyse geeft middels visualisatie in D3.js een duidelijk overzicht van mogelijke hotspots in je software

Bruikbaarheid tooling

Bij het gebruik van de tooling liep ik tegen een aantal beperkingen aan, doordat de tools niet goed op elkaar zijn afgestemd. Zo genereert de geadviseerde tool ‘code maat’ een csv met file paden met forward slashes, terwijl de Python tools een backward slash gebruiken. Om vervolgens deze data te kunnen gebruiken, moet deze eerst worden aangepast. Ook in situaties waarbij één repository gebruikt wordt voor meerdere modules ontstaan mogelijk problemen.

Daarnaast is het belangrijk dat er correct is omgegaan met het versiebeheersysteem. Om goede resultaten uit de analyses te vergaren, zouden wijzigingen gebundeld gecommit moeten zijn. Ook goed gebruik van commit messages zullen waardevolle resultaten kunnen opleveren.

Tot slot is het lastig om analyses over tijdspannen uit te voeren, wanneer er veel files of modules zijn verplaatst. Zeker wanneer geen Git is gebruikt, kan een analyse over tijd een verkeerd beeld geven. Dit is niet onoverkomelijk, maar wel goed om in het achterhoofd te houden.

 

Conclusie

Als je als developer regelmatig met legacy systemen te maken krijgt, dan is dit boek een absolute aanrader. De theorieën, die de schrijver beschrijft, geven interessante inzichten en de parallel met de forensische technieken is treffend. Met behulp van de aangereikte tools kun je een heel eind komen, maar een geïntegreerde toolset zou het nog leven nog gemakkelijker maken.

Leave a Reply

Your email address will not be published. Required fields are marked *