Niet zo gemakkelijk als het lijkt

Ik programmeer veel en ontwerp applicaties. Ik lees veel
boeken over techniek en modelleren, toch is IT een bijzonder vak waar eigenlijk
te weinig opleiding in gegeven wordt. De meeste dingen heb ik geleerd door zelf
naar kennis te zoeken en uit de praktijk. Zelden heb ik iets opgeleverd wat
achteraf niet goed bleek te zijn, of te beperkt. En dit terwijl ik ook best
grote projecten heb gedaan. Nu geloof ik dat je kennis moet delen om het te
vermenigvuldigen en bij deze wil ik ook wat kennis achterlaten.

 

Op de eerste plaats: Niets is zo gemakkelijk als dat het
lijkt. Op dit moment hebben we twee stagaires die ik af begeleid. Ze zitten in
het derde jaar van een IT opleiding. Om een punt duidelijk te maken wilde ik ze
laten zien dat niets gemakkelijk is om te ontwerpen. Ik nam als voorbeeld een
boekenwaarderingssite en stelde voor om de tabellen te maken die ervoor nodig
zijn om de gegevens over boeken in op te slaan.

 

Simpel? Dat zou je denken, maar de komende paar regels zal
je duidelijk worden dat het alles behalve simpel is. Welke velden zou je de
tabel Boek geven?

 

Een titel, misschien een tagline of subtitel en dan ons
eerste punt: Schrijver. Maak je hier een tekstveld voor? Of maak je daar een
relatie aan door een veld SchrijverId te maken en een aparte tabel met Schrijvers?
Wat doe je dan als het boek door meer dan één schrijver geschreven is? Alleen
een tekstveld is weer gevaarlijk als gebruikers van de site zelf boeken toe mogen
voegen. Dan gaat het zeker mis en ben je direct je mogelijkheid kwijt om
bijvoorbeeld een overzicht te produceren van hoeveel boeken je van schrijvers
hebt aangezien namen heel veel dubbel voor zullen komen en er dus redundantie
ontstaat.

 

We gaan nog even verder. Geef je een titel in de originele
taal of de titel zoals de vertaling heet. Hebben die dezelfde ISBN? Hoe zorg je
dat de diverse vertalingen als deze worden ingevoerd aan elkaar gelijk zijn?

 

Neem het genre van het boek. Kan het boek slechts één genre
hebben? Een Sci-fi thriller wordt dan Sci-Fi? Dan verlies je weer veel data als
je rapporten wilt maken. Hetzelfde geld als het een tekstveld wordt.

 

Drie verschillende applicaties die iets met boeken doen
kunnen geheel eigen specificaties hebben afhankelijk van het doel wat je met de
applicatie wilt bereiken. Duidelijk is wel dat als je een bepaalde keuze maakt,
dit gevolgen kan hebben voor veranderende inzichten in de toekomst. Daarom is
het vak van applicatie-ontwikkelaar nog zo onvolwassen en zijn er wellicht
weinig opleidingen voor. Meestal richt een opleiding zich op de techniek of is
juist theoretisch, terwijl je voor applicatie ontwikkelaar op beide vlakken
sterk moet zijn. Om je communicatieve vaardigheden nog maar even buiten
beschouwing te laten.

 

In theorie vind iedere ontwikkelaar dat er een goed
functioneel ontwerp moet komen. Zelf heb ik er zelden één gezien, en als er één
was sloot deze vaak slecht aan bij de praktijk of was te algemeen. Iedereen
roept het dus wel, maar is het ook nodig? Of moet er iets meer komen dan alleen
een functioneel ontwerp, of hoe zou zo’n functioneel ontwerp er uit
moeten zien?

 

Persoonlijk geloof ik meer in het opschrijven van een wens in
een verhaaltje met een samenvatting, maar ook veel details. Naar aanleiding van
zo’n verhaaltje ga je daar als ontwikkelaar over praten en stel je
vragen. Op basis daarvan kun je al beginnen met het maken van de applicatie om
zodoende de beschreven zaken vorm te geven in iets tastbaars. Naar aanleiding
daarvan komt vaak het voortschreidend inzicht en kom je pas tot de werkelijke
kern van de wens waarvoor er een applicatie gemaakt moet worden.

 

Als een functioneel ontwerp teveel details bevat en
honderden pagina’s lang wordt, zijn er maar weinig mensen die het
volledig lezen en zullen begrijpen. Of raak je het overzicht kwijt, of wordt
het al weer snel te technisch. Of duurt het opstellen zo lang dat de
specificaties al achterhaald zijn als een ontwikkelaar zijn tanden erin zet.

 

Het punt dat ik maak is dat het vak van applicatie
ontwikkelaar nog erg onvolwassen is, en dat het lijkt dat er toch geen killer
theorie bestaat die iedereen zou moeten gebruiken. Van IT projecten mislukken
er dus ook veel . Eén van de dingen die ik zelf veel toepas en ook erg
toepasbaar vind is DDD, ofwel, Domain-Driven Design.

 

Gebruik Google voor een uitleg. Voordat ik een voorbeeld
geef wil ik vooral kwijt dat je met DDD niet exact bent met je applicatie en
vooraf precies alles weet wat er gedaan moet worden, maar dat als je DDD goed
toepast de kans dat je een doodlopende weg in slaat een stuk kleiner maakt. Je
zit meestal wel goed
J

 

Met DDD kijk je naar objecten en beschrijft deze. Voor de
samenhang tussen deze objecten maak je een model. Hierover kun je praten en
filosoferen en als je daarover consensus bereikt heb je een goed vertrekpunt.

 

Een voorbeeld. Laatst zag ik een artikel over een school. Je
had studenten, leraren en ouders van studenten. Hiervoor zou je natuurlijk drie
tabellen kunnen maken: Studenten, Leraren, Ouders. Deze hebben contactgegevens,
deze zou je in de tabellen op kunnen slaan of je maakt er per tabel wat
gerelateerde subtabellen bij: StudentAdres, LeraarAdres, etc.

 

Hoewel dit prima kan werken is het een hoop werk en zul je
veel logica redundant moeten uitvoeren. In DDD zou je voor kunnen stellen om
een object Persoon (en een tabel Persoon) aan te maken. Studenten, Leraren en
ouders zijn namelijk allemaal personen en hebben een aantal eigenschappen die
vast staan zoals geboortedatum, geslacht, naam, etc. Dit geld ook voor adressen
en bijvoorbeeld communicatiemiddelen zoals Telefoonnummers en e-mail adressen. Als
een persoon Student maar ook Leraar is, of leraar en ook ouders van een student,
dan hoef je de gegevens niet in drie tabellen te vullen (die dus ook meteen
redundante gegevens bevatten).

 

Uiteraard zul je bij studenten andere gegevens vast willen
leggen dan bij leraren, je zult dus ook Objecten zoals Student en Leraar aan
moeten maken. Een eigenschap van zo’n object heeft dan een verwijzing
naar een PersoonId. Als je dus een school-applicatie wilt maken zul je ook
Lokalen, Locaties, Vakken, Roosters etc. aan moeten maken en de relaties
daartussen beschrijven. Grote kans dat een redelijke deel van de applicatie
voor meerdere scholen gebruikt zouden kunnen worden, DDD denken leidt dus ook
naar standaard oplossingen. Dit is wat kort door de bocht maar in toekomstige
stukken zal ik hier vast wel verder op in gaan.

 

Hoe dan ook, welke applicatie je ook wilt maken, niets is zo
gemakkelijk als het lijkt..

 

Henri Koppen

24 februari 2008

Advertisements
Dit bericht werd geplaatst in Uncategorized. Bookmark de permalink .

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s