Op 30 juni vierde JDriven als Java Consultancy bedrijf zijn 10 jarig bestaan met een Java conferentie op de prachtige locatie van Fort de Batterijen in Nieuwegein. De dag zou ik het liefst omschrijven als een geslaagd pleidooi voor kennisdeling. Vandaar ook hun motto “Commit Develop Share” en de titel voor de conferentie: “FortX, Charge Your Knowledge”. Het was even spannend of mijn routeplanner de goede weg had gekozen toen ik via een omleiding over het fietspad langs het kanaal moest, maar uiteindelijk kwam alles goed.

Eerst denken, dan bouwen

Na de opening door JDriven begon de dag met een enerverende presentatie door Simon Brown, de auteur van het C4-model, over de verloren kunst van software architectuur.

Simon Brown, The lost art of software architecture

Met agile software ontwerp, en technieken als TDD en Extreme Programming, zijn veel teams de waarde van een goed ontwerp, en bijbehorende technieken, uit het oog verloren. Zijn pleidooi was dan ook om niet te ver hierin door te slaan en helemaal niet meer na te denken voor we software gaan bouwen. Het is juist belangrijk om van te voren na te denken over wat we willen maken en hoe we het willen maken, daar de juiste technieken bij te gebruiken, en zo ook de waardevolle discussies over het ontwerp te kunnen hebben voor de daadwerkelijke implementatie.

Simon Brown, The lost art of software architecture (2)

Java, tegenwoordig & toekomstig

Hierna begonnen de parallele sessies en koos ik voor de presentatie van Ties van de Ven en Jeroen Resoort: “LTS to LTS: changes from Java 11 to 17”. Aangezien ze hun presentatie echter oorspronkelijk anderhalf jaar eerder hadden willen geven (in het werkelijke Jubileumjaar van JDriven), was er al weer heel wat gebeurd in het Java landschap en hadden ze besloten zich meer te richten op toekomstige veranderingen in Java, en daarom de titel veranderd naar “Modern Java”. Na een vlugge recap van de veranderingen van Java 11 naar 17, werd gekeken naar de veranderingen in JDK 18 en toekomstige releases, waaronder Project Valhalla. Hoewel erg interessant zal ik niet teveel op de technische details ingaan, die kunnen belangstellenden terug vinden op hun gitlab pagina

Ties van de Ven en Jeroen Resoort, Modern Java

To mock or not to mock

Na een ruime pauze en een heerlijke vega wrap van de gehuurde foodtruck, begonnen de volgende sessies. Ik koos ervoor om naar de presentatie “Bigger Unit Tests are Better - why small unit test classes will slow you down” van Peter Schuler te gaan. Ik had al vluchtig een youtube opname van een eerdere presentatie van hem gezien, en wilde nu graag eens goed naar zijn verhaal luisteren.

Peter Schuler, Bigger Unit Tests are Better - why small unit test classes will slow you down

Tegenwoordig weet iedere software ontwikkelaar dat hij zijn code moet testen, om iets betrouwbaars op te leveren. Vaak wordt er gesproken over de “test pyramide” en worden alle klassen op het laagste niveau getest: een testklasse per klasse. De kern van zijn betoog was dat door je software op zo’n laag niveau te testen, je eigenlijk je testen sterk koppelt aan je code, terwijl we weten dat we juist op moeten passen voor een hoge koppeling tussen klassen in onze code. Daardoor wordt het onderhoud en herstructurering (refactoring) van de code lastig, want bij iedere structurele wijziging in de code, moeten we dan ook wijzigingen gaan doorvoeren in onze tests, terwijl de eisen (requirements) niet veranderd zijn. Dat levert risico’s en een hoop extra werk op. Door onze testen te richten op de plek waar de eisen liggen (bijvoorbeeld op een REST endpoint in onze API), vermijden we dit probleem, en wordt het ook nog eens makkelijker om met niet-technische collega’s over de software te praten. We hoeven de testen niet meer te refactoren wanneer we de code refactoren, en onze testen hoeven enkel nog te veranderen wanneer de business requirements veranderen. Ook Kent Beck meldt dat het koppelen van je testen aan de structuur van je code een slecht idee is.

Peter Schuler, Bigger Unit Tests are Better - why small unit test classes will slow you down (3)

Automatisch kom je dan bij de discussie wat je dan wel en niet zou moeten mocken. Als je grotere unit tests schrijft, moet je onderliggende componenten eerst aan elkaar knopen voor je kunt gaan testen. Dat contrasteert met de mockist aanpak, waarbij een ontwikkelaar juist alle afhankelijkheden, zelfs degenen die met onderdeel zijn van de gewenste functionaliteit, uitmockt. Ook dat geeft echter een hoge koppeling tussen tests en code, zoals ook Martin Fowler hier beschrijft.

Peter Schuler, Bigger Unit Tests are Better - why small unit test classes will slow you down (2)

Het blijkt zo maar weer dat het concept van Test Driven Design conceptueel vrij lastig te vatten blijkt. Er zijn veel valkuilen die tot moeilijk te onderhouden software kunnen leiden. 100% coverage is dus geen garantie voor goede software. Persoonlijk denk ik dat meerdere manieren van testen nut hebben in verschillende situaties. Zo kan de “mockist” benadering van unit testen zeer goed onderhoudbare code opleveren wanneer er een conceptueel blok van samenhangende funtionaliteit geimplementeerd moet worden. Zie voor een goede aanpak bijvoorbeeld de combinatie van Need-Driven Design (zie ook site van Mock Objects) en de aanpak van “Uncle Bob”. Wanneer je echter een nieuw endpoint aan een reeds bestaande API toe wil voegen, en je functionaliteit een conceptueel geheel vormt, maar zich over verschillende lagen van je applicatie uitspreidt, lijkt de aanpak van Peter Schuler het meest logisch.

Bescherm & waak over je werk

De volgende presentatie was een keynote door Brian Vermeer: “Empowering Developers to Embrace Security”. Een heel interessant betoog over hoe we het probleem van beveiliging kunnen aanpakken door een “Security Champion Program” op te zetten binnen de bedrijven waar we werken.

The Message-Driven Modulith

Daarna had ik de presentatie van Robbert van Waveren bijgewoond over “The Message-Driven Modulith, or how to start your next big project”. Het is inmiddels vrij algemeen bekend dat het starten van een applicatie met microservices, over het algemeen niet zo’n goed idee is. Het vraagt behoorlijk wat extra inspanning om een set aan microservices goed te testen, te monitoren en te onderhouden. Het beste werkt dit dan ook wanneer de team-structuur de applicatie-structuur weerspiegelt. Het is echter verstandig om je applicatie wel modulair te starten, zodat je later zonder al te veel problemen van een monoliet-architectuur naar een microservices-architectuur kunt overstappen, zie daarover ook mijn vorige blog post. Robbert van Waveren had zelf de proef op de som genomen door een modulaire pokerapplicatie te schrijven waar op de koppelvlakken tussen de modules gebruik gemaakt werd van een message bus. Een heel interessante benadering om voor toekomstige projecten te overwegen!

Robbert van Waveren, The Message-Driven Modulith, or how to start your next big project

Tot slot, een NASA traktatie

De conferentie werd afgesloten met een inspirerend verhaal van Lois Kim, gevolgd door een afsluitend verhaal van Rob & Erik van JDriven. Lois Kim is een ontwerper die verscheidene projecten voor de NASA had uitgevoerd, waarbij het werk van de NASA voor het brede publiek gevisualiseerd en gepromoot werd, en zij kon ons op een aantal van haar fascinerende ontwerpen trakteren tijdens de presentatie.

Closing Keynote by Rob & Erik

Al met al een hele leuke dag, perfect verzorgd en met heel veel interessante presentaties, waarbij vakmanschap, het plezier in software ontwikkelen en de boodschap van het belang van kennisdeling heel duidelijk naar voren kwamen.

Over Auke Auke

Auke is nieuwsgierig, naar de zin van het leven, maar vooral naar Java. Als een pitbull bijt hij zich vast in een probleem (en dat is gelukkig niet verboden).

Vragen of opmerkingen zijn welkom. Bel of mail Auke.