Als je als leider in engineering tot nu toe alleen maar gefocust was op:

• Uitvoerbare programma’s schrijven in een bepaalde tijd om te voldoen aan de behoeften van de klant/belanghebbenden
• Een product verzenden dat niet defect is en goed werkt
• Exacte productreleaseschema’s volgen

… nou, je doet het goed vanuit zakelijk oogpunt. Maar er is een belangrijk maar vaak verwaarloosd onderdeel van het bouwen van een product dat je misschien over het hoofd ziet – de basisprincipes van schone code.

Sommige leiders hebben de neiging om dit over het hoofd te zien en doen onrecht aan de technische kant van de productie.

Ja, hoe vaak heeft jouw team vastgezeten aan de rommelige code van iemand anders? Of vind je het erg moeilijk om functies te bouwen? Of op zoek naar goed geschreven documentatie als leidraad?

De kans is groter en al deze gebeurtenissen duiden op het toevoegen van meer technische schuld aan het product in de vorm van spaghetti-code.

En dat brengt me bij ons onderwerp,

Laten we eens kijken wat hij over dit onderwerp te vertellen heeft.

Keerthi: Op dit moment hebben bedrijven met legacy softwareproducten veel technische schuld opgelopen in de vorm van spaghetti-code. Wat zijn volgens u dingen die organisaties over het hoofd zien bij het bouwen van software?

Jana: Ten eerste denk ik dat het engineeringteam moet weten wat de leiding als prioriteit stelt; er kan bijvoorbeeld technische schuld en spaghetti-code in de codebasis sijpelen als er een agressief releaseschema is of als de engineeringprocessen zoals CI/CD niet op de juiste manier door de leiding aan hen worden uitgelegd.

Ten tweede moet het leiderschap een manier vinden om engineeringprocessen in te stellen die veel vergevingsgezindheid bieden.

Vaak stellen de leiders echt hoge verwachtingen in termen van zeggen – elke code die je schrijft moet volledig geautomatiseerd zijn, en dan zeggen ze, de verwachting is zo duidelijk dat ik niet zal toestaan dat je code incheckt die niet volledig geautomatiseerd is vanuit een teststandpunt.

Ontwikkelaars hebben echter altijd uitdagingen als het gaat om volledig geautomatiseerde testgevallen. Toch zijn ze soms in staat om te komen met wat ik noem – uitvoerbare testgevallen, in de zin dat het tenminste goed werkt in hun ID, Eclipse, enz.

In dat geval is er geen sprake van een goede cultuur, want ook al is de vraag juist en extreem hoog, er is geen vergevingsgezindheid.

We moeten ontwikkelaars toestaan om op zijn minst dat soort praktijken te omarmen, die ik extreem veeleisende maar vergevingsgezinde engineering praktijken noem.

Daarom is het cruciaal dat het leiderschap hier kennis van neemt en na verloop van tijd verbeteringen doorvoert in plaats van meteen in het begin heel hoge verwachtingen te stellen en het team te dwingen om te falen.

Keerthi: Jouw mening: Wat zet het engineeringteam ertoe aan om de code rommelig te maken?

Jana: Het is de bedoeling dat niemand een rommelige code schrijft. Mijn ervaring is dat dit meestal gebeurt als we jonge mensen in het engineeringteam hebben die ofwel een leercurve doorlopen of in de beginfase zitten – waar ze een andere bug gaan repareren of een nieuwe functie toevoegen zonder duidelijkheid over de technologie of het framework of de productinfrastructuur.

Softwareontwikkeling is namelijk een continu proces.

Ook al hebben alle continue processen geweldige standaard werkprocedures, nieuwe mensen die deelnemen aan het bouwen van oude dingen zullen dingen kapot maken, en dat komt vaak voor.

Dus ik denk dat ze een soort mentorschap nodig hebben of een voogd die er altijd moet zijn, of in ieder geval het grootste deel van de tijd.

En wat ik denk is – alle rommelige codes zijn geen technische schuld.

De technische leiding moet investeren in het bouwen van een codebase met veel verfijning op het gebied van betrouwbaarheid en robuustheid, die de codebase zal sandboxen tot een niveau waarop je weet dat de rommelige code geen invloed heeft op de bedrijfscontinuïteit en uiteindelijk geen kostbare fouten worden.

Keerthi: Wie is verantwoordelijk voor technische schuld?

Jana: Ik zou zeggen dat de persoon die eigenaar is van dat specifieke stuk code verantwoordelijk is, maar de leiding is verantwoordelijk.

Keerthi: Wat zit er achter de term “schone code”? Benadruk de voordelen voor de productkwaliteit en het bedrijf in het algemeen.

Jana: Er zijn een paar verwachtingen die ik heb met betrekking tot schone code:

1. Onderhoudbaarheid – Het moet eenvoudig genoeg zijn om begrepen te worden door iedereen die nieuw in het systeem komt.
2. Schone code is iets dat 24/7 werkt in een productieomgeving met een zeer minimale set problemen.
3. Schone code zorgt er altijd voor – het laat een goed auditspoor achter als er iets fout gaat.
4. Alles wat die codebase doet, moet worden blootgesteld als een API. Er mag niets worden gemasseerd in de code op bepaalde eigendomsbestanden of in sommige databases.
5. Schone code moet een duidelijke weergave van de bedrijfslogica bevatten. Het belangrijkste is dat het enige zin voor documentatie heeft op meerdere niveaus.

Samengevat, als een codebasis zo is gebouwd dat teams niet in productie hoeven te schieten, geen last-minute patchfixes hoeven uit te voeren, niet achter het schema op de releaseknop hoeven te drukken en geen last hebben van ontevredenheid van klanten, dan zou ik die code een schone code noemen.

Keerthi: Geef een paar tips om een code schoner achter te laten dan je hem hebt gevonden.

Jana: Leslie B. Lamport, een laureaat van de Turing award, zegt – Als je iets wilt doen, moeten we natuurlijk … allemaal introspectiemachines zijn en als ingenieur of ontwikkelaar, als je een software engineering probleem wilt oplossen, moet je schrijven.

“Schrijven is de manier van de natuur om ons te vertellen hoe slecht ons denken is.” – Leslie Lamport

Als je niet schrijft, denk je niet goed na.

Als ik schrijf zeg, heb ik het niet over code schrijven.

Ik heb het over iets schrijven voordat je code gaat schrijven.

Elke ontwikkelaar, of hij nu een kleine functie schrijft of een groot complex systeem ontwerpt, het is belangrijk dat hij zijn denkproces aanvult met schrijfopdrachten.

En het is niet de bedoeling om je schrijfspecificaties eruit te laten zien als een elegante poëzie. Het gaat erom dat je jezelf nooit ondubbelzinnig laat in termen van wat je wilt dat het systeem doet en wat je wilt dat het programma doet.

Keerthi: Hoe kan de technische leiding deze clean code-concepten samenbrengen om een foutloos product uit te brengen?

Jana: Ik denk niet dat we een schone codebasis willen onderhouden en minder op technische schuld willen scoren voor het uitbrengen van een ‘foutloos product’. We doen dat omdat we de ‘code agility’ willen verbeteren.

Met code agility bedoel ik – Heeft het team de mogelijkheid om features in een kortere tijdspanne te pushen?

Zou het mogelijk zijn om granulaire functies elke dag of meerdere keren per dag in productie te nemen?

Als leider in engineering zou je in staat moeten zijn om context te verzamelen en af te leiden uit deze engineeringprocessen, code commits of andere meetmethoden door een zeer geavanceerd proces op te zetten of gebruik te maken van platforms zoals GitHub om de wendbaarheid van code voortdurend te beoordelen en te verbeteren.

Vraag voor jou:

Wat vind jij van de onderwerpen die in deze editie van Z to A Pulse aan bod komen?

Laat ons je opmerkingen of suggesties hieronder weten. Schrijf u in om toekomstige edities te ontvangen met de meest opwindende onderwerpen op het gebied van engineering excellence.

Bedankt voor het lezen!

Lees meer als je geïnteresseerd bent:

1. HORUS: Een technische handleiding die Zuci volgt voor het samenbrengen van concepten voor schone code
2. De mythische man-maand: Essays over software-engineering
3. Denken en schrijven, met Leslie Lamport