Single Blog

Programmeren: Alles begin en eindigt met structuur

12 november 2019, Written by 0 comment

Stel je wil carriere maken in de IT en je wil programmeren of het vanuit je hobby is of het is een goede job opperunitie om programmeur te worden. Nu is er al jaren een te kort aan goed personeel in de IT en met name ontwikkelaars en dus heb ik al veel nieuwe ‘talenten’ voorbij zien komen maar programmeren is een vak, een ambacht en naar mijn mening niet voor iedereen weggelegd.

Een stukje persoonlijke geschiedenis

Zelf ben ik begonnen met programmeren als kind van 13 jaar op een Commodore 64. Voor de 40+ er onder ons de beste game console ooit gemaakt. Voor de wat jongere generatie een totaal onbekend systeem. Toen ik begon waren er twee keuzes. Of je programmeerde in BASIC of in Assembler.

Nieuw en enthousiast dat ik was, begon mijn eerste programeer ervaringen in BASIC. Zag er simpel uit en had een paar boeken met wat voorbeeld spelletjes erin. Noem het de ‘Hello World’ van gaming. Nadat ik wat van die voorbeelden had over getypt. Ja dat moest in die tijd nog zonder Internet, USB stick of floppydisks. Begon ik te begrijpen hoe ik dit zelf kon doen, en al snel zette ik mijn eerste kleine stappen in het programeervak.

Als echte gamer kwam ik er al snel achter dat programmeren in BASIC niet snel genoeg was om echte spelletjes te maken. Dus Assembler boek gekocht en daarmee aan de slag gegaan. Ineens kon alles wel snel maar echt eenvoudiger werd het er niet om want Assembler bleek toch wel andere koek maar uiteindelijk toch een basis aan kennis opgedaan. Helaas is het me nooit gelukt om een game te maken maar de ervaringen smaakte naar meer en ik besloot dat ik later game programmeur wilde worden.

Van hobby programmeren naar professional

Dus met deze droom/doelstelling naar de Universiteit getogen want dat was toch wel het hoogst haalbare niveau en daar zou ik wel de nodig kennis mee krijgen om deze droom te verwezelijken. Tot mijn grote verbazing kregen we geen enkel vak dat iets te maken het met het programmeren in C/C++. Toch wel de taal voor game development. Dit bleek later een heel belangrijke reden te hebben. C/C++ is een taal waarbij je makkelijk zonder structuur mee aan de gang kunt en daardoor snel spaghetti code kon maken. Nee, wij kregen imperatief programmeren in Modula2 (een variant van Pascel), programmeertechnieken en functioneel programmeren in Miranda.

Hoewel ik al 20 jaar niets meer met deze programeertalen doe bleken ze in mijn carriere wel een belangrijke houvast te bieden in alle andere talen die ik inmiddels beheers zoals, C/C++, Java, PHP, Python, Perl en Javascript.

Structuur aanbrengen voordat je begint

Veel beginnend programmeurs of nog in hun opleiding of cursus zitten worstelen met de standaard dingen. Ik heb het dan even niet over de grootste uitdagingen als debuggen of omzetten van een specificatie naar code. Ik zie vooral dat het al mis gaat in de opzet van de project structuur. Veelal worden bestanden met verschillende toepassingen in een folder gestopt waardoor er te veel bestanden in een map komen zonder dat er nog duidelijk is waarvoor dat bestand dient.

Begin dus wanner je bijvoorbeeld een simpele website maakt in HTML altijd een map structuur aan te legen waarin je een aparte map maakt voor je plaatjes, je javascript en je CSS. Dan kan je tenminste altijd terug vinden waar je je verschillende bestandtypen hebt staan.

Maar bij Java projecten werkt het bijna hetzelfde. Maak een source of src map voor je broncode. Een assets map voor je plaatjes en overige assets die je zo willen toevoegen. Een test map voor je unit tests en een deploy map voor alles wat je wil dat er gedeployed moet worden.

Het lijkt allemaal zo simpel. Helaas word het te vaak vergeten. Dat is jammer want zoeken naar wat je waar hebt gedaan wil niemand. Laat staan wanneer je de code van een andere moet veranderen.

Kortom begin met een goede structuur van je project. Daarna breng je structuur aan in je bestanden. Zoals bij Java Classes: Altijd eerst alle public en properties, daarna protected en onderin je private zaken. Zo kan een ander direct zien hoe de interface met je class eruit ziet. Dus niet alles door elkaar heen plaatsen. Nee, netjes op volgorde zodat je opvolger er snel mee aan de slag kan.

Geert van de Voorde