1. Welke technologie moet ik kiezen?

Misschien wel de meest cruciale vraag wanneer je een website, webshop of app laat bouwen. Met welke technologie moet je die maken? Ga je voor een bestaand CMS of ga je alles vanaf de grond af aan custom laten bouwen? Wil je je app native gaan ontwikkelen of kies je voor een framework waardoor je met één codebase apps voor Apple als Android kunt maken?

Als het goed is heb je deze vragen al in een eerder stadium afgekaart met jouw internetbureau. Als de strategiefase en functioneel-ontwerpfase grondig zijn aangepakt, dan kan jouw webbureau je vertellen welke technische oplossingen de beste zijn voor de realisatie van jouw site of app. Voordat men aan de developmentfase aankomt is dus al bekend welke techniek, CMS of frameworks gebruikt gaan worden.

Hieronder schetsen we een aantal vuistregels waar je rekening mee kunt houden in de keuze voor de techniek.

Welke techniek kies ik voor mijn website?

Wanneer je een website wilt met een homepage, een blog, een paar pagina’s met content en bijvoorbeeld een contactformulier, dan is het vrijwel altijd de beste keuze om voor een bestaand CMS te kiezen. Custom iets laten maken zou hier een overkill zijn.

Dat wordt al anders wanneer je een website wilt met daarin mijn-omgevingen, koppelingen naar andere systemen of complexe webshops. Soms kun je dit allemaal oplossen in een bestaand CMS, eventueel aangevuld met custom code, maar niet altijd. Soms is het slimmer om voor een 100% custom oplossing te gaan. Waar die grens ligt is soms lastig te bepalen.

Waar je in elk geval op moet letten is wat er standaard kan in een bestaand systeem en welke aanpassingen je daarop moet maken om het te krijgen zoals je het wilt. Als er veel tijd vrij moet worden gemaakt om bestaande software aan te passen, leg er dan eens het alternatief van alles custom maken naast. Maak vervolgens niet alleen een keuze op basis van kosten, maar kijk ook naar de toekomstbestendigheid van de gekozen oplossing. Als je met de goedkoopste oplossing twee jaar vooruit komt, maar met de custom (en duurdere) oplossing vijf jaar, dan is maatwerk opeens minder duur dan het lijkt.

Welke techniek kies je voor een app?

Hoe ‘dichter je op de hardware komt’, hoe raadzamer het is om een app native te laten bouwen. Hardware in een telefoon zoals een fotocamera, gyroscoop, luidspreker of de microfoon zijn best complex en op veel manieren te gebruiken in een app. Met de originele programmeertaal kun je die functies het beste en het meest nauwkeurig aansturen. Native app development is dan de beste keuze.

Als de app wat minder gebruik maakt van de hardware in een telefoon, dan zou het gebruik van een framework een betere keuze zijn. Apps waar vooral content wordt geserveerd met eenvoudige interacties met de gebruiker zijn hiervoor zeer geschikt. Door een framework te gebruiken lever je niet in op de functionaliteiten die je kunt inbouwen, maar je bespaart wel tijd in de developmentfase. En dat maakt de pricing van een app gelijk een stuk vriendelijker.

2. Zorg voor een soepel proces

Hoe goed en compleet je FO ook is, je zult altijd merken dat tijdens het developmentproces dingen anders lopen dan gepland of bedacht. Wellicht omdat je tussentijds een briljante feature bedenkt die er nog bij moet komen of omdat het bedachte plan in de praktijk net niet helemaal goed uitvoerbaar blijkt. Dat kan gebeuren en is part of the job. De vraag is hoe je daar mee omgaat. Hieronder een paar tips:

• Leg duidelijk je eerste versie vast en stick to the plan: bedenk samen met je webbureau wat de eerste versie van je site wordt wordt (V1) waar je naartoe gaat werken. Nieuwe features die je later bedenkt kunnen altijd gemaakt worden, maar schuif die door naar V2 of V3. Zo creëer je rust in het project en heeft je webbouwer de ruimte om te gaan voor een V1 die kwalitatief helemaal op orde is. Een focus op kwantiteit (zoveel mogelijk features) leidt meestal tot het inleveren op kwaliteit.
  
• Werk in sprints en met tickets: leg voor elke week of voor elke twee weken precies vast waaraan wordt gewerkt. Zorg dat er voor iedere taak een helder ticket is in bijvoorbeeld Jira of Trello. Hoe gedetailleerder het ticket is hoe beter. Omschrijf een ticket liever zo: “Op de nieuwspagina een button toevoegen met de tekst ‘contact’, graag 100px onder het contentblok en in het midden uitgelijnd, linken naar contactpagina”
  
  dan zo: “button ‘contact’ toevoegen”.
  
  Je webbureau is principe de partij die de tickets aanmaakt, maar loop deze zelf altijd kritisch na om te kijken of de lijst compleet is en vooral of de tickets expliciet genoeg en duidelijk zijn.
  
• Focus op het doel: soms heb je iets bedacht, maar kom je er met jouw webbouwer achter dat dat niet helemaal goed uitvoerbaar is. What a bummer, maar dat kan altijd gebeuren. Kijk samen met je bureau naar een alternatief en hou daarbij het doel wat je hebt voor ogen. Als de knop niet groen kan worden, kijk dan naar blauw of rood. Misschien niet wat je in eerste instantie in gedachte had, maar waarschijnlijk bereik je er wel hetzelfde doel mee. En daar gaat het uiteindelijk om.
  
• Zorg voor een goede OTAP straat: OTAP staat voor Ontwikkeling, Testing, Acceptatie, Productie. Vier verschillende plekken voor jouw site en elke plek heeft zijn eigen regels. Op de ontwikkelomgeving mag er van alles verkeerd en scheef staan, op productie absoluut niet. Op de acceptatieomgeving zet je al je content neer om te kijken of alles klopt, en daarna publiceer je het op de live omgeving (productie). Op de testserver mag je helemaal los gaan en alle mogelijk gebruikersscenario’s testen en kijken waar het mis gaat of niet lekker loopt.

3. Let op de snelheid van je site

Een mooie en complexe site of app is natuurlijk prachtig, maar als die heel traag is, dan doe je niemand daar een plezier mee. Hou tijdens de developmentfase in de gaten hoe je website scoort met een tool als Google PageSpeed. Je wilt een minimale score van 7,5 halen, maar het liefst een 8+, op zowel mobiel als desktop.

Wanneer de snelheid lager is dan moet je in actie komen. Ga met je webbouwer om tafel om te kijken wat mogelijke oorzaken zijn van de matige prestaties. GIT en een goede deploytool zijn hierbij handige hulpmiddelen. Je kunt dan snelheden testen van verschillende versies van je site. Zo kun je zien vanaf welk moment in de developmentfase de site langzamer is geworden. Je kunt dan gerichter in de codebase zoeken wat precies de traagheid veroorzaakt. En er zijn uiteraard vele tools beschikbaar die developers kunnen inzetten om de performance van de website te bekijken en zien waar kansen voor optimalisatie liggen.

4. Zorg voor een veilige website

Het succes van je site wordt ook bepaald door hoe veilig die is. En de manier waarop is geprogrammeerd is daarbij van grote invloed. Bij verkeerd programmeren ontstaan kwetsbaarheden in de site waar hackers en andere kwaadwillenden misbruik van kunnen maken.

Soms is het lastig te bepalen of je website qua code helemaal veilig is want je kunt niet altijd zien of je site 100% veilig is. Vaak kom je er pas achter als het te laat is. Wat kun je doen om je website te checken op veiligheid en potentiële beveiligingsrisico’s? Je hebt een paar opties:

1. Zorg ervoor dat je website en de server waarop die draait ten alle tijde up to date zijn. Dan weet je zeker dat de meest voor de hand liggende veiligheidsrisico’s zijn afgedekt.
2. Voer zogenaamde penetratietests (pentests) uit. Er zijn vele tools beschikbaar die de jouw website kunnen scannen op kwetsbaarheden. Een penetratietest probeert op allerlei manieren je website te hacken. Als dat lukt, dan kan de pentest je vertellen waar kwetsbaarheden in je site zitten.
3. Laat een derde partij een codereview uitvoeren. Hoewel programmeurs – net als loodgieters en timmermannen – altijd wat op elkaars werk hebben aan te merken, kan het soms nuttig zijn om een derde partij naar de code te laten kijken.