Over deze aflevering
Dennis Doomen is te gast. We praten met hem over zijn open source project Fluent Assertions & CQRS/Event Sourcing.
Delen
// Gasten
// Luister op
Wat je leert#
- •Wat Fluent Assertions inhoudt en waarom
- •Hoe je een open source project opzet
- •Wat CQRS en Event Sourcing betekenen
- •Hoe AVG impact heeft op Event Sourcing
- •Waarom TDD een design techniek is
Transcript
Welkom bij de tweede aflevering van CodeKlets. Ik ben Saber Karmous. En ik ben Kishen Simbhoedatpanday.
Ja, dit is de tweede aflevering. Het was wel, de eerste was best, vond ik best spannend.
Was ook heel gaaf, was met Pauline. Nee, maar dat was echt wel gaaf. Dit heeft me best wel verrast,
want je weet natuurlijk nooit wat voor persoon je aan tafel hebt. En dit was leuk.
Ja, het was heel gezellig. Een hele leuke, spontane meid ook. Veel gelachen.
Veel ook inhoudelijke, facking-inhoudelijke dingen ook met haar gesproken. Ja, het was echt goed.
Ja, dat vond ik ook. Maar goed, ik zat daarna. Ik wilde nog één opnemen.
En ja, dan zit je te wachten, te wachten en dan hopen dat je weer een gast kunt vinden.
Gelukkig hebben we best wel een lijst met hele interessante gasten die we binnenkort hopelijk kunnen op gaan nemen.
Dus daar kan ik niet op wachten. Die gast van vandaag, Klapper Zoel, die is ook heel erg gaaf.
Maar het viel mij op dat ik echt wel zin had om weer een nieuwe op te nemen.
Dus ik vind het echt wel gaaf om te doen.
Elke week gaan we gewoon tijd maken.
Ja, precies. Oké, maar deze keer hebben we een gast die voor mij heel bekend is.
Dat is een collega van mij. Die werkt ook bij Alviva Solutions en dat is Dennis Domen.
We zijn heel blij dat hij aanschuift bij ons. Dennis werkt dus bij Alviva Solutions.
Zit al ruim twee decennia in het vak.
Ik weet niet hoe je dit doet, man. Na tien jaar was ik afgeraakt.
Hoe hou je je in het volk?
23 jaar.
23 ook. Hij heeft zich inmiddels gespecialiseerd in het verbeteren van het hele software ontwikkeltrekken
bij organisaties die software bouwen op basis van .NET technologie.
Dan doe je gewoon alleen maar .NET.
Ik kan mezelf fullstack noemen, maar dat is een beetje een hype term.
Natuurlijk kan ik JavaScript en TypeScript, maar mijn hart ligt nog steeds bij .NET.
Heb je ook een tattoo ergens met .NET?
Nee, dat doe ik niet aan.
Nou, dat is maar goed, want dat vind ik altijd een beetje vreemd.
Ik ben er ook de scheidrecht voor.
Ja, precies. Maar goed, het gaat over allerlei facetten.
Dus architectuur, teams, mensen, infrastructuur, tools en de processen die daar allemaal mee te maken hebben.
Dat is een redelijk breed inzet bij die jongen.
Dat is wel handig. Hij heeft twee kinderen en nog een vrouw.
En hij heeft ook handbaltraining. Dat is wel een verrassing voor mij.
Dat wist ik dus niet.
Ja, voor mij ook wel. En ook voor mijn familie.
Maar mijn vrouw is een handbalfanaat.
En mijn kinderen zijn op handbal gegaan.
En in een gegeven moment word je een soort van vrijwilliger.
En ja, waarom niet?
Het is leuk. Je staat buiten.
Frisse lucht.
Hij schrijft verder ook nog blogs.
Nou, ik weet niet, waar had hij de tijd vandaan?
Internationale conferenties.
En hij onderhoudt meerdere open source projecten.
Dat komen we later denk ik nog wel op terug.
En hij schijnt ook nog iets met C-Shop te doen.
Dat is eigenlijk wel best wel logisch, maar ook wel handig.
Het zou wel een beetje lullig zijn als je .net deed en alleen maar Javascript kon.
Dat is niet zo handig, denk ik.
Maar goed.
Dit komt meteen bij het eerste onderwerp,
zodat we meteen met de deur in huis vallen.
Dat is een project waar hij denk ik best wel trots op is.
Nou, we gaan niet alleen over dat project hebben,
maar ook een aantal verwante zaken.
Dat is Fluid Assertions.
Dat is een library om assertions mee te schrijven.
Dat is bij unit testen, dus TDD of BDD.
Als ik het goed heb.
En dat doet hij al een tijdje.
Hoe lang eigenlijk?
Tien jaar.
Tien jaar.
Toen vallen zag ik het vandaag.
Ik zat te kijken naar de aantekeningen voor een komende presentatie.
Toen zag ik dat ik het samen met collega Martin Opdam,
ook bij Aviva werkend, in 2009 het idee al zijn we eigenlijk mee gestart.
En volgens mij pas in 2010 kwam het op CodeKlets.
Maar goed, in 2009 zijn we er al mee begonnen.
Toen heette het nog Custom Assertions ofzo.
Het was meer een hobbyprojectje.
Niet echt serieus bedoeld.
Die Fluid Assertions is wel een betere naam.
Moet ik eerlijk zeggen.
Ja, dat loopt wat lekkerder.
Wat vloeiender.
Dit is echt een nerd-talk dit.
Ja, precies.
Ik hoop dat mensen daar mogen luisteren.
Maar hoe ben je eigenlijk geïnspireerd?
Hoe oud ben je Fluid Assertions gaan doen?
Is dat toevallig omdat je dacht.
Nou ja, dit probleem lopen we nu samen met Martin, zei je.
Ja.
We lopen iedere keer een beetje tegen dezelfde problemen aan.
Ja, dat is zeker zo.
Ik ben niet iemand die gewoon puur uit een hobby sfeer iets gaat bedenken, iets gaat bouwen.
Ik ben niet iemand die bijvoorbeeld, weet ik veel, als er iets nieuws uitkomt.
Een nieuwe .netversie of een nieuw framework ofzo.
Dat ik dan in de avonduren gewoon eens iets in elkaar ga zetten.
Pure voor de lol.
Het zit niet in me.
Ik moet echt een probleem willen oplossen.
En volgens mij hadden we toen het probleem.
Ik ben ook weer iemand die houdt van leesbare code.
Ik wil graag dat mijn code zelfbeschrijvend is.
Dat is misschien een beetje een ideologische insteek.
Maar ik vind het belangrijk dat het duidelijk is.
Dat het de intentie laat zien.
En ik kan me nog wel vaak herinneren dat we toen met bestaande toolingen daar
niet echt uit de voeten kwamen.
En dat we gegeven met zijn experimenteren.
En voor mij had het ook ergens gezien.
Een soort gelijk project in een andere platform.
En dat is eigenlijk zo gegroeid.
En we hadden ook nooit bedacht dat het zo groot zou zijn.
Ik zag vanmiddag dat we volgens mij richting de 28 miljoen downloads gaan.
Nou, ik wou dat ik daar een cent per download van kreeg.
Of bitcoins.
Ja, precies.
Maar dat is eigenlijk zo gegroeid op een of andere manier.
En wat was de onderscheidende factor volgens jou?
Wat je beschrijft dat je ergens een soort gelijk framework had gevonden.
Ja, dat is een hele goede vraag.
En eerlijk gezegd weet ik het antwoord daar niet op.
Want er zijn een soortgelijke frameworks.
Maar die zijn op een of andere manier nooit zo populair geworden.
Waar denk je dan als je zelf zou mogen?
Misschien de presentatie die ik erover gedaan heb.
Misschien de blogs die ik erover geschreven heb.
Het laten zien aan andere mensen.
Het is gebaseerd op een fluent API.
En dat betekent het leest lekker makkelijk.
Je hebt een variabele.
Je gaat in je whatever IDA je wil gebruiken.
Visual Studio Rider.
Je doet een dot.
En je ziet shoot staan.
En je doet nog een keer een dot.
En je ziet precies alle opties die je hebt.
En het leest ook heel erg duidelijk.
En een van de dingen waarvan ik zelf denk dat het wel vrij uniek is opzich van andere frameworks.
Als een unit test faalt.
Dan vind ik het heel belangrijk dat het heel duidelijk is waarom die faalt.
Ik heb dus een hekel aan van expected, false en found true.
Dat zegt helemaal niks.
Dus ik heb het altijd een onderdeel gemaakt om het proberen heel explic te maken.
Dat je meteen ziet zonder dat je een code krijgt van oh dat is de reden waarom het faalt.
Ja, je probeert ontwikkelaars net zoals je zelf zegt mooie code.
Het is duidelijke code te schrijven.
Het moet lezen als een boek.
Ja, absoluut.
Absoluut.
Oké.
Ja, dat is wel.
Kijk, want het grappige is.
Ik heb het best vaak.
Trouwens eigenlijk altijd als ik unit test schrijf dan gebruik ik het voortaan.
Het lijkt wel een reclameblok.
Maar dat is ook feitelijk echt zo.
Nogmaals, ik verdien er niks mee.
Nee, nee, nee.
Maar goed.
Maar het grappige is als je het leest.
Je denkt, ja, het zijn een search.
Je denkt, ja, een big deal zeg maar.
Hoe kan dit nou zo veel impact hebben?
Maar het grappige is als je het niet gebruikt.
Dan denk je, shit, ik mis het.
Dus het is al heel snel dat ik dan via de Visual Studio Package Manager, als ik het niet heb, dat ik het meteen installeer.
Dus als het in de package niet gebruikt wordt, dan sneak ik altijd die package erbij in.
Maar het is steeds vaker zo dat als ik ergens kom en ze hebben unit test geschreven, dat het in de search gebruikt wordt.
Dus dat is wel echt opvallend.
Ja.
Dus dat is al wel een...
En dat is ook echt kick om te zien hoor.
Want ik zeg al, ik had het zelf niet verwacht dat het zo ver zou gaan.
Maar op een gegeven moment ontdek je je eerste blogpost.
Dat iemand een blogpost schrijft over je open source library.
En vorig jaar zag ik voor het eerst een Pluralsight Training.
En toen denk je wel van, wow, dat is toch wel kicken.
Dat vind ik eigenlijk wel bijzonder, ja.
Dat iemand alles dan een cursus verzint met spullen die jij verzond hebt.
Dan heb je wel, ja, dan ben jij gewoon klaar.
Dat denk ik wel.
Ik zag een open source vereniging van een collega.
Ik zag ook voor het eerst een blogpost over voorbij komen van iemand anders die het gewoon gebruikt.
Ik denk dat je dan een punt hebt bereikt dat je dat dan gaat spelen.
Als andere mensen gaan praten, gaan schrijven over iets wat je gemaakt hebt.
Dan heb je denk ik, misschien is dat wel een beetje dat kantelpunt voor een library.
Ja, ja, ja.
Ja, het lijkt me wel heel erg gaaf.
Ik heb het helaas niet mogen meemaken, maar goed, dat is wel heel gaaf.
En zijn er ook negatieve zaken geweest waarvan je dacht van nou,
want het is een open source project.
Heb jij bad stories?
Oh, joh.
Ja, weet je, het is net een echt software project.
Je hebt te maken met mensen die bepaalde wensen hebben,
dingen die niet passen, die niet in de filosofie passen.
Je hebt mensen die kritiek leveren,
dat ze bijvoorbeeld een bepaalde featje niet mooi vinden.
Je hebt zelfs mensen die hele vloeiend APIs afsweren.
Waarschijnlijk zijn dat de mensen die misschien een keer een slecht ervaring hebben gehad.
Die zitten de verkeerde kant van de hype cycle.
Maar in het algemeen, ja, weet je, het is software.
Dus je moet gaan nadenken over breaking changes.
In tien jaar tijd is er heel veel veranderd in de .NET wereld.
Allerlei frameworks zijn bedacht en constructies om meerdere platformen
of meerdere verschillende frameworks te ondersteunen.
We moesten met Mono ondersteunen, Xamarin.
We hebben .NET Core, veranderen ook weer van alles.
Dus je bent continu bezig geweest om het weer compatible te maken,
nieuwe features te ondersteunen en, net als een echt software project,
je maakt ook keuzes, keuzes waar je later spijt van hebt.
Je hebt een bepaalde constructie bedacht,
een bepaalde API en later ontdek je van ja,
dat zit niet helemaal lekker in elkaar.
Mensen snappen het niet, dat is niet intuïtief genoeg.
Maar je kunt het niet zomaar aanpassen,
want je wilt geen breaking changes centraliseren.
En dat is nog steeds zo, zeker met het aantal downloads,
zie je ook dat mensen dingen gaan gebruiken op een manier die je niet verwacht had.
Of dat ze een bepaalde functie tijd willen toevoegen die gewoon niet past in het idee.
Je wilt dingen recht trekken.
Een heel mooi voorbeeld is, iemand voegt een nieuwe functie toe.
Ik wil een regular expression match methode hebben.
Als je dat wilt toevoegen, bijvoorbeeld voor strings,
misschien wil je die ook wel hebben voor collecties of zo.
Maar wat de contributors vaak doen, is alleen maar die ene feature toevoegen.
En als je als feedback geeft,
ja, het is niet helemaal consistent,
zou je diezelfde methode ook op die andere klas kunnen zetten,
dan hebben ze er vaak geen zin meer in.
Dat is een lastige. En ook kwaliteit van de code.
Ik wil ook, Flunt is voor mij niet alleen een library,
maar het is ook een soort van, hoe zou je het zeggen,
een voorbeeld van hoe ik vind hoe je code moet schrijven.
Ik heb daar een vrij sterke mening over.
En als iemand eens iets aanlevert,
wat hij in ieder geval doet, ja, wat doe je dan?
Ga je dan een review geven van, ja, ik wil geen far gebruiken,
of er moet betere documentatie op,
of zeg je van, ja, die persoon heeft wel zijn best gedaan,
laat ik het maar gewoon het werk voor hem doen of voor haar doen.
Ja, ja, dat kan ik me wel eens bevoorstellen,
want het is natuurlijk, ja, het is open source, het is gratis,
maar goed, iemand steekt daar gewoon heel veel tijd en effort in.
Andere zijn er tegelijkertijd ook afhankelijk van.
Dus ik snap ook wel dat je bijvoorbeeld,
als je vrijdagmiddag moet je nog even snel een test goed aan de praat krijgen,
dan blijkt er een issue te zijn.
Of is het niet helemaal duidelijk, zeg maar,
hoe een bepaald iets werkt met de Flute Assertions?
Dat kan ik me voorstellen.
Ik denk, nou, ik moet nu deze bug, die moet voor mij nu opgelost worden.
Maar ja, dat kun je niet verwachten van iemand.
Aan de andere kant van jou bijvoorbeeld, van, ja,
je gaat niet stil op sprong denken van nou,
ik ga nu voor hem en voor iedereen die dat op vrijdagmiddag doet,
dat probleem oplossen.
Dus dat, dus je van de gebruikers is te begrijpen,
maar van de maintainer of de eigenaar,
of de oprichter van het project.
Ja, kun je niet verwachten dat hij ook alles voor je doet.
Dus dat is wel, ja, wel.
Dat is een lastige balans soms.
Ja, ja, ja.
Je hoort echt best wel mensen die gewoon best wel populaire open source
project hebben, die gewoon echt denken van nou,
ik stop je gewoon mee, want ik krijg zoveel, ja,
hoe zeg je dat?
Negatieve feedback is vooral op github dan,
dat er echt een complete rant in zo'n github issue plaatsvindt.
Kijk, het voordeel van dit is een library.
Het is een library die je alleen maar in unit tests gebruikt.
Het wordt bijvoorbeeld een ander verhaal als jij een framework
bouwt.
In .NET space heb je best wel frameworks om bijvoorbeeld
beeld scripts te maken, cake, sake, nuke.
En daar zie je dat er vaak wat mensen achter zitten die vrij
specifieke mening hebben.
En dat betekent ook,
als het niet voldoet aan hun mening,
dat het ook heel lastig is om te overtuigen dat wat ze hebben
gebouwd bijvoorbeeld niet goed te gebruiken is in een groot
complex systeem.
Misschien omdat ze het zelf dat die ervaring niet hebben of
dat ze toch een bepaalde filosofie hebben.
En dat is ook heel lastig om het gewoon in tekst,
weet je wel, in een discussie op github,
op Slack, wat dan ook, uit te vechten om het zo maar even
te zeggen.
Ja, ja, precies.
Het is eigenlijk ook een beetje zoals, ja,
als je boos bent dat je eigenlijk niet verstandig is om dan
een mail te sturen naar iemand.
Het is eigenlijk een beetje hetzelfde medium, zeg maar.
En ja, er zijn eerlijk is eerlijk, zeg maar,
onder software ontwikkelaars zijn er wel een aantal
mensen die zijn redelijk, ja, direct of ja,
noem het misschien lomp, zeg maar.
Takloos.
Ja, precies.
Dus dat is nu eenmaal zo.
En die willen ja gewoon heel specifiek,
altijd op een heel specifieke vraag,
terwijl er best wel wat context bij komt kijken.
Ja, dat klopt.
Dus dat is wel een ding.
Ja, achteraf gezien zijn er echt zaken die jij
misschien in het begin anders had willen doen.
Ja, achteraf is altijd een beetje...
Ja, natuurlijk.
Ja, daarom is het een beetje een lastige vraag.
Of een beetje koffiedik kijken,
maar nee, ik ben eigenlijk wel tevreden
Weet je, het is...
Je hebt keuzes gemaakt,
maar het is...
Weet je, de keuzes die je maakt
zijn ook weer niet zo kritisch voor wie dan ook.
Nieuw releases maak je dingen weer wat netter.
Ja, je krijgt nu wel een beetje een soort van feature bloot.
Er zitten nu zoveel dingen in.
Ja, is het eigenlijk niet gewoon complete?
Maar goed, ik krijg nog steeds verzoek om dingen toe te voegen.
Nee, ik heb dat zeker niet.
Het is gewoon zo gebouwd.
Zou ik het anders doen?
Nee.
Het is ook geen architectuur die je neerzet.
Kijk, bij architectuur en complexe systemen,
daar heb je veel eerder de neiging om van, ja, ships.
Ik heb een bepaalde keuze gemaakt.
Achteraf was dat misschien een beetje naïef.
Maar ja, met een library zoals dit heb je daar helemaal geen last van.
Het is geen framework.
Dat scheelt al.
Heb je ook voor de luisteraars thuis een gouden tip
voor het opzetten van zo'n project?
Poeh.
Dat is wel een lastige.
Als ik daarover na had kunnen denken.
Nee.
Een open source project populair maken.
Ja, weet je, het is gewoon...
Ook al heb je een mooie oplossing voor een probleem,
dan is nog de vraag hoe uniek is dit?
En vinden mensen het?
Ja, ik denk uiteindelijk Twitter en een blog en dat soort zaken,
dat helpt heel erg.
Maar uiteindelijk is het ook maar gewoon gelukt dat iemand het ziet.
Weet je?
Het is in het algemeen wel mond-to-mond reclame.
Dat denk ik wel, grotendeels.
Dat zie je ook wel.
Heb je dat veel gedaan?
Nou ja, goed.
Kijk, ik kom af en toe wel eens op conferenties
en ik help best wel wat klanten natuurlijk.
Dus ik kom weleens hier en daar wat.
En je laat het gewoon zien, weet je.
In dit geval is het een heel laagdrempelige library.
Dus je voegt het toe en je kunt er aan het slag mee.
Je hebt geen learning curve, weet je.
Je hebt geen documenten die je moet lezen.
Dat helpt natuurlijk allemaal.
Maar het is meestal als mensen het dan zien.
Oh ja, dat helpt wel inderdaad.
En het is ook geen investment die je doet.
Het is niet van ja, maar nu gaan we een framework adopteren.
Ja, wat betekent dat voor ons?
Weet je, wat voor impact heeft dat op de lange termijn?
Dat is helemaal niet van belang.
Ja, je kunt het ook een doer, zeg maar.
Dat is een stap terug.
Dat is zonder dat in één keer alles instopt.
Dus dat is op zich het risico is redelijk klein om dit te gaan gebruiken.
Als je in de JavaScript wereld zit en je moet in één keer een keuze gaan maken tussen
we gaan Angular doen, we gaan React doen, we gaan Vue.js doen.
Ja, dat is een hele andere keuze.
Dat is een veel fundamentalere keuze.
Architectuur gaat over de keuzes die je maakt
en naar hoeverre die keuzes teruggedraaid kunnen worden.
Bij dit soort dingen is het natuurlijk gewoon een no-deal.
Ja, precies.
Een non-issue.
Non-issue, ja, precies.
Een no-deal, het zal wel...
Nee.
Oh ja, jij zet er ook andere kanten aan.
Dat is op zich gewoon een bijzonder verhaal, als ik dat zo kan zeggen.
Kijk, het project bestaat tien jaar.
Dat betekent dat je over die tien jaar hier en daar toch wel periodes had
dat je dezelfde mensen die jou hielpen, contributors,
die jou hielpen om het project verder te brengen.
En ik heb nu een gozer uit Zweden, Jonas Nierup, die heel erg actief erin is.
Maar die gozer, die is 3,24.
Dus toen ik begon met het project, zat hij nog waarschijnlijk nog niet eens...
was hij nog niet eens aan het studeren.
Maar er is ook een jongen geweest uit de Verenigde Staten
die jaren geholpen heeft.
Die is gegeven moment ook in het Vreemde Legion gegaan.
Omdat in een bepaalde fase van zijn leven heb ik zelfs nog een referentie geschreven.
En vorig jaar kreeg ik een keer een reactie op een pull request in GitHub
van zijn vader.
Oh, wauw.
Ja, echt.
Van dit is de vader van die en die.
En ik ben zijn accountant sluiten, want mijn zoon is overleden.
Oh.
Ja.
Oh, en hij was...
Natuurlijk, omdat hij in het Vreemde Legion is gegaan.
Of daar niet mee te maken?
Nee.
Oh, oké.
Nee, hij was depressief en heeft bepaalde keuzes gemaakt.
Ja, moet ik toegeven.
Ik ken hem nooit.
Ik heb hem nooit persoonlijk gezien.
Ik heb hem nooit gesproken.
Ik heb hem nooit op video gehad.
Maar ik heb wel jaren met hem toen nog op Flowdoc discussies gehad.
Ja, dat is toch wel even dat je denkt van even slikken.
Ja, dat hakte wel even in.
Dat lijkt me wel, ja.
En zijn naam is gewoon...
Ja, die is gewoon tot het einde den dagen onderdeel van mijn code base geworden.
Die zie je gewoon terug in commits en pull requests en issues.
Ja, precies.
Dan denk je toch eventjes van wauw.
Sjongejonge.
Ja, dat is wel waar.
Ja, want het hoort altijd wel...
Het komt wel wat dichterbij, zeg maar, als dit soort dingen gebeuren.
Maar goed, het heeft natuurlijk ook wel met leven te maken.
Dus ja, dat gebeurt dus wel.
Ja.
Ik vond het toch wel even de moeite waard om dat te doen.
Ja, ja.
Nee, dat is het zeker zo.
Ja, ik bedoelde dat mensen die staan niet stil bij dit soort dingen.
Had ik ook niet kunnen voorspellen, zeg maar.
En er zijn altijd mensen die hebben natuurlijk altijd wat vraagtekens over TDD of BDD.
Ja, dat moet je helemaal niet doen, want ja, stom.
En mijn code, die werkt toch wel.
Dat is wel een veel minder discussie dan voorheen.
Maar je merkt af en toe komt er weer zo'n golf.
Van ah, hoeft niet, weet je wel.
Nee, dat is allemaal niet zo heel belangrijk.
Ik weet niet hoe jij erin staat, zeg maar.
Nou ja, ik kijk.
Unit testen, TDD, ik doe dat nu denk ik bijna 15 jaar.
En eigenlijk, het is jammer dat we geen visueel aspect hebben in deze podcast.
Maar je hebt gewoon de hype cycle en daar heb je gewoon mee te maken.
Je ziet gewoon dat, en daar ben ik zelf ook onderdeel van geweest,
eigenlijk elke principe, elk concept waar we het over hebben,
daar zie je gewoon een facering.
Je ziet dat iemand het eens een keer hoort op een conferentie
of een collega die erover vertelt.
En dan zie je in het algemeen dat mensen zoiets hebben van,
nou, weet je, daar moet ik hier mee,
allemaal extra werk, weet je wel, dat hebben we niet nodig,
ik ben goed genoeg erin.
En dan worden ze enthousiast,
dit vertel ik ook al eens op mijn presentaties,
worden ze enthousiast, gaan ze toepassen,
worden ze heel erg enthousiast, enthousiast,
gaan ze helemaal los, gaan ze er misschien wel presentaties over geven,
gaan ze blogs over schrijven.
En dan ontdekken ze op een gegeven moment de keerzijde van zoiets.
Want geen enkele tool is, ja, ik geloof niet een silver bullet.
Dus wat je in dat gegeven moment ziet ontstaan,
is dat mensen eigenlijk een beetje last van de keuze die ze krijgen.
En daar een soort van mentaal een ombeslager gaan maken,
waarin ze zeggen van, ja, nee, maar TDD, dat is gewoon,
ik weet niet of je het mag zeggen, maar kut.
Ja, dat was waarschijnlijk, ja.
Ja, de vorige aflevering was ook redelijk...
Ja, dat was redelijk direct, ja.
Ja.
Het is helemaal shit en het leidt naar koppeling
en het zorgt ervoor dat je niks meer kan refactoreren
en dat soort argumenten.
En dan wordt het aan de kant geschoven.
Dat zie je eigenlijk met heel veel technieken.
Dat zie je met dependency injection containers,
dat zie je met event sourcing als een architectuurstijl,
coding standard, hetzelfde verhaal.
En wat je dan eigenlijk ziet,
is dat je heel veel van die senior developers hebben,
die dat dan hebben afgesworen,
want zij hebben namelijk gezien dat het niet werkt.
Ik ben zelf heel erg bewust van die hype cycle.
Ik heb zelf het idee dat ik wel redelijk ontdekt heb
van wanneer dingen niet werken, wanneer ze wel werken,
dat gaat alles.
En TDD is precies zo'n voorbeeld.
Ik ben ervan overtuigd dat het echt goed werkt,
maar je moet het goed toepassen.
Dat is nogal lastig.
Je moet een goede testscope hebben
en je moet het begrijpen wanneer je het wel of niet toepast.
Je moet niet gewoon alles op die manier doen.
Software ontwikkeling is gewoon best wel een creatief proces.
En soms moet je gewoon een stukje code gewoon eventjes schrijven
