Architectuur, elegantie versus noodzaak *

[Verwijderd]

Toegegeven, het ontwerpen (en ontwikkelen) van een elegante (OO) architectuur (MVC, Front Controller, Data Transfer Objects enzovoort enzovoort) is iedere keer weer een aangelegenheid om van te watertanden. Maar niet zelden vraag ik mij vervolgens af in hoeverre de ontworpen architectuur daadwerkelijk noodzakelijk is. Schematisch/ontwerptechnisch ziet een architectuur die bestaat uit laag op laag en waarbij per laag het principe van 'separation of concern' wordt toegepast er prachtig uit en het voelt gewoon goed, wanneer alles vervolgens ook werkt, want wie heeft niet eens iets geschreven dat werkte, maar waarvan je daarna een aantal nachten niet goed sliep omdat je gruwelde van hoe het er onder de motorkap uitzag.

Toch is ook in dit verband de wet aan de orde: overdaad schaadt. Maar waar leg je de grens? De één legt hem hier, de ander daar. Er zijn geen allesomvattende absolute regels voor. Het is een kwestie van gevoel in combinatie met ervaring.

Hoe gaat een ieder hier om met het duel tussen elegantie versus noodzaak? Hoe weet je bijvoorbeeld dat het verstandig is om een Abstract Factory design pattern toe te passen voor de laag die met de database gaat communiceren, wanneer op het moment van ontwerpen niet aan de orde is, dat de database ooit zal worden vervangen of iets dergelijks?

[JKVA]

Uit het Agile Manifesto:
"Simplicity--the art of maximizing the amount of work not done--is essential."
http://agilemanifesto.org/principles.html

Ofwel, bouw iets zo eenvoudig mogelijk. Houd geen rekening met eisen die in latere iteraties kunnen komen.

Uit hetzelfde manifest:
"Continuous attention to technical excellence and good design enhances agility."

Ofwel, ga niet overdesignen. Als je twijfelt over een designkeuze, kies je de meest eenvoudige. Maarrrr, zorg wel voor "technical excellence", dus zaken als circulaire dependencies of duplicate code zijn uit den boze.

Ik probeer meestal volgens deze regels te leven, maar als ik verwacht dat er op langere termijn iets gaat gebeuren, dan sorteer ik daar doorgaans wel op voor. Maar meestal breek ik dan nog niet met bovenstaande regels, aangezien die voorsorteringen achteraf gewoon kwestie van goed design waren en bijvoorbeeld duplicate code verholpen.

Ofwel 2: K.I.S.S.

[Verwijderd]

Ik ben het eens met het K.I.S.S. principe, maar ik moet bekennen dat wij ons er niet altijd aan houden. Neem als voorbeeld de Object Relational Mapper. Fowler stelt dat ActiveRecord prima gebruikt kan worden als het data model niet te complex is. Wij daarentegen vinden ActiveRecord ranzig aangezien je je code voor het opslaan zo veel mogelijk wil scheiden van de objecten. Daarom gebruiken we altijd Table Data Gateway, ook voor de makkelijke gevallen. Dat is ook helemaal geen probleem zolang je een leuke tool gebruikt om je code te genereren, die vervolgens ook nog overweg kan met custom aanpassingen.
Daarnaast denk ik ook dat de architectuur heel verschillend is voor verschillende toepassingen. Wanneer je je bezig houdt met webapplicaties en web interfaces, dan is de opbouw van ieder project toch wel nagenoeg hetzelfde. Je hebt je framework met je MVC, classes voor connecten met de database, wat logging classes, orm classes, validation classes, rbac classes.
De grootste variatie zit hem in de manier van het ontwerpen van je data model. Met een beetje UML tekentool kan je naar XML exporteren, als je daar vervolgens een XSLT over heen gooit om XML te krijgen die je code generator kan gebruiken, dan kan je zo je complete ORM gebeuren laten genereren. Hoe je het wendt of keert, een webapplicatie is altijd iets van; toon pagina overzicht, bewerk pagina, verwijder pagina etc. Je MVC architectuur stuurt de verzoeken door naar de juiste Controllers, die roepen de juiste Actions aan. Het framework kijkt of je toegang hebt, voert de juiste acties uit (geen toegang naar de Authentication module doorsturen, wel toegang actie uitvoeren). Je populate je view met attributen, rendert de view en dispatcht.
Ik ga echt niet bij elk project weer nadenken over de juiste MVC architectuur en hoe ik de RBAC moet regelen. Uit ervaring leer je vanzelf wat voor jou werkt, en wat niet, wat een goede aanpak is, wat je kan hergebruiken, en wat niet.
Overdaad hoeft niet per se te schaden. Doorgaans wil je zo weinig mogelijk code, maar ik heb liever een wat netter design en 1000 extra regels code die toch uit een generator komen.

[Verwijderd]

Verwijderd schreef op zondag 07 oktober 2007 @ 12:36:
Hoe gaat een ieder hier om met het duel tussen elegantie versus noodzaak? Hoe weet je bijvoorbeeld dat het verstandig is om een Abstract Factory design pattern toe te passen voor de laag die met de database gaat communiceren, wanneer op het moment van ontwerpen niet aan de orde is, dat de database ooit zal worden vervangen of iets dergelijks?

Om nog even concreet hierop in te haken. Ook al is het nu niet aan de orde, dat kan het misschien wel worden. En ik ben het er niet mee eens dat Agile development zegt dat je je nu niet moet bezighouden met problemen in de toekomst. Daarnaast; je maakt eenmalig zo'n ontwerp en gebruikt dat natuurlijk voor al je projecten. Even concreet. Onderstaande maak je natuurlijk een keer. Implementeer je en klaar is Kees. Voor je volgende project ga je natuurlijk niet weer nadenken hoe je verbinding gaat leggen. Nee, je Framework maakt gewoon verbinding met de benodigde databases.

Het punt is; vaak gebruik je een framework over meerdere projecten. Ook als je voor een individueel project verwacht dat er maar een database engine gebruikt zal gaan worden en dat nooit zal veranderen, dan is het alsnog slimmer om gewoon je uitgebreidere versie te pakken, die ook met complexere zaken overweg kan. Je wil niet na een half jaar, als je een update aan je framework wil uitrollen, per klant gaan kijken hoe je alles precies geimplementeerd hebt, en welke zaken je over moet gaan nemen. Als je eenmaal een nette oplossing gemaakt hebt voor een Abstract Factory voor het connecten met de database, dan kan je dat toch net zo goed overal gebruiken? Het enige verschil zit hem vervolgens in de aanroep. Je moet dan namelijk doen:

PHP:

$database = DatabasePool::getInstance()->getDatabase();

Nou, niet echt iets om over te vallen lijkt me. En zo is je ontwerp wel een stuk netter.

PHP:

class DatabasePool {

    protected $instancePool;
    protected function __construct () 
    {
        $this->instancePool = new ArrayMap ();
    }

    public static function getInstance() { ... }
    public function register(Database $database = null, $connection = 'default') { ... }
    public function getDatabase($connection = 'default') {
        if ($this->instancePool->get($connection) == null) {
            throw new DatabaseException ('There is not registered any database connection with the name \'' . $connection . '\' yet.');
        }
        
        return $this->instancePool->get($connection);
    }
}

interface Database {
    public function connect ($hostname, $username, $password, $database);
    public function disconnect ();
    public function query ($sql);
    public function lastInsertId ();
    public function escapeString ($string);
    public function startTransaction ();
    public function commit ();
    public function rollback ();
}
class MysqlDatabase implements Database {
    ...
    public function query($sql) {
        if (!$query = mysql_query ($sql))
            throw new DatabaseException ('MySQL says: ' . mysql_error () . '. The following SQL was given to the database server: ' . $sql, E_USER_ERROR);
        
        return new MysqlResultset($query);
    }
    ...
}

interface Resultset extends IteratorAggregate {
    public function length();
    public function first ();
    public function next ();
}

class MysqlResultset implements Resultset {
    ...
}

[JKVA]

Verwijderd schreef op zondag 07 oktober 2007 @ 15:37:
[...]


Om nog even concreet hierop in te haken. Ook al is het nu niet aan de orde, dat kan het misschien wel worden. En ik ben het er niet mee eens dat Agile development zegt dat je je nu niet moet bezighouden met problemen in de toekomst.

Dat kun je wel vinden, maar je kunt niet agile werken met zo'n denkwijze. De kracht zit hem juist in het feit dat je per iteratie leeft.

Vergeet overigens niet dat Agile zegt dat je perfectie na moet streven. Als je 'perfecte' code hebt, zijn wijzigingen geen probleem en hoef je niet door je hele code heen. Dit is natuurlijk theoretisch en in de praktijk niet altijd haalbaar, maar de impact is iig beperkter.

Daarnaast; je maakt eenmalig zo'n ontwerp en gebruikt dat natuurlijk voor al je projecten. Even concreet. Onderstaande maak je natuurlijk een keer. Implementeer je en klaar is Kees. Voor je volgende project ga je natuurlijk niet weer nadenken hoe je verbinding gaat leggen. Nee, je Framework maakt gewoon verbinding met de benodigde databases.

Ik durf het ook niet eens architectuur te noemen. 1 keer iets bouwen en dat altijd gebruiken. Voor een website kun je dat nog wel doen, maar dan vind ik het eigenlijk al amper architectuur. Architectuur is het zoeken van de beste oplossing voor een gegeven probleem. En de ene keer betekent dat top-of-the-bill tooling gebruiken. De andere keer kan directe DB access wel beter zijn.

Sterker nog, klanten hebben veelal zelfs eigen tooling, standaarden en richtlijnen. Bovendien is de omgeving bij elke klant weer anders, waardoor een oplossing die in het ene geval goed werkt, in de andere omgeving helemaal verkeerd is. There is no golden hammer.

Het punt is; vaak gebruik je een framework over meerdere projecten. Ook als je voor een individueel project verwacht dat er maar een database engine gebruikt zal gaan worden en dat nooit zal veranderen, dan is het alsnog slimmer om gewoon je uitgebreidere versie te pakken, die ook met complexere zaken overweg kan. Je wil niet na een half jaar, als je een update aan je framework wil uitrollen, per klant gaan kijken hoe je alles precies geimplementeerd hebt, en welke zaken je over moet gaan nemen. Als je eenmaal een nette oplossing gemaakt hebt voor een Abstract Factory voor het connecten met de database, dan kan je dat toch net zo goed overal gebruiken? Het enige verschil zit hem vervolgens in de aanroep.

Dat is standaardisatie en absoluut een factor bij het kiezen van een oplossing. Maar het is zeker niet de enige factor. De klant zal het namelijk worst wezen dat het voor jou als supplier gemakkelijker is dat je een te uitgebreide tool gebruikt. Dat moet je zelf namelijk maar uitzoeken. Ze betalen jou immers zodat ze niet zelf alle lastigheden op moeten lossen. De klant legt veel meer nadruk op non-functionals zoals performance, security, maintainability, manageability, etc.

Tenslotte, standaardisatie is ook niet alles. Bij de bank waar ik momenteel gedetacheerd zit (dit geldt btw voor veel grote organisaties) zijn overal procedures en standaarden voor. Gevolg is dat je voor je kleine project allemaal frameworks gebruikt die zware overkill zijn. Aan de andere kant, bij een groot project komen ze weer tekort. Nogmaals, no golden hammer.

[Verwijderd]

JKVA schreef op zondag 07 oktober 2007 @ 16:25:

Ik durf het ook niet eens architectuur te noemen. 1 keer iets bouwen en dat altijd gebruiken. Voor een website kun je dat nog wel doen, maar dan vind ik het eigenlijk al amper architectuur. Architectuur is het zoeken van de beste oplossing voor een gegeven probleem. En de ene keer betekent dat top-of-the-bill tooling gebruiken. De andere keer kan directe DB access wel beter zijn.

Sterker nog, klanten hebben veelal zelfs eigen tooling, standaarden en richtlijnen. Bovendien is de omgeving bij elke klant weer anders, waardoor een oplossing die in het ene geval goed werkt, in de andere omgeving helemaal verkeerd is. There is no golden hammer.

[...]

Dat is standaardisatie en absoluut een factor bij het kiezen van een oplossing. Maar het is zeker niet de enige factor. De klant zal het namelijk worst wezen dat het voor jou als supplier gemakkelijker is dat je een te uitgebreide tool gebruikt. Dat moet je zelf namelijk maar uitzoeken. Ze betalen jou immers zodat ze niet zelf alle lastigheden op moeten lossen. De klant legt veel meer nadruk op non-functionals zoals performance, security, maintainability, manageability, etc.

Tenslotte, standaardisatie is ook niet alles. Bij de bank waar ik momenteel gedetacheerd zit (dit geldt btw voor veel grote organisaties) zijn overal procedures en standaarden voor. Gevolg is dat je voor je kleine project allemaal frameworks gebruikt die zware overkill zijn. Aan de andere kant, bij een groot project komen ze weer tekort. Nogmaals, no golden hammer.

Zoals je al merkt is het helemaal afhankelijk van de branche waarin je werkt en de mate waarin systemen voort moeten borduren op bestaande systemen en in hoeverre die geintegreerd moeten worden. Imho zou ik voor een web applicatie nooit afstappen van een oplossing die voor mij goed werkt om web applicaties in te schrijven. Mocht een klant perse J2EE gebruiken met Hibernate, dan is dat prima, maar dan kan ik dat niet leveren.

Mijn laatste punt van de discussie; je noemt dat geen architectuur. Wat is dan wel architectuur? Ook gestandaardiseerde oplossingen bevatten toch een zekere mate van architectuur? De gekozen architectuur is sterk afhankelijk van je vertrekpunt. Zijn er al veel systemen die geintegreerd moeten worden, dan is een gestandaardiseerde oplossing waarschijnlijk niet mogelijk. Is de trein echter nog niet vertrokken, dan kan volgens mij een gestandaardiseerde oplossing prima ingezet worden als locomotief.

[Alarmnummer]

Zo gauw een klasse meerdere responsibilities begint te krijgen, of een responsibility is versnipperd over meerdere klasses, dan kon het wel eens tijd zijn om je structuur op te frissen. Ik hou ook van zo weinig mogelijk overhead, maar ik zie zo nu en dan wel code waar echt te weinig aandacht aan structuur is gespendeerd. Je krijgt dan code waar je niet meer over kunt redeneren.

-Onduidelijke naamgeving: als je al geen duidelijke naam aan een class kunt geven, hoe moet je dan afleiding wat zijn responsibilities zijn
-Onduidelijke responsibilities: bv hele chain van classes die hun gewicht niet kunnen dragen, of classes die veel en veel te veel doen (vaak zichtbaar binnen unit tests als je een shit load aan mocks moet injecteren).
-Onduidelijke documentatie (of geen) waardoor je niet meer begrijpt wat uberhaubt het idee achter iets is.
-Duplicatie: niet alleen op methode niveau, maar ook hele subsystemen.

Zo gauw je een complex systeem van boven af niet als eenvoudige componenten (objecten met duidelijke responsibilities) kunt omschrijven (hoe het communiceert met de buitenwereld, hoe het moet schalen, waar de security issues zijn), dan zou je wel eens een gebrek aan software architectuur kunnen hebben.

Ik heb ook wel eens de indruk dat dit komt doordat mensen veel te fundamentalistisch zijn met hun Agile aanpak. Ze zijn doorgeslagen en accepteren geen enkele vorm van architectuur (architectuur is not agile.... bull shit). En je hebt ook uiteraard mensen die het gewoonweg niet interesseerd maar zichzelf wel een 100% senior vinden "boeken lezen doe ik niet aan".. Tja.. wat moet je daar mee.

[ Voor 15% gewijzigd door Alarmnummer op 07-10-2007 17:36 ]

[misfire]

Ik denk dat het belangrijk is om te definiëren wat "architectuur" is. Is het de tekening, is het de stenen, of is het het idee? Hier zou je op zich al een hele discussie kunnen voeren. Ik zie zelf softwarearchitectuur als een oplossing voor een idee die direct kan worden vertaald naar een implementatie en vice versa. Sommigen beschouwen architectuur en implementatie juist als verschillend, of zien architectuur puur als idee, tekening of implementatie.

De tegenstelling tussen elegant en noodzakelijk zie ik niet. Ik denk dat de meest elegante architectuur alleen de meest noodzakelijke elementen bevat. De vraag is dus wat mij betreft: wat beschouw je als "noodzakelijk" voor je architectuur?

Ik ben zelf ook fan van KISS en YAGNI (You Arent Gonna Need It). Deze principes vereisen een bepaalde flexibiliteit van je architectuur. Je moet namelijk later de mogelijkheid hebben om dingen aan te passen aan een dan eventuele complexere realiteit. Verrassend genoeg versterken deze mechanismen juist precies deze eigenschap: een simpele architectuur is namelijk gemakkelijker aan te passen, en dus flexibeler. Omgekeerd is het zo dat als je factories, delegates enz. toevoegt om eventueel toekomstige flexibiliteit op die onderdelen te kunnen bieden, je juist de architectuur als geheel minder flexibel maakt.

Tot slot denk ik dat een goede architectuur ook komt door goed te luisteren naar feedback van je code. Is het moeilijk om (unit) testen te maken? Waarschijnlijk is de code niet goed ontkoppeld. Vind je het moeilijk om documentatie boven je code te zetten? Waarschijnlijk heeft de code dan geen eenduidige sterke verantwoordelijkheid. Goede documentatie en testen leveren denk ik ook zeker een elegante architectuur op en zijn minstens zo belangrijk als een goed gebruik van patterns.

[Verwijderd]

Het klinkt misschien heel flauw maar simpelweg zoals altijd: "de gulden middenweg"
En deze regel zorgt ervoor dat het geen one-liner post is.

[EfBe]

JKVA schreef op zondag 07 oktober 2007 @ 13:19:
Uit het Agile Manifesto:
"Simplicity--the art of maximizing the amount of work not done--is essential."
http://agilemanifesto.org/principles.html

Ofwel, bouw iets zo eenvoudig mogelijk. Houd geen rekening met eisen die in latere iteraties kunnen komen.

Dat staat er niet. Als jij een analyze uitvoert en je WEET dat er met 90% kans een bepaalde aanvulling nodig is in zeer korte tijd, dan ben je een rund als je daar geen rekening mee houdt. Het enige wat bedoelt wordt met die opmerking hierboven uit het manifesto is dat je niet de gehele wereld moet willen modelleren, dus dingen die je NIET hebt gevonden tijdens je analyse, daar hoef je dus geen rekening mee te houden.

Uit hetzelfde manifest:
"Continuous attention to technical excellence and good design enhances agility."

Ofwel, ga niet overdesignen. Als je twijfelt over een designkeuze, kies je de meest eenvoudige. Maarrrr, zorg wel voor "technical excellence", dus zaken als circulaire dependencies of duplicate code zijn uit den boze.

Ook DAT staat er niet. Het agile manifesto is een serie open deuren en de quote die jij aanhaalt is daar een goed voorbeeld van. Tjonge, goed design zorgt voor agility (== adaptive to change). Wie had dat gedacht zeg.

Jij geeft dan een invulling naar jouw mening wat er bedoeld wordt met de elementen in de manifesto-open-deur opmerking.

Maar is dat niet gewoon 'common sense' ? Maak van je design geen janboel... duh...

Ik probeer meestal volgens deze regels te leven, maar als ik verwacht dat er op langere termijn iets gaat gebeuren, dan sorteer ik daar doorgaans wel op voor. Maar meestal breek ik dan nog niet met bovenstaande regels, aangezien die voorsorteringen achteraf gewoon kwestie van goed design waren en bijvoorbeeld duplicate code verholpen.

Dat manifesto is niet iets wat je vertelt hoe je moet leven. Je moet gewoon logisch nadenken en je t.a.t. beseffen dat wat je aan het doen bent een MIDDEL is om je doel te bereiken (== oplossing voor probleem van opdrachtgever) en niet het DOEL an sig. Daarom is het geneuzel over methodieken en tools ook totaal irrelevant. Een timmerman zemelt ook niet over welke boormachine hij gaat gebruiken, dat is nl. niet interessant, wat interessant is waar hij de gaten gaat boren en waarom.

[mOrPhie]

Eens met EfBe. Agile werken betekent echt niet dat je geen goed design kunt hebben. Integendeel. Je kunt in het design essentiele keuzes (voor de toekomst) maken, die waarborgen dat je in iteratie 6 ook nog agile bent. Dat is direct ook het "technical excellence" verhaal. Simplicity en Agility sluiten elkaar dus niet uit, maar vullen elkaar aan.

Overigens, om direct op de vraag van de TS in te gaan: Is het niet zo dat een design aan elegantie verliest, zodra er over-design optreedt en je dus impliciet ook de noodzaak uit het oog verliest? Ofwel, als een designkeuze puur idealistisch is, wat is er dan elegant aan? In dit geval wordt het design een doel an sich, en dat is soms leuk, maar niet elegant imho.

[JKVA]

EfBe schreef op maandag 08 oktober 2007 @ 13:00:
[...]

Dat staat er niet. Als jij een analyze uitvoert en je WEET dat er met 90% kans een bepaalde aanvulling nodig is in zeer korte tijd, dan ben je een rund als je daar geen rekening mee houdt. Het enige wat bedoelt wordt met die opmerking hierboven uit het manifesto is dat je niet de gehele wereld moet willen modelleren, dus dingen die je NIET hebt gevonden tijdens je analyse, daar hoef je dus geen rekening mee te houden.
[...]

Ik zeg ook niet dat ik het 100% letterlijk neem. Wat agile wel voorschrijft, is dat je een user story op de meest eenvoudige manier oplost (wel rekening houdend met algemene designprincipes).

[...]
Ook DAT staat er niet. Het agile manifesto is een serie open deuren en de quote die jij aanhaalt is daar een goed voorbeeld van. Tjonge, goed design zorgt voor agility (== adaptive to change). Wie had dat gedacht zeg.

Jij geeft dan een invulling naar jouw mening wat er bedoeld wordt met de elementen in de manifesto-open-deur opmerking.

Maar is dat niet gewoon 'common sense' ? Maak van je design geen janboel... duh...
[...]

Het is ook common sense en je ziet dat het werkt. Maar tegelijk zie je ook genoeg projecten waar ze denken sneller/goedkoper te zijn door troep af te leveren. Dus zo'n open deur is het schijnbaar nog niet voor iedereen.

Bovendien gaat het dieper dan "geen janboel". Die hard XP-ers elimineren alle vormen van duplicate code. Dus ook code die niet exact hetzelfde is, maar dat naar een hoger abstractieniveau trekken/parametriseren/weet-ik-wat-voor-truuk toepassen om de meest perfecte code te realiseren als ze maar kunnen. En dat is iets waar ik zelf ook nogal eens in doordraaf.

[...]

Dat manifesto is niet iets wat je vertelt hoe je moet leven. Je moet gewoon logisch nadenken en je t.a.t. beseffen dat wat je aan het doen bent een MIDDEL is om je doel te bereiken (== oplossing voor probleem van opdrachtgever) en niet het DOEL an sig. Daarom is het geneuzel over methodieken en tools ook totaal irrelevant. Een timmerman zemelt ook niet over welke boormachine hij gaat gebruiken, dat is nl. niet interessant, wat interessant is waar hij de gaten gaat boren en waarom.

En dan ga je met een drilboor een schilderij ophangen.

Maar je hebt wel degelijk een punt. Je moet eerst bepalen welk probleem je wilt oplossen alvorens aan de oplossing te beginnen.
Een architectuur is een middel om een bepaald doel te bereiken. Eerst moet het doel duidelijk zijn en daarop baseer je een architectuur. Zomaar roepen dat je JSF + Spring + Hibernate gaat doen, in een 4 lagen architectuur, gebruikmakend van DTO's, met XFire voor je Web Services, heeft niks met architectuur te maken. Jammergenoeg zie ik wel veel 'architecten' (let op de quotes) op deze manier werken.
Het argument is dan meestal: "Zo heb ik al meerdere projecten gedaan en die gingen ook goed.". WTF???

[EfBe]

JKVA schreef op maandag 08 oktober 2007 @ 18:37:
[...]
Ik zeg ook niet dat ik het 100% letterlijk neem. Wat agile wel voorschrijft, is dat je een user story op de meest eenvoudige manier oplost (wel rekening houdend met algemene designprincipes).

Maar dat is een wijsheid die je al sinds jaar en dag op tegeltjes tegenkomt: Waarom moeilijk doen als het makkelijk kan?

En nu de hamvraag: wat is eenvoudig en wat is moeilijk? Dingen waar je je dagelijks mee bezig houdt lijken me niet behoren bij 'moeilijk'.

[...]
Het is ook common sense en je ziet dat het werkt. Maar tegelijk zie je ook genoeg projecten waar ze denken sneller/goedkoper te zijn door troep af te leveren. Dus zo'n open deur is het schijnbaar nog niet voor iedereen.

Tuurlijk wel. Een open deur wordt niet ineens een gesloten deur, een open deur is per definitie een open deur, omdat de opmerking eigenlijk kant noch wal raakt. "Water is nat". Maar niet bij -200 C. Toch is het een open deur.

Iets kan nog zo logisch zijn, er zijn altijd factoren die ook een rol spelen en wellicht roet in het eten gooien (een moving deadline, gewoon te weinig kennis van zaken, specs zijn een moving target, budgetten worden gehalveerd etc.etc.. ). Ik vind het overigens per definitie verkeerd om te impliceren dat agile zorgt voor betere software. Er is maar 1 factor die ervoor zorgt dat je betere software krijgt en dat is dat je met vakmensen werkt.

Bovendien gaat het dieper dan "geen janboel". Die hard XP-ers elimineren alle vormen van duplicate code. Dus ook code die niet exact hetzelfde is, maar dat naar een hoger abstractieniveau trekken/parametriseren/weet-ik-wat-voor-truuk toepassen om de meest perfecte code te realiseren als ze maar kunnen. En dat is iets waar ik zelf ook nogal eens in doordraaf.

En dan wel roepen dat je niet moet over-engineeren? Wat voor zin heeft oeverloos refactoren om maar een 'rule' te halen? Zeker bij grote code bases loop je het risico dat je gewoon duplicate code hebt, er is nl. niemand die alle classes kent. In de code base waar ik zelf aan werk (300K regels C# code) heb ik elke regel zelf ingetikt en bedacht. Maar toch heb ik 2 classes gedefinieerd die hetzelfde doen (in 2 sub projects). Tja, je onthoudt echt niet alles en bij veel grotere codebases is dat alleen maar erger, want dan heb je grote teams en weet echt niemand meer alle classes en methods.

Overigens, een codebase die geen duplicate code heeft maar daardoor wel moeilijker is te begrijpen is IMHO echt niet te prefereren boven een code base met wat duplicate code wat het leesbaarder maakt. Dat neemt niet weg dat wanneer je bv door inheritance (die er al is) wat methods kunt generalizeren, je het uiteraard beter kunt refactoren, maar inheritance hierarchieen bv creeeren om het elimineren van een method is bv iets wat ik niet altijd zou prefereren.

Maar je hebt wel degelijk een punt. Je moet eerst bepalen welk probleem je wilt oplossen alvorens aan de oplossing te beginnen.
Een architectuur is een middel om een bepaald doel te bereiken. Eerst moet het doel duidelijk zijn en daarop baseer je een architectuur. Zomaar roepen dat je JSF + Spring + Hibernate gaat doen, in een 4 lagen architectuur, gebruikmakend van DTO's, met XFire voor je Web Services, heeft niks met architectuur te maken. Jammergenoeg zie ik wel veel 'architecten' (let op de quotes) op deze manier werken.
Het argument is dan meestal: "Zo heb ik al meerdere projecten gedaan en die gingen ook goed.". WTF???

Daarom is 'architect' ook een wank word .

Het is steeds meer gemeengoed dat 'architect' gewoon een software engineer is die meeprogrammeert, hoe anders wil je kunnen bepalen dat wat je verzint klopt? Maar Yegge in de link hierboven legt dat veel beter (en humoristischer) uit

[misfire]

Een timmerman heeft toch echt meer dan één boormachine, want dat is erg belangrijk om zo efficiënt mogelijk gaten te kunnen boren.

Het is zeker waar dat de wijsheden uit methodieken en patterns open deuren en common sense zijn. Niemand zegt hier ook dat dit de allesomvattende wijsheid is waarmee je alles perfect kunt doen. Dat wil niet zeggen dat de principes en ideeën je geen houvast kunnen geven en kunnen inspireren om dingen op een betere manier te doen. Bovendien zijn dit ook ideeën die door velen (meestal niet it-ers) die je moet overtuigen meer kredietwaardig zijn omdat het in een boekje staat, en daarom kan het een hefboom zijn om goede gewoontes te introduceren.

Natuurlijk is het zo dat goede vakmensen het belangrijkst zijn voor een goed resultaat. Joel Spolsky verwoordt dit denk ik goed in Hitting the High Notes. Ken "Scrum" Schwaber (erg goed verhaal, luister maar naar de eerste 4 minuten) zegt het zo: "if you use Scrum in a crappy team, your team will produce in a highly predictable, very transparent, controlled manner... crap!". Maar ik denk dat juist goede vakmensen bereid zijn om goede ideeën van anderen te omarmen en niet af te doen als "dat weet ik toch wel beter".

Ten slotte vind ik een groot voordeel van methodieken enz dat ze een effectief communicatiemiddel zijn. Het is verrekte makkelijk om te praten over use cases, continuous integration enz zonder dat je continu iedereen dit hoeft uit te leggen en hun te overtuigen van de sterke en zwakke kanten. Natuurlijk lijdt ook dit weer tot Babylonische spraakverwarringen omdat niet iedereen hetzelfde idee heeft over een use case, maar je zit meestal toch wel in de buurt van elkaar.

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 10-10-2007 09:54 . Reden: Sorry, verkeerde topic... ]