Wat is het nadeel van een boilerplate?
Dat hij groeit zonder dat je het merkt. Bij elk project stop je er iets bij dat handig lijkt, en dat gaat er nooit meer uit.
Na twee jaar sleep je bij elke nieuwe site code mee die je in geen van je projecten nog gebruikt.
Dat kost laadtijd, en het maakt fouten zoeken lastiger.
Hoe dat gebeurt
Eén klant wil een boekingsformulier, dus dat komt erin. De volgende wil een nieuwsbriefkoppeling. Beide blijven staan, want je weet maar nooit.
Niemand haalt ooit iets weg, want niemand durft. Dat is precies waarom opschonen een afspraak moet zijn en geen goed voornemen.
Het tweede nadeel
Dat alles op elkaar gaat lijken. Niet in ontwerp, maar in denken: je bouwt elke site op dezelfde manier omdat de basis dat suggereert.
Voor de meeste projecten is dat prima. Voor een project dat echt iets anders vraagt, is het een rem.
Wat je eraan doet
Zet twee keer per jaar een moment in je agenda om je basis door te lopen. Alles wat je een jaar niet hebt aangeraakt, gaat eruit.
Leg daarnaast per onderdeel vast waarom het erin zit. Zonder die toelichting durft niemand later iets te verwijderen.
Mijn vuistregels
- Twee keer per jaar opschonen, in de agenda en niet in je hoofd.
- Alleen erin wat je in acht van de tien projecten gebruikt.
- Schrijf per onderdeel op waarom het er is.
- Twijfel je? Dan hoort het er niet in.
Die laatste is de enige regel die de groei echt afremt.
Wanneer het misgaat
Als een gekocht thema als basis wordt gebruikt. Zo’n thema belooft geschikt te zijn voor restaurants, advocaten en fitnessclubs tegelijk, en laadt de code voor alle drie.
Jij gebruikt er één. De rest laadt gewoon mee. Meer daarover lees je bij hoe herken je een opgeblazen thema.
Het is geen reden om het niet te doen
De nadelen zijn allemaal te ondervangen met onderhoud. De winst in tijd en in minder fouten weegt daar ruim tegenop.
Zolang je maar accepteert dat een basis onderhoud vraagt. Meer daarover lees je bij pagespeed.