Hoe beoordeel je de kwaliteiten van een developer als niet-programmeur?

In een wereld waar alle webdevelopers komen met hun eigen — haast eindeloze — door jargon doordrenkte lijst met specialiteiten en prestaties die moeilijk in perspectief te plaatsen zijn, is het vaak moeilijk om het kaf van het koren te scheiden.
Of je nu een eenmansbedrijf bent op zoek naar een enkele developer, een marketingmanager op zoek naar een bureau of een bureau op zoek naar een nieuwe developer werknemer, als je een langdurige relatie aan wilt gaan (wat je zou moeten), kun je waarschijnlijk enkele tips gebruiken om de juiste developer te vinden.
Simpel gezegd, er zijn waarschijnlijk eigenschappen waarvan je weet dat je ze wilt, zoals X jaar ervaring of vaardigheid in taal Y. In dit artikel ga ik het daarentegen hebben over een eigenschap waarvan je niet weet dat je deze wilt: de mogelijkheid om kwaliteitscode te produceren.

Na het lezen van dit artikel heb je een idee waarom goed geschreven code belangrijk is, waar je dealbreakers moet zoeken en wat je van een developer kunt verwachten om ervoor te zorgen dat jij en je gebruikers een naadloze ervaring hebben. Kort gezegd: de praktische waarde van kwaliteit, of praktaliteit™.

Dit artikel gaat uit van enige voorkennis over webtechnologieën, maar niet van programmeren 😁.

Laten we de meest voorkomende situatie nemen: je vertegenwoordigt een bedrijf en moet een bureau vinden dat je website gaat ontwikkelen en onderhouden, bij voorkeur natuurlijk voor zo lang dat nodig blijkt te zijn. Normaal gesproken legt men in een dergelijke situatie ruwweg alle nadruk op de volgende criteria: betrouwbaarheid, ervaring, prijs en design.

Vertrouwen is de basis voor elke relatie. Een website online krijgen zonder een partner die je kunt vertrouwen, is zelden eenvoudig. Je weet dit en vindt uiteindelijk een ervaren bureau dat goed communiceert en kan aantonen dat het deadlines haalt. Nadat jullie alle ins en outs hebben besproken, concluderen ze dat ze je website voor 70% van je budget live kunnen laten gaan binnen de gestelde tijd. Mieters! Na enkele iteraties kom je samen uit bij een ontwerp en enkele weken later is jullie website online, zoals beloofd.

3 jaar later…

Je hebt wat kleine veranderingen nodig. Ze zijn doodsimpel, maar niet iets dat je vanuit het CMS kunt doen. Het bureau moet ernaar kijken. Je neemt contact met ze op en vraagt ​​hoe lang ze erover gaan doen. Vervolgens komen ze terug met een verhaal over hoe het gros van de code is geschreven door iemand die er niet meer werkt, of erger nog: ze werken er nog steeds, maar kunnen gewoon niet begrijpen wat ze eerder hebben geschreven.

Over het algemeen verwacht je vandaag de dag min of meer dezelfde behandeling als toen je de relatie aanging. Met die reden heb je niet onderhandeld over een soort “nazorgplan”. Het is moeilijk voor te stellen hoe zo’n plan eruit zou zien, zelfs met het oog op de huidige situatie. Ik bedoel, natuurlijk heb je met elkaar afgesproken dat ze altijd bugs voor jullie zullen oplossen, maar “op maat” wijzigingen zijn niet makkelijk kwantificeerbaar en als zodanig was de enige belofte die werd gedaan “vaste prijs, gebaseerd op hetzelfde uurloon.” Het aantal uren is echter hoog of onbekend. Dus, wat zijn je opties? Als je niet iemand in huis hebt die aan je website kan knutselen, kun je een veelvoud betalen van wat nodig zou zijn voor de veranderingen, een ander bureau zoeken dat het voor minder kan doen (onwaarschijnlijk) of je kunt een geheel nieuwe website regelen. Ai… Plots is de 70% die je 3 jaar geleden betaalde niet zo “mieters” meer.

Functioneel gesproken draait elke website op niets anders dan een groot aantal verschillende programmeertalen. De bovengenoemde criteria waarop iedereen lijkt te focussen, hebben daarentegen niets te maken met de code en de onderhoudbaarheid ervan.

Dit komt omdat voor de meeste mensen die zelf geen code schrijven, code behoorlijk binair is (woordgrap zeer intentioneel): het is werkend of niet werkend. Op zichzelf is die aanname niet goed of fout; het is het sentiment dat ertoe doet:
Voor de meeste niet-programmeurs is code, zolang er geen zichtbare bugs zijn, zo goed als perfect. Laat me je vertellen waarom dat verkeerd is, van back-end tot content.

Back-end

75% van alle websites heeft een back-end geschreven in PHP. Dit is de taal die de meeste CMS’en aanstuurt, inclusief WordPress, het meest gebruikte CMS ter wereld. Vanwege deze veelvoorkomendheid zit er een enorme gemeenschap van actieve developers achter. Eenvoudige copy-paste voorbeelden van code zijn overal op het internet te vinden en er zijn honderden PHP-handleidingen geschreven voor elk niveau developer, beginneling tot pro.

Dit alles bij elkaar zorgt ervoor dat de instapdrempel voor het gebruik van PHP vrij laag is. Het betekent ook dat er genoeg amateurs in de business zitten. Ze kunnen de klus misschien wel klaren, maar in ruil daarvoor zijn beveiligingsmaatregelen onvolledig (zonder dat jij of zij het weten), lijken laadtijden op die van het inbel tijdperk (als millennial, weet ik daar natuurlijk alles van) en met randgevallen wordt amper rekening gehouden.

Randgeval

Over randgevallen gesproken, ik heb ooit een forum bezocht waar ik het adres van m’n persoonlijke website kon invoeren bij het plaatsen van een comment. Het adres is mijn volledige naam met een punt tegen het einde: gustvandew.al. Voor de rest van het internet is deze “domeinhack” niets meer dan een Albanese website. En toch, na het proberen te versturen van m’n comment, liet een kleine rode waarschuwing me weten dat het “geen geldige URL” was. Ik probeerde het nog eens door een combinatie van onze goede oude https:// en www. erin te mixen, maar het mocht niet baten.

Mogelijkheden om te controleren of een adres een geldig adres is, zijn in alle back-end-talen beschikbaar in de vorm van “libraries”; code die door anderen voor je is geschreven omdat het functinaliteit bevat die vaak nodig is. Ze kunnen allemaal controleren op het bestaan ​​van een adres door het adres daadwerkelijk te pingen om te zien of het een antwoord krijgt, dus er blijft geen enkel excuus over voor de website om willekeurige landen hun TLD’s niet te ondersteunen. Helaas had het forum dat ik bezocht een verouderde library gekozen of geprobeerd het wiel opnieuw uit te vinden, wat mislukte.

Voor een developer om zijn eigen implementatie te maken van iets dat in talloze uitvoeringen voor ze is geprogrammeerd, moet er een tastbaar voordeel zijn. Als dat er is, zal de developer goed moeten nadenken over alle situaties waarin hun gebruikers zich kunnen bevinden en hoe ze het geheel toekomstbestendig kunnen maken.

Dat gezegd hebbende: je zou eindeloos veel randgevallen kunnen bedenken en testen, maar als manier om er de kwaliteit van de back-end code mee uit te vinden, zou ik het niet bepaald efficiënt noemen. Toch zijn er altijd wel wat dingen die de back-end regelt die aan het oppervlak te zien zijn. Op websites die door hetzelfde bureau gemaakt zijn kun je als bezoeker dus testjes uitvoeren.

Controleer op websites gemaakt door hetzelfde bureau:

Zijn de responstijden en laadtijden draaglijk?

Talloze onderzoeken (sommigen door giga’s zoals Google, Amazon en Walmart) hebben aangetoond dat de ervaren snelheid van je website van cruciaal belang is voor conversie en gebruikerservaring. Statistieken over de kwestie veranderen voortdurend naarmate het web en de verwachtingen van gebruikers evolueren, dus ik heb een afbeelding gemaakt waarvan ik vond dat het goed samenvatte waar elke studie over de kwestie het unaniem over eens is:

Ondanks het belang ervan, zou het je misschien verbazen dat deze analyse van 5M+ webpagina’s door Backlinko heeft vastgesteld dat de responstijden gemiddeld 1,3 seconden zijn op desktop en 2,6 seconden op mobiel en dat de laadtijden gemiddeld 10,3 seconden zijn op desktop en 27,3 seconden op mobiel.

Je zou kunnen concluderen dat de responstijden onbetekenend zijn in vergelijking met zulke laadtijden, maar niets is minder waar. Hoe langer de responstijd, des te meer je gebruikers zich in de wacht gezet zullen voelen. En dat bij iedere interactie met de server — op een website, met de internetsnelheden die we tegenwoordig hebben.

Als het je echter lukt om je pagina bruikbaar te houden terwijl bestanden op de achtergrond worden ingeladen, is er vanaf dat moment vrijwel geen probleem. Ook door ervoor te zorgen dat bestanden correct in de cache worden opgeslagen, worden de laadtijden na de eerste keer dat de pagina wordt bezocht verkort.

Zijn er op maat gemaakte foutmeldingpagina’s?

Vraag een pagina aan die niet bestaat door het padnaam (het stuk na de slash) te wijzigen naar onzin.

Krijg je op maat gemaakte 404-pagina’s? Perfect! (dit is echter normaal)
Krijg je blanke pagina’s, standaard foutmeldingen of programmeergebrabbel te zien? Rode vlag!

Kun je formulieren breken?

Het hangt allemaal af van wat je als een “gebroken formulier” beschouwt, maar hier zijn enkele suggesties:

• Kunnen tekstvelden die louter letters zouden moeten toelaten (zoals een naamveld), ook cijfers of andere dingen bevatten die duidelijk niet geldig zouden moeten zijn, zoals emoji?
• Kun je wegkomen met het invullen van slechts 1 letter in verplichte velden?
• Als je een formulier verstuurt en het mislukt, zijn de velden die je had ingevuld dan nog steeds ingevuld?
  Ook foutief ingevulde velden moeten hetzelfde blijven. Als gebruiker wil je over het algemeen zien welke waarden je hebt ingevoerd die de check niet hebben doorstaan, zodat je mogelijk fouten kunt spotten en corrigeren.

Hoe nuttig zijn de padnamen?

Het aantal tekens dat in een URL kan worden gebruikt, is zeer beperkt. De meeste onbruikbare tekens kunnen echter nog steeds worden gerepresenteerd, maar enkel door ze te coderen (een spatie wordt bijvoorbeeld %20). Zoals je je kunt voorstellen, maakt het gebruik van dergelijke tekens in je padnaam (het deel achter de domeinnaam) ze snel onleesbaar. Daarom is er maar één situatie waarbij het gebruik van zulke gecodeerde tekens zou moeten plaastvinden: wanneer de padnaam tekst bevat die 1 op 1 moet worden gekopieerd om de website te laten functioneren. Een voorbeeld is de padnamen die je krijgt als je een Google-zoekopdracht uitvoert. Zoeken naar “katten en honden” resulteert in een padnaam met de “query” ?q=katten%20en%20honden. Google kan dit stuk van de URL niet “mooier maken” naar ?q=katten-en-honden, want dan zou je zoeken naar “katten-en-honden”.
Statische pagina’s zoals die met algemene voorwaarden kunnen daarentegen vriendelijke adressen zijn, zoals /algemene-voorwaarden.

Wanneer een gebruiker producten filtert, moet de padnaam dit ook weerspiegelen. En nee, /schoenen?maat=2,3&kleur=8 is niet leesbaar genoeg, noch ziet het er toekomstbestendig uit. De maat-waarden komen niet overeen met werkelijke schoenmaten, de kleur-waarde is geen echte kleur en het vergroten of verkleinen van het aantal opties voor een van de twee filters wordt snel problematisch.

Wees voorzichtig wanneer:

Het bureau voorstelt van hun zelfgemaakte CMS gebruik te maken

Een CMS van de grond af aan opbouwen is een enorme taak. Het onderhouden ervan is een constante taak. Als er niet ten minste één zeer deskundige developer aan het CMS werkt, zou ik het voor geen goud vertrouwen. Alleen ervaren developers kunnen anticiperen welke obstakels te verwachten zijn, hoe ze er omheen kunnen werken en hoe ze alles stabiel en veilig kunnen maken. Een CMS geeft je alle controle die je nodig hebt, wat betekent dat het een hacker ook alle controle kan geven die ze nodig hebben; het is niet iets wat je kunt riskeren fout te laten gaan. En dan hebben we het nog niet eens gehad over het feit dat je waarschijnlijk wilt dat bugs snel opgelost worden.

Het hebben van een kwetsbare infrastructuur rond je CMS is niet bepaald verstandig. Developers die cruciaal zijn om de kwaliteit van het CMS te behouden, zullen daar tóch op een gegeven moment mee stoppen — dat is een gegeven. De vraag is “wanneer?”

• Het bureau kan developers ontslaan die het onderhouden.
• Deze developers kunnen zelf weggaan, ook al was het het bureau’s intentie ze te behouden.
• Het bureau kan het CMS helemaal laten vallen.
• Het bureau kan liquideren.

Vanaf dat moment is het een kwestie van tijd totdat de bugs beginnen binnen te stromen.

Open-source CMS’en zoals WordPress worden verzorgd door een leger van nerds die niets anders willen dan constante verbetering. Ze repareren bugs voor je, net zoals een bureau dat zou doen. Als je een functie voorstelt die meer implementeerders van het CMS ten goede zou komen, voegen ze die toe, net als een bureau, maar zonder de kosten. Open-source CMS’en passen ook snel nieuwe standaarden toe, terwijl het gemiddelde huisgemaakte CMS langzaamaan steeds meer in de versukkeling raakt.

Maak altijd afspraken over:

Veilig verkeer

Op websites moet altijd een SSL-certificaat zijn geïnstalleerd, zodat je verkeer veilig (HTTPS) is. Gelukkig wordt dit langzaamaan algemene kennis. Wat echter nauwelijks algemene kennis is, is dat het genereren van een SSL-certificaat gratis is en dat het verversen ervan makkelijk kan worden geautomatiseerd. Het moet altijd bij een website worden geleverd, dus laat niemand je er een hoofdprijs voor in rekening brengen, laat staan ​​een periodieke!

De padnamen

Het veranderen van padnamen nadat ze in productie zijn gegaan, is verre van moeilijk. Toch is er nóg een reden voor mij om te benadrukken hoe belangrijk het is om dit vanaf het begin goed te doen: URL’s worden van tijd tot tijd gedeeld en gedeelde URL’s hebben twee vervelende eigenschappen:

1. Ze zijn verschrikkelijk in het wekken van interesse wanneer ze lelijk of onleesbaar zijn.
2. Ze veranderen niet mee wanneer je padnamen op je website verandert. Heb je dus een typo uit je padnaam gehaald, maar is deze al gedeeld op social media? Dan heb je dus pech, en zal de typefout altijd zichtbaar zijn, daar.

Performance

“Het duurt nooit meer dan X milliseconden om een resource (zowel bestanden als serverreacties die door onderliggende scripts verwacht worden) volledig te downloaden vanaf het moment dat het verzoek is verzonden” is een goed startpunt. Door simpelweg een maximum te stellen aan de hoeveelheid tijd die een actie kan nemen, worden de developers ertoe aangezet om efficiënte code te schrijven. Of je nu van plan bent een kleine website te maken waarbij de enige interactie een contactformulier is of een volwaardige web-app die constant interactie heeft met een database, ik zou het maximum specificeren voor elke actie waar gebruikers het voltooien van af moeten wachten. Dit omvat het genereren, opvragen, opslaan en filteren van data, evenals het opvragen van (sub-)pagina’s. Voor downloads van grote bestanden richt je je natuurlijk meer op de gemiddelde downloadsnelheid dan bijvoorbeeld de responstijd.

Een technisch onderlegd persoon zal op de juiste cijfers voor jouw project moeten komen.

Het is echter niet alleen de taak van de back-end om je website snel te laten werken. De front-end speelt hierin ook een belangrijke rol, dus laten we daar op ingaan!

Front-end

De front-end technologieën HTML en CSS (en de DOM) evolueren samen met een almaar groeiend aantal gebruikers en apparaten, terwijl aan de scripttaal JavaScript langzaam wordt gewerkt om de ervaring van het schrijven van JavaScript te verbeteren. Het is een taal die bekend staat om zijn eigenaardigheden en uitzonderingen, en toch is het de meest gebruikte programmeertaal ter wereld dankzij de hedendaagse alomtegenwoordigheid van het web (wat de vraag naar developers aanzienlijk vergroot). Dat, gecombineerd met de zachte leercurve, zijn twee elementen die er in het laatste decennium voor hebben gezorgd dat er een enorm levendige gemeenschap achter de taal zit.

Het is gemakkelijk om uit te breiden op reeds bestaande implementaties, wat betekent dat er elke dag nieuwe JavaScript-frameworks worden geboren. Dit betekent ook dat de gemiddelde front-end skillset steeds meer gefragmenteerd raakt. De manier waarop we JavaScript schrijven verandert voortdurend, eens bruikbare libraries worden vervangen door in de browser gebakken API’s en het de facto framework van morgen is gisteren al vervangen.

Al met al blijkt het schrijven van JavaScript dat de tand des tijds overleeft moeilijk te zijn. Dit is jammer, omdat er goede redenen zijn om aan te nemen dat, binnen de context van codekwaliteit, de rol van de front-end developer het meest cruciaal is:

• De front-end-code is wat er naar gebruikers wordt verzonden. Hun perceptie van je bedrijf is het belangrijkste.
• De front-end-code is wat zoekmachines zoals Google kunnen inspecteren. Ze kunnen niet zien wat er in de back-end gebeurt, en het maakt ze ook niet uit hoe “goed” je website eruit ziet. Ze geven om de prestaties, structuur en, natuurlijk, inhoud van je website.
• Vanwege het brede scala aan omgevingen waarin front-end code moet worden uitgevoerd, komen sommige soorten fouten alleen in specifieke situaties voor, waardoor ze voor de developer onopgemerkt kunnen blijven. Dit kan ertoe leiden dat een aanzienlijk deel van de gebruikers de website niet correct kan gebruiken, zonder dat iemand daarvan op de hoogte is.
• Een slecht presterende back-end kan soms worden verholpen door een goede front-end. Als de respons- en/of laadtijden lang zijn en daar weinig/niets aan te doen is, is het de taak van de front-end developer om gebruikers de feedback te geven die ze nodig hebben. Het verschil tussen een pagina die niets lijkt te doen en een pagina met een eenvoudige laadafbeelding is als dag en nacht.

Randgeval

Dit gebeurde tijdens het schrijven van dit artikel. Mijn wederhelft heeft toegang tot een web-app waarin ze haar werkschema kan inzien (voor een multinational, ja). Terwijl ze probeerde in te loggen, bleef de app zeggen dat het wachtwoord dat ze had ingevoerd verkeerd was. Nu is het niet zo ongebruikelijk voor een persoon om plotseling een wachtwoord te vergeten — vooral als het een tijd geleden is dat hij/zij het zich voor het laatst heeft moeten herinneren — maar ze logt daar minstens één keer per week in.

Na een paar pogingen te hebben gedaan, merkten we dat ze geen internetverbinding had. “Vreemd. Hoe kan een website mogelijk zien of het wachtwoord correct is zonder verbinding?”
En inderdaad, zodra we de internetverbinding herstelde en probeerden in te loggen, werden we onmiddellijk toegelaten.

Zonder internetverbinding kan de back-end natuurlijk onmogelijk verantwoordelijk zijn voor deze fout, dus het is de front-end waar de fout ligt. Zoals duidelijk is gemaakt, viel deze specifieke interface standaard terug op een “verkeerd wachtwoord”-foutmelding, ook al kunnen en zullen netwerkfouten altijd optreden. We hadden het geluk dat we binnen enkele minuten ontdekten wat er mis was, want deze manier van foutafhandeling kan anderszins enorme frustratie veroorzaken. Als er een obstakel is, ben je als gebruiker volledig afhankelijk van de feedback die een website je geeft. Geen feedback krijgen is al erg genoeg, maar feitelijk onjuiste feedback kan een obstakel onoverkoombaar doen lijken. Op zo’n moment vertrekken de meeste gebruikers liever meteen.

Hoe eenvoudig het ontwerp van je website er ook uitziet, een slechte front-end developer kan je SEO-inspanningen verpesten en de gebruikerservaring te gronde richten. Dat, het feit dat de front-end als gebruiker makkelijk te inspecteren is en het feit dat ik zelf een front-end developer ben, is waarom deze checklist het uitgebreidst is.

Controleer op websites gemaakt door hetzelfde bureau:

Worden phablets ondersteund?

Controleer niet alleen of de website er goed uitziet op je desktop en je mobiele telefoon afzonderlijk. Neem de desktopversie en verklein het browservenster zodat je van elk schermformaat kunt zien hoe de website erop uitziet, vooral tussen telefoon- en tabletformaten. Die formaten zijn de meest onhandige om te ondersteunen en het kost vaak wat extra tijd om te perfectioneren. Meestal is de vensterbreedte waar de lay-out moet wisselen van twee-koloms naar een-koloms de lelijkste. De kans is groot dat er tablets en telefoons in landschap oriëntatie zijn die deze versie van het ontwerp altijd zien.

Is het logo een vectorafbeelding?

De lay-out en tekst op een website worden in wezen weergegeven door sets coördinaten te volgen en pixels te vullen aan de hand van de vormen die deze coördinaten construeren.

Dit betekent dat ze, in tegenstelling tot rasterafbeeldingen, oneindig kunnen worden opgeschaald zonder kwaliteitsverlies.

Elke op maat gemaakte visual op een website dat geen momentopname is (foto’s, screenshots, enz.), kan waarschijnlijk een vectorafbeelding zijn. Logo’s zijn een veelvoorkomend voorbeeld hiervan. Logo’s zijn tegenwoordig overweldigend plat, bestaande uit simpele geometrische vormen. Als het logo aan die eisen voldoet, maar geen vectorafbeelding is, zou ik een heel goede uitleg waarom verwachten.

Hoeveel lettertypen worden er gedownload?

Elke discipline in elke hoek van het internet is het hiermee eens: een website moet proberen het aantal lettertypefamilies zo dicht mogelijk bij 1 te houden, bij voorkeur niet hoger dan 2! Per lettertypefamilie zijn er variaties zoals vet, cursief en vet cursief; allemaal volledige lettertypen die afzonderlijk moeten worden gedownload. Hier is hun grootte verwaarloosbaar; een enkele afbeelding van lage kwaliteit kan gemakkelijk meer bytes zijn dan alle lettertypen samen. Het zijn de afzonderlijke verzoeken die ertoe doen, evenals de harmonie van de pagina (het komt zelden voor dat een goed ontwerp meer dan twee lettertypefamilies gebruikt, maar dat is de verantwoordelijkheid van de ontwerper, niet de front-end developer).

Overige lettertypen kunnen natuurlijk worden gedownload voor speciale gevallen, zoals bijvoorbeeld een “monospace font” voor code of een “icon font” voor, nou ja, iconen. (Vanwege de oneindige, vector-gedreven schaalbaarheid en “zwart-wit” aard van tekst, zijn iconen als pijltjes en social media logo’s tegenwoordig vaak letters uit een lettertype)

Zijn alle favicons er?

Met deze Favicon-checker kun je zien welke versies van het logo de developers voor verschillende applicaties hebben geleverd. Als alles goed is geconfigureerd, zien de favicons er consistent uitzien.

Zijn er placeholders voor dingen die nog gedownload moeten worden?

Dit is echt een van mijn pet peeves. Er is niets zo vervelend als proberen ergens op te klikken wanneer- WHOOPS! De hele pagina verspringt omdat een afbeelding klaar is met downloaden en je klikt op het verkeerde.

Kun je de website met je toetsenbord navigeren?

De statistieken zijn hier ietwat wazig. Conservatieve statistieken tonen aan dat minstens 8,5 procent van de bevolking een handicap heeft die het internetgebruik beïnvloedt, van wie de helft een visuele beperking heeft. Onder hen is natuurlijk een significante hoeveelheid mensen die hun gezichtsvermogen herstellen met fysieke hulpmiddelen als een bril, of die vanwege hun beperking überhaupt zelden toegang tot het internet zoeken. Wat je overhoudt, is een goede 1 procent gebruikers voor wie het toetsenbord voor navigatie absoluut noodzakelijk is. Voor de rest van de slechtzienden kan het de voorkeur zijn, al is het maar af en toe.

Zijn lettertypegroottes relatief?

Wellicht weet je niet dat het mogelijk is, maar je kunt de lettertypegrootte van je browser wijzigen in de instellingen. Mensen met verminderde gezichtsscherpte kunnen besluiten de lettergrootte te vergroten, zodat ze de tekst op je website beter kunnen lezen.

Als je zelf de lettergrootte van je browser vergroot, groeit alle tekst dan respectievelijk op een logische manier? Hoe ver kun je gaan voordat de lay-out van de pagina breekt? Je zou de lettergrootte met minstens 50% moeten kunnen vergroten zonder dat dit gebeurt.

Wees voorzichtig wanneer:

Een front-end developer zegt dat iets onmogelijk is.

Ik kan me geen enkel geval herinneren waarin een front-end developer correct beweerde dat een taak onmogelijk was. Begrijp me niet verkeerd, genoeg dingen zijn praktisch onmogelijk, maar ze zijn veel zeldzamer dan je zou denken. Met dat in gedachten, overweeg ze een uitleg te vragen waarom de taak onmogelijk is. Als ze moeite hebben om een ​​manier te vinden om het probleem te beschrijven of als ze de taak snel wegschuiven als “simpelweg te ingewikkeld”, bestaat de kans dat de developer niet eens weet wat ze niet weten / waar ze meer over zouden moeten weten.

Maak altijd afspraken over:

Universele ondersteuning.

Elk deel van je website moet voor iedereen toegankelijk zijn, op elke locatie en op elk apparaat.

Zoals ik al zei, moet toetsenbordnavigatie sowieso mogelijk zijn. Alle elementen waar je met de muis mee kunt interacteren (voornamelijk invoerelementen) moeten een duidelijke, voor de hand liggende indicator hebben voor wanneer je ernaartoe navigeert met de Tab-toets. Deze indicator zit standaard in de browser als een extra rand, of “focusring”.

Dat deze ringen (of andere, herkenbare indicatoren) er überhaupt zijn, is niet het enige dat van belang is, maar ook het contrast tussen de ring en de achtergrond! Kleurenblinde mensen gebruiken bijvoorbeeld vaak het toetsenbord omdat het moeilijk te zien is welke elementen klikbaar zijn omdat voor hen contrast, niet kleur, de enige betrouwbare factor is. Daarnaast zijn er tal van tijdelijke redenen voor mensen om het toetsenbord te gebruiken: kapotte touchpad, lege muisbatterij, gebroken arm, oogletsel, verloren bril.

Bovendien hebben mobiele apparaten ook geen muis, dus geen enkele essentiële functionaliteit kan afhankelijk zijn van alleen-muisinteracties. Denk aan functionaliteit die activeert wanneer je je cursor ergens positioneert, of bij het indrukken van de rechter muisknop.

Zoals uitgelegd in mijn laatste blogpost, nemen de meeste wijzigingen die je moet aanbrengen om basis-, maar essentiële, ondersteuning voor slechtzienden toe te voegen, slechts een paar minuten van je tijd in beslag. Maar naast het feit dat het een inherent goede zaak is om mensen met een handicap te ondersteunen, is er een extra reden om dit te doen die je misschien niet had overwogen:

Als geen van de websites van je rivalen ze ondersteunt, maar jij wel, kun je vrijwel alle conversies voor jezelf houden, wat betekent dat de eerder genoemde 1 procent aanzienlijk kan oplopen. Als je concurrent 10 keer zoveel verkeer heeft als jij, maar geen van hun gebruikers met een visuele beperking daar uiteindelijk koopt vanwege hun problematische navigatie, dan zou dat betekenen dat je — in een ideale wereld waar elke dergelijke gebruiker op hun beurt naar jouw website gaat — geen verhoging van 1 procent krijgt, maar een verhoging van 10 procent.

Performance

Net als bij de back-end, kun je simpelweg harde getallen betrekken bij de front-end performance. Er zijn er twee waar ik in het bijzonder aandacht aan zou geven:

1. “De FMP (First Meaningful Paint) vindt plaats binnen X milliseconden.”
   Het is de beste basis die ik kan bedenken, aangezien deze vereiste aansluit op het feit dat gebruikers binnen enkele seconden weer weg zijn als ze niets zien.
2. “Op geen enkel moment gaat de FPS (frames per second) onder X.”
   Niemand houdt van een stotterende webpagina. Een developer kan misschien prachtige, complexe parallax-effecten creëren die naadloos worden afgespeeld op hun hoogstaande computer-setup, maar als hetzelfde script de ​​gemiddelde mobiele telefoon terugbrengt naar een slakkenpas, is er iets mis. Daarom zou ik vragen om een ​​overzicht van alle “dynamische momenten”. Dit zijn momenten waarbij er wijzigingen worden aangebracht aan de pagina of animaties worden afgespeeld. Neem deze momenten door op tragere apparaten.

Van MDN:

“Users expect all interface interactions to be smooth and all user interfaces to be responsive. Animation can help make a site feel faster and responsive, but animations can also make a site feel slower and janky if not done correctly. Responsive user interfaces have a frame rate of 60 frames per second (fps). While it is not always possible to maintain 60fps, it is important to maintain a high and steady frame rate for all animations.”

Content

Of de cont-end, zoals ik het graag noem.

Content is niet geprogrammeerd, maar wordt door de eigenaar aangeleverd via een CMS. Om deze reden lijkt content niet bepaald iets dat een hoge of lage kwaliteit heeft, qua code. Het zijn tenslotte alleen je teksten / afbeeldingen / video’s, niets van “lage kwaliteit”, toch? Een misleidende veronderstelling.

Je content ondergaat veel transformaties voordat het door je gebruikers wordt gezien. Ten eerste moet een visuele interface (de CMS-pagina van je website) je content ontvangen en interpreteren. Voor bestanden zoals afbeeldingen is dit proces vrij eenvoudig. Voor tekst zijn er echter tal van implementaties.

Ten tweede moeten de gegevens naar de back-end worden gestuurd en in de database worden opgeslagen. Zo kunnen ze later weer opgehaald worden.

Ten slotte, wanneer een gebruiker een resource opvraagt, moeten de relevante gegevens weer uit de database worden gelezen en teruggestuurd worden naar de front-end om daar te worden weergegeven in wéér een andere visuele interface (de pagina die je bezoeker ziet).

Al deze stappen zorgen ervoor dat je content wijzigingen ondergaat, zij het door opnieuw te formatteren of door te coderen / decoderen. Het is zo gemakkelijk om het te verknallen dat de meest voorkomende fout (de ampersand, &, weergegeven als &amp) door de jaren heen een aantal vragen op Reddit heeft gegenereerd van mensen die zich afvragen waarom ze het op verschillende plekken op het internet blijven zien. Sommige grote namen doen het nog steeds op sommige plekken fout, zoals SoundCloud:

Zoek je op een artiest met een ampersand in de naam, dan krijg je normale resultaten:

Zoek je daarentegen naar een specifiek item uit een discografie, dan krijg je dit:

Semantiek

Het grootste probleem met de verschillende stappen die je content neemt voordat deze je gebruikers bereikt, ligt echter niet in de voorheen genoemde soorten bugs, maar in iets heel anders: semantiek, het ding waar onze grote vrienden in de cloud en hun webcrawlers waarde aan hechten. De back-end developers, front-end developers en jij moeten het eens zijn over hoe je de content van je website maakt en bewerkt. Dit kan in wezen slechts op één manier worden gedaan: door jou intuïtieve tools te bieden waarmee het moeilijk is (of onmogelijk, als dat je voorkeur is) om fouten te maken. Meestal betekent dit dat er minimale verantwoordelijkheid aan jou wordt overgedragen en dat je via een eenvoudige, maar volledige, interface gestuurd wordt.

De trieste realiteit is dat het vinden van een balans tussen deze kwaliteiten erg moeilijk is. Er zijn veel technische regels waarover we je liever niet expliciet willen moeten vertellen, maar we moeten er ook voor zorgen dat deze regels worden nageleefd. Daarom worden alles-in-een-oplossingen zoals Rich Text Editors (RTE’s) over het algemeen gezien als de beste methode om content te verwerken.

Ze zijn gemakkelijk te gebruiken en zitten boordevol functies, en dat is precies waar het mis kan gaan. Je kunt elke teksteigenschap met een paar klikken wijzigen. Als je wilt, kun je mediabestanden in het midden van een zin plaatsen. Je kunt tabellen creëren en in sommige editors kun je tabellen zelfs vanuit je klembord plakken. De meeste RTE’s hebben ingebouwde image-editors en ik denk niet dat het lang zal duren voordat het ook voorzien van een video-editor de norm wordt. Al deze mogelijkheden maken het beheren van content zo eenvoudig dat ze je kunnen doen vergeten om de rol van een stuk content expliciet te vermelden, en dat terwijl dit essentieel is voor je SEO-ranking én toegankelijkheid.

Het op deze manier gebruiken van RTE’s is analoog aan het toegereikt krijgen van een grote set penselen en verven, waarmee je elke look creëert die je maar wilt, alleen om erachter te komen dat je eigenlijk binnen de lijnen moet kleuren.

Een hint van wat ik bedoel, is te vinden in alledagelijkse editors wiens look en feel door RTE’s worden nagebootst, zoals Microsoft Word. Hoewel het verstrekken van “extra” informatie (meta-informatie) voor Word-documenten zinloos is als je ze enkel gaat afdrukken, is dit nog steeds een prominent onderdeel van het programma. De redenen zijn voornamelijk dezelfde als voor het web. Hieronder is een video van 2 minuten uit de kennisbank van Microsoft waarin ze worden uiteengezet (geloof me, je wilt deze tot het einde zien).

Zoals je kunt zien, voegt de juiste semantiek structuur toe en draagt het ​​informatie met zich mee waar andere programma’s gebruik van kunnen maken. Schermlezers kunnen het documentoverzicht lezen, zonder dat je er expliciet een hoeft te genereren. Toetsenbordgebruikers kunnen naar een volgende sectie gaan door naar de eerstvolgende koptekst te springen. Webcrawlers kunnen informatie beter extraheren en prioriteren tijdens het indexeren van je website.

Het huidige RTE-landschap bestaat voornamelijk uit editors die het product zijn van verschillende ideeën en technologieën die langzaam tot één product culmineren; sommigen blinken écht uit in bepaalde taken, maar geen enkele is helemaal perfect. Het kwaliteitsverschil tussen betaalde RTE’s en gratis RTE’s wordt langzaam kleiner, maar is mogelijk cruciaal. Al deze kenmerken en variaties maken het moeilijk om het bos door de bomen te zien, maar ze komen neer op één advies:

Wanneer je een bureau of developer beoordeelt die aan een CMS of een RTE gaat werken, vraag hen dan hoe de gebruikers de juiste semantische elementen voor hun content kunnen creëren.

Zoals gezegd zijn er tal van implementaties voor het beheren van content, vooral voor tekst. Sterker nog, er zijn niet eens officiële standaarden als het hierom gaat — niet in HTML, noch in JavaScript — dus wees niet te streng voor de developer. Door naar deze dingen te vragen, kun je een indruk scheppen of de developer zich überhaupt zorgen maakt over dit soort dingen en of ze zich inzetten om het beste product te produceren dat ze kunnen.

Hieronder staat een lijst met contentelementen, waarvan de meeste een belangrijk semantisch doel hebben. Misschien doe je er goed aan het ergens op te slaan (door dit artikel natuurlijk te bewaren), zodat je er altijd naar terug kunt keren om de punten opnieuw door te nemen voor het volgende project. Houd deze lijst bij de hand, en je hoeft je geen zorgen te maken dat er iets mist zodra het ontwikkelproces achter de rug is.

Koppen

In plaats van de lettergrootte en -dikte te vergroten, moet er een optie zijn om koptekst van broodtekst (de rest van de tekst) te onderscheiden. Dit kan worden gedaan door jou afzonderlijke gebieden voor de koppen en broodtekst te geven, waardoor visueel onderscheid wordt gecreëerd in de interface. Ook kan de RTE worden voorzien van een aangewezen “kop”-knop. Hoe dan ook, je zou 6 koptekstgroottes moeten kunnen maken. HTML biedt 6 koptekst niveau’s.

Bijna alle RTE’s worden met deze functie geleverd.

Lijsten

Er zijn 3 verschillende mogelijkheden tot het creëren van lijsten:

1. De algemene, ongeorderde lijst (“unordered list” (<ul>))
   Deze beginnen met een bullet “•”.
2. De genummerde lijst (“ordered list” (<ol>))
   Bij dit type lijst moet je ook aan kunnen geven of hij op- of af- moet tellen en vanaf welk getal. Die dingen zijn allemaal deel van de standaard.
3. De omschrijvingslijst (“description list” (<dl>))
   Dit (veel obscuurdere) type lijst bestaat uit sets van termen en beschrijving.

Verder is het natuurlijk een enorm pluspunt als de RTE automatisch een lijst voor je begint als je een zin begint met een “-” of “1”.

Tabellen

Ik herinner je er maar even aan dat ze bestaan. Als je ooit tabelgegevens wilt presenteren zoals je zou doen in Microsoft Excel, dan heb je tabellen nodig.

Citaten

Naast de quote zelf en de persoon die je citeert, moet je bij elke quote ook de naam van het geciteerde materiaal en een URL naar dat materiaal kunnen specificeren. Op die manier kan een zoekmachine je quote valideren.

Afkortingen

Ik heb in dit artikel veel gebruik gemaakt van de <abbr> tag. Iedereen zou deze moeten gebruiken!

Meer obscure tekststijlen

Misschien is het markeren van tekst jouw ding.

Verwijderde tekst is ook iets dat je misschien wilt kunnen aanmaken.

Dan zijn er nog _subscript en ^superscript. Hoewel ze meestal worden gebruikt voor wiskundige formules, zijn er genoeg redenen om ondersteuning voor hen te vragen, met name superscript. Met superscript kun je zaken typen als 2^e, 2² and praktaliteit™.

Inline tekst met meerdere kolommen

Ik heb mensen kolommen in hun tekst zien maken door enorm veel witruimte toe te voegen tussen stukjes tekst. Ook heb ik de opeenvolgende nachten geen oog dichtgedaan.

Grappen terzijde, ik heb dit meerdere keren zien gebeuren. Er is zoveel mis met het op die manier maken van kolommen dat ik het niet eens ga uitleggen; als je de laatste paar duizend woorden op hebt gelet, weet je wel waarom. Als je wilt dat een stuk tekst wordt opgesplitst in 2 of 3 kolommen, vraag de developers daar dan een optie voor toe te voegen.

Ik heb het niet over de mogelijkheid om in de lay-out van de pagina kolommen te maken, maar over de mogelijkheid om te beslissen over hoeveel kolommen de browser je tekst moet verdelen (standaard is dit 1). Wanneer je tekst toevoegt / verwijdert, blijven alle kolommen namelijk automatisch op dezelfde hoogte.

Oh, en als je denkt dat je nooit ondersteuning voor meerdere inline kolommen nodig hebt, bedenk dan hoe hoog een boodschappenlijstje er zonder uit zou zien op je website.

Netheid

Tekst

Inline tekststijlen

Met “inline” bedoel ik dat je binnen één zin of paragraaf wisselt tussen stijlen. Dit zou geen ding moeten zijn.

Natuurlijk moet je je tekst gekleurd, vet, cursief of monospace kunnen maken. Maar — zoals eerder besproken — hoe deze varianten van je lettertypes eruit zien, zijn ontwerpbeslissingen. Je website hoort er waarschijnlijk niet uit te zien als een lagere school knutselwerkje, dus eigenschappen als lettertypefamilie, lettergrootte, woordafstand en regelafstand mogen helemaal niet inline worden gewijzigd.

Link stijlen

Om aan het bovenstaande punt toe te voegen, is er een plaats waar het geen zin heeft om iemand welke stijl dan ook te laten veranderen, en dat zijn hyperlinks. Onze eerste blogpost dook toevallig in op dit onderwerp en het toegankelijkheidsaspect ervan.
Kort gezegd: hoe meer dingen je weghaalt die een link herkenbaar maken, hoe vervelender het weer wordt voor slechtzienden.

Dubbele spaties

Er zijn genoeg redenen om geen spellingcontroles te implementeren, maar er moet in ieder geval worden gecontroleerd op meer “universelere” fouten, zoals dubbele spaties, dubbele komma’s, enz.

Ik heb dubbele spaties gezien op websites van alle kalibers en is (natuurlijk) nooit met opzet gedaan. En dat terwijl een simpele zoekopdracht naar dubbele spaties in een tel is gebeurd.

Afbeeldingen

Tekst in afbeeldingen

Een van de dingen die jij zelf moet vermijden, is het toevoegen van afbeeldingen met tekst erin. Ja, er zijn situaties waarin stukjes tekst in afbeeldingsformaat mogen komen, zolang ze geschikte beschrijvingen krijgen in de functionele opmaak van de pagina. Flashy graphics die alleen gemaakt kunnen worden met externe tools zoals Photoshop zijn hier een voorbeeld van. Tekst die alleen voor esthetische doeleinden in afbeeldingen is opgenomen, in plaats van bedoeld te zijn voor schermlezers en webcrawlers, kan worden genegeerd.

Slecht uitgesneden afbeeldingen

Donkere tekst op lichte achtergronden is beter leesbaar dan andersom. Dit geldt zowel voor papier als voor schermen. Als zodanig is een “blank canvas” bijna altijd wit, ook voor beeldbewerkingssoftware. Maar het maken en testen van je afbeeldingen met alleen een witte achtergrond kan ervoor zorgen dat je website in plaats van een verfijnde indruk, een slordige indruk afgeeft. Zelfs Google weet dit zo af en toe te verpesten:

Denk hier altijd aan wanneer je afbeeldingen maakt of gaat laten maken. Als je denkt dat je zeker weet dat de achtergrond niets anders is dan wit, denk dan nog eens goed na. Geforceerde dark mode keert veel kleuren op de pagina om, inclusief de achtergrondkleur, maar niet die in afbeeldingen.

Maak altijd afspraken over:

Open Graph-gegevens

Bekijk onze blogpost over Open Graph.

Complete faviconset

Zoals ik eerder zei, zou een Favicon-checker een harmonieuze set pictogrammen moeten laten zien. Dit zorgt ervoor dat wanneer mensen jouw website als snelkoppeling op hun apparaat bewaren, deze snelkoppeling visueel identiek is aan een normale app, met jouw branding. Zo past het icoon beter tussen de rest.

Dubbel Check:

Spelling en grammatica

Google bestraft websites niet voor spellings- en grammaticafouten omdat taal veel te divers is om met vertrouwen te zeggen of iets “fout” is. Elke dag worden nieuwe woorden bedacht en mensen spellen woorden soms zelfs expres verkeerd.

“Dus wat is het probleem?” denk je misschien. Het blijkt dat het bouncepercentage voor pagina’s met taalfouten twee keer zo hoog is als voor pagina’s zonder. Je zou bij voorkeur een professional in moeten huren om je content te schrijven. Ga je dat niet doen? Zorg er dan in ieder geval voor dat alles door meerdere mensen wordt gecontroleerd op fouten.

Je wensen & vereisten

Dit is een van die dingen die de kwaliteit van de codebase kunnen verlagen, zelfs als er competente developer aan het werk zijn: klanten die tijdens de ontwikkeling de eisen veranderen. Dit is niet zó erg, als het maar met mate gebeurt. Ik ben echter in situaties geweest waarin klanten hebben gevraagd om praktisch alles te veranderen terwijl ze al hadden ingestemd met wat er werd ontwikkeld. Dingen kunnen akelig worden, niet alleen omdat je moet betalen voor de extra tijd die wordt besteed aan het doorvoeren van de wijzigingen, maar ook omdat het bureau maar net de tijd beschikbaar moet hebben om voor je te werken. Zorg er dus voor dat je wensen en vereisten duidelijk zijn vastgelegd. Een manier om hiervoor te zorgen is goede communicatie.

Je hebt waarschijnlijk zelf een vrij goed idee van hoe je website eruit zou moeten zien en hoe deze zou moeten functioneren. Maar omdat je geen developer bent, kun je onmogelijk alle beslissingen voorzien die vanuit jouw kant moeten worden gemaakt. Dat is waar de developers inspringen. Nadat je ze hebt verteld wat de intenties van je website zijn en welke vereisten je zelf hebt uitgewerkt, zouden zij die met hun developersmentaliteit moeten kristalliseren om je te kunnen vertellen wat er ontbreekt. Dit is een proces dat hand in hand kan gaan met het testen van prototypes, iets dat het ontdekken van verdere vereisten een stuk eenvoudiger maakt.

Aan de andere kant is een andere veelgemaakte fout dat klanten vergeten na te denken over welke onderdelen ze eigenlijk verwachten dat ze herbruikbaar / bewerkbaar zijn. Laten we dit voorbeeld nemen: je gaat tweedehands T-shirts verkopen op je website. Gebruikers gaan hun T-shirts plaatsen, vergezeld van één foto van de voorkant en één van de achterkant. Met dit eenvoudige concept in gedachten, zou een van je vereisten kunnen worden: “Gebruikers moeten 2 afbeeldingen per bericht uploaden”. Het lijkt goed, maar later kom je misschien tot het besef dat je gebruikers ook een afbeelding van het waslabel moeten kunnen toevoegen, dus je moet het maximum verhogen van 2 naar 3. Oh ja, en die derde foto is optioneel, dat moet ook.

Maar kunnen deze dingen? Hebben de developers het gemakkelijk veranderbaar gemaakt in de codebase? Zo niet, dan staat je een vers berekende factuur te wachten. Niet alleen dat, maar hoe langer je wacht voordat je om de wijziging vraagt, hoe groter de kans dat er complicaties optreden. Een betere vereiste zou dus zijn geweest: “Het aantal afbeeldingen dat gebruikers bij ieder bericht kunnen uploaden is configureerbaar vanuit het CMS. Tevens kunnen deze upload-opties optioneel of verplicht worden gemaakt vanuit het CMS.”

Vuistregel:
Probeer bij het bedenken van eisen geen redenen te vinden om aspecten te fixeren, maar andersom: probeer redenen te vinden om ze open te laten.

Laten we het T-shirt-voorbeeld hierboven nemen. Wanneer je de vereisten opsomt, kun je gemakkelijk naar de limiet van twee afbeeldingen kijken en deze meteen accepteren. “Een T-shirt heeft maar twee kanten. Dat zal niet veranderen”, zou de redenering kunnen zijn. Wanneer je jezelf er daarentegen toe zet om goed na te gaan ​​waarom je een aspect op een later moment wél zou willen wijzigen, wordt het veel moeilijker om het aspect te fixeren.

Hoewel het vrij simpele, tegengestelde denkwijzen zijn, geeft deze manier van denken de ruimte aan dat “wat als?”-gevoel om de voorhand te nemen. Het is veel enger om bewust te zeggen dat er geen enkele reden is of zal zijn dat je het aspect in de toekomst wilt veranderen dan om het gewoon open te laten.

“Gebruikers willen misschien close-ups van slijtage, een foto van iemand die het T-shirt draagt, een aparte foto van de branding of eentje van het waslabel zien,” zijn dingen die toch al vrij snel in je opkomen wanneer je jezelf ertoe zet redenen te verzinnen om de limiet open te laten.

Vooral als je een vereiste evalueert die een hoeveelheid bevat (zoals “2 afbeeldingen per bericht”), zou ik je aanraden om er opnieuw over na te denken. Het is zelden schadelijk om dergelijke opties open te laten.

Tot slot

Ik besloot dit artikel te schrijven omdat ik de laatste tijd wat kleinere wijzigingen heb aangebracht aan een website die door een ander bureau is gemaakt. De mensen die bij het betreffende bureau werken, zeggen op hun eigen manier dat ze aan de top staan ​​als het gaat om webdevelopment, wat ze stellig geloven. Echter:

• Ze hadden een WordPress-thema geïnstalleerd en daarna lieten ze mij het geheel responsive maken (behalve dat ze niet in staat zijn om een ​​responsive website te ontwikkelen, kozen ze niet eens een thema dat dat is. Verbazingwekkend). De CSS die ze hadden geschreven, maakte de website zo wankel dat vrijwel geen van de elementen op de pagina correct was uitgelijnd. Ik moest het allemaal oplossen.
• Alle koppen waren (en zijn nog steeds) wazige rasterafbeeldingen, nieteens geplaatst in kopelementen (semantiek, weet je nog?).
• De actie “Alle resultaten bekijken” van hun filter kostte 80 seconden om te reageren, zonder natuurlijk een laadindicator.
• Ze moesten me vragen om dingen van kleur te veranderen; iets wat binnen de eerste 2 minuten van iedere CSS-cursus wordt uitgelegd.
• Om een ​​afbeelding in de rechteronderhoek van een element te plaatsen, creëerden ze een hele nieuwe rij eronder, vulden deze met vier kolommen, lieten de eerste drie leeg en plaatsten de afbeelding in de laatste. Vervolgens verplaatsten ze de afbeelding visueel naar boven, naar de juiste locatie.
  Dit is vergelijkbaar met het inhuren van een helikopterpiloot om constant voor de zon te vliegen, in plaats van gewoon je zonnebril op te zetten.

Laat me hun standpunt over hun expertise herhalen:
Ze beweren niet dat ze “oké” zijn.
Ze beweren niet “goed” te zijn.
Ze beweren niet eens dat ze “erg goed” zijn.
Nee, ze beweren tot de allerbesten te behoren.

Conclusie? Overweeg altijd een ​​second opinion!

In mijn ervaring vertellen goede developers waarom ze de dingen doen die ze doen, niet hoe of hoe goed. Ik heb regelmatig developers ontmoet waarvan ik denk dat ze zich in een positie wurmen door haastig een aantal cutting-edge technologieën te noemen in de hoop dat de persoon aan de andere kant bijt, in plaats van uit te leggen waarom hun methodologieën de betrokken mensen ten goede komen — jij, je collega’s, je klanten.

Er zijn genoeg pet peeves die ik niet heb besproken, zoals developers die een andere taal dan Engels gebruiken bij het benoemen van dingen in hun code of developers die gigantische frameworks inladen voor slechts één van diens functionaliteiten. De eerste is stilistisch en objectief onbelangrijk voor de gebruikerservaring, de laatste is te algemeen.

Aan de andere kant lijken sommige van de dingen die ik heb besproken misschien een beetje overdreven. Immers, “is het logo een vectorafbeelding?” is waarschijnlijk niet iets waar je eerder wat om gaf, laat staan nu. Nee, de kern van de controles is dat hun gecombineerde resultaten je een redelijk goede indicatie geven van de kwaliteit van het werk dat wordt gedaan. Zoals ik al zei, wilde ik controles opnoemen die aan het oppervlak te vinden zijn, wat de mogelijkheden ernstig beperkt. Dat gezegd hebbende, zou ik wanneer een developer géén van alle checks haalt sowieso niet onder de kap durven te kijken.

function getAge ($date) {
  return substr(date('Ymd') - date('Ymd', strtotime($date)), 0, -4);
}

echo getAge('1990-01-01');