Inhoud
Wat vooraf ging (computationeel denken)
U hebt het te programmeren probleem reeds onderworpen aan computationeel denken. zodat u het probleem volledig begrijpt en reeds een stappenplan (algoritme) hebt opgesteld om het probleem op te lossen.
- Door decompositie hebt u het probleem ontleed in kleinere, handelbare (deel)problemen.
- U hebt patronen ontdekt en door verdere abstractie hebt u een model (of modellen) ontworpen van datgene dat u nodig hebt (Denk aan het model van een kat om een kat te kunnen tekenen).
- U hebt een stappenplan (algoritme) opgesteld om het probleem op te lossen.
Zover bent u. Het probleem is begrepen, de te gebruiken modellen zijn doordacht en een stappenplan (of stappenplannen) zijn klaar en geëvalueerd.
U bent klaar om te programmeren. Maar hoe begint u nu eigenlijk met te programmeren?
Een paar praktische methoden, principes en tips volgen hieronder.
Ontwerpmethoden
Er zijn twee belangrijke ontwerpmethoden:
- Top-down
- Bottom-up
Ik zou er nog een derde willen aan toevoegen:
- Event-driven
Voor ik deze methoden meer in detail bespreek, weet dat het geen drie totaal afzonderlijke methoden maar dat ze tijdens het programmeren ook kunnen en mogen gecombineerd worden.
Top-down ontwerpen
Bij top-down begint u bij het algemeen, complexe probleem dat u gaandeweg opdeelt in kleinere deelproblemen (ook wel procedures, functies, modules of subroutines genoemd). Hebt u deze omschrijving nogal eens gelezen? Inderdaad, het heeft veel weg van decompositie bij computationeel denken.
Subroutines, procedures, modules of functies, hoewel het geen echte synoniemen zijn en er, naargelang de programmeertaal, onderlinge verschillen kunnen zijn en dat daarenboven geldt dat sommige programmeertalen enkel maar één van deze begrippen gebruikt (Java en C# kennen enkel maar het begrip functies) verwijzen ze in deze tekst alle vier naar hetzelfde, namelijk een deelprogramma. Of anders gezegd, programmeercode die gegroepeerd wordt onder een specifieke naam en die via deze naam kan aangeroepen en uitgevoerd worden.
Praktisch begint u met het hoofdprogramma (in sommige programmeertalen wordt dit main() genoemd) dat een aantal subroutines (procedures, functies) oproept. Vervolgens worden elk van deze subroutines geprogrammeerd al kunnen deze subroutines op zich weer andere subroutines oproepen,…
Top-down ontwerp is de eerste keuze bij meer klassieke procedurele programmeertalen.
Praktisch voorbeeld: een website bouwen
Stelt dat u een website moet bouwen. Door computationeel denken weet u reeds wat u nodig hebt.
Nu u aan de slag gaat om de website te bouwen zou u de top-down methode kunnen toepassen (zou kunnen want top-down is niet de enige methode die u kunt gebruiken. De keuze is aan u, de programmeur/ontwerper).
U begint met het ontwerpen van de startpagina die ook de navigatiemenu bevat. Deze navigatiemenu bevat alle linken naar de onderliggende pagina’s. Vervolgens gaat u deze onderliggende pagina’s ontwerpen. Bevat zo’n onderliggende pagina opnieuw een link naar andere pagina’s dan gaat u ook deze ontwerpen.
U werkt u dus van de top, de meest algemene pagina, naar omlaag naar de meer specifieke pagina’s.
Bottom-up ontwerpen
Bij Bottom-up begint u met de “technische” onderdelen te programmeren. Eens de onderdelen geprogrammeerd zijn worden deze samengevoegd tot ze het uiteindelijke programma vormen. Hebt u ooit iets gebouwd met lego? Wel, dan hebt u bottom-up gewerkt.
Objectgeoriënteerd programmeren werkt volgens het bottom-up ontwerp. Door computationeel denken hebt u een model vastgelegd (denk aan het model van een te tekenen kat). Dit model bevat de eigenschappen/kenmerken die nodig zijn (om een kat te tekenen). Bij objectgeoriënteerd programmeren vertrekt u van dit model, dat hier een klasse wordt genoemd. Deze klasse bevat alle eigenschappen (properties) en methoden (de algoritmen, berekeningen, bewerkingen,… die met, of op, het model kunnen worden uitgevoerd) waaruit het model bestaat. Deze klassen vormen de bouwstenen voor de objecten, de basis waarmee het programma op gebouwd wordt.
Praktisch voorbeeld: Star Citizen
Star Citizen is momenteel het meest ambitieuze “computerspel”. Het heeft de intentie om een geheel universum te bouwen waar u in kunt rondvliegen/lopen en dit alles in 3D en “real time”. Het is een open project wat betekent dat u veel van de ontwikkeling kunt volgen via wekelijkse video’s op hun website.
Om een universum te bouwen werkt u best niet top-down. Want dit zou betekenen u begint bij het universum zelf, nadien de zonnestelsels die het universum bevat, nadien de planeten en manen, nadien pas de schepen die kunnen landen op deze planeten, enz. Kortom, een top-down benadering zou snel problematisch worden om zo’n complex “spel” te programmeren.
Een bottom-up ligt meer voor de hand. Star Citizen vertrekt vanuit basisfunctionaliteiten, technische uitdagingen die ze eerst oplossen. Nadien laten ze deze samenvloeien tot het complexe geheel in dit geval een “living universe”. In grote lijnen is Star Citizen begonnen met:
- het ontwerpen van een paar ruimteschepen.
- de hangar waar de ruimteschepen zich bevinden en waar u ze in 3D kunt bekijken.
- het “vlieg”-model voor deze schepen en een bijhorende “Arena” waar dit kon getest worden.
- het ontwerpen van een ruimtebasis.
- het FPS-gedeelte (First Person Shooter).
- de landing van uw ruimteschip op een planeet/maan.
- …
Al deze onderdelen worden eerst geprogrammeerd. Eerst wordt de basis (bottom) gelegd en nadien wordt er vanaf deze basis opgebouwd (up) tot het hele universum uiteindelijk in mekaar sluit.
Het voordeel van de bottom-up methode is o.a. dat u:
- eerst de technische problemen kunt oplossen.
- de technische problemen eerst afzonderlijk kunnen uitgetest worden.
- dat u eerst een eenvoudigere oplossing kunt ontwerpen om dan later naar een meer geavanceerde oplossing over te schakelen.
Event-driven ontwerpen
Events/gebeurtenissen zijn acties die kunnen gebeuren of uitgevoerd worden tijdens het werken met het programma. Voorbeelden van events zijn:
- de pagina wordt geladen
- de pagina is geladen
- de gebruiker klikt op een knop
- de gebruiker beweegt de muis over een object
- de gebruiker typt een toets in
- …
Bij event-driven programmeren wordt de “control flow”, de opeenvolging van de uit te voeren instructies, van het programma bepaald door de volgorde waarin de events/gebeurtenissen plaats vinden. De instructies die horen bij het klikken op een specifieke knop worden pas uitgevoerd indien er daadwerkelijk op die specifieke knop gedrukt wordt.
Programma’s die veel interactie vragen van de gebruiker zoals interactieve websites, mobiele apps, eenvoudige spelletjes zijn vaak event-driven. Deze programma’s beschikken dan ook vaak over een geschikte gebruikersvriendelijke GUI (Grafische User Interface).
Bij event-driven ontwerpen bouwt u (vaak) eerst de GUI en bedenkt u welke events er kunnen plaatsvinden of nodig zijn (let op, de GUI wordt gebouwd met de nodige events in gedachte, zo zal u een knop toevoegen aan de GUI juist me de bedoeling om er op te kunnen klikken en niet andersom. U gaat geen knop plaatsen omdat die er mooi staat en u vervolgens de vraag stellen wat er zou kunnen gebeuren als u op deze knop zou drukken). Vervolgens programmeert u elk van deze events.
Programmeerprincipes
Voor u aan het programmeren slaat moet u weet hebben van een aantal belangrijke programmeerprincipes. Deze programmeerprincipes dient u in het achterhoofd te houden als u aan het programmeren gaat.
Ik bespreek hier slechts een beperkt aantal, belangrijke, programmeerprincipes. Sommige programmeerprincipes die typisch zijn voor een bepaalde manier van programmeren (bv. het programmeerprincipe S.O.L.I.D. dat typisch is voor objectgeoriënteerd programmeren) kunnen later, ten gepaste tijde, aangekaart worden.
De 3 programmeerprincipes die hier aan bod komen zijn:
- DRY – Don’t Repeat Yourself
- KISS – Keep It Simple, Stupid
- YAGNI – You Ain’t Gonna Need It
DRY – Don’t Repeat Yourself
DRY is simpel gezegd: schrijf geen twee keer dezelfde code.
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Bovenstaande quote gebruikt twee (nieuwe) begrippen: piece of knowledge en representation.
Stel, u moet connectie maken met een databank. Om connectie te maken met een databank hebt u, een paar lijnen, programmeercode nodig. U plaatst deze programmeercode in een subroutine (functie, procedure, module, deelprogramma, u kiest de juiste benaming zelf maar). Deze subroutine krijgt een specifieke naam. De code in de subroutine is de piece of knowledge de naam van deze subroutine is de representation waarmee de piece of knowledge wordt aangeroepen.
De subroutine, en de bijhorende code, wordt slechts eenmaal geschreven. De representation die deze subroutine aanroept wordt iedere keer hergebruikt waar u de piece of knowledge, in dit geval de connectie met de databank, nodig hebt.
Als u nog een stapje verder wilt gaan dan kunt u stellen dat de subroutine eerst wordt toegekend aan een variabele die de functie van representation op zich neemt. Iedere keer u de piece of knowledge van die subroutine nodig hebt doet u dat via deze variabele.
By the way, een variabele is een voorbehouden locatie in het computergeheugen waar u een waarde kunt bijhouden/stokkeren voor later hergebruik. De variabele heeft een naam en is vaak van een specifiek type. Het type bepaalt het aantal bytes dat gereserveerd wordt in het computergeheugen voor deze variabele en de naam van de variabele wordt gebruikt om toegang te krijgen tot deze locatie in het computergeheugen. De waarde die wordt bijhouden in die locatie, en waar de variabele naar verwijst, kan in de loop van het programma variëren/wijzigen. Later komen we specifiek terug op het begrip variabele.
Waarom is het DRY-principe belangrijk?
Als u tegen dit principe zondigt, en u herhaalt dezelfde code herhaaldelijk, dan zal u bij iedere potentiële wijziging aan deze code, deze wijziging moeten herhalen op alle plaatsen waar u de code gebruikt hebt.
Stel, u wilt een specifieke foutboodschap weergeven. Deze foutboodschap zal op meerdere plaatsen gebruikt worden. U kunt zondigen tegen het DRY-principe en deze foutboodschap telkens waar u ze nodig heeft opnieuw intypen. Maar stel dat u de foutboodschap wilt wijzigen. Dan moet u overal waar u deze foutboodschap ingetypt hebt de wijzigingen aanbrengen (en hopelijk vergeet u er geen te wijzigen).
Past u het DRY-principe toe dan hebt u die foutboodschap (piece of knowledge) wellicht aan een variabele (representation) toegekend die u nadien herhaaldelijk gebruikt hebt. Als u nadien de foutboodschap (piece of knowledge) wilt wijzigen moet u enkel maar op die ene plek, waar u de waarde aan de variabele hebt toegekend, de wijziging aanbrengen.
Door DRY te programmeren:
- wint u tijd (omdat u sneller fouten kunt verbeteren vermits u ze maar op één plek moet verbeteren).
- beperkt u de kans op fouten.
- maakt u de code ook leesbaarder.
Het is eenvoudig om te zondigen tegen het DRY-principe!
Stel, u hebt een eenvoudig programmaatje waar u op een gegeven ogenblik een eenvoudige berekening moet maken (bv. een BTW-berekening). Dit is een eenvoudige berekening die u ter plekke uitvoert. Op een andere plek in het programma moet u opnieuw een BTW-berekening maken. U herschrijft uw berekening opnieuw. Op dit moment bent u eigenlijk al aan het zondigen tegen het DRY-principe omdat u dezelfde berekening herhaald hebt.
Wat had u dan moeten doen om DRY te programmeren?
Op het moment dat u de eerste keer die berekening moest programmeren had u zich de vraag moeten stellen of u diezelfde berekening (diezelfde code) nog eens zou kunnen nodig hebben. Indien die kans bestaat plaatst u deze code (piece of knowledge) in een subroutine en gebruikt u een verwijzing naar deze subroutine (representation) telkens u die code nodig hebt, dus telkens u de BTW wilt berekenen.
Kopiëren en plakken van code binnen hetzelfde project/programma is zondigen tegen het DRY-principe. Iedere keer u dus op CTRL-C drukt (u weet wel de sneltoetsen om te kopiëren) met de bedoeling te CTRL-V’en (plakken) binnen hetzelfde project/programma, weet dan dat u op het punt staat te zondigen tegen het DRY-principe en denk even na of het echt niet anders kan!
Weet dat programmeercode zelden 100% DRY zal zijn, het is ook geen echte ramp wanneer code twee keer wordt getypt, maar DRY moet wel een streefdoel zijn.
Functies gebruiken om het DRY-principe toe te passen
Praktisch worden aan het DRY-principe tegemoet gekomen door het gebruik van functies.
When you find yourself writing code that is similiar or equal to something you’ve written before, take a moment to think about what you’re doing and don’t repeat yourself.
KISS – Keep It Simple, Stupid
KISS is simpel gezegd: wanneer de oplossing te complex lijkt is er wellicht een simpelere oplossing.
The simplest explanation tends to be the right one.
Eigenlijk is hiermee bijna alles gezegd. Als een oplossing te complex lijkt, als de code te complex oogt, dan is het waarschijnlijk niet de meest efficiënte en correcte oplossing.
Dit betekent ook vaak dat u het probleem eens moet vanuit een andere invalshoek bekijken, “Out of the box”.
Stel, uw opdrachtgever heeft klantinformatie in een Excel-lijst geplaatst en hij wilt deze Excel-lijst kunnen importeren in het programma dat u aan het programmeren bent. Als u de Excel-lijst als een Excel-bestand op zich probeert te importeren dan hebt u heel wat programmeerwerk voor de boeg. Zo’n Excel-lijst, in Excel-formaat, bevat immers ook heel wat typische Excel-functionaliteiten die u eigenlijk niet nodig hebt maar die u moet mee verwerken indien u het wilt importeren.
Maar… Excel heeft een export-functie naar een CSV-formaat en een CSV-bestand is niet meer dan een tekstbestand met waarden gescheiden door een scheidingsteken (meestal een puntkomma) en dus zonder al die overbodige Excel-functionaliteiten.
Dus, heeft het een KISS en programmeer de import van een CSV-bestand, veel simpeler.
Houdt het KISS-principe ook in uw achterhoofd wanneer u op zoek gaat naar code op het internet. Internet is een schat aan inspiratie voor het oplossen van programmeerproblemen. Alleen, als u zoekt naar een probleem krijgt u vaak heel wat mogelijke oplossingen voorgeschoteld. Bekijk gewoon de oplossing en lijkt ze u op het eerste zicht te moeilijk, te complex, ga dan maar verder op zoek naar een meer simpele oplossing, u zult ze zeker vinden.
Waarom is het KISS-principe belangrijk?
De toepassing van het KISS-principe leidt tot simpelere code, minder codelijnen en dus minder kans op fouten en gemakkelijker te debuggen!
One way to minimize the amount of bugs in an application is to maximize the number of lines of code that aren’t written, and avoiding needless complexity is a sure way to help achieve this goal.
Everything should be made as simple as possible, but no simpler. — Albert Einstein
Simplicity is the ultimate sophistication. — Leonardo da Vinci
YAGNI – You Ain’t Gonna Need It
YAGNI is simpel gezegd: programmeer niet wat u niet (direct) nodig hebt.
Always implement things when you actually need them, never when you just foresee that you need them.
YAGNI gaat uit van 2 feiten:
- U hebt steeds te weinig resources (geld).
- U loopt reeds achterop uw tijdschema.
Dus:
- Programmeer functionaliteiten (die echt nodig zijn) en geen features (die leuk zijn te hebben)!
- Programmeer nog geen functionaliteiten die u nog niet meteen nodig hebt!
YAGNI slaat vooral op het tweede punt: “programmeer nog geen functionaliteiten die u nog niet nodig hebt ook al voorziet u misschien dat u ze in de toekomst nodig zult hebben.”. Het is dus een variant, een aanvulling op het KISS-principe.
Dit laatste kan misschien wat raar lijken. Als u denkt/verwacht dat u de functionaliteit nodig zult hebben, ook al is er op dit ogenblik nog geen directe behoefte aan, waarom zou u het dan al niet meteen programmeren, dan bent u ervan af?
Vergeet niet dat:
- U steeds geld- en tijdgebrek hebt!
- U nu reeds achter loopt op uw tijdschema!
Dus, waarom zou u het nu al programmeren als u het pas later nodig hebt? Aangezien u het nog niet meteen nodig hebt is er nog steeds de kans dat:
- U het uiteindelijk niet nodig zult hebben.
- U tegen de tijd dat u het nodig hebt misschien een beter inzicht gekregen hebt en u het daardoor efficiënter kunt programmeren.
- U de code zo langer simpel houdt (KISS-principe).
Een praktijkvoorbeeld
Ik heb, pas dit schooljaar, de opdracht gekregen een evaluatietool te programmeren die door mijn collega’s leerkrachten gebruikt wordt om evaluaties, en bijhorende punten behaald door de cursisten, in te geven. Een leuke functionaliteit zou zijn dat het mogelijk moet zijn een vroegere evaluatie, van het vorige schooljaar, opnieuw te hergebruiken als een “nieuwe” evaluatie voor het huidige schooljaar.
Die evaluatietool is zo goed als “af” en heeft een eerste test door mijn collega’s met succes doorstaan. Toch is de bovenstaande functionaliteit nog niet geprogrammeerd omdat er op dit ogenblik nog geen vorig schooljaar is en er dus nog geen evaluaties van het vorige schooljaar zijn die te hergebruiken zijn.
Het is niet uit luiheid dat ik dit nog niet geprogrammeerd heb, nee, het is het toepassen van het YAGNI-principe!
Waarom is het YAGNI-principe belangrijk?
Stel dat u het YAGNI-principe niet toepast. Dat u zondigt tegen het YAGNI-principe en dat u alles meteen wilt programmeren en ook veel “onnodige”, maar misschien wel leuke, features toevoegt (men noemt dit feature creep), dan loopt u het gevaar dat uw project:
- geen resources (geld) meer heeft voor het beëindigt is en het er misschien nooit komt.
- de deadline, als die er is, wellicht niet haalt.
- het niet simpel is (en dus zondigt tegen het KISS-principe).
Het al eerder genoemde Star Citizen zit wellicht in dit schuitje (hoewel ik voorzichtig ben want wie ben ik om iemand als Chris Roberts op de vingers te tikken?). Maar toch zijn er een aantal feiten rond Star Citizen die erop wijzen dat ze zondigen tegen het YAGNI-principe. Op het ogenblik van het schrijven is het project veel complexer geworden dan origineel bedoeld was en bevat het veel meer feautures. Het is geëvolueerd van een “space simulater” met beperkte landing in afgebakende gebieden op een beperkt aantal planeten naar een volledige vrijheid op elke planeet (en maan) met elk hun eigen fauna en flora en dit allemaal in first person 3D. Kortom he tis geëvolueerd, van een spel, tot het bouwen van een zo realistisch mogelijk universum.
Maar:
- Ondanks een budget van meer dan 150 miljoen (op het moment van het schrijven) zijn er geruchten (en acties van hun die deze geruchten lijken te bekrachtigen) dat ze stilaan in geldnood komen.
- Het project, of toch een belangrijk deel ervan (“Squadron 42”), had initieel moeten klaar zijn in 2015. We zijn nu halfweg 2017 en men zit nog maar in “alpha”. Iedere deadline, die ze zichzelf opgelegd hebben, hebben ze steeds met vele maanden overschreden. Een lanceerdatum lijkt nog veraf, meer zelfs het lijkt steeds verder weg.
- Er is een afnemende interesse van de originele “backers” die het project via Kickstarter hebben helpen lanceren waardoor het project voeling met de originele basis verliest.
Als Star Citizen uiteindelijk faalt zal het niet respecteren van het YAGNI-principe een hoofdoorzaak zijn!
The cheapest, fastest, and most reliable components of a computer system are those that aren’t there. – Gordon Bell
Debuggen
Debuggen is het proces van het opsporen en oplossen van programmeerproblemen.
Voor we aan de slag gaan met programmeren nog een paar tips over hoe u moet omgaan met foutmeldingen en waar u de juiste informatie haalt.
Er is niets verkeerd aan een foutmelding
Nu ja, uiteraard wel, een foutmelding wijst erop dat er iets fout is met de programmeercode. Maar, deze foutmeldingen horen nu eenmaal bij het programmeren en zeker wanneer u leert programmeren. Niemand heeft ooit een programma geschreven zonder dat er wel eens een foutmelding verscheen.
Het valt me ook op hoe een student die begint met programmeren vaak de moed verliest bij 2 foutmeldingen, daar waar ervaren programmeurs, die ik ook vaak in de les heb, rustig blijven bij 99 foutmeldingen. Ze zijn het immers gewoon geworden.
Dus, foutmeldingen horen bij het programmeren! Ze wijzen op iets dat verkeerd is in de programmeercode en ze dienen opgelost te worden. Maar… ze zijn nooit een reden tot paniek of een reden om de moed te verliezen.
The devil is in the detail
Als beginnende programmeur zal u zeker vaak geconfronteerd worden met foutmeldingen. Al even vaak zullen deze fouten details zijn.
Zo zijn vele programmeertalen hoofdlettergevoelig. Het eerste dat ik dus altijd controleer als een student me roept dat zijn programma niet werkt is nagaan of er geen typfouten gekropen zijn in de namen van de gebruikte objecten/variabelen/commando’s en nagaan of het hoofdlettergebruik consistent is.
Hiermee heb ik de helft van de fouten al opgelost.
Wees overtuigt van uw oplossing
Een groot probleem bij foutmeldingen is dat de beginnende cursist gaat twijfelen aan zijn oplossing (daar waar de fout vaak een detail is).
Vandaar dat het computationeel denken, dat vooraf gaat aan het programmeren, zo belangrijk is. Computationeel denken zorgt ervoor dat u het probleem volledig begrijpt en dat u een correct stappenplan (algoritme) hebt uitgewerkt om het probleem op te lossen. Van deze oplossing dient u dus overtuigt te zijn dat ze correct is! Met deze wetenschap weet u dat foutmeldingen voortkomen uit details of incorrect gebruik van een commando maar dat de fout niet in uw logica zit.
Oké, in realiteit zal u tijdens het programmeren vaak ook fouten in uw logica (algoritme) ontdekken maar eigenlijk zou dit niet mogen want het wijst op een foutief afsluiten van het computationeel denken.
Vindt u geen oplossing, neem dan eens afstand
Het is me al vaker overkomen dat ik de fout “niet zie”, dat ik niet meteen oplossing vind. Vaak helpt het om wat afstand te nemen van het probleem. ik heb er dan ook niets op tegen dat studenten tijdens het programmeren even het leslokaal verlaten. Ook al neemt u afstand van het probleem, onbewust blijft u verder zoeken naar de oplossing en heel vaak vindt u deze door afstand te nemen.
Als ik vastzit in een denkproces bezoek ik vaak “de kleinste kamer” om de een of andere duistere reden liggen daar veel oplossingen verborgen.
U kunt het niet weten, u moet het opzoeken
Ik heb jaren lesgegeven in Visual Basic. Het commando om een boodschappenvenster weer te geven is in Visual Basic (of in C#) onder Windows is MessageBox.Show("Hello, world.");.
Toen ik later overstapte naar Javascript bleek dit commando niet meer te werken (los van het feit dat dit commando niet aan te bevelen is internetbrowser-omgeving). In Javascript is het commando om een boodschappenvenster weer te geven window.alert("Hello, world");.
Hoe kon ik dit weten?
Ik kon dit niet weten, ik heb het moeten opzoeken!
Stel, u bouwt een website met een afgesloten gedeelte die een aanmelding/login van de gebruiker vereist. U wilt de gebruiker de mogelijkheid geven zich aan te melden met zijn Facebook-account.
Ook al hebt u al jaren ervaring in het programmeren van websites, de eerste keer dat u dit wilt implementeren (het kunnen aanmelden met uw Facebook-account) zult u, ook als ervaren programmeur, geen flauw idee hebben hoe, met welke concrete commando’s, u dit moet doen!
U zult het moeten opzoeken.
Waar?
In de documentatie van uw gekozen programmeertaal, in de documentatie van Facebook, via een zoekmachine op het internet.
De oplossing staat online
De oplossing staat online, vaak toch.
Als beginnende leerkracht moest ik een “nieuwe” programmeertaal geven (Turbo C++). Het programma werd besteld en een paar weken later werd een loodzware doos boordevol boeken en een paar diskettes afgeleverd. Ik kon beginnen de boeken te “lezen”. Stond de oplossing daar niet in, tja, dan moest ik het zelf uitdokteren.
Nu kunt u programmeeromgevingen, met bijhorende programmeertalen, gratis downloaden en dit zonder zware boeken.
De documentatie staat dan ook online.
Zit u met een vraag, een programmeerprobleem, een foutmelding die u niet meteen begrijpt, open dan uw favoriete zoekmachine en typ een gepaste zoekopdracht. U vindt meteen tal van mogelijke oplossingen.
Wees echter kritisch met online gevonden oplossingen. Een paar tips:
- Geef de voorkeur aan oplossingen die komen van de officiële website of van betrouwbare bronnen.
- Pas het KISS-principe toe. Lijkt de oplossing u te complex, zoek dan verder, wellicht bestaat er een simpelere oplossing.
- “Kopieer” de oplossing kritisch. Ik bedoel, de aangeboden oplossing zal nooit één op één passen in uw programmeercode (u gebruikt bv. andere benamingen). Gewoon kopiëren en plakken zal zelden lukken, u moet “intelligent” kopiëren en plakken, het moet geïntegreerd worden in uw programmeercode.
Weet niet van buiten, weet te vinden
Stel, u hebt het bovenstaande probleem van het aanmelden met een Facebook-account op uw website opgelost. Gaat u nu die programmeercode van buiten leren? Nee, allé, als u dat persé wilt doen mag u dat uiteraard, maar ik zou het niet doen.
Wat ik wel zal doen is ervoor zorgen dat ik weet waar ik de oplossing kan terugvinden door bv. een eigen “bibliotheek met oplossingen” aan te leggen waar ik de oplossing aan toevoeg, de website met de oplossing te bookmarken of gewoon door te onthouden waar ik de oplossing zelf al een geïmplementeerd heb.
Het kost me dan ook niet teveel tijd om de gewenste oplossing terug te vinden.
Slechts een handvol professionele programmeurs, met vele jaren ervaring, zullen volledige programma zonder iets op te zoeken, uit het hoofd, kunnen programmeren. Verwacht, en verlang, dit dus niet van u, beginnende programmeur. Er is niets mis mee als u iets moet opzoeken!
Een fout oplossen kan tot andere fouten leiden
Door het correct toepassen van het DRY-principe zou dit niet, of niet te vaak, mogen voorkomen maar toch gebeurt het vaak dat het oplossen van een fout tot nieuwe fouten op andere plaatsen in de programmeercode leidt.
Oké, dit zal zich niet zo vaak voordoen bij de eenvoudige problemen waar wij mee gaan leren programmeren, maar dit is zeker een veel voorkomende kwaal bij complexe programma.
Dus na iedere foutoplossing dient het programma opnieuw uitvoerig getest!
Hoe lost u uiteindelijk de complexe bugs op?
Iedere programmeeromgeving heeft wel een aantal tools om bugs te lijf te gaan (breakpoints, watches, step by step compiling,…). Aangezien deze gebonden zijn aan de ontwikkelomgeving, en ik het hier algemeen wil houden, ga ik hier niet verder op in. Maar weet, u lost complexe bugs vaak op … met “bloed zweet en tranen”.
Star Citizen is hier al een paar keer gevallen en de reden is dat u de ontwikkeling van dit ambitieuze project van nabij kunt volgen. Ze hebben ook een reeks waarin bugs worden getoond en opgelost (Bugsmashers). De gebruikte programmeertaal is C++, de meest gebruikte programmeertaal voor computerspelen, en is zeker niet de meest toegankelijke programmeertaal voor een beginnende programmeur. Dus als u deze filmpjes bekijkt, laat u niet afleiden, of ontmoedigen door de programmeertaal. Een mooi voorbeeld hoe bugs kunnen ontstaan en worden aangepakt in Star Citzen vindt u hieronder.
Behandelde Basiscompetenties uit de module ICT Programmeren – Start to program
- IC BC228 – kent de verschillende principes en onderdelen op basis waarvan een programma kan opgebouwd worden
- IC BC229 – begrijpt de basisprincipes van programmeren
99 little bugs in the code,
99 bugs in the code,
1 bug fixed… compile again.
100 little bugs in the code.
