Ga naar inhoud. | Ga naar navigatie

Persoonlijke hulpmiddelen

Navigation

U bent hier: Home / Achtergronden / Programmeren vs. configureren

Programmeren vs. configureren

Hedendaagse tools maken het steeds makkelijker om applicaties te bouwen. Alhoewel, je zou kunnen stellen dat het gebruiksvriendelijker maken van de tooling noodzakelijk is om om te kunnen blijven gaan met de toenemende complexiteit van ICT-systemen.

Bouwblokken

Hoewel er nog steeds heel veel geprogrammeerd wordt gebruik makend van een steeds groter wordende berg computertalen, worden de meeste applicaties samengesteld uit standaard bouwblokken als: frameworks, componenten, adapters en connectors, bibliotheken, widgets. Al deze bouwblokken hebben gemeen dat ze in meer of mindere mate geconfigureerd moeten worden. Je ziet dan ook dat software ontwikkelaars steeds meer bezig zijn met configureren in plaats van programmeren.

Defaults

Al dat configureren is vaak saai en tijdrovend werk. Daarnaast is het ook nog eens foutgevoelig, want vaak kom je er pas bij het testen achter dat iets foutief is geconfigureerd. En dat is pas ergens achteraan in het ontwikkelproces. Vandaar dat veel gebruik wordt gemaakt van defaults, waarden die niet afwijken van de default hoeven niet geconfigureerd te worden en zullen waarschijnlijk ook geen fouten opleveren. In de open source wereld is er een mooie term voor: "convention over configuration": veel frameworks hebben dit paradigma al met open armen ontvangen.

Het ontwikkelproces

Een ontwikkelproces bestaat doorgaans uit de volgende (iteratieve) stappen:

1. coding
2. configuration
3. compile
4. unit-test
5. integrate & commit
6. build
7. package
8. deploy
9. integration-test
10. release
11. acceptence-test

Uiteraard zijn hier allerlei variaties denkbaar en niet alle stappen zullen altijd nodig zijn. Hoewel de flow sequentieel is (dus van stap 1, naar stap 2, en verder) is het ook iteratief (na een stap 3, compile moet misschien weer terug worden gegaan naar stap 1 of 2 om dingen aan te passen). Echter, het illustreert in ieder geval de volgordelijkheid van het software ontwikkelingsproces.

Afleiding

Wat opvalt is dat naarmate er meer geconfigureerd moet worden in een project er relatief meer tijd gaat zitten in de verschillende test-fasen. Gaat men traditioneel uit van een verhouding codering vs. test van 2:1 (2 uur bouwen en 1 uur testen) tegenwoordig gaat dat meer in de richting 2:3 (2 uur bouwen tegen 3 uur testen) of nog erger. Eerlijkheidshalve dient hierbij vermeld dat configureren niet alleen tijdens het bouwen maar ook bij het deployen plaatsvind en daarmee onderdeel wordt van het test-traject.

Moderne tools voor systeemintegratie - zoals TIBCO BusinessStudio - zorgen er weliswaar voor dat het bouwen van software sneller gaat dan met pure coding via een text-editor, maar zorgen er tegelijkertijd voor dat fouten pas in een laat stadium worden gevonden. In die zin leidt het gebruik van bouwblokken en standaard configuratie waarden er vaak toe dat het specificeren van de juiste waarden nog wel eens wordt vergeten. Het bouwen met blokken mag dan snel zijn, het leidt vaak af van de noodzakelijke configuratie stappen. Bovendien zitten veel waarden vaak diep in de user interface van de betreffende tools verstopt. Er is dus wel wat te zeggen voor het in ere stellen van een oud paradigma: data-driven development, waar data en code er samen voor zorgen dat software doet wat het moet doen.