Dit artikel zal niet in elk detail van goede softwareontwikkeling of -ontwerp duiken. In plaats daarvan is het gebaseerd op de overtuiging dat alle principes voortkomen uit diepere overwegingen van goed codebeheer. Uiteindelijk zijn de beste praktijken diegene die passen bij de unieke benadering van jou en jouw team voor het creëren van kwaliteitscode.

Dit artikel bevat enkele tips om in de juiste richting te bewegen bij het bouwen van je nieuwe ecosystemen.

Het biedt je inspiratie om je op het juiste pad te brengen.

Zoals je in mijn bio kunt lezen, ben ik een ervaren ontwikkelaar geworden.

Ik heb meer ervaring opgedaan door fouten te maken en shortcuts te nemen dan door de heilige first-time-right code te typen.

Ik heb ook veel ervaring opgedaan door te zien hoe dingen in de loop van de tijd falen.

Daarom wil ik 8 dingen benadrukken die ik in het verleden heb geleerd en waarvan ik wenste dat ik ze wist als minder ervaren ontwikkelaar:

Heb je ooit Stack Overflow, GitHub-oplossingen of zelfs ChatGPT gebruikt om dat stukje code te kopiëren dat alles zou moeten laten werken?

Raden wat er gebeurde, de volgende dag blijkt het niet echt te werken zoals verwacht in productie. Nu moet je de flow van die gekopieerde code aanpassen en het goed laten werken. Aangezien je dit niet vanaf nul hebt gebouwd en er niet echt goed naar hebt gekeken, kan het je enorm veel tijd kosten om het goed te krijgen.

Vind een goede balans in het gebruiken van code die je niet eerder hebt gezien van andere bronnen. Controleer of het werkt zoals bedoeld binnen jouw oplossing, en ontdek de basisprincipes van de code die je hebt overgenomen.

Als development manager zeg ik altijd tegen teamleden dat ze zich moeten laten inspireren. We leren altijd nieuwe dingen: nieuwe manieren van coderen, technieken, oplossingen, benaderingen en zelfs nieuwe talen. Laat je inspireren door guru’s van over de hele wereld, maar volg hen niet om “cool” te zijn. Probeer af en toe waardevolle informatie te halen uit hun berichten, artikelen of video’s.

Een andere tip is: “doe dit niet tijdens klantentijd”. Ik gebruikte het woord ‘inspireren’ omdat je je eigen pad moet vinden, of dat pad moet vinden dat bij jouw team past. Je wilt waarschijnlijk 80% van de ideeën van je guru’s volgen, in plaats van 100%. Besteed geen weken aan geïnspireerd raken. Persoonlijk kijk ik eens in de twee maanden naar nieuwe dingen, op een regenachtige zaterdag (in Nederland hebben we er genoeg). Ik besteed gemiddeld ongeveer 2 uur elke 2 maanden. Het hangt ook een beetje af van de trends die er zijn. Als jongere programmeur besteedde ik hier veel meer tijd aan, en probeerde ik nieuwe dingen uit in hobbyprojecten. Dus toen mijn baas me de volgende keer vroeg om in te springen op nieuwe technieken, had ik al wat hobbyervaring.

Het deel over nieuwe technieken: kies ze zorgvuldig. In het begin probeer je op alles te springen wat je kunt grijpen, dat is natuurlijk. Naarmate je meer ervaring opdoet, ontdek je dat sommige nieuwe dingen nooit echt zullen doorbreken. Voor je het weet, kun je bijna voorspellen welke dat zijn. Het is ook niet slecht om af en toe naar iets compleet anders te kijken. Als .NET-ontwikkelaar kun je bijvoorbeeld eens JAVA proberen – zonder oordeel – en kijken of je het aan de praat krijgt. Houd je tijdens dit proces aan de basisprincipes. Je zult zien dat je dezelfde doelen kunt bereiken met een andere taal. Probeer hier een open geest te houden en de voor- en nadelen van die andere taal aan te wijzen. Sommige patronen worden meer gebruikt in C#, terwijl andere vaker voorkomen in JAVA.

Heb je je ooit afgevraagd hoe jouw oplossingen daadwerkelijk worden gebruikt? Of nog erger, heb je ooit code gebouwd zonder enig idee te hebben wie het gebruikt, of welk type gebruiker het gebruikt?

Het is niet zo ongebruikelijk dat wij programmeurs het overzicht verliezen van wat er precies gebouwd moet worden. Of beter gezegd, wat het doel van de applicatie is. Wat proberen we hier op te lossen of te automatiseren? Heel vaak missen we het grotere geheel.

Je bent heel diep in je code bezig om het werkend te krijgen. Je beslist welke patronen je moet gebruiken en maakt de code leesbaar. Een ander aspect waar je je mee bezighoudt, is hoe je verbinding maakt met de database-tabellen en waar je je data seedt en dergelijke dingen. Met andere woorden, veel van wat we dagelijks doen, gaat veel dieper dan het schilderen van het grotere geheel.

Dus, hoe gaan we hiermee om? Hoe kunnen we onze klanten tevreden houden met de eindresultaten? De truc hier is om eerder te “show down”. De meesten van ons fixen dingen totdat ze volledig werken en laten het dan aan de klant zien. Nu is de klant altijd tevreden, toch?……….

Fout, de klant is nooit helemaal tevreden. Hij laat een paar opmerkingen achter over de applicatie. En je hebt overuren gemaakt om het werk op tijd af te krijgen. Het probleem is nu dat de software niet zo flexibel is. Sommige opmerkingen zouden te lang duren om te fixen. Wat je nu waarschijnlijk zult doen, is concessiesoftware creëren – zoals ik het altijd noem. Je probeert de klant naar een minder tijdintensievere weg te leiden, zodat je je eindproduct kunt opleveren en het af kunt maken. En nu heb je een stuk software geleverd dat niet precies is wat de klant wilde.

Verkeerd! De klant is nooit volledig tevreden. Hij laat altijd wat opmerkingen achter over de applicatie. En jij hebt overuren gemaakt om het werk op tijd af te krijgen. Het probleem nu is dat de software niet zo flexibel is. Sommige opmerkingen zullen veel te lang duren om op te lossen. Wat je waarschijnlijk nu zult doen, is wat ik altijd “concessie-software” noem. Je probeert de klant te wijzen op een minder tijdsintensieve route, zodat je je eindproduct kunt leveren en het project kunt afsluiten. En nu heb je een stuk software geleverd dat niet precies is wat de klant wilde.

Laatste opmerking: zal dit leiden tot perfecte software? Hell no… je bent net begonnen. Wanneer de eindgebruikers de softwareproducten in de echte wereld gebruiken, zullen ze nog steeds dingen tegenkomen die ze anders zouden willen doen. Maar de hoofdrichting voorkomt dat je helemaal opnieuw begint.

Vroeger heb ik veel software ontwikkeld. Van kleine tools tot enterprise-oplossingen of klant-specifieke oplossingen die als gegoten passen. Het maakt niet uit wat je probeert te creëren; dingen kunnen plotseling groter worden. Dit is waar andere leden van het team in beeld komen en proberen dingen toe te voegen aan jouw tool, op maat gemaakte software, enterprise-oplossing of zelfs jouw hobbyproject.

Misschien niet eens volledig, maar je probeert een voorbeeld te geven van een bepaald probleem dat je eerder hebt opgelost. Wanneer deze voorbeeldfragmenten niet goed zijn geprogrammeerd, zal dit leiden tot dezelfde problemen als besproken in deel 5. De code kan niet worden gekopieerd of hergebruikt. Probeer dus dingen achter te laten die kopieerbaar zijn.

Het volgende dat je moet overwegen om geweldige software te creëren die de tand des tijds doorstaat, is een klein plan over wat te doen en wat niet te doen. In de .NET-wereld weet je waarschijnlijk wel iets over NuGet-pakketten of npm voor Angular, enzovoort. Deze pakketten moeten zorgvuldig worden geselecteerd. Zorg ervoor dat je pakketten gebruikt die je zelf hebt gemaakt, waarvan de code beschikbaar is, of pakketten die wereldwijd veelvuldig worden gebruikt. Dit voorkomt dat toekomstige updates je software breken.

Laatste tip: wanneer je op maat gemaakte software ontwikkelt—software specifiek voor één klant—probeer dan een standaard te stellen. Niet alleen technisch, maar ook functioneel. Probeer de software zo te bouwen dat deze ook voor andere typen industrieën kan worden gebruikt. Dit betekent niet dat je velden en tabellen aan de software moet toevoegen die nooit zullen worden gebruikt. Dit betekent dat als het bedrijf verandert, je flexibel bent in het aanpassen of toevoegen van nieuwe functies wanneer dat nodig is. Ik heb op de harde manier ontdekt dat werken met herbruikbare componenten veel beter werkt dan het hebben van aangepaste ontwerpen en benaderingen voor elk nieuw project. Ik zal daar een andere keer een artikel over schrijven.

Dit zijn enkele coachingtips om naar een professioneler resultaat te werken.