Essentiële tips voor ontwikkelaars die aan een nieuw project beginnen

Als ontwikkelaar voel je je soms wellicht wat overweldigd wanneer je aan een nieuw project begint. Van het configureren van je nieuwe laptop tot beste werkwijzen vinden en omgaan met containerisering; er is veel om rekening mee te houden. In deze blog coveren we een mix aan tips en handige trucjes die ons al hebben geholpen op eerdere projecten. Zo kan jij bepalen wat voor jou belangrijk is, en wat je eventueel links laat liggen of zelfs wilt vermijden. Laten we eraan beginnen! 

Welke codeerwijzen zijn de beste (voor mij)? 

Best practices voor codering zijn essentieel om kwaliteit te behouden. Ze zorgen ervoor dat je code clean, begrijpelijk en robuust is. Dat gezegd zijnde, zijn er veel methoden en acroniemen op de markt waardoor je je op den duur wellicht afvraagt welke je nog kan of moet gebruiken. Zonder te muggenzifterig te worden over elk principe, geven we je een kort overzicht mee van enkele methodologieën die de moeite waard zijn: 

1. SOLID is eigenlijk een verzameling van vijf principes: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, en Dependency Inversion. Samen helpen ze je om modulaire en onderhoudbare code te ontwerpen door scheiding van functies, uitbreidbaarheid en losse koppeling te bevorderen. SOLID is oprecht een solide methode. We raden aan het toe te passen op vrijwel elk stuk code dat je schrijft.
2. Clean Code refereert naar het schrijven van code die gemakkelijk te lezen en begrijpen is. Natuurlijk is dat subjectief, maar algemeen verwijst het naar de praktijken die beschreven zijn in het boek Clean Code: A Handbook of Agile Software Craftsmanship door Robert Martin. Het benadrukt helderheid, eenvoud, en het gebruik van betekenisvolle namen voor variabelen zoals functies en klassen. Net als SOLID zou je Clean Code eigenlijk altijd moeten gebruiken.
3. KISS staat voor Keep It Short and Simple en promoot eenvoud op meerdere vlakken, zoals code architectuur en implementatie. Het zorgt dat je onnodige complexiteit vermijdt en kiest voor simpele oplossingen. Als je SOLID gebruikt, gebruik je ook KISS.
4. CQRS (Command and Query Responsibility Segregation) is een patroon dat lees- en updatebewerkingen scheidt voor een data store. Je hoeft dit niet altijd te gebruiken; het hangt af van de applicatie en de architectuur van je project.
5. DDD (Domain-Driven Design) tot slot, is een aanpak die focust op het afstemmen van je softwarearchitectuur met je bedrijfsdomein. Het vergemakkelijkt communiceren met domeinexperten. Dit is eerder een beslissing op hoog niveau die wellicht al gemaakt is, en opnieuw erg afhankelijk van de applicatie en bestaande architectuur van je project. 

Nu we die vijf hebben overlopen, geven we je nog wat eigen praktische tips en best practices mee: 

• In onze ervaring is communicatie cruciaal om de beste methodes te bepalen en gebruiken. Meestal worden ze besproken tijdens architectuur en code reviews. Daarbij zullen de meer ervaren ontwikkelaars en/of architecten er al een paar bepaald hebben op voorhand. Zoals we eerder aanhaalden, zal het gebruik van CQRS en DDD dus waarschijnlijk al beslist zijn voor jou.
• Een goede manier om erachter te komen wat best practices zijn voor codering, is om open-source repositories te checken met meerdere bijdragen. Bekijk, bijvoorbeeld, de website van Microsoft en GitHub. Je kan veel leren van het bekijken en interpreteren van die code, net als van het werken met een senior ontwikkelaar.
• Besteed aandacht aan pull requests! Die maken het je gemakkelijker om codekwaliteit te monitoren en samen te werken met andere ontwikkelaars, én het leert je wel wat over de codebasis van je project.  

Het (on)belang van containerisering 

Containerisering is een gangbare praktijk wat betreft het moderniseren van monolithische applicaties, en terecht. Het is alsof je een complexe puzzel opbreekt in behapbare stukjes. Ze zijn veel flexibeler, kunnen draaien op elke cloudinfrastructuur, en laten je gemakkelijk opschalen. Tot slot elimineren containers beruchte scenario’s als: ‘het draait op mijn computer’. Ze zorgen voor consistentie over verschillende omgevingen heen, hetgeen je applicaties een betrouwbare runtime-omgeving oplevert. 

Als je probeert uit te vissen of containers en microservices de ‘way to go’ zijn, kijk je best eens naar de infrastructuur van je klant. Probeer erachter te komen welke processen onttrokken en veranderd kunnen worden in zelfstandige microservices. Lichte en tijdgebonden processen zijn vaak ideale kandidaten. 

Indien je beslist te werken met containers, zijn dit onze aanbevelingen: 

• Vermijd het gebruik van een ‘root user’ in je containers. Dat is alsof je iemand admin privileges geeft tot een applicatie en compromitteert dus de beveiliging van je diensten. 
• Gebruik multi-stage builds met twee verschillende omgevingen: eentje met de Software Development Kit (SDK) en de andere met de runtime-omgeving. Het helpt je om je containers schoon en efficiënt te houden. 
• Overweeg het gebruik van managed containeromgevingen in plaats van het opzetten en beheren van je eigen Kubernetes-infrastructuur. Zo kan jij focussen op je code.  
• Vergeet niet om regelmatig je containers te onderhouden. Houd ze up-to-date met beveiligingspatches en verwijder onnodige rommel. 

De volgende trend binnen codering: Microsoft Dev Box 

Als ontwikkelaar is een van de meest vervelende en tijdrovende onderdelen van een project, het verkrijgen van de juiste hardware, configuratie en toegang. Je krijgt een laptop van de klant en moet dan bijna een dag spenderen aan het correct installeren ervan. Dat gezegd zijnde, denken we dat dit snel zal verdwijnen. 

Microsoft Dev Boxes zijn kant-en-klare, projectspecifieke werkstations die vooraf geconfigureerd en centraal beheerd worden. Ze kunnen je krachtige, cloudbased ontwikkelomgevingen bieden, wat betekent dat jij je kunt concentreren op het schrijven van code. Je hebt geen fysiek apparaat van de klant meer nodig. Geen gedoe meer dus met toegang tot het beveiligde netwerk van de klant of een uur wachten op de installatie van Visual Studio. Dev Boxes zijn vergelijkbaar met GitHub’s Code Spaces, maar met de extra voordelen van naadloze integratie binnen het Azure ecosysteem. 

Dev Boxes zijn nu al een paar maanden beschikbaar in GA (General Access), maar misschien heb je er nog niet van gehoord. Wij denken echter dat het een van de meest gangbare praktijken zal worden en de toekomst van coderen zal veranderen, vooral voor grotere organisaties en ambitieuze projecten. 

Samengevat 

Een nieuw project starten kan best spannend zijn voor een ontwikkelaar, maar met de juiste tips kan je de uitdagingen zelfzeker aan. In deze blog hebben we de verschillende best practices voor coderen geëxploreerd die je kan gebruiken, hoe je kan starten met containerisering, en waarom wij denken dat Microsoft Dev Box weleens de toekomst kan zijn. 

Als we nog een laatste advies mogen meegeven, is het dat je je altijd open moet blijven opstellen naar nieuwe ideeën toe, dat je best zo effectief mogelijk communiceert met je team en blijft leren, van welke bron je ook verkiest. Happy coding, en moge je projecten een knallend succes worden! 

 

Heb je al ervaring opgedaan ondertussen, maar ben je plots ook aangesteld als leider van andere ontwikkelaars? Check dan zeker onze andere blog: Wat je moet weten voor je een eerste project leidt als ontwikkelaar. 

Wil je graag samen meer leren over coderen? Bekijk onze vacaturepagina en laat ons weten waar je naar op zoek bent!