Tag software architectuur
Nog zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Vandaag pen ik kort neer welke inzichten ik de tweede dag opdeed.
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
Horizontale en verticale architectuur
Als we onze applicatie verticaal op zouden hakken, dan zouden we af kunnen komen van onze ongemakkelijke naamgevingsconventies. Elke slice zou zijn eigen project krijgen, en elk project zijn eigen model. Of het nu over items in isolatie gaat, of items in een toets, of items in een itembank - we zouden in de code altijd over Item kunnen spreken - net als de gebruiker.
Tests als ontwerpmiddel
Tests zijn een ontwerpmiddel, een design tool. Ze fungeren als indicator voor de kwaliteit van het ontwerp van je code. De vuistregel is even eenvoudig als zag-het-niet-want-het-stond-recht-voor-mijn-neus-vanzelfsprekend: Is het moeilijk om er een test voor te schrijven? Dan deugt het ontwerp niet!
Zelfs de testpiramide is niet meer heilig!
Ik ben altijd in de veronderstelling geweest dat mijn geautomatiseerde tests een piramidevormige verhouding tot elkaar zouden moeten hebben: aan de basis enorm veel unittests, in het midden een goede hoeveelheid integratietests, en aan de top een bescheiden aantal end to end (E2E) tests. Totdat ik Learning Domain-Driven Design van Vlad Khononov las. (Een aanrader, overigens!)
Wat is de O in SOLID nog waard?
Een ontwikkelaar die eens code schrijft en deze nooit meer aan denkt te hoeven passen, is een ontwikkelaar die rot in zijn applicatie verwelkomt. Een al te strikte naleving van het Open-closed principe (OCP) getuigt van een ronduit onverantwoorde houding - in elk geval binnen de context van Agile ontwikkeling. Waar komt de aantrekkingskracht van het OCP dan vandaan?
Schorseneren en software architectuur
Een ontwerper van een systeem - of dat nu een kok is of een softwarearchitect - dient niet alleen rekening te houden met de functionele eigenschappen van zijn componenten. Smaak is niet alles! Een lekker ingrediënt kan om allerlei redenen niet in een gerecht terechtkomen. De impact van het ingrediënt op de afwasser - niet onbelangrijk! - kan dusdanig zijn dat het verstandig is om toch maar een ander smaakje te kiezen.
Domain-Driven Design en Ludwig Wittgenstein
Vaak gebruiken verschillende delen van de business dezelfde woorden op verschillende manieren, of gebruiken ze verschillende woorden voor hetzelfde concept. Dat is een frustrerende situatie voor een softwareontwikkelaar, maar een feest voor een taalfilosoof.
De kwestie autorisatie
Onze Product Owner ging anderhalve week ondergronds met onze informatie-analist om een autorisatiematrix uit te tekenen. Toen hij het eindresultaat eindelijk presenteerde aan het team, leidde hij zijn verhaal in met de woorden: “We gaan jullie meenemen.” Dat was een slecht teken.
Incrementele versus iteratieve ontwikkeling
Als ik geen zin heb om over software ontwikkeling te lezen tijdens mijn ontbijt, zet ik een filmpje op YouTube op. Laatst keek ik er een van software architect George Fairbanks over de bijdrage van softwareontwikkelprocessen aan (het wegwerken van) technische schuld. Ik at die ochtend, als ik me het goed herinner, afbakbroodjes met jam. Het was dus in meerdere opzichten een prima begin van de dag.