The principles of decoupling

De  applicaties waar je aan werkt worden bij elke sprint steeds een beetje groter en complexer. Naarmate de codebase groeit kom je steeds vaker pijnpunten tegen. De architectuur van je code sluit niet goed aan bij de toekomstwensen van de applicatie. Komt je dat bekend voor? Ons wel!

Scrum is een werkwijze die zich goed leent voor veranderende requirements. Logisch dus dat je niet van tevoren weet welke wensen er allemaal zijn voor de toekomst. Door een roadmap bij te houden kan je dit gedeeltelijk ondervangen, maar niet volledig. Het is dus normaal dat je constant moet bijschaven aan de architectuur van je applicatie.

In veel gevallen zijn er ‘design patterns’ die je kan toepassen. Een design pattern is een blauwdruk voor het oplossen van een vaak voorkomend probleem.  Door gebruik te maken van een bepaalde structuur in je code houd je je code onderhoudbaar en uitbreidbaar. Er zijn nog meer dingen die je kan doen om je development proces te stroomlijnen, daarover kan je meer lezen in de blog van Jeroen.

Veel developers worden enthousiast van het schrijven van ‘goede code’. Maar goede code schrijven kost veel tijd.  Hoe maak je de afweging wanneer je een design pattern toepast? En welke design patterns zijn dan juist erg nuttig? Zijn er ook scenario’s waarin je beter even geen ‘goede code’ kan schrijven? Met die vragen zaten een aantal van onze developers. Om die vragen te beantwoorden hebben we de hulp ingeschakeld van Matthias Noback.

Om te beginnen hebben we samen doorgesproken waar we precies tegenaan lopen en waarom dat voor ons een probleem is. Met onze input heeft hij een training samengesteld die inspeelt op onze vragen. Met een klein clubje hebben we een interactieve ‘ensemble programming’ sessie gehouden waarin we samen een simpele applicatie geschreven hebben. Daarbij ging Matthias de code schrijven, maar vertelden wij als groep welke code hij moest schrijven. Op die manier hebben we samen bestaande kennis versterkt en nieuwe kennis opgedaan over “The principles of decoupling”.

Het niet toepassen van ‘decoupling’ uit zich op veel manieren. Een van de meest tot de verbeelding sprekende voorbeelden is een ogenschijnlijk simpele wijziging die erg veel ontwikkeltijd kost. In veel gevallen is dit een teken dat er geen decoupling toegepast is.

Door decoupling goed toe te passen kan je een applicatie onderhoudsvriendelijker en daarmee ook toekomstbestendiger maken. Dat doe je door verschillende onderdelen van je code onafhankelijk van elkaar te maken. Daardoor hoef je niet bang  te zijn dat een aanpassing op één plek in de code er voor zorgt dat er op een andere plek iets kapot gaat.  Decoupling in combinatie met automatisch testen en een goede static code analyzer zorgt ervoor dat je een verandering snel en zorgvuldig kan opzetten. Wil je meer weten over decoupling? Dit artikel is een goed startpunt.

Met deze nieuw opgedane kennis kunnen we de steeds groeiende codebases van de applicaties van onze klanten weer elke dag een stukje beter maken!

Geschreven door: Maarten Kuiper