Blogg

Kvalitetssäkring av gränssnittskod - så skapar du ett gränssnitt som fungerar för alla användare

  • 21 mars 2017
  • 0

Vi som jobbar med gränssnittsutveckling på NetRelations har alltid strävat efter att kunna vara stolta över det vi levererar. Vi vill bygga gränssnitt som ser ut och fungerar som det är tänkt – för alla användare. Men även under ytan, i koden som bara vi som jobbar med den ser, är det viktigt för oss att hålla hög standard. Är du nyfiken på hur vi arbetar med kvalitetssäkring av vår gränssnittskod är detta blogginlägget för dig!

Artikelverktyg:

Kod som det är ordning på blir lättare att läsa, förstå och underhålla. Och om alla utvecklare följer samma kodstil och riktlinjer blir det enklare att sätta sig in i andra projekt än de man själv har byggt upp.

Vi har interna riktlinjer för det, men det finns också verktyg som kan automatisera och underlätta mycket, och jag tänker mig att det kan vara intressant för andra att se vad vi använder och hur.

Vår kvalitetssäkring kan delas in i fyra områden: HTML, CSS, JavaScript och tillgänglighet. De hänger delvis ihop, som jag går in på senare. Vi använder byggverktyget Grunt för att paketera  vår gränssnittskod för leverans (slå ihop flera filer, minifiera koden med mera), så det passar väldigt bra att integrera de delar av kvalitetssäkringen som kan automatiseras där.

De flesta av oss har också sina kodredigerare (var och en använder det man trivs bäst med, så det kan vara Atom, Sublime Text, TextMate, Visual Studio Code eller något helt annat) inställda så att de plockar upp samma inställningar som Gruntbygget använder och därmed kan ge feedback direkt när man skriver kod. Detta gäller främst för CSS och JavaScript.

HTML

Grundplåten för ett webbgränssnitt är HTML-koden. Utan den finns inget att visa. Här finns en självklar standard att följa i form av W3C:s rekommendationer – den aktuella just nu är HTML5.1. Vi ser till att all HTML-kod validerar med hjälp av grunt-html.

Utöver det har vi några interna riktlinjer för hur vi skriver HTML. Till exempel skriver vi alla tagg- och attributnamn med gemener och omger alla attributvärden med `"`. För att hålla ordning på oss där använder vi grunt-htmlhint.

Vi vill också göra det lättare att bygga webbgränssnitt som är tillgängliga för alla användare, och har därför ett internt verktyg som analyserar all HTML-kod, den som faktiskt överförs såväl som den som genereras av JavaScript. Verktyget, som vi kallar Best Practice Checker, varnar för potentiella tillgänglighetsproblem och ”code smell”. Best Practice Checker har sitt ursprung i NetRelations Inspector och finns som plugin till Grunt samt som tillägg till Chrome och Firefox, men det är Grunt-versionen som körs automatiskt.

Alla ovanstående verktyg körs på samtliga HTML-vyer i våra prototyper – kompletta sidor såväl som enskilda komponenter.

CSS

Så fort vi sparar en CSS-fil går CSSComb igenom den och justerar formatering (indentering, radbrytningar, var vi använder mellanslag m.m.) och sorterar alla deklarationer inom regler enligt en bestämd ordning. På så sätt kommer vår CSS att se i princip likadan ut oavsett vem som har skrivit den.

Vissa saker fångas inte upp av CSSComb, så vi använder stylelint som komplement, tillsammans med tilläggen stylelint-order och stylelint-selector-bem-pattern. Eftersom stylelint kan köras direkt i de flesta kodredigerar får vi direkt feedback om vi skriver CSS som inte följer våra regler. Med stylelint-selector-bem-pattern håller vi kolla på att vi följer den variant av BEM som vi använder.

JavaScript

För JavaScript klarar vi oss med eslint, som varnar när vi inte följer de regler vi har definierat och automatiskt fixar mycket som är relaterat till formatering av JavaScriptfiler. Precis som stylelint kan eslint ge oss feedback direkt i våra kodredigerare.

Tillgänglighet

Som jag nämnde i avsnittet om HTML använder vi ett egenutvecklat verktyg, Best Practice Checker, för att testa de tillgänglighetsaspekter som är möjliga att testa automatiskt (en del som är relaterat till tillgänglighet kräver manuell testning för att vara pålitlig). Några exempel på vad som testas är korrekt användning av rubriker, att länkar innehåller rimliga mängder text, att tabeller är korrekt strukturerade och att alla formulärelement har en beskrivande text.

Vi använder via Best Practice Checker även axe-core och får då reda på mer designrelaterade problem som om element har för låg kontrast mellan text och bakgrund.

Ger enhetlighet och sparar tid

Sammantaget ger alla de verktyg vi använder för validering, testning och lintning vår gränssnittskod en enhetlighet som gör det lättare för oss att jobba i varandras projekt vid behov. Det underlättar också versionshantering eftersom våra diffar blir fokuserade på faktiska kodskillnader och inte hur radbrytningar eller indenteringar är gjorda.

Våra kodstilsregler och uppföljningen av dem gör också att vi inte behöver lägga energi på att komma ihåg vilken kodstil vi ska använda – det talar verktygen om för oss. Och efter ett tag sitter det i ryggmärgen utan att man behöver tänka på det. Verktygen blir våra lärare!

Vill du veta mer om hur vi kan hjälpa dig att kvalitetssäkra gränssnitt?

Välkommen att kontakta oss via formuläret eller ta en kontakt med vår försäljningschef Filip Berglund. 

Är du gränssnittsutvecklare och gillar hur vi arbetar med gränssnitt hos oss?

Tveka inte att söka någon av våra lediga tjänster

0 kommentarer

Skriv kommentar