Ga naar hoofdinhoud

Engineeringbeslissingen

Tijdens het project heb ik meerdere architectuurkeuzes gemaakt die bepaalden hoe onderhoudbaar het platform zou worden.

1. Centraliseer gedeeld gedrag, niet alles​

GOED
shared utility → shared/

GOED
business-specifieke logica → forms/FORM_001.js

VERMIJDEN
elk formulier afhankelijk maken van één gigantisch implementatiebestand

De library houdt herbruikbaar gedrag centraal zonder ongerelateerde formulieren onnodig aan elkaar te koppelen.

2. Houd de loader lichtgewicht​

De loader bepaalt context en laadt code.

Hij wordt niet de plek waar businessregels zich opstapelen.

loader-verantwoordelijkheid:
context → scriptselectie → laden

niet:
context → alle businessregels in het systeem

3. Behandel render-timing als platformprobleem​

In plaats van elk formulier zijn eigen setTimeout te laten bedenken, wordt timing als shared utility aangeboden.

veel losse delays
        ↓
één herbruikbare timinghelper

4. Scheid deployment van development​

Developers zouden JavaScript niet handmatig naar hogere omgevingen moeten kopiëren.

codewijziging
   ↓
pipeline
   ↓
gecontroleerde promotie

5. Infrastructuur moet reproduceerbaar zijn​

Bicep maakt infrastructuur reviewbaar en herhaalbaar in plaats van alleen afhankelijk te zijn van portalconfiguratie.

6. Documentatie is onderdeel van onderhoudbaarheid​

Een platform is pas echt bruikbaar wanneer een andere developer begrijpt hoe ermee gewerkt moet worden.

Daarom werd de documentatiesite als onderdeel van het project gebouwd, niet pas achteraf.