Dev Summit: "Toekomstbestendige apps? Terug naar de basis"

Op de Dev Summit 2024 zullen veel nieuwe, maar ook bekende gezichten ijzersterke talks, masterclasses en workshops verzorgen. Nadat hij vorig jaar succesvol zijn debuut had gemaakt, is Peter van Vliet, softwarearchitect en medeoprichter van Masking Technology opnieuw van de partij binnen de devops-track. Dit keer geeft hij de masterclass 'Hoe bouw je toekomstbestendige applicaties?'. Nu al beginnen met de voorpret? Dan download je hier Event-app Developers Summit 2024.

Peter is een doorgewinterde IT-specialist met meer dan twintig jaar ervaring. Tot zijn zestiende levensjaar had hij weinig interesse in computers, maar een eerste kennismaking met programmeren veranderde alles. Sindsdien heeft hij zich ontwikkeld van junior tot ervaren full-stack ontwikkelaar, met expertise in technologieën zoals Java en .NET. Tegenwoordig werkt hij veel met JavaScript en TypeScript en is hij mede-eigenaar van Masking Technology, een klein IT-bedrijf dat hij samen met een compagnon runt. Het bedrijf richt zich op het efficiënter maken van software-ontwikkelingsprocessen en het toekomstbestendig maken van applicaties.

In zijn werk komt Peter veel uitdagingen tegen, vooral bij de voortdurende doorontwikkeling van applicaties. "Verandering is de enige constante", zegt hij. Dat betekent vaak dat applicaties voortdurend moeten worden aangepast om bij te blijven. Organisaties worstelen met deze aanpassingen, vooral wanneer bestaande onderdelen opnieuw moeten worden ontwikkeld. De complexiteit van veranderingen en de hoge druk om mee te gaan met de nieuwe requirements legt een grote last bij softwareteams, aldus Peter.

Discipline en het beperken van requirements

Een van de principes die Peter en zijn compagnon hanteren, is het beperken van requirements tot de essentiële onderdelen. "We zijn vaak geneigd om een lange backlog op te bouwen", legt hij uit. "Wij zeggen: kijk naar de must-haves en pak die op." Hij wijst erop dat requirements die niet onmiddellijk nodig zijn, vanzelf terugkomen als ze echt belangrijk blijken. Door requirements bewust klein te houden, wordt onnodige complexiteit vermeden en kunnen ze sneller inspelen op veranderingen. De focus wordt dan behouden op wat echt belangrijk is, en het voorkomt het jaarlijks evalueren van de backlog om oude items die niet meer relevant zijn te verwijderen.

In zijn aankomende masterclass deelt Peter inzichten en praktische vuistregels. "We gaan de hele softwareontwikkelingscyclus door, van de eerste requirements tot aan het onderhoud", vertelt hij. Hij legt uit dat een goede basis begint bij een nauwkeurige selectie van requirements en eindigt bij zorgvuldig onderhoud. "Het draait om discipline in het volgen van regels, maar met de flexibiliteit om deze aan te passen als dat nodig is." Een groeimindset is hierbij volgens hem essentieel; ontwikkelaars moeten bereid zijn om bestaande regels los te laten wanneer veranderingen dit vereisen.

Ruim je oude rommel op

Peter benadrukt het belang van het maken van duurzame keuzes. Hij raadt ontwikkelaars aan om te kiezen voor bewezen frameworks en libraries die op de lange termijn ondersteund worden, zelfs als ze minder trendy zijn. "De 'saaie keuze' is vaak de betere keuze", zegt hij. Peter heeft ervaren dat applicaties soms langer in gebruik blijven dan oorspronkelijk gepland. Dit heeft geleid tot zijn focus op keuzes die passen binnen de verwachte levensduur van een applicatie.

Een ander punt dat Peter benadrukt, is de noodzaak om elke regel code zorgvuldig af te wegen. “Elke regel code die ik schrijf, brengt onderhoudskosten met zich mee. Moet ik die regel wel schrijven?". Hij moedigt ontwikkelaars aan om alleen noodzakelijke code toe te voegen, omdat overbodige functionaliteiten op termijn meer onderhoud vereisen. Peter deelt ook een motto dat hij vaak hanteert: "Ruim je oude rommel op". Dit betekent dat functionaliteiten die niet meer worden gebruikt, snel uit de applicatie moeten worden verwijderd, om het systeem overzichtelijk en onderhoudsvriendelijk te houden.

Hij wijst op het belang van consistentie bij het volgen van eenvoudige regels, zoals het beperken van abstracties en het vermijden van afhankelijkheden die de flexibiliteit beperken. Deze basisregels, die ogenschijnlijk eenvoudig zijn, vergen volgens Peter toch een bewuste, gedisciplineerde aanpak om ze goed te implementeren.

Terug naar de basis

Peters doel voor de masterclass is om deelnemers aan te moedigen tot bewuste keuzes en ze te helpen nadenken over de langetermijngevolgen van hun beslissingen. “Ik wil het publiek triggeren om niet alleen maar te rennen, maar juist even stil te staan en na te denken over elke stap", vertelt hij. Hij hoopt dat zijn tips en inzichten deelnemers helpen om hun eigen ontwikkelprocessen te verbeteren, en ze weerbaarder maken tegen de constante veranderingen in de technologie.

Als afsluitende boodschap benadrukt Peter het belang van eenvoudige, universeel toepasbare regels die direct waarde kunnen bieden. "Die simpele regels geven houvast en helpen om toekomstbestendige keuzes te maken", concludeert hij. "Terug naar de basisprincipes, maar met een moderne blik."

Zo koop je je tickets voor de Developers Summit

De kaartverkoop voor de Developers Summit is alweer even gaande, dus zorg dat je snel je kaarten in huis haalt zodat je hét event van het jaar niet hoeft te missen. Tickets zijn verkrijgbaar voor 299 euro (plus 1,99 euro servicekosten) of als ‘3 halen, 2 betalen’-deal. Vergoedt jouw werkgever de tickets? Dan ontvang je een factuur voor de administratie. Persoonlijke gegevens worden niet gedeeld met partners.

Kijk hier voor het privacybeleid van Tweakers.

Ben je student? Mail ons dan via [e-mail], zodat je een ticket kan kopen voor een gereduceerd tarief van 75 euro.

Reacties (24)

[roelboel]

Hij raadt ontwikkelaars aan om te kiezen voor bewezen frameworks en libraries die op de lange termijn ondersteund worden, zelfs als ze minder trendy zijn.

Daar heb ik wel iets over te zeggen in het teken van toekomstbestendigheid: ik zou willen stellen dat frameworks minder toekomstbestendig zijn dan libraries. Waarom? Een framework bepaalt het wereldbeeld van je code. Jouw code leeft in de realiteit van het framework. En daarmee is de levensduur van jouw code afhankelijk van het voortbestaan van het framework. Een library daarentegen die niet meer voortbestaat is veel minder catastrofaal.

Daarnaast: frameworks werken uitbreiding tegen en zijn niet samen te stellen: https://tomasp.net/blog/2015/library-frameworks/
En nog meer te lezen: https://plbrault.com/blog-posts/the-problem-with-frameworks/

[Reactie gewijzigd door roelboel op 12 november 2024 12:03]

[SPee]

Dat ligt aan het framework en het ecosysteem waarin het zit.
Robuuste frameworks die al jaren bestaan en langzaam evolueren zijn ook in de toekomst goed bruikbaar. Ja, je hebt vaak minder hippe mogelijkheden, maar het werkt en doet wat het moet doen. Zelfs 10 jaar later is de basis vaak nog hetzelfde. In mijn ervaring zouden bv Spring of JavaEE hier onder vallen.
Kijk je naar frontend frameworks, dan is het al meer dynamischer. Angular heeft met de stap van v1 naar v2 een te grote stap gemaakt, waardoor vele ontwikkelaars zijn weggevallen. Maar daarna is de evolutie bedachtzamer gegaan en is updaten naar de nieuwe versie een stuk makkelijker geworden.
Maar voor de frontend zijn er (zeker in de laatste 5-10 jaar) echt zoveel "frameworks" bijgekomen en die werken (helaas) niet goed samen of zijn goed doordacht. Een nieuwe framework oppakken is "trendy" en daar moet niet lichtzinnig mee omgegaan worden. Soms is het beter om "nee" te zeggen om een nieuw framework te gebruiken of toe te voegen en het met een bestaande framework op te lossen.
Voor libraries geldt eigenlijk hetzelfde. Want ik heb ook gezien dat een library evolueert tot een framework en dan heb je hetzelfde probleem.

[sfranken]

Daarnaast: frameworks werken uitbreiding tegen en zijn niet samen te stellen: https://tomasp.net/blog/2015/library-frameworks/

Is een blog van bijna 10 jaar oud nog relevant vraag ik mij af? Toegegeven, van front-end spul (JS, TypeScript, react, etc) heb ik 0,0 kaas gegeten..

[roelboel]

Ja, want het gaat om het conceptuele probleem van frameworks, dat onveranderlijk is.

[gitaarwerk]

Zoals eigenlijk met alles: "it depends", maar naar mijn ervaring, kan ik deze mening dnek ik wel delen. Daarbij vind ik eigenlijk dat een toekomstbestendigheid van een software product vooral samen gaat met de meer vanilla aanpak. Het is vaak niet sexy, ook soms meer overhead dan vernieuwingen die bepaalde frameworks/libraries/doorvertalingen vinden, maar het kunnen terugvallen op fundamentelen technieken, maken het meer bestand. Maar het zijn vaak wat veel variaties om alles over een kam te scheren.

Een architectuur met duidelijk doel waarom iets zo is, en waarom het zo zou moeten zijn, stelt men in staat beter te kunnen evolueren. Maar het hangt wel echt samen met hoe een bedrijf moet functioneren. Niet alle requirements zijn voorspelbaar (meer niet dan wel). Persoonlijk daarom van mening dat ook devs soms een stuk business mee moeten krijgen. Al zijn soms de meningen dat deze zich helemaal niet moeten bemoeien of ervanaf te weten (gegarandeerd altijd 'leuke gesprekken' )

[Ed Vertijsment]

Hoewel ik het in zekere mate met je eens ben moet je ook niet vergeten dat libraries die eigenlijk bijna een framework rol vervullen maar niet helemaal in de praktijk worden samengevoegd met andere libraries waardoor je niet 1 maar n keer een dependency moet onderhouden. Een voorbeeld is React, wordt vaak samen gebruikt met een router en mogelijk andere libraries van die orde waar andere frameworks meer geintergreerd zijn. Je moet dan niet alleen react, maar ook de router bijhouden, en op zo’n manier dat ze blijven samenwerken.

[Ed Vertijsment]

Als je toekomstbestendig en terug naar de basis samen in een argument wil zien: probeer even een lijstje te maken van breaking changes in zeg eens JavaScript of <taal X> en React <of library Y> en je krijgt een redelijk idee van een kostenfactor voor het gebruik van Y.

Daarmee wil ik niet zeggen dat je Y niet moet gebruiken en alles zelf in X moet gaan implementeren maar dit zijn wel afwegingen die je kan maken, dat zelfde geld voor architectuur en andere keuzes, vaak genoeg wordt er naar iets gegrepen omdat het hip is gepushed wordt door een leverancier zonder dat er een noodzaak voor is of daadwerkelijk bijdraagt aan de business case.

Saai is goed, en daar kan je beter alleen van afwijken als het echt nodig is.

[Xander2]

Als je toekomstbestendig en terug naar de basis samen in een argument wil zien: probeer even een lijstje te maken van breaking changes in zeg eens JavaScript of <taal X> en React <of library Y> en je krijgt een redelijk idee van een kostenfactor voor het gebruik van Y.

Dit is een sterk punt, wanneer je over toekomstbestendigheid praat heb je niet de juiste tool voor de job met JavaScript of derivaten omdat het web platform in beweging is en je gewoonweg geen invloed hebt op de onderliggende infrastructuur.

Wil je toekomstbestendig leveren dan moet je kunnen garanderen dat de onderliggende API's voor een gesteld jarentermijn beschikbaar en onderhouden blijven. Dat is er absoluut niet het geval bij JavaScript en heeft weinig te maken met requirements.

Stabiel, toekomstbestendig leeft op gespannen voet met veranderingen en als requirements/wensen zo vluchtig zijn is toekomstbestendig simpelweg een onmogelijke eis.

[Ed Vertijsment]

Dit is een sterk punt, wanneer je over toekomstbestendigheid praat heb je niet de juiste tool voor de job met JavaScript of derivaten omdat het web platform in beweging is en je gewoonweg geen invloed hebt op de onderliggende infrastructuur.

Ik wil ook niet zeggen dat je zonder libraries aan het werk moet, ik werk momenteel aan een op React gebaseerd systeem omdat de requirements daarbij aansluiten. Het punt dat ik probeer te maken is dat je niet React moet gaan gebruiken omdat het hip is, als een van de doelstellingen is om weinig onderhoud te hebben.

Dat is er absoluut niet het geval bij JavaScript

Dit klopt niet, JavaScript is in zeer sterke mate backwards compatible, om die reden heeft het nog steeds veel oude flaws. Bij JavaScript is het interessante dat de taal zelf wel erg stabiel is (dat betekent niet dat er geen nieuwe features bij komen) maar dat veel libraries dat niet zijn, vandaar dat ik het gebruikte om dit punt te maken.

Bij Python zie je bijvoorbeeld vaak het omgekeerde, de taal zelf is onderhevig aan veel veranderingen en gebruikt geen semver, waar veel van de libraries daarvoor dat wel doen.

[Xander2]

Het gaat niet om de taal JavaScript, want die is prima geborgd via ECMA standaarden.

De libraries zijn dat niet en dat is uiteindelijk waar je software op bouwt omdat interpreter en libraries een geïntegreerd geheel zijn.

[Ed Vertijsment]

En daarom mijn punt juist: vraag je per library of je de dependency wilt onderhouden.

[SPee]

Semver is niet de oplossing die het pretendeerd te zijn. Er wordt te verschillend mee omgegaan en regelmatig niet goed.
Bv een minor update, maar opeens wel van een hogere major framework afhankelijk zijn of aneere breaking changes.

[Ed Vertijsment]

Dat is dan een major change volgens Semver, anders mee omgaan is gewoon geen semver. Minor update = backwards compatible.

[SpiceWorm]

Je geeft 2 voorbeelden van dramatische frameworks wat dat betreft.

[Ed Vertijsment]

Ik noem er volgens mij überhaupt maar 1, en ik heb het bewust zo geschreven dat je het kan toepassen op elke library/framework/afweging naar keuze.

[SpiceWorm]

Sorry ik bedoel dat je twee voorbeelden geeft van talen/frameworks waar zeer veel verandering in is geweest dan in bijv c++ / c# .net / java.

[Ed Vertijsment]

JavaScript is backwards compatible, in tegenstelling tot React, dat is exact mijn punt. Wil je weinig onderhoud kan het dus interessant zijn om React links te laten liggen. JavaScript heeft wel veel verandering gezien, maar dat zou doorgaans niet moeten resulteren in het breken van bestaande code.

[HooksForFeet]

Of je leest The Pragmatic Programmer en je bent voor twee tientjes klaar.

[himlims_]

Is dat anno 2024 nog relevant?

[bzzzt]

Waarom zouden best practices niet meer relevant zijn na een aantal jaar?
Je kan de principes uit dat boek toepassen op alle softwareontwikkeling, van Cobol tot hippe JavaScript frameworks.

[jaapzb]

The pragmatic programmer is inmiddels een 20ste editie van die zeker nog relevant is. Ik heb hem vorig jaar pas voor het eerst gelezen. Zeker een aanrader. Ik zou dit boek veel eerder aanraden dan bijvoorbeeld de boeken van uncle bob

[HooksForFeet]

Eens, Uncle Bob heeft ook z'n waarde maar TPP is echt een standaardwerk waar iedere serieuze programmeur bekend mee zou moeten zijn.

Ik ben persoonlijk verder erg gecharmeerd van Code Complete omdat ik daar ooit mee begonnen ben, maar het is wel een erg dikke pil en ik denk dat bijvoorbeeld Clean Code en The Clean Coder van uncle Bob hetzelfde in minder tekst weten over te brengen, maar na TPP zijn dat allemaal wel goeie boeken om te leren hoe je nou echt goed programmeert, en dat dat iets anders is dan "iets dat goed werkt" produceren.

[brammerd21]

Tis wat minder pragmatisch en ik ken Paul Peter niet, maar luisteren naar iemand die boeiend kan spreken heeft zijn eigen waarde.

[Reactie gewijzigd door brammerd21 op 12 november 2024 13:14]

[mutley69]

Ik wordt vrolijk van dit artikel. Het is blij in deze droevige tijden dat er nog gezond verstand bestaat en dat het kritisch denken niet verdwenen is. Hoe men dat realiseert moet eigenlijk kunnen veranderen en dat lijkt mij doenbaar. Ik herinner me een uitspraak van een bedrijfsleider die zei dat een test om van de ene databank engine op de andere over te stappen gedurende een week - bijna een miljoen € had gekost. Dan val je bijna achterover (nu dat was geen klein pakket dat getest werd).