Innhold
Jeg elsker å lese artikler og utdrag for å finne det siste og beste innen CSS, men virkeligheten er at mange av oss er på voksende team, og takler det (noen ganger) harde faktum at ikke alle utviklerne våre er frontend-utviklere. Hvis det er en måte å forbedre CSS på lang sikt, er det ikke ved å gjøre blødningskanten av ting (og deretter gi tilbakefall etter tilbakeslag), men i stedet fokusere på å utjevne våre nåværende ressurser, fortrenger det verste vi ser , i dag.
Siden det er noen få artikler som artikulerer meninger om ‘worst practices’, la oss fokusere på strategiene vi kan bruke for å fortrenge denne praksis. De viktigste komponentene jeg anbefaler er opplæring, stilguider og kodegjennomgang.
Trening starter ikke bare den første dagen til en utvikler, eller slutter etter de første dagene eller ukene. Opplæring består av praktikantprogrammer, ombordstigning, etterutdanning, indoktrinasjonsdokumentasjon og kanskje mer. Sørg for å inkludere frontend-utvikling for alle utviklere for internprogrammer og ombordøkter, selv om de sjelden berører den delen av bunken. Virkeligheten er at de sannsynligvis vil til slutt, og det er best å være forberedt.
Etterutdanning er både en velsignelse for kodebasen og et flott rekrutteringsverktøy - folk blir ofte utviklere fordi de liker å lære. Jeg har skrevet om gleden ved selskapets hack-dager, men andre muligheter for videreutdanning spenner fra tradisjonelle eksterne kilder, for eksempel konferanser, til interne lyn-samtaler og bokklubber.
Stilguider er en annen viktig komponent. Det er tre typer: en interaktiv stilguide der komponenter kombineres i felles ordninger; en visuell ordbokstypestilguide der individuelle komponenter defineres og deles; og en tekststil guide som klargjør vanlige uttrykk og praksis. Starbucks stilguide er en hybrid av de interaktive og ordbokstil guider, men mer interaktive; det gir ikke bare komponenter, det gir komponenter med kontekst.
Hvis du er fascinert av alternativet for visuell ordbok, vil du se GitHubs stilguide. GitHub bruker et åpen kildekodeverktøy opprettet av et eget kalt KSS (Knyle Style Sheets). Denne modusen for stilguide genereres gjennom dokumentasjon skrevet i SCSS og er en veldig god måte å gradvis bygge en stilguide mens du gir litt informasjon og brukssaker for hver komponent.
Å legge til en tekststilsguide på CSS-en i selskapets dokumentasjon er en verdifull måte å passivt veilede utviklere på. Hver gang en utvikler må stoppe og finne ut hvorfor koden skrives på en bestemt måte (for eksempel slurvet innrykk), kaster de bort verdifull utviklingstid.GitHubs stilguide inneholder en tekstkomponent. Google og ThinkUp er andre gode eksempler på denne typen stilveiledning. Disse veiledningene fungerer som gode 'argumentløserne' for alle idiosynkrasier og hjelper deg med å lede et team mot ren, skannbar og lesbar kode.
Kodevurderinger
En flott måte å aktivere overvåking av kodekvalitet er å introdusere kodegjennomgang i teamets arbeidsflyt. Kodegjennomgang er en prosess der all kode som sendes til produksjon først blir godkjent av minst en annen utvikler, helst en seniorutvikler. Hvis teamet ditt bruker GitHub eller et lignende versjonskontrollsystem, kan du enkelt legge til linjekommentarer for å hente forespørsler om å diskutere kode, påpeke brudd på stilguider og godkjenne at den sendes før den slås sammen i produksjon.
Hvis du har forpliktet deg til å utjevne teamet ditt og prioritere kodekvalitet, bør du også vurdere den generelle arkitekturen og utviklingen, samt hvordan iscenesettelses- og forsendelsesprosessen spiller en rolle i hvordan du kan veilede utviklere og utvikle kodebasen.
Det skjer ikke alt på en dag. Ta med nye strategier litt om gangen, følg hvordan de fungerer for teamet ditt, og jeg er sikker på at du får gode resultater.
Pam Selle er en profesjonell webutvikler og UI-ingeniør i Philadelphia, PA, og jobber for tiden for AxisPhilly. Denne artikkelen dukket først opp i nummer 241 av nettmagasinet.
