Een idee moet je niet direct in beton proberen te gieten

Het bouwen van een custom management omgeving in WordPress ben ik een klein half jaar geleden al eens mee begonnen. Mijn aanpak was om het direct in classes op te bouwen en de functionaliteit daarmee direct in beton te gieten. Dat werd geen succes. Sterker nog ik heb er weken aan gewerkt en het werkte voor geen meter.

De tweede poging om de custom management omgeving te bouwen ben ik de afgelopen week mee begonnen. Door op een nogal dirty manier – zoals ik in mijn vorige blog heb beschreven – een prototype te bouwen ging dat extreem snel. Dat niet alleen. Het werkt ook nog eens perfect.

Vandaag was mijn gedachte. Het prototype is klaar. Nu is het tijd om het prototype alsnog in classes te verwerken en het geheel in Wpx verwerken. Na een dag programmeren is de conclusie: Dit was geen goed idee. Door alles in een vaste structuur te gieten moet ik keuzes maken die ook in de toekomst gevolgen zullen hebben. Als gevolg daarvan ga je op een heel andere manier programmeren.

Als je iets lekker in beton giet dan kan het geen kant meer op zodra het beton is uitgehard. Dat is precies wat er gebeurd. Je bent je flexibiliteit in het ontwikkelingsproces in één klap volledig kwijt. Daarnaast kun je niet zomaar meer voor creatieve oplossingen gaan om problemen die je gaandeweg tegenkomt op te lossen.

Wanneer de custom management omgeving onderdeel van Wpx wordt dan zal het een bepaalde structuur moeten hebben. Dan moet het in beton gegoten zijn. Op dat moment is het immers onderdeel van een groter geheel. Daar moet het dan ook perfect op aansluiten. Natuurlijk is het ook lekker als het er meteen onderdeel van wordt. Alleen blijkt dat dus een utopie te zijn.

De vervolgvraag is, wat is dan wel verstandig om te doen. De oplossing die ik zelf zie is om te kijken waar flexibiliteit en ruimte voor creatieve oplossingen nodig is en waar standaardisatie in deze fase van het ontwikkelingsproces van toegevoegde waarde is. In andere woorden wat werkt er al perfect én waar zijn nog creatieve en flexibele oplossingen gewenst of zelfs noodzakelijk.

Waar ik bij het bouwen van de custom management omgeving tegenaan loop is vooral de routing en ook verwijzing tussen verschillende management pagina’s. Het prototype heb ik gebouwd rondom hosters, die weer hostingbase posts en daarvan afgeleide hostingpackages hebben. Het is lastig om de onderlinge verwijzingen (relationships) in een model te standaardiseren.

Om dat concreet te maken. Het makkelijkste is om iets te doen als /beheer/%post_id%/edit. Daarbij kan %post_id% van een willekeurige post zijn. Stel je bewerkt een hostingpackage en na het opslaan van de wijzigingen wil je een redirect (terug) naar het overzicht van hostingpackages van de hoster hebben.

Ergens zal het systeem moeten weten dat hij terug moet verwijzen naar de hoster. Door de url structuur kan het systeem het daar niet uithalen. Dan moet dat dus “onderwater” geconfigureerd worden. Dat met een cookie regelen ben ik niet van gecharmeerd. Dan moet er iets in de configuratie van de manager staan. Die configuratie op een zodanige manier standaardiseren betekent dat je of een complexe structuur moet bouwen die rekening houdt met verschillende situaties of juist een simpele structuur pakt die weer beperkingen heeft.

Gelukkig zijn er ook zaken die wél al in beton gegoten kunnen worden. Het bewerken van een bepaalde post zelf is redelijk overzichtelijk. Het grote voordeel daarbij is ook dat in het Wpx framework de metadata velden al gestandaardiseerd zijn. Hier blijkt dus weer een voordeel van standaardisatie. Je zit er aan vast en anderzijds geeft het ook duidelijkheid en maakt het (toekomstige) ontwikkeling van software mogelijk.

De kunst is om in elke fase van het ontwikkelingsproces de juiste mix te vinden van standaardisatie en flexibiliteit bij het bouwen van een prototype. Wanneer ik morgen weer aan de slag ga ik mij eerst richten op wat wél al voor standaardisatie in aanmerking komt. Daarna ga ik daar de flexibele schil als prototype omheen bouwen om vervolgens te kijken wat er al zodanig ontwikkeld is dat ik het ook in beton kan gieten.

Dat proces zal zich waarschijnlijk blijven halen totdat de volledige custom management omgeving in WordPress volledig in beton gegoten is en het uiteindelijk zelfs een integraal onderdeel van het Wpx framework zal uitmaken.