Verzorging code
Functies en kritieke onderdelen in code (onderdelen die niet in één oogopslag te verklaren zijn) zijn voorzien van comments. Logische structuur in componenten van je project. Variabelen en functies hebben beschrijvende namen. Je bent je bewust van code conventies van de programmeertaal waarin je werkt.
Functies en kritieke onderdelen in code (onderdelen die niet in één oogopslag te verklaren zijn) zijn voorzien van comments.
Het thema van CLE4 was game design.
Hier was het de bedoeling om samen met je team een game te maken. Omdat iedereen een eigen level heeft is het belangrijk om duidelijk aan te geven wat mijn stuk code doet. Zo kunnen mijn teamleden mijn code misschien hergebruiken of verbeteren.
Logische structuur in componenten van je project.
In mijn code heb ik alle alle variabelen die bij elkaar horen bij elkaar gezet in de code. Dit is zodat ik dan meteen naar de code van die specifieke variabele kan gaan.
Een logische structuur brengt overzicht in je structuur. Hieronder zie je daarom ook dat er onderscheid word gemaakt tussen dev en docs.
– In de dev map worden de functionaliteiten van de game geschreven. Hierin word er gecodeerd in TypeScript, dit wordt compiled naar JavaScript ES6.
– In de docs map worden de HTML, CSS, Images en JS pagina’s gelezen.
– .gitignore is een file die mappen onzichtbaar maakt deze worden niet gepusht.
– tsconfig.json is een file met daarin compileropties die instructies meegeeft wanneer er van de codeertaal TypeScript naar JS wordt compiled.
– README.md bevat gebruikersinstructies en algemene informatie over het product.
Variabelen en functies hebben beschrijvende namen.
Ook hebben de variabelen en functies een passende naam. De platformen heten platform de achtergrond heet background etc. Ik heb ervoor gekozen om het in het Engels te doen omdat de code door meerdere mensen kan worden gesnapt.
Je bent je bewust van code conventies van de programmeertaal waarin je werkt.
Coderingsconventies zijn stijlrichtlijnen voor de programmeertaal waar je in werkt. Ze hebben betrekking op:
– Benoemings- en declaratieregels voor variabelen en functies.
– Regels voor het gebruik van witruimte, inspringing en opmerkingen.
– Programmeerpraktijken en -principes
Codeerconventies veilige kwaliteit:
– Verbetert de leesbaarheid van de code
– Maak code-onderhoud eenvoudiger
– Codeerconventies kunnen gedocumenteerde regels zijn die teams moeten volgen, of gewoon uw individuele codeerpraktijk zijn.
https://www.w3schools.com/js/js_conventions.asp
https://google.github.io/styleguide/jsguide.html#file-name
https://levelup.gitconnected.com/coding-conventions-for-writing-javascript-f3f697f6b4a5
https://phaser.io/docs/2.6.2/Phaser.Text.html
De code conventies van Javasript kun je op meerdere websites terug vinden. Ook is er een van Phaser.
Versiebeheer
Je kan met een versiebeheersysteem samen aan een product werken, waarbij ieders inbreng gelijkwaardig is. Je kunt uitleggen hoe versiebeheer werkt, en waarom dit geschikter is voor samenwerken aan code dan bijv. Dropbox. Commits zijn klein en beschrijf je ook kort en bondig.
Je kan met een versiebeheersysteem samen aan een product werken, waarbij ieders inbreng gelijkwaardig is.
Hoe werkt GIT precies:
De versiebeheersysteem waar in CLE4 in gewerkt is heet GIT. GIT zorgt ervoor dat je makkelijk aanpassingen kan maken aan de code. GIT documenteert ook wat voor aanpassingen je hebt gemaakt. Je kan mensen toevoegen aan je GIT zodat ook zij aanpassingen kunnen maken.
https://github.com/DarkSherko/Zombie-Game
Je kunt uitleggen hoe versiebeheer werkt
– Via GIT krijg je toegang tot een Repository, ook kan je er zelf een maken.
– Op de Repo staan files met daarin jou code, of code van een andere Repository.
– GIT geeft de mogelijkheid om de Repo te clone, dit zorg ervoor dat het naar je lokale computer schijf word overgezet.
– De files en de code erin kunnen op deze manier makkelijk worden bewerkt in een Integrated Development Environment. In mijn geval Visual Studio Code.
– Zodra je GIT clone hebt gebruikt krijg je toeging tot GIT push. GIT push stuurt al jou gemaakte wijzigingen aan de bestanden naar de Repository die erbij hoort.
– De GIT push bestanden noemt met Commits, dit zijn dus de gewijzigde bestanden.
– Door commits uit te voeren kan een andere programmeur makkelijker verder gaan met jou werk.
Waarom dit geschikter is voor samenwerken aan code dan bijv. Dropbox.
Waarom is GIT beter dan Dropbox:
– Ten eerste is Github een opensource, dit betekend dat je het gratis kan gebruiken. De versiebeheer van Dropbox daarentegen een betaalde versie is.
– Github maakt gebruik van issue tracking, hiermee kan er via de GIT repo bugs in je code worden gevonden en aanpakken.
– Via git is het ook mogelijk op een website te hosten vanaf de Repository, ook dit is gratis.
– Versies van het gehele project zijn beschikbaar via Github ik vergelijking tot Dropbox die alleen de versies van de filers heeft die op de Repo staan.
Op deze manier kan je terug naar je oude versie code.
– Elke revisie in GIT is ook voorzien van comments zodat er gedocumenteerd word wat er veranderd word. Bij Dropbox is dit niet het geval, want daar zie je alleen de revisie nummers, en moet de documentatie anders gedaan worden. Werken in een team via GIT is daarom makkelijker.
– Github heeft ook een grote community, je kan op deze manier makkelijker code leren. Ook kan je andermans repo clone zodat je de informatie kan opdoen uit hun gemaakte werk. Dropbox daarentegen is niet public, dit zorgt ervoor dat je code niet kan bezichtigen. Projecten zijn daarom makkelijker te vinden via Github.
Commits zijn klein en beschrijf je ook kort en bondig.
Het is beter om kleine veranderingen te documenteren, in plaats van in een keer een grote commit met 10+ veranderingen. Waarom? Dit houdt het allemaal veel overzichtelijker. Dit geld ook voor het werk dat Ik nu uitvoer tijdens CLE 4. Op de GIT staan nu alleen de gameplay elementen, de final game wordt lokaal gemaakt.
Overdracht
Je bent in staat acceptatiecriteria (definition of done, specificaties) zodanig op te stellen dat het product te bouwen is door iemand anders zonder verder overleg. Je bent in staat om een klantgerichte gebruikershandleiding op te leveren.
Je bent in staat acceptatiecriteria (definition of done, specificaties) zodanig op te stellen dat het product te bouwen is door iemand anders zonder verder overleg.
Hieronder ziet u de user stories staan, dit document bevat ook de acceptatiecriteria.
De definition of done heb ik verwerkt in in een Trello bestand. Dit heb ik gedaan door een checklist toe te voegen aan de opdrachten die er gedaan moesten worden. Op deze manier is er een duidelijk overzicht van wat er gedaan moet werken voor elk onderdeel. En zo weet je of de opdracht voldaan is wanneer de checklist balk op 100 procent staat.
Je bent in staat om een klantgerichte gebruikershandleiding op te leveren.
Hierbij de gebruikshandleiding voor het spel van CLE4.
Herkansing
versiebeheer
Ik heb geleerd hoe je moet commits moeten doen vis Github. Voorheen deed ik alleen add files maar ik heb geleerd dat commits niet zo werken.
Ik maak gebruik met github dessktop en de normale github webpagina.
Ik gebruikt github desktop voor fetch origion en push origin.
Ik gebruik de webpagina voor het bekijken van mijn github pagina omdat het overzichtelijker is via de webpagina. De desktopversie laat je Repositories niet zien.
Voor het herkansen van de buildingblock heb ik een game gemaakt. Het is een eenden spel.
In de github kunt u de commits en de code zien.
https://github.com/0957822/herkansing
https://github.com/0957822/herkansing/commits/master
