Boekbespreking
‘AntiPatterns, Refactoring Software, Architectures, and Projects in Crisis’
Patterns staan al geruime tijd in de belangstelling en kregen met de publicatie van het boek ‘Design Patterns’ een brede bekendheid. Naast patterns – constructies die in de praktijk hun waarde hebben bewezen en daarom geschikt zijn om met succes te worden hergebruikt – kennen we nu ook antiPatterns: constructies die in de praktijk hun desastreuze effect hebben bewezen, reden om ze te vermijden.
In het boek ‘AntiPatterns’ beschrijven Brown e.a. enige tientallen van deze ‘te vermijden constructies’, gegroepeerd naar drie perspectieven op softwareontwikkeling: dat van de ontwikkelaar, dat van de architect en dat van de manager. Het is een boek met een duidelijke boodschap: het kan beter en dus moet het ook beter.
Het boek bestaat uit twee delen. Deel 1, hoofdstuk 1 tot en met 4, is een introductie in patterns en antiPatterns. Deel twee, hoofdstuk 5 tot en met 7, bevat de beschrijvingen van de antiPatterns.
Introductie
De geschiedenis van patterns gaat terug tot 1977 toen de architect Christopher Alexander in zijn boek ‘A Pattern Language’ het gebruik van een template beschreef als methode om ervaringen vast te leggen (een template is een vaste indeling van tekstdelen, een pattern language of pattern catalog is een verzameling patterns, beschreven volgens een bepaalde template). In 1987 herontdekten softwareontwikkelaars de publicatie van Alexander en pasten zijn inzichten toe op hun eigen vakgebied. Sinds de publicatie van het boek ‘Design Patterns’ (Gamma e.a., 1994) zijn patterns gemeengoed, met name onder OO-ontwikkelaars.
Een pattern is een algemene oplossing voor een bepaalde categorie van problemen. Bij een pattern staan dus een probleem en een oplossing centraal. Een antiPattern gaat uit van twee oplossingen. De eerste, de antiPattern-oplossing, heeft per saldo negatieve consequenties, de tweede, de ‘refactored solution’, is een aangepaste vorm van de oplossing met per saldo positieve consequenties.
Bij de beschrijving van antiPatterns spelen drie onderwerpen een belangrijke rol: de oorzaken (root causes), de drijfveren (primal forces) en het software design-level model.
Brown e.a. baseren de oorzaken van het mislukken van softwareontwikkelingsprojecten op een variatie op de zeven hoofdzonden: haast, desinteresse, bekrompenheid, luiheid, hebzucht, onwetendheid (intellectuele luiheid) en hoogmoed.
De drijfveren voor de besluitvorming zijn het management van functionele eisen, van performance, van complexiteit en van flexibiliteit van het te ontwikkelen systeem, van IT-resources en van innovatie. Problemen met drijfveren zijn problemen van gebrek aan evenwicht: het teveel aan aandacht voor de ene drijfveer gaat dan ten koste van de aandacht voor een andere.
Het software design-level model is een piramide met, vanaf de top bezien, de volgende niveaus: objecten en klassen, micro-architecturen, frameworks, applicaties, systemen, ondernemingen en, aan de basis, het ‘global level’.
De drijfveren en design-levels worden gerelateerd aan de rollen ontwikkelaar, architect en manager. Daaruit blijkt een duidelijke relatie tussen rol, drijfveer en design-level. Zo is het management van functionele eisen een zaak van ontwikkelaar en architect die zich afspeelt op de niveaus van applicaties en systemen. Het management van IT-resources blijkt een zaak voor het management op ondernemingsniveau en ‘global level’.
Het nut van het begrippenkader ‘oorzaken, drijfveren en design-level’ is bij de beschrijving ervan in hoofdstuk 2 al evident. De betekenis in de context van antiPatterns is dat dit begrippenkader deel uitmaakt van het template voor de antiPatterns.
Gebruik van templates is karakteristiek voor patterns en onderscheidt patterns van andere, vrijere vormen van beschrijving. De gegeven voorbeelden geven een beeld van de verscheidenheid aan templates:
Het ‘Micro-Pattern’ is de meest eenvoudige vorm en lijkt sterk op de vorm die Alexander gebruikte. Het kent drie onderdelen: naam, probleem en oplossing.
Onder de naam ‘Mini-AntiPattern’ hebben de schrijvers ook een antiPatterntemplate van drie onderdelen opgenomen: naam, antiPattern-probleem en ‘refactored solution’.
Het ‘Full AntiPattern’-template wordt in detail beschreven. Het bestaat uit achttien onderdelen. Enkele ervan hebben te maken met de naamgeving: de naam van het antiPattern, de ‘Also Known As’ (aka): andere namen waaronder het antiPattern bekend is, en de naam van de ‘refactored solution’. Andere onderdelen verwijzen naar het begrippenkader van oorzaken, drijfveren en design-level. Het type ‘refactored solution’ geeft aan of de oplossing is gevonden in (aanpassingen in) de software, de gebruikte technologie, de inrichting van het proces of in de rol, in de toedeling van verantwoordelijkheden. De ‘refactored solution’ is een beschrijving van de oplossing. Andere onderdelen zijn: de generieke vorm van het antiPattern, de beschrijving van de symptomen en de consequenties, eventueel bekende afwijkingen (‘in die situatie kan het wel goed werken’) en een voorbeeld.
AntiPatterns
Met name in het hoofdstuk ‘Software Development AntiPatterns ’ blijkt de OO-achtergrond van de schrijvers: er is zelfs een antiPattern ‘Functional Decomposition’, aka ‘No OO’. In dit hoofdstuk worden zeven antiPatterns en zeven mini-antiPatterns beschreven.
Twee voorbeelden: Lava Flow zijn stukken code in programma’s waarvan niemand weet waarvoor ze zijn, maar die ook niemand eruit durft te halen en Mushroom Management is de aanpak waarbij ontwikkelaars uit de buurt worden gehouden van gebruikers: ‘Keep your developers in the dark and feed them fertilizer’.
In het hoofdstuk ‘Software Architecture AntiPatterns’ is de OO-achtergrond nog wel merkbaar, maar dan vooral in de gegeven voorbeelden, de antiPatterns op zich zijn algemeen van aard. In dit hoofdstuk vinden we zes antiPatterns en zeven mini-antiPatterns.
Het laatste hoofdstuk, ‘Software Project Management AntiPatterns’, beschrijft vijf antiPatterns en tien mini-antiPatterns. Van beide geef ik een voorbeeld: Death by Planning is een duidelijk voorbeeld van een oplossing die een probleem kan worden. Te veel planning leidt tot een verschuiving van de aandacht van het opleveren van producten naar het opleveren van plannen. Fire Drill: het beroep van brandweerman bestaat uit dagen verveling, afgewisseld door uren hoogspanning. Veel projecten verlopen ook zo: de definitie van eisen en wensen wil niet vlotten, budgetten komen niet beschikbaar, goedkeuring laat op zich wachten. En dan, plotseling, moet er volgende week geïmplementeerd worden.
Een aanbevelenswaardig boek. Prettig leesbaar, waarbij de op veel plaatsen humoristische toonzetting aan het serieuze karakter geenszins afbreuk doet, integendeel: het maakt duidelijk dat de manier waarop we onze projecten uitvoeren soms komische aspecten heeft. En dat is tragisch.
De drie perspectieven geven iedereen die een rol heeft in softwareontwikkelingsprojecten het nodige ter overdenking (de projectmanager wist al dat zijn ontwikkelaars wat zaken niet helemaal op orde hadden, maar antiPatterns houden ook hem een spiegel voor; hetzelfde geldt voor de ontwikkelaars en de architecten). En ten slotte, in een open sfeer, op zich al een succesfactor, kan het kennen van antiPatterns in de verschillende gebieden de leiden tot een betere communicatie. Want de dingen benoemen, een naam geven, doet communicatie beter verlopen. Patterns en antiPatterns doen precies dat: de dingen een naam geven.
Brown, William J., Raphael C. Malveau, Hays W. McCormick III, Thomas J. Mowbray: AntiPatterns, Refactoring Software, Architectures, and Projects in Crisis, Wiley, New York, 1998.
XXV + 309 pagina’s
ISBN: 0-471-19713-0
Literatuur
Gamma, Erich, Helm, Richard, Johnson, Ralph and Vlissides, John: Design Patterns, Addison-Wesley, Reading, MA, 1994
