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 de juiste richting op te gaan bij het opbouwen van je nieuwe ecosysteem(s). Het biedt je inspiratie om op het juiste pad te komen. Zoals je in mijn bio kunt lezen, ben ik een ervaren ontwikkelaar geworden. Ik heb meer ervaring opgedaan door fouten en shortcuts te maken dan door de heilige eerste keer goed code te typen. Ik heb ook veel ervaring opgedaan door te zien hoe dingen in de loop der tijd mislukten.

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:

In mijn vroege twintiger jaren heb ik veel onafhankelijk bereikt. Ik ontwikkelde websites, webapplicaties, tools en zelfs volledige systemen helemaal zelf. Er waren maar weinig problemen die ik niet kon oplossen. Als je momenteel aan het begin van je carrière staat, herken je misschien dit gevoel. Anderen leken mijn vooruitgang alleen maar te belemmeren. Dit resulteerde in een overvloed aan code die ik alleen moest beheren. Echter, dat was nooit een probleem. Ik blink uit in het gelijktijdig jongleren met meerdere taken. Wees gerust, ik heb het onder controle.

Plotseling besef je dat je hoog op een golf van zelfvertrouwen hebt gereden, en dat je applicaties hebt ontwikkeld die klanten adoreert. Maar oh, het verhaal wordt ingewikkelder! Net wanneer je jezelf als een tovenaar in het coderen beschouwt, begint de toren van code te wankelen. Terwijl je dieper ingaat op de mysterieuze kunsten van goed programmeren, dringt het tot je door dat je misschien, heel misschien, een paar code-omwegen hebt genomen. Pogingen tot reparatie voelen als het ontcijferen van oude hiërogliefen (Heb ik dit echt geschreven?). Welkom in de Vallei van Wanhoop, waar niet eens de dapperste zielen het aandurven om alles weg te gooien en opnieuw te beginnen, hoewel die gedachte wel door je hoofd schiet. Vroeger was samenwerking de spreuk die ik in mijn toverboek verwaarloosde. Nu, als een doorgewinterde tovenaar van software, zie ik de kracht van peer review en het creëren van code die zelfs gewone stervelingen kunnen beheren. Als ik deze gezamenlijke toverkunst eerder had omarmd, zou mijn code misschien niet zoveel aanpassingen hebben hoeven ondergaan, niet alleen voor nieuwe trucs maar ook voor de oude. Samenwerken in het rijk van code versterkt niet alleen je digitale creaties, maar weeft ook een sterkere band binnen het team van programmeurs. Vergeet niet, de echte uitdaging van coderen is niet alleen spreuken voor jezelf uit te spreken, maar ook betoveringen achter te laten die het hele team kan gebruiken. Deze collaboratieve kunst beklimt hoogtes die veel verder reiken dan de eenzame tovenaar. Dus investeer de tijd om die krachtige, leesbare toverdrank van code te brouwen.

Dit onderwerp draait allemaal om het hebben van logica op één plek. Ik denk dat dit waarschijnlijk het meest betwiste onderwerp in softwareontwikkeling is. Ik weet wat ik moet coderen, maar waar moet ik het plaatsen? Je kunt hier veel over lezen als je het DRY-principe googelt: Don’t Repeat Yourself. Als softwareontwikkelaar wil je dingen eenmaal doen, en alleen eenmaal.

Dit principe kan de tegenhanger zijn van het creëren van leesbare code, dus je moet hier heel voorzichtig mee omgaan. En nu zeg ik niet dat het een slechte praktijk is, absoluut niet. Zorg er gewoon voor dat je dit bespreekt met andere ontwikkelaars, zodat ze nog steeds begrijpen wat er in de code gebeurt.

Code op één plek hebben houdt ook in dat je gegevens toegang hebt tot een tabel of dataset op één plek. Dit voorkomt dat je vanuit verschillende delen van het systeem naar dezelfde tabel schrijft en zorgt ervoor dat de volgende ontwikkelaar er vertrouwen in heeft om de code te wijzigen indien nodig. We splitsen backend (API) services en zorgen ervoor dat ze alleen naar hun eigen schema schrijven wanneer een enkele databaseaanpak wordt gebruikt.

Veel van de dingen die we creëren, zijn om processen voor onze klanten te automatiseren. We maken dingen gebruiksvriendelijk en zorgen voor gegevensinvoer met de minste mogelijke inspanning. Zelfs het vervangen van repetitieve taken door volledig geautomatiseerde oplossingen. Goed werk, jongens.

Maar een ontwikkelaar vergeet vaak dat repetitieve taken ook verborgen zijn in het ontwikkelingsproces zelf. Bijna dezelfde code keer op keer typen. Refactoring kost veel tijd om de hele codebase consistent te maken. Dat is waar tools van pas komen. Nu gebruiken we in mijn vakgebied veel HTML, C#, Razor/Blazor, SQL, JavaScript en wat JSON. In het verleden heb ik veel tools gemaakt in dezelfde taal als de output van de generatortools. Dit leidde vaak tot hoofdpijn. Daarom besloot ik om daar een beetje verandering in aan te brengen door Python als toolset te gebruiken om dit te bereiken. Het tweede voordeel was het leren van de Python-taal.

Maar wat je hier ook kiest, zorg ervoor dat je het gebruikte code opnieuw overdenkt voor het bouwen van de applicaties die je net hebt afgeleverd. Misschien is er een manier om een deel van je werk te automatiseren. Het algemene idee — vooral bij het creëren van een volledig ecosysteem — is om het volgende project met minder moeite te bouwen in vergelijking met het vorige.

Zoals we eerder hebben besproken in het onderwerp “ga niet solo”, probeer alles samen te doen wanneer je kunt. Dit betekent ook dat alle geschreven code door het team jouw verantwoordelijkheid is. Aangezien je deel uitmaakt van het team, zou je het moeten kunnen oplossen, net als iedereen in het team. (Ik weet dat er soms verschillende disciplines zijn).

Je hoeft dit gedeelte opnieuw niet alleen op je schouders te nemen, dit is ook een teaminspanning. Wanneer iemand vastloopt, help elkaar dan. Leer samen over de gemeenschappelijke uitdagingen die voor jullie liggen. Een ander ding dat ik vaak zie, is dat mensen naar anderen wijzen; dit heeft de code nooit plotseling laten werken. Dit is dus nutteloos. Aan de andere kant, wacht niet te lang met vragen om hulp, we zijn hier samen in.

Volg ons om toegang te krijgen tot deel 2, waar we de andere 4 onderwerpen bespreken die eerder op deze pagina zijn genoemd.