Zet je frontend op de rails met Component Storming

Frontend development is nog steeds een ondergeschoven kindje. Veel ontwikkelaars houden zich liever niet bezig met het frontend en veel bestaande methoden lenen zich meer voor backend code. Dat terwijl frontend juist heel belangrijk is voor een internetbureau zoals dat van ons. Het frontend is namelijk dat stuk van de applicatie of website waar de eindgebruiker direct mee in aanraking komt. Daarom ontwikkelden we onze eigen werkwijze voor het in de steigers zetten van een frontend binnen onze projecten: Component Storming.

Een catchy naam en een intern wiki-artikel. Meer heb je natuurlijk niet nodig voor een eigen methodologie. Maar wat is nu precies de reden dat we dit nodig hadden? Als internetbureau lopen wij tegen andere problemen aan dan productteams. De doorlooptijden zijn kort, het aantal projecten waar je aan werkt is hoog en het resultaat moet minstens zo goed zijn als het ontwerp.

Dit wil dus zeggen dat we projecten zo moeten insteken dat:

Inmiddels hebben we Component Storming toegepast bij het realiseren van complete single-page JavaScript applicaties, frontend component libraries en op corporate websites, ontwikkeld op basis van een traditionele template taal zoals Twig.

Niet meer helemaal scherp wat componenten ook alweer zijn? Lees ons artikel over component-based werken.

Hoe Component Storming werkt

Samenwerken vereist communicatie. Hoewel onze ontwerpcollega’s snappen hoe je in (design-)systemen moet denken, is de eerste stap dat onze frontenders samen bepalen wat wat is én wat een component is. Samen doorlopen we één voor één de individuele paginatemplates én beantwoorden we de volgende vragen:

Hoewel dit ongelofelijk basaal klinkt, is het vroegtijdig hebben van deze discussie cruciaal. Er is namelijk geen harde regel wat precies een component is. Vraag twee frontenders een component op een pagina de definiëren, en je krijgt drie verschillende antwoorden. De keuze om een component te hergebruiken, of een nieuw component te maken is subtiel, maar kan grote gevolgen hebben. Ook bouw je direct een gemeenschappelijk taal; nu weten we allemaal wat er bedoeld wordt met het “ContractProgressBar” en hoe deze anders is van het “ProgressBar” component.

Maar dit is niet waar Component Storming stopt. Wanneer het eerste paginatemplate is besproken, worden de individuele componenten direct aangemaakt. Wanneer je een frontend framework gebruikt, beschik je vaak over een command-line-tool om snel componenten aan te maken. Met een simpele copy-paste kom je natuurlijk ook een eind. Vervolgens “nesten” we de verschillende componenten zoals net besproken. Op die manier leg je direct vast wat je zojuist besproken hebt. Niet in documentatie, maar in de daadwerkelijk codebase.

Voor single-page applications gaan we nog een stapje verder. We bouwen niet alleen de individuele pagina’s op, maar definiëren ook direct de “routes”–zeg maar de URLs die er voor zorgen dat er daadwerkelijk wat weergegeven wordt wanneer je een pagina in de browser bezoekt. Nog zo’n ding waar ontwikkelaars eeuwig over kunnen discussiëren, maar ook dit schept direct duidelijkheid.

Wanneer de Component Storming sessie is afgerond, zorgt één frontender voor het vastleggen wat er tijdens de sessie is besproken. Dit zijn concrete resultaten van de Component Storming sessie en zorgen voor een solide basis voor de rest van het frontend ontwikkelproces.

Op dit moment heb je dus een hele basale structuur van het frontend staan, plus een duidelijk overzicht met de uitstaande taken. Wanneer we daadwerkelijk aan de frontend implementatie beginnen, zien we stukje-bij-beetje het project tot leven komen. De focus ligt dan voornamelijk op een goede implementatie van het ontwerp. Discussies over naamgeving en structuur zijn bijna niet meer nodig.

Waarom Component Storming werkt

Component Storming is dus zeker geen hersenchirurgie, maar deze manier van werken levert ons wel veel op. Laten we nog even teruggrijpen naar onze originele problemen:

Toch is het naar voren halen van mogelijke discussies het belangrijkste speerpunt van Component Storming. Door het vastleggen van deze discussie in de codebase creëer je geen “paper tiger”, maar een solide basis om op door te bouwen–zonder “waste”.

Wil je meer weten over Component Storming, en weten wat het jouw organisatie kan opleveren? Spar dan een keer vrijblijvend met een van onze experts. We denken graag mee!

Keertje sparren? Plan een afspraak in

Component Storming is tot stand gekomen door het werk van onze frontend experts Arjen en Rick.