Artikel
Att få kontroll på din frontend
Som utvecklare kan man behöva tackla olika sorters problem varje dag i veckan. Om det inte är äldre webbläsare som inte riktigt håller vad de egentligen aldrig har lovat, så är det strulande javascript eller tredjepartsstjänster som plötsligt upphör att existera. Ett annat problem är CSS, inte så mycket att hantera det och få det att fungera, som att få en bra struktur på hela bygget och en stabilitet som gör att det inte rasar som ett korthus när en ny utvecklare ska in och förändra eller lägga till något.
På Kodamera har vi utvecklat flertalet webbplatser med invecklad – oftast responsiv – design där mängden information är stor. En lärdom som vi dragit efter alla dessa projekt är att man behöver ha en plan för hur man strukturerar upp sin CSS om man vill att slutresultatet skall bli lättöverskådligt, flexibelt och lätt att underhålla. Här har vi under det gångna året tagit en mängd steg i rätt riktning för att få till stånd ett arbetssätt som höjer leveranskvaliteten och ger utvecklarna ytterligare stöd till att fatta rätt beslut.
Philip Walton som är ingenjör på Google menar att det finns två olika typer av CSS-problem; visuella och strukturella problem. Av dessa två är det de senare som har visat sig vara de som ger mest huvudvärk i det långa loppet.
Visuella CSS-problem
Har du någonsin försökt få ett element centrerat både horisontellt och vertikalt inuti ett annat element? Försökt få två kolumner att vara lika höga trots att de har olika mängd innehåll? Kämpat med att dina marginaler av någon anledning är dubbelt så breda i IE6? Historiskt sett så är det CSS-utmaningar av detta slag som fått störst publicitet, och det har skrivits drösvis med böcker om hur man bäst tacklas med specifika layout-problem på bästa sätt (mycket tack vare att webbläsarna på den tiden gjorde sådan kunskap oumbärlig p.g.a. obefintlig standardisering). Idag så är förslag på lösningar till den här typen av problem oftast en enkel googling bort, och utvecklingen av webbstandarder har också gjort att det idag är lättare än någonsin att få ett homogent resultat i flertalet av de större webbläsarna.
De visuella problemen ger sig oftast tydligt tillkänna när de dyker upp och bromsar temporärt upp utvecklingstakten tills dess att de lösts. Men tack vare mängden av dokumentation som finns att tillgå på nätet idag så är de sällan några större showstoppers, och har man inte redan innan målat in sig i ett hörn vad gäller möjliga lösningsalternativ så brukar de flesta problem av visuell karaktär likt farthinder vara relativt lättöverkomliga.
Strukturella CSS-problem
Strukturella problem har till skillnad från de visuella en tendens att smyga sig på en; de upptäcks oftast inte i mindre kodbaser utan tenderar bli påtagliga först när mängden kod växer, vilket gör att när de väl upptäcks är det oftast för sent att med enkla medel göra någonting åt dem. Resultatet kan i värsta fall vara en kodbas som tenderar att fungera precis som det är tänkt, men som är allt annat än smidig att underhålla och/eller vidareutveckla. Utmaningen här handlar om att ta språkets (i det här fallet CSS och Sass) natur i beaktande, och formulera arbetssätt som gör det möjligt att arbeta runt eller helt undvika dessa relativt vanliga fallgropar. Målet är en arkitektur som kan skala uppåt utan sidoeffekter, och som möjliggör att en kollega kan återkomma till kodbasen 6 månader senare och göra tillägg och/eller ändringar utan risk att något besläktat element på en annan plats av webbplatsen går sönder.
CSS har arv som ett centralt tema; själva namnet (Cascading Style Sheets) antyder att språket möjliggör ett upplägg där regler ärver egenskaper av varandra. I små och begränsade projekt möjliggör detta att man kan skriva kompakta och effektiva stilmallar, men i större projekt gör denna benägenhet till arv att man enkelt hamnar i en situation där objekt ärver av varandra i flera steg, och där en liten ändring i mitten av kedjan får oanade konsekvenser. Och vips så har man ett strukturellt problem på halsen.
På Kodamera så tror vi på långsiktiga lösningar där vidareutveckling och förvaltning är en naturlig del av en webbplats livscykel. Tillika strävar vi efter att leverabeln skall vara likvärdig oavsett vilka enskilda individer som varit inblandade i projektet. För att detta skall fungera i praktiken så har vi arbetat med att höja ribban för vad som levereras i vad som på fackspråk kallas ”the front-end”, det vill säga den genererade HTML & CSS-koden.
Verktygslådan
Idag finns det en uppsjö av ramverk och metodologier för att skriva CSS, och det är lätt att man blir överväldigad av antalet valmöjligheter. Efter att ha sonderat terrängen under en tid började vi för drygt ett år sedan att använda en något modifierad variant av BEM som namnkonvention för att strukturera upp markup och stilmallar. BEM står för Block, Element, Modifier och är egentligen inget annat än en samling regler för hur du bör arbeta med (och enbart med) CSS-klasser för att namnge och strukturera upp innehåll så att du undviker den typ av problem som jag nämnt här ovan. BEM är varken ett verktyg eller en tjänst utan ett mindset vilket gör att tröskeln för att komma igång med det är relativt låg. Det enda kravet är att man har kontroll på den HTML som genereras (för att kunna styra vilka CSS-klasser som sätts vart) vilket kan innebära att man behöver ha en viss kännedom om det publiceringsverktyg som man använder för att generera webbplatsen.
Efter ett antal projekt där vi arbetat med BEM är magkänslan att lovorden över metodologin är berättigade; så länge konventionen följs har man en enastående kontroll över både arv och specificitet – två områden där CSS lätt kan bita en i svansen om man inte är försiktig.
Eftersom BEM är en konvention snarare än ett verktyg så innebär det också konventionen behöver följas om löftet om kontroll skall infrias. Med anledning av detta, och för att främja homogenitet i skeppad kod överlag, började vi även använda oss av automatiserad granskning av skriven Sass/CSS i samband med att BEM infördes som praxis. Tekniskt sett så använder vi oss av SCSS-Lint som via en Grunt-plugin rullar i bakgrunden och skannar den genererade CSS’en varje gång utvecklaren sparar sin Sass-fil. Om pluginen hittar någon rad som inte stämmer överens med de syntax-regler vi satt upp skickar den ut ett felmeddelande och uppmärksammar utvecklaren som kan vidta lämpliga åtgärder. Detta har visat sig fungera ypperligt i praktiken; förutom att pluginen fångar eventuella slarvfel redan innan de skickas in i versionshanteringen så hjälper den till att lätta den kognitiva bördan för utvecklaren, som istället kan fokusera på sådant som pluginen inte har möjlighet att värdera (semantik, övergripande struktur etc.).
Avrundningsvis
Att anamma sådana här arbetssätt är för oss på Kodamera en självklarhet när det gäller att få våra produkter och vårt arbete att ligga i framkant. Idag kan vi med trygghet konstatera att vi har ett angreppsätt vad gäller den CSS vi levererar som kan skala från det lilla projektet till det stora, utan att tappa i läsbarhet, struktur eller stabilitet längs vägen. Vi vill kunna leverera hög kvalitet på det vi producerar åt våra kunder, och sådana här initiativ är ett sätt för oss att uppfylla våra mål.
