Sharing IT Best Practices with youSharing IT Best Practices with you
Gestructureerd programmeren
Een programmeerstijl is een set codeerregels die alle programmeurs moeten volgen bij het schrijven van programmacode. Gestructureerd programmeren maakt een goed programmeerstijl mogelijk. Wanneer meerdere programmeurs aan hetzelfde softwareproject werken, moeten ze vaak werken met de programmacode die door een ander is geschreven. Dit is lastig of soms onmogelijk, als alle ontwikkelaars een andere programmeerstijl volgen om het programma te coderen.
Een geschikte programmeerstijl omvat het gebruik van:
Deze afspraken maken de programmacode leesbaar en begrijpelijk voor iedereen, waardoor debuggen en het oplossen van fouten eenvoudiger worden. Ook helpt een juiste coderingsstijl de documentatie en bijwerking te vereenvoudigen.
Tijdens het coderen blijven de coderegels zich vermenigvuldigen, waardoor de grootte van de software toeneemt. Geleidelijk aan kunnen we om de stroom van het programma niet meer onthouden. Als we vergeten hoe software en de onderliggende programma’s, bestanden en procedures zijn opgebouwd, kunnen we het programma niet delen, debuggen of aanpassen. De oplossing hiervoor is gestructureerd programmeren. Het moedigt de ontwikkelaar aan om subroutines en loops te gebruiken in plaats van eenvoudige sprongen in de code. Daardoor is de code duidelijker en de efficiëntie verbetert. Gestructureerde programmering helpt de programmeur ook de coderingstijd te verkorten en de code correct te organiseren.
Gestructureerd programmeren geeft aan hoe het programma gecodeerd moet zijn en kent drie concepten:
Software maken we altijd om herhaalbare taken me uit te voeren. Deze zogenaamde bedrijfsprocessen staat bij ontwikkelaars bekend als het probleem. Het is dus erg belangrijk dat we begrijpen hoe we het probleem top-down moeten oplossen. Bij een top-down analyse splitsen we het probleem op in kleine stukjes waarin elk stukje een logische werking heeft. Ieder probleem lossen we individueel op. Een stappenplan maakt duidelijk hoe we het probleem stap voor stap op te lossen.
Tijdens het programmeren plitsen we de code op in een kleinere groepen van instructies. Deze groepen staan bekend als modules, subprogramma’s of subroutines. Modulair programmeren op basis van de gemaakte top-down-analyse. Het ontmoedigt sprongen met behulp van ‘goto’-instructies in het programma. Goto instructies zorgen vaak voor een niet traceerbaar programma. Springen in een programma moet je in de programmeerstijl verbieden, het hoort niet bij gestructureerd programmeren.
Verwijzend naar de top-down analyse, verdeelt gestructureerd coderen de modules verder in kleinere code-eenheden in de volgorde van uitvoering. Gestructureerd programmeren maakt gebruik van de besturingsstructuur, die de stroom van het programma bestuurt. Gestructureerd coderen daarentegen, maakt van een besturingsstructuur om de instructies in definieerbare patronen te organiseren.
De programmeerstijl kan per organisaties, besturingssysteem of programmeertaal verschillen. De volgende coderingselementen kunnen we zien als coderingsrichtlijnen van een organisatie:
Deze sectie geeft aan hoe we functies, variabelen, constanten en globale variabelen moeten noemen.
Dit zijn de spaties links aan het begin van de regel, meestal 2-8 witruimte of enkel tabblad.
Dit definieert de regels voor het schrijven van wiskundige, toewijzings- en logische operatoren. De toewijzingsoperator ‘=’ moet bijvoorbeeld een spatie ervoor en erna hebben, zoals in ‘x = 2’.
De regels voor schrijven if-then-else, case-switch, do-while en voor besturingsstroomstatements alleen en op geneste wijze.
Bepaalt hoeveel tekens er op één regel mogen staan, meestal is een regel 80 tekens lang. Afbreken definieert hoe een lijn moet worden ingepakt, als deze te lang is.
Dit bepaalt hoe we functies moeten declareren en oproepen, met of zonder parameters.
In de variabelen sectie geven we aan hoe we variabelen van verschillende gegevenstypen moeten declareren en definiëren.
Opmerkingen behoren tot de belangrijke coderingscomponenten, omdat ze in de code zelf beschrijven wat de code feitelijk doet. Daarnaast geven ze meer informatie over het programma in de code. Deze sectie is dan ook bedoeld als documentaties voor het onderhoud van de programmatuur.
Het maken van softwaredocumentatie is een belangrijk onderdeel van het ontwikkelproces. Goed geschreven documentatie is een geweldig hulpmiddel voor het vastleggen van informatie over het bedrijfsprocesdie nodig is om te weten over het softwareproces. Softwaredocumentatie biedt ook informatie over het gebruik van het product.
Een goed onderhouden documentatie moet de volgende documenten bevatten:
Deze documentatie is een belangrijk hulpmiddel voor softwareontwerper, de ontwikkelaar en het testteam om hun taken uit te kunnen voeren. Dit document bevat alle functionele en niet-functionele requirements van de bedoelde software.
Bronnen van dit document kunnen zijn:
Deze documentatie werkt als een basis voor de software die ontwikkeld moet worden en gebruiken we hoofdzakelijk in de verificatie- en valideringsfasen. De meeste testgevallen zijn rechtstreeks afgeleid van de requirements.
Deze documentatie bevat alle informatie die nodig is om de software te bouwen. Het bevat:
Deze documenten werken als repository voor programmeurs om de software te ontwikkelen. Hoewel deze documenten geen details bevatten over de codering van het programma, geven ze alle nodige informatie voor de codering, zoals de CRUD-matrix.
Deze documentatie houden de ontwikkelaars en de programmeurs bij. De documenten bevatten alle informatie over de code. Tijdens het schrijven van de code vermelden de programmeurs:
De technische documentatie vergroot het begrip tussen verschillende programmeurs die aan dezelfde code werken. Het verbetert de herbruikbaarheid van de code en maakt debugging eenvoudig en traceerbaar.
De gebruikersdocumentatie verschilt van al het bovenstaande. Alle eerdere documentatie is nodig voor het bijhouden van informatie over de software en het ontwikkelingsproces. Gebruikersdocumentatie legt echter uit hoe het softwareproduct zou moeten werken en hoe het je het gewenste resultaat moet krijgen.
Deze documentatie kan bestaan uit software-installatieprocedures, gebruikershandleidingen, verwijderingsmethode en speciale verwijzingen om meer informatie te krijgen, zoals licentieaanpassing enz.
Er zijn enkele uitdagingen voor het ontwikkelteam tijdens het ontwikkelen van de software:
Programmeerinterfaces van hedendaagse talen zijn zeer geavanceerd en beschikken over een enorme bibliotheek aan functies. Om de kosten van de ontwikkeling te verlagen, geven we er echter de voorkeur aan de code opnieuw te gebruiken. Het gaat om code die eerder is gemaakt voor andere software.
Elke keer als we nieuwe software aan klanten uitgegeven, moeten ontwikkelaars versie- en configuratiegerelateerde documentatie bijhouden. Deze documentatie moet zeer accuraat en op tijd beschikbaar zijn.
Het kan zijn dat de klant een totaal andere technische infrastructuur heeft dan de ontwikkelaar. De software die intern wordt ontwikkeld werkt dan in eerste instantie wel intern. Maar aan het einde van het project moet deze worden aangepast aan de host-machines van de klant. Soms is het onmogelijk om een software te ontwikkelen die ook werkt op de doelmachines.
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.