Het artikel positioneert extreme programming in het kader van zeer herkenbare praktijksituaties. Eigenlijk zoals het er in het merendeel van de gevallen aan toegaat.
In grote lijn ben ik het derhalve met Van Solingen eens. Maar de grote ontbrekende in zijn betoog is het onderhoudsproces. Wat is dit proces anders dan 'guerrillero's'. Ten voeten uit! Niets is minder voorspelbaar, aan willekeur onderhevig, grijpt altijd mis op documentatie en is bovenal niet te beheersen. Dat wil zeggen als je niet de passende maatregelen treft. Dat kan namelijk. Vandaar dat ik begon met 'meer dan coïncidentie'. Even uitleggen.
Een beheersingsinstrument voor 'uitwassen' van deze omvang moet namelijk aan minimaal de volgende eigenschappen voldoen.
a) Geschikt zijn voor de meest gebruikte ontwikkelplatforms. In casu meerdere ontwikkeltalen ondersteunen in dezelfde 'look and feel'. b) Het moet naast focus op een enkel programma ook de relatie weergeven tot de rest van de applicatie: een repository-functie. c) Het moet de meest geavanceerde 'where-used'- en 'consist-off'-vraagstellingen direct kunnen beantwoorden. d) Het moet zich voegen naar individuele programmeerstijlen, zoals: Jackson, Warnier/Orr, Hipo, Modulair Goto/ Mainstream, enzovoort. e) Het moet in staat zijn statische tests uit te voeren naar gezichtspunten als: standaardenconsistentie, controle van de procesgang en de gegevensstroom, input/output, aanroepstructuren en sequenties, enzovoort. f) Het moet een impliciet 'standard enforcement' tool vormen, die 'uit den boze'-instructies en -naamgevingen onmiddellijk terugwijst.
Onderhoud
Met de rest van de gewenste flexibiliteit val ik Van Solingen bij. Het keiharde feit wil nu dat ik al jaren een tool gebruik dat aan al deze aspecten tegemoet komt, een product van Nederlandse bodem en onwikkeld voor het doel waarvoor het staat. Onderhoud van applicatie software! Inmiddels is een ander aspect van de 'coïncidentie' wel duidelijk. De eisenlijst a tot en met f, slaat niet alleen op onderhoud, maar evenzeer op 'extreme programming'. De verwantschap komt, omdat na de eerste 100-tal instructies, al het impliciet zoeken naar consistentie start. Dit gedrag is zo verborgen, dat het de meeste ontwikkelaars niet eens opvalt. Als je recht voor je uit kunt kloppen duurt de ontwikkeling van een programma van zeg 2000 instructies niet zo lang. Maar ja, onderweg zijn er andere processen gaande die de zaak wat ophouden!
Van Solingen heeft dit in zijn artikel goed duidelijk gemaakt met onder andere duo-programming, peer-review, hercompileren, voortdurende integratieslagen, enzovoort.
De 'coïncidentie' die ik eigenlijk bedoelde, slaat op mijn korte reactie in Computable van 11 mei jongstleden op de eerder verschenen reeks artikelen over de euro. Daar noemde ik terloops het onderhoudsproces, maar vooral het effectieve antwoord daarop, niet alleen voor de aanpassing voor de euro. Mijns inziens is het tool X-Ray/Maintain een passend antwoord op 'extreme programming', om de simpele reden dat deze wijze van programmeren in de praktijk in de meeste gevallen dé methode is. Mogelijk ongewild weliswaar ten gevolge van wat menselijke trekjes.
De vraag is of je wilt blijven steken bij de constatering, of dat je er iets aan wilt doen. Citaat Van Solingen: 'Even verder kijken kan zeker geen kwaad'. Het door mij genoemde hulpmiddel slaat wat dit betreft twee vliegen in een klap! Je moet wel aan de naamgevingsconventie voldoen om het op internet te vinden. Zie het als een eerste test. Succes!
Ronald Wouterson Amstelveen
Om te kunnen beoordelen moet u ingelogd zijn: