Antipatterns: Who built these pyramids?

 
30 augustus 2009

Omschrijving
Een (aantal) slimme geest(en) heeft/hebben in het verleden een fantastisch ontwikkelframework neergezet voor een applicatie. Er zijn diverse geavanceerde plug-in structuren zichtbaar, en veel is configureerbaar. Daarnaast zit er een vorm van caching in die veel werk uit handen neemt, alleen: er mist documentatie. Sterker nog, er is geen enkele documentatie. Daarnaast blijken veel van de structuren in meer of mindere mate overbodig of zijn al lang niet gebruikt doordat er diverse mensen aan hebben gewerkt die niet op de juiste wijze uitbreidingen hebben gemaakt.

De makers van de pyramide zijn echter al jaren geleden vertrokken. Niemand kent de gedachtengang achter dit fraaie stukje meesterwerk meer.

Symptomen
Gebruik van reflectie, veel verschillende modules. Daarnaast vaak grote “layer supertypes”, in de vorm van abstract classes.

Oplossingen

  • De pyramide beschouwen als een prototype, uithuilen en opnieuw beginnen.
  • De pyramide via reverse-engineering goed documenteren en de gedachtengang achter de software in het ontwikkelproces embedden.
  • Voorkomen kan door documentatie af te dwingen tijdens bouw van dit soort frameworks.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur, Development

Tags:


Reacties (2)

  • Andries,
    Ik ben het op veel punten eens met je analyse. Probleem is echter dat deze wereldwonderen, vaak niet zoals met de pyramides, nog beheerd moeten worden. En dan bedoel ik dat de software up&running gehouden moet worden, uitgebreid waar nodig en dat bugfixes toegepast moeten worden.

    Dat is in feite de kern van het anti-pattern: mooie ingewikkelde structuren bedenken, vervolgens weglopen zonder goede manier van overdracht.

    Geplaatst op 06 september 2009 om 7:19 Permalink

  • Andries Nieuwenhuize schreef:

    ANTIPATTERNS: WHO BUILT THESE PYRAMIDS?

    Op het eerste gezicht een begrijpbaar ‘anti’-pattern, maar ik zou willen betogen dat dit helemaal geen anti-pattern is! Het is juist een heel goed pattern!

    Laten we het volgende eens overwegen. De Eggys hebben aardig wat documentatie in de muur gebeiteld. De meest handelt over hun goden en hadden een [voor hun dan] belangrijke functie, maar ze hebben ff niet vermeld hoe je een piramide maakt. Waarom? Vergeten? Beroepsgeheim? Toch ook aardig om in de muur te krassen? Misschien is een onmiskenbare eigenschap van zo’n piramide (lees wereldwonder) wel dát het niet overdraagbaar is aan anderen en dát het niet te documenteren valt. Zo groots, zo veelomvattend, zo gigantisch.

    Men is snel geneigd te denken dat een ‘wereldwonder’ ook op een zodanige manier (wonderlijk) tot stand is gekomen. “Dit is zo fantastisch, dit moet ook wel goed in elkaar gezet zijn. Die lui waren goed!” Hypotheses hierover zijn genoeg te vinden. “The secret lays in the sand” en nog meer van dit soort. Dit temeer omdat er geen enkele spoor van fouten of bruut geweld te vinden is. Het lijkt allemaal met het kleinste gemak in elkaar gezet te zijn.

    De antithese zou zijn dat het gewoon ontzettend veel energie heeft gekost om een piramide te maken. Niks geen slimme truckjes, zwevende hefbomen, vliegende tapijten of andere vergane wijsheid om stenen te versjouwen. Gewoon keihard werk! Wie weet, is het raadsel van de piramides wel erg eenvoudig! Stapel de ene steen op de andere, succes!

    Hier even wat tegengas op de oplossingen:
    > Voorkomen kan door documentatie af te dwingen tijdens bouw van dit soort frameworks.
    Misschien wijzigt er zo veel dat men pas aan het einde van de piramide fatsoenlijke documentatie vast kan stellen. Misschien heeft een piramide ook wel een ‘piramide’ aan documentatie nodig? Is dat nog wel zinvol dan?

    > De pyramide via reverse-engineering goed documenteren en de gedachtengang achter de software in het ontwikkelproces embedden.
    Ga d’r maar aanstaan.Dit proces kan even lang duren dan er zelf een bouwen. En het enige wat je dan weet is hoe een piramide in elkaar zou kunnen steken.

    > De pyramide beschouwen als een prototype, uithuilen en opnieuw beginnen.
    Deze cynische getinte zin heeft m.i. de ware wijsheid in zich. Een piramide moet mensen laten huilen, d.w.z. emotioneel raken! Het moet mensen aansporen er zelf een te maken als dat nodig is. Een ‘wereldwonder’ moet zijn functionaliteit duidelijk naar buiten uistralen. Op zo’n manier, dat een ieder die er zin in heeft er ook een kan maken, zonder in de papyri te duiken. Je ziet in gedachten een farao bij een piramide staan: “Wow, dat wil ik ook!”, want iedereen kan zien hoe het resultaat eruit moet zien. Geen documentatie mensen maar inspiratie! En, ‘Make it good and make it last’. Een fenomeen waarin we in dit huidige ‘update’-paradigma helemaal vanaf geweken zijn. ‘Make it somehow and (re)make it again’ lijkt nu het devies te zijn.

    Als we, in deze synthese, onszelf nu even de metafoor uitworstelen en met deze gedachten naar de software-wereld kijken vallen ons een aantal dingen op. Geen enkele ‘wereldwonder’ is bij Microsoft vanzelf gegaan. Uit m’n hoofd heeft het .NET-framework 40.000 manuren in zich. Als we het pr-gehalte daar van afhalen zitten we misschien wel aande 50.000. En waarom stopt het bedrijf zijn support voor ‘oudere’ Windowsversies? Documentatie lijkt me toch geen probleem? Ja, op aanwezigheid dan! Ik ben benieuwd hoeveel Microsoft-engineers nog aanpassingen kunnen doen op Windowsversies die voor XP het levenslicht hebben gezien.

    Geplaatst op 31 augustus 2009 om 16:08 Permalink