allan ebdrup bloghoved ny

Kodekvalitet i JavaScript

JavaScript er modnet meget i de senere år – eller rettere brugen af JavaScript og VM’erne er modnet, JavaScript sproget selv har ikke ændret sig det store.

I dag gør jeg mange ting som en selvfølgelighed for at sikre kvaliteten i den JavaScript-kode, jeg skriver. Det har ikke altid været en selvfølgelighed, og måske er ikke alt, jeg gør, en selvfølgelighed for dig. Derfor vil jeg dele nogle af de ting, vi gør hos e-conomic for at sikre kvaliteten i vores JavaScript-kode. Vi bruger nemlig JavaScript i browseren samt på serveren med Node.js.

  • JSHint. Tjekker vores kode med statisk kodeanalyse og fanger en masse fejl som fx variabler, der ikke er deklareret. Hvis du kun kan gøre én ting på denne liste, så kør JSHint. Mange IDE’er har integration med JSHint, slå det til.
  • IDE med stavekontrol. Hvis du fx skriver window.loaction i stedet for window.location vil stavekontrollen fange det.
  • Unittests. Vi bruger testrammeværket Jasmine til kode i browseren og Mocha på serveren. JavaScript er forretningskritisk kode – hvis det fejler, kan brugeren ikke bruge websitet, så selvfølgelig skal det unittestes.
  • Integrationstests. Vi bruger Mocha på serveren til at kalde alle endpoints i API‘et og teste, at de virker. Vi bruger Phantom til at køre integrationstest på lavt niveau af browserkoden. Phantom er et stykke software, der giver dig en ”headless” browser, dvs. at alt virker som en rigtig browser, bortset fra at den ikke renderer noget på skærmen. Vi bruger Selenium til at køre rigtige browsere gennem testscenarier.
  • Continuous integration. Vi har en CI-server (TeamCity), der kører alle tests og JSHint, hver gang nogen checker kode ind. Vi har skærme under loftet i kontoret, der hele tiden viser, om noget har fejlet. CI-serveren kører også et natligt build, hvor der kan køres ting som load/performance-tests med JMeter, worker-jobs, der laver oprydning osv.
  • Code coverage. Lige nu kører vi code coverage-rapporter ad hoc. Med en code coverage-rapport kan du se, hvilke dele af koden der er blevet ramt af dine tests. Det er super godt til at se, om der er testscenarier, du har glemt at lave, hvilket er specielt godt, hvis man skriver noget kode og først bagefter skriver tests til det. Det er også godt til at finde død kode, der slet ikke bliver kaldt og kan slettes. Jeg har en plan om at prøve at gøre code coverage til en del af check-in, så hvis man checker en fil ind med lav code coverage, fejler buildet.
  • Systematiseret review af kode. Du får ikke lov til at skrive kode, uden at det bliver tjekket af en anden programmør. Vi bruger github, og det har den kæmpe fordel, at man kan skrive kommentarer til et commit inde midt i koden, der er committed. Når der skrives en kommentar, får alle på udviklerteamet en mail. Det er en super god måde at få hele teamet til at kommunikere om kodestandarder og god praksis, så det ikke bare en nogle best practice-dokumenter, der ligger i en skuffe og samler støv.
  • Oprydning. Vi har en forretning, der har en god forståelse for, at der skal løbende oprydning til i en kodebase, for at den ikke sander til. Når vi laver oprydningsarbejdet løbende i hvert sprint, håber vi at slippe for at skulle betale en meget høj pris for nye features, når oprydningsarbejdet har hobet sig op, og læsset vælter.
  • Staging er fuldstændig identisk med produktion. Det miljø, vi bruger til acceptancetest og diverse ad hoc-tests, der kræver et ”rigtigt” miljø, er et fuldt duplikeret produktionsmiljø. Det betyder, at det har lige så meget databasekraft i sit cluster, og vi kan endda skrue op og ned for webserverne. Det har været guld værd at have et sådant miljø, og det fanger ting, man ellers ikke ser.
  • DevOps. Der er skærme under loftet hos os udviklere, hvor vi løbende kan se, hvor belastet databasen er. Der er også sat alarmer op, så der lyder fuglelyde i kontoret, så snart koden kaster en exception i produktion. Det har gjort, at jeg fx var i stand til at rette en kundes problem, inden kunden havde fået ringet til supporten. Det har dog den ulempe, at jeg farer sammen, hver gang jeg hører en måge i haven, for alarmen med mågelyden er en specielt slem fejl, som vi kun har set i test. Det er lidt irreterende når man bor tæt på havet. Denne overvågning er lavet med loggly.com og alertbirds.com.
  • Log browserrelaterede JavaScript-fejl i produktion. Hvis du ikke gør noget aktivt for at logge disse fejl, forsvinder de ud i det blå.

Ud over alt dette har vi også en QA-afdeling, der løbende systematisk udfører diverse tests. Det er dem, der står for Selenium- og JMeter-tests og vedligeholder CI-serveren.

En balancegang

Mange af punkterne på listen kan overgøres, det handler om at finde en balancegang. Hvert af punkterne kan bruges til at højne kodekvaliteten. Det er dog ikke en eksakt videnskab hvordan de skal bruges, det handler om at finde en måde der passer til ens biks.

Ingen garanti

Selvom vi gør alle de ovennævnte ting, er vi på ingen måde garanteret mod kode af lav kvalitet. Der er stadig ufatteligt meget, der afhænger af, at man har en simpel arkitektur og holder sin kode simpel og velstruktureret. Det at lave god, vedligeholdelsesvenlig kode af høj kvalitet kræver stadig gode programmører og erfaring.

Hvad gør du selv?

Jeg håber, du blev inspireret af ovenstående liste. Og hvis du har ting, du gør, som mangler på listen, så skriv endelig en kommentar.

Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Peter Müller

Kodestandarder hjælper til at holde en kodebase let læselig og at gøre det lettere at overtage kollegaers arbejde hurtigt.

Brug versionsstyring og hold alle commits atomiske, således at der ikke sniger sig mærkelige newlines, whitespaces, newlineskift eller sågar flere funtionaliteter ind i samme commit. Her har git hjulpet mig meget med muligheden for at stage delmængder af en række ændringer man har lavet. Det gør det meget lettere at overskue historikken af et projekt og finde stedet hvor en regression blev introduceret.

  • 2
  • 0
#2 Peter Müller

Jeg har haft stor success med at tvinge mig selv til at tænke på alle mine projekter som open source, også selvom de ikke er det eller nogensinde bliver det.

Grunden til at det har hjulpet mig er at jeg tvinger mig selv til at se projekter fra aftagerens synsvinkel. Det betyder jeg skal være god til at dokumentere min præmis og mine arkitekturvalg, og i øvrigt modularisere og integrere med andre open source projekter i stedet for at lave endnu et not-invented-here hack.

Det hjælper at have en fiktiv kritiker på skulderen, som ikke har brug for mere en ét kritikpunkt før han vælger et konkurrerende produkt.

  • 4
  • 0
#4 Mark Gjøl

Jeg er Java og C#-udvikler som også til tider får kastet Javascript-opgaver efter mig. Jeg forventede egentlig at lære lidt om hvordan man skriver god kvalitetskode i javascript ved at læse denne artikel, men lærte kun noget om værktøjer der kunne hjælpe mig med finde fejl i den (Meget ironisk, i øvrigt, at der er fejl i første ord i emnet om at man skal bruge stavekontrol - en fejl som stavekontrollen ikke ville fange, i øvrigt).

Ting der er værd at vide: 1. Hvad er det bedste værktøj at skrive i? Jeg bruger Eclipse, og lige nu er det ok, men ikke meget mere. 2. Hvordan skal man strukturere sin kode? Jeg får dårlige nerver af at have alt i én fil - eller næsten i én fil! 3. Hvad er gode tricks, dos and don'ts? F.eks: Brug jquery, brug ikke eval. 4. Ting om at lægge layout i css og hvordan man skal manipulere med det visuelle den vej.

... Og sikkert en masse andre ting. Hvis man ikke ved så meget om god stil i javascript, så vil man stadigvæk kunne bestå de fleste af ovenstående uden anmærkninger - for det kan jo sagtens virke selvom det er en stor gang spaghetti.

  • 2
  • 0
#5 Peter Müller

  1. Hvad er det bedste værktøj at skrive i? Jeg bruger Eclipse, og lige nu er det ok, men ikke meget mere.

Jeg bruger Sublime Text 2 med en opsætning som kan findes i mine dotfiles. Text editorer er ret personlige, så jeg vil ikke sige den er bedre end andre, jeg kan bare godt lide den.

  1. Hvordan skal man strukturere sin kode? Jeg får dårlige nerver af at have alt i én fil - eller næsten i én fil!

Du skal modularisere så meget som muligt. Tag et kig på require.js, som er en async script loader i javascript med AMD modul implementation. Det har alle fordelene du kende fra andre programmeringssprog med hensyn til dependency management. Det giver dig kun lokalt scopede variabler og moduler, således at du ikke sviner globalt, det loader tingene on demand, hvilket er rart i development.

Når du går i produktion vil du gerne reducere http requests, så der anbefales det lige at pakke tingene, hvilket r.js og en masse andre buildværktøjer kan være behjælpelige med.

  1. Hvad er gode tricks, dos and don'ts? F.eks: Brug jquery, brug ikke eval.

Det er et langt større emne end en hurtig kommentar kan afdække, og det er desuden yderst subjektivt. Læs en bunke blogposts fra folk som har brudt grænserne for hvad man troede javascript kunne de sidste par år.

Ting om at lægge layout i css og hvordan man skal manipulere med det visuelle den vej.

HTML er til struktur. Din struktur skal helst tilføje semantik. Lær dine html-tags, der er ikke så mange af dem og din kode bliver uendeligt meget lettere læselig end hvis alting er generiske div-tags. Undgå at tilføje overflødige wrapper tags. Det gør det sværere at læse og gør siden langsommere.

CSS er til udseende. Hvis du laver prøver at få ting til at 'se ud' med html eller javascript så gør du det forkert. Modulariser din css, hold den i eksterne filer. Hvis du skal lave dynamisk manipulering af udseendet med javascript så se først hvor langt du kan komme med CSS. Man kan med fordel have et sekundært layout på et element, som beskriver en anden view state, ved simpelthen at toggle en CSS class i stedet fo at manipulere lowlevel med inline styles. På den måde bliver det også genbrugeligt og lettere læseligt. Hvis du vil animere overgange så overvej at bruge CSS transitions i dit state switch i stedet for javascript animationer.

  • 5
  • 0
#6 Morten Jensen

@Mark Gjøl

  1. Hvad er det bedste værktøj at skrive i? Jeg bruger Eclipse, og lige nu er det ok, men ikke meget mere.
  2. Hvordan skal man strukturere sin kode? Jeg får dårlige nerver af at have alt i én fil - eller næsten i én fil!
  3. Hvad er gode tricks, dos and don'ts? F.eks: Brug jquery, brug ikke eval.
  4. Ting om at lægge layout i css og hvordan man skal manipulere med det visuelle den vej.

1) Det er en meget subjektiv vurdering. Hvad gør at Eclipse kun lige slår til for dig? Jeg bruger selv Sublime Text til det meste 2) Er der andre løsninger end at dele koden op i flere filer og tilføje hos callee? Udover server side includes f.eks. 3) Det er et stort emne efter min mening, og det kommer an på hvad du skal lave. "JavaScript: The Good Parts" af Douglas Crockford, giver nogle okay pointers, men han er lidt en evangelist IMO. 4) Kommer det ikke meget an på dit valg af framework? jQuery, Prototype, Dojo etc. etc.

Hvis du er bange for spaghetti-kode, så kan man jo f.eks. teste for cyklomatisk kompleksitet eller andre pseudo-mål f.eks. vha. lint-værktøjer.

Fedt indlæg Allan, jeg vil bruge en weekend i den nærmeste fremtid på at udbygge vores build-infrastruktur :)

  • 2
  • 0
#8 Kristian Dalgård

Helt enig med Lars Bjerregaard, det ser ud til, at I gør alting rigtigt i jeres virksomhed.

Jeg glæder mig personligt til, at 'Yeoman' kommer i en mere færdig version, så jeg kan få glæde af mest muligt af ovenstående uden at skulle bruge meget tid på at sætte det op. Det bliver helt sikkert let at integrere med Sublime Text 2.

  • 1
  • 0
#11 Allan Ebdrup Blogger

Jeg forventede egentlig at lære lidt om hvordan man skriver god kvalitetskode i javascript ved at læse denne artikel, men lærte kun noget om værktøjer der kunne hjælpe mig med finde fejl i den

Jeg er enig med Peter Müller i at det er et meget stort emne, og jeg synes det er et fint svar han skriver.

Jeg håber at du kunne bruge listen til noget alligevel, selvom blogindlæget ikke levede helt op til dine forventninger.

JSHint har faktisk nogle ting i sin analyse af koden som sikrer god kodestil på lavt niveau. Så brug JSHint som det første. Og fejlfri kode er også kvalitet :-)

  • 1
  • 0
Log ind eller Opret konto for at kommentere