4xs Forum
4xs Forum
Home | Profile | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Speciaal
 Filosofie
 Niets is zo gemakkelijk als het lijkt
 New Topic  Reply to Topic
 Printer Friendly
Author Topic  

Henri
Administrator

Netherlands
915 Posts

Posted - 24 Feb 2008 :  15:37:22  Show Profile  Visit Henri's Homepage  Reply with Quote
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 #61514;

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
  Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To: