Innovatie & Strategie

Dit is een bijdrage van Itility
Software-ontwikkeling
Software engineering: een balans tussen werkwijze en resultaat

Software engineering: een balans tussen werkwijze en resultaat

Softwareconsultants Nick, Aran en Thom delen hun visie op software engineering.

19 mei 2020
Door: Itility, partner

Softwareconsultants Nick, Aran en Thom delen hun visie op software engineering.

Wat onze kijk is op software engineering bij Itility?  We vroegen het onze softwareconsultants Nick, Aran en Thom. Aan de hand van drie stellingen delen zij hun visie over onderwerpen zoals software best practices, CI/CD, DevOps en consistente documentatie, waarmee ze een kijkje in de keuken van Itility geven en hun rol als software engineers toelichten.  

 

Voor een software engineer is de code die je schrijft niet de belangrijkste bijdrage aan het project.

Nick van der Veeken: Je belangrijkste taak is het vormgeven van de manier waarop software ontworpen, gebouwd en getest wordt. Dit zorgt ervoor dat alle subsystemen goed samenwerken en uiteindelijk zonder problemen draaien in productie. Hiervoor is een helikopterview over de verschillende projectfases noodzakelijk, maar ook een kritische houding ten opzichte van het proces, de architectuur, de organisatie en de technologie. Deze factoren zijn namelijk allemaal van invloed op de resulterende softwarekwaliteit. Natuurlijk besteed je tijd aan het coderen; dat is de kern van software engineering. Maar die tijd wordt onproductief als je niet genoeg tijd besteed aan het delen van kennis, het vaststellen van ontwerp- en documentatiestandaarden en het optimaliseren van de toolchain die gebruikt wordt voor CI/CD.

 

Voor een software engineer vindt de echte test plaats in productie.

Aran Vink: Als ik zeg dat de echte test plaatsvindt in productie, bedoel ik zeker niet dat code niet nauwkeurig getest hoeft te worden in een eerder stadium. Sterker nog, een geautomatiseerd testproces biedt heel veel meerwaarde. Echter kan het automatiseren van deze tests veel tijd en geld kosten. Het is dus belangrijk om eerst een goede inschatting te maken van hoe kritiek de applicatie is voor je product of service. Je hebt simpelweg geen ongelimiteerde middelen ter beschikking voor het schrijven van een geautomatiseerd testproces voor elke willekeurige applicatie/code. Je moet hierin met je klant de juiste balans zoeken tussen de kosten en de daadwerkelijke waarde die het oplevert. Zo weet je hoeveel je voor een bepaalde applicatie mag besteden aan testautomatisering, en hoeveel aan het testen en oplossen van problemen in productie. 

Kijkend naar de praktijk zien we dat automatische tests veel fouten uit je code kunnen filteren, maar de meest complexe situaties ontstaan in productie. Als je streeft naar een applicatie van hoge kwaliteit moet je er dus voor zorgen dat je snel kan reageren op fouten in de productieomgeving. Dat maakt een DevOps team van essentieel belang. Het constant monitoren en loggen van inkomende data kan onverwacht gedrag al vroeg signaleren, zodat het team kan reageren voordat er echte problemen ontstaan. De DevOps manier van werken zorgt daarnaast voor kortere ontwikkelingscycli, waardoor je flexibeler bent in het doorvoeren van veranderingen of verbeteringen binnen je applicaties. In andere woorden: als je op een agile manier te werk gaat en je voorbereid bent op snelle aanpassingen, dan is het testen in productie een ideale manier van werken.

 

Voor een software engineer is het je taak om jezelf overbodig te maken.

Thom Koomen: Dit betekent dat het werk dat je aflevert van dermate hoge kwaliteit moet zijn, dat toekomstige werkzaamheden ofwel geautomatiseerd zijn, ofwel makkelijk over te dragen zijn aan een collega. Uiteraard klinkt het controversieel om op een manier te opereren waardoor je mogelijk zonder werk komt te zitten, maar dit betekent ook dat je werkgever en/of klant jouw skills flexibel kan inzetten voor verschillende projecten en oplossingen. Bij een plotselinge behoefte aan jouw expertise binnen een ander project, verschuivende prioriteiten (waardoor je huidige werkzaamheden naar de backlog worden verplaatst) of een onverwachte afwezigheid/ziekte, moet een collega het werk zonder problemen kunnen oppakken waar jij gestopt bent.

Wat betekent dit voor je dagelijkse activiteiten? Naast het communiceren en documenteren van alle besluiten die je maakt, moet de software die je ontwikkelt logisch ontworpen zijn en daarmee begrijpelijk voor een ander. Het moet duidelijk geschreven en gedocumenteerd worden, er moet een consistente stijl, formattering en syntax gebruikt worden, en er moet een nette structuur en versiebeheer aanwezig zijn. In het kort: het schrijven van goed gedocumenteerde en makkelijk leesbare code. Hoe meer je jezelf overbodig kan maken, hoe meer je van waarde bent voor je werkgever en klant.

Dus hoe komt dit samen?
Kijkend naar de stellingen, zien we twee essentiële elementen van software engineering terugkomen: ‘wat je maakt’ en ‘hoe je het maakt’. Aan de ene kant wil je een betrouwbare applicatie bouwen met een moderne architectuur, en aan de andere kant wil je een effectief ontwerpproces en een gestroomlijnde softwareproductie toolchain. Hoewel vaak een tastbaar resultaat (wat je maakt) gevraagd wordt, zijn beide elementen even belangrijk. Zonder een goed fundament (hoe je het maakt) zul je het gewenste resultaat niet bereiken.

Voor meer blogs over software engineering, deep dives en best practices ga naar onze blogwebsite.

Reactie toevoegen