Embedded development is vaak complex, traag en afhankelijk van hardware. Maar dat betekent niet dat verbetering lang hoeft te duren. Veel vooruitgang zit niet in grote veranderingen, maar in kleine keuzes die je direct kunt maken. Keuzes die zorgen voor betere code, kortere feedbackloops en minder frustratie.
In dit artikel delen we vijf dingen die je morgen al kunt verbeteren – zonder dat je hele platform of toolchain op de schop hoeft.
1. Maak kleinere commits – en commit vaker
Versiebeheer is geen archief, maar een communicatiemiddel. Toch zie je in embedded projecten vaak enorme commits waarin dagen of weken werk zitten. Met als gevolg dat het lastig is om te reviewen, moeilijk te revert’en en bijna onmogelijk te testen wat de impact van één wijziging is.
Kleinere commits – bijvoorbeeld per fix, per functie of per aanpassing – maken je werk inzichtelijker en stabieler. Ze helpen reviewers sneller begrijpen wat er gebeurt, en maken het makkelijker om fouten te traceren als er iets stuk gaat.
Committen wordt soms uitgesteld omdat het builden of testen lang duurt. Maar juist dan is het belangrijk: je wilt weten wát je verandert, en wanneer. Een commit hoeft niet perfect te zijn – maar het moet wel coherent zijn. Denk aan: “cleaned up sensor init sequence” in plaats van “werkversie 3 laatste echt”.
2. Automatiseer ten minste één test in je project
Automatisch testen voelt in embedded development soms als een brug te ver. De hardware is complex, de omgeving lastig te simuleren en het voelt alsof handmatig testen sneller is. Toch is niets zo krachtig als geautomatiseerde feedback.
Begin klein. Je hoeft geen volledige HIL-setup te bouwen om te profiteren van automatisering. Schrijf één test die:
- een functie valideert zonder hardware-afhankelijkheid
- een scenario simuleert met een gesimuleerde input
- controleert of een statusflag correct verandert bij bepaalde inputs
Dat ene automatische testje bespaart je misschien al tientallen minuten per week – en het voorkomt dat een fout opnieuw insluipt.
De eerste stap is meestal de lastigste. Daarna wordt testen een gewoonte, geen obstakel.
3. Geef je fouten duidelijke foutcodes (en log ze)
Veel embedded systemen geven nog steeds generieke foutmeldingen: “Error”, “Status = 1”, of – erger nog – helemaal niets. Daardoor kost debuggen onnodig veel tijd, vooral als het probleem niet reproduceerbaar is op je ontwikkelbord.
Een simpele verbetering is het invoeren van foutcodes met betekenis. Bijvoorbeeld:
ERR_TIMEOUT_SENSORERR_INIT_MOTOR_FAILEDERR_DATA_OUT_OF_RANGE
Combineer dit met gestructureerde logging (bijvoorbeeld met timestamp en componentnaam), en je hebt een veel beter beeld van wat er misgaat – zeker als het in het veld gebeurt.
Nóg beter is het als je deze logs remote kunt uitlezen of bewaren bij incidenten. Maar zelfs zonder netwerkverbinding helpt het enorm als je weet wat fout ging, in plaats van alleen dát het fout ging.
4. Gebruik TODO’s en FIXMEs bewust (en werk ze bij)
Bijna elk embedded project zit vol met kleine notities in de code:
c
// TODO: beter afhandelen als sensor disconnected is
// FIXME: tijdelijke workaround voor bug #42
Op zich is daar niets mis mee. Maar als die opmerkingen niet worden bijgehouden of afgevinkt, worden ze ruis – en op termijn risico’s.
Gebruik TODO’s als een tijdelijke reminder met een duidelijk doel. Voeg eventueel een ticketnummer toe zodat het traceerbaar is. Plan regelmatig een korte review van openstaande TODO’s/FIXMEs, bijvoorbeeld tijdens een sprintwissel of releasevoorbereiding.
Door TODO’s actief te beheren, maak je je codebase betrouwbaarder en voorkom je dat ‘tijdelijke hacks’ permanent blijven staan.
5. Zorg voor een consistente codeopmaak – en automatiseer die
Veel teams discussiëren eindeloos over tabs vs spaces, waar accolades horen, of hoe lang een regel mag zijn. Maar al die discussies zijn zonde van de tijd als je tooling het voor je kan doen.
Gebruik een codeformatter (zoals clang-format voor C/C++ of black voor Python) en spreek samen één stijl af. Automatiseer het formatteren via pre-commit hooks of als onderdeel van je CI-pipeline. Zo voorkom je dat stijlverschillen een rol spelen bij reviews of mergeconflicten.
De winst zit niet alleen in nette code, maar ook in rust: als iedereen dezelfde opmaak gebruikt, kun je focussen op de inhoud in plaats van op spaties.
Samenvattend
Je hoeft niet te wachten op de volgende release of hardware-update om beter embedded software te maken. Veel verbeteringen kun je vandaag nog doorvoeren. Denk aan:
- Kleiner committen en vaker delen
- Eén eenvoudige test automatiseren
- Zinnige foutcodes gebruiken én loggen
- TODO’s actief bijhouden
- Codeopmaak automatiseren
Het zijn stuk voor stuk kleine aanpassingen, maar ze maken een groot verschil in samenwerking, kwaliteit en ontwikkelsnelheid.
En het mooiste: je hoeft er geen nieuwe tools voor te kopen of een lang projectplan voor te schrijven. Alleen een keuze om het morgen anders te doen.
_
Over Ndus3
De consultants van Ndus3 bewegen op het snijvlak van engineering en software. Ze ondersteunen bedrijven in de maakindustrie op projectbasis met oplossingen, advies en begeleiding. Vanuit een drietal vestigingen in Nederland kunnen engineers op een breed scala van vakgebieden ingezet worden bij klanten in de sectoren Manufacturing, Energy, Life-Science en Mobility. Op die manier bedient Ndus3 zijn klanten met lokale aanwezigheid en landelijke slagkracht!
Weten over deze case of wat we als Ndus3 voor jouw organisatie kunnen betekenen? Mail dan Gerben van Manen via gerben@ndus3.com of neem contact op via ons contactformulier.
