Je game uit 5.1 werkt. Maar hoe ziet de code eruit? Als je over een half jaar een nieuwe vijand wilt toevoegen, weet je dan nog waar je moet zijn? En kan iemand anders jouw code lezen?

In deze module maak je je eigen code netter, en je leert uitleggen waarom hij beter is geworden. Dat is wat een developer in het werkveld elke dag doet: code die er al is verbeteren, en verantwoorden waarom.

Je werkt aan je eigen game uit 5.1. Je begint niet opnieuw.

Op deze pagina:

Leerdoelen

Aan het eind van deze module kun je:

• eigen code conventies opstellen, je keuzes onderbouwen en ze consequent toepassen
• je eigen code verbeteren met de SOLID-principes: in elk geval S en O, en voor een goed ook L, I of D
• uitleggen waarom een verbetering je code leesbaarder, uitbreidbaarder of beter onderhoudbaar maakt
• uitleggen waarom je in een situatie kiest voor een abstracte class of een interface
• je game buiten de Unity-editor laten draaien, als build

Onderdelen

1. Code conventies — je eigen afspraken over hoe je code schrijft
2. SOLID — naslag bij de lessen op donderdag, toepassen op je code
3. Technisch ontwerp — een class diagram van je code, vóór en ná
4. Build & port — je game buiten de editor
5. Eindpresentatie — hoe je presentatie van 15 minuten eruitziet

Onderdelen

Planning

<aside> 💡

Leg je verbeteringen meteen vast. Maak vóór je iets aanpast een screenshot of kopie van de oude code. Achteraf terugzoeken hoe het was, lukt bijna nooit — en zonder "vóór" kun je niet laten zien wat je hebt verbeterd.

</aside>

Beoordeling

Je cijfer voor deze module bestaat uit 2 onderdelen: