Hvordan lage koden din lett mulig med Living Style Guides

Style guides of yesteryear er vanligvis tenkt på som designorienterte dokumenter som fokuserer på merkevarebygging og fargebruk. Men med advent av sinnsykt store kodebaser for nettsteder som Facebook eller Googles store utvalg av produkter, har stilguider siden utviklet seg.

Disse dagene inneholder levende stilguider alltid oppdatert dokumentasjon av gjeldende kodebase og brukssaker. Med disse dokumentene kan vi skrive mye mer vedlikeholdsbar og gjenbrukbar kode mens vi umiddelbart ser hvordan optimalisert vår kodebase er.

Hva er i en levende stilguide?

Leve stil guider er lik de eldre kolleger; de inneholder logoen og merkevareinformasjon, fargebruk, samt en generell oversikt over kodebruk. Kodestykket er hvor du enkelt kan finne duplikat eller nær lignende kode og kombinere den for å optimalisere kodebase, eller se komponenter som allerede er i bruk. De fleste guider viser enten en "log" stil tilnærming der hver kode forekomst er dokumentert, eller bare den bevisst modulære koden er dokumentert.

Ikke bare gjør disse guiderne fokus på HTML og CSS, men også andre språk som kan moduleres for ytelse som JavaScript og PHP. Noen få solide eksempler på levende stil guider kan bli funnet på GitHub , Mozilla , og MailChimp . Som du kan se fra disse eksemplene, er det vanlig å ha enten en side eller en underside for å vise brukssaker ved siden av koden for hver komponent. Dette gjør det enkelt å gå og ta dem når du trenger dem, og for ukjente designere eller utviklere å se hvordan komponenter fungerer på en interaktiv måte.

Starter din egen levende stil guide

Begynn din egen livsstil guide dokumentasjon fra grunnen av kan virke skremmende, spesielt for større prosjekter. Men vanligvis er det en avkastning på investeringen av tid som kreves for å få det gjort. Større prosjekter drar nytte av en levende dokumentasjon av nettstedstiler og kodestruktur. Mindre prosjekter har en mindre merkbar, men noen ganger fortsatt verdt, returnerer på din tid investering. I begge tilfeller, hvis du jobber med et prosjekt som en dag kan bli avlevert til en annen designer eller utvikler, vil det gjøre dagen for å se slik dokumentasjon.

Start med fundamentet

Komponenter du bruker ofte er det beste bruksveske for en levende stilguide, knapper kommer umiddelbart i gang. En kort liste over ting du kanskje vil vurdere å dokumentere, er oppsettalternativer (muligens skissere et rutenett), typografi, fargebruk, knapper og lenkeformater, formstiler, varsler eller varsler og listestyling. Omtrent alt som kan ha nytte av å være gjenbrukbart, kan legges til i det vesentlige. Når du skisserer, husk å holde ting fleksibelt. Stil aldri et varsel eller en knapp som er spesifikk for en side eller brukskasse, med mindre det er absolutt nødvendig. I stedet legger du til modifikatorklasser for å bygge på grunnlaget for ting som farge, typografi eller estetiske endringer. På denne måten kan du alltid stole på .knappen for å angi en konsistent bredde-, høyde- og tekststørrelse, samtidig som modifikasjonsklassene kan endre ting som er spesifikke for hver brukskasse.

Målene for vedlikeholdsbar kode

Hensikten med vedlikeholdsbar kode er å gjøre ting gjenbrukbare og fremtidssikre. Komponenter som varslingsbjelker, knapper, overskrifter og bunntekster, er gode eksempler på gjenbrukbar kode - Ting du kan bruke flere ganger på hele siden, eller på samme side. Hvis du bryter gamle eller allerede skrevet kode ned for å gjøre det mer vedlikeholdbart etter det faktum, er det faktisk ganske enkelt. Begynn med å fjerne CSS ned til det grunnleggende. Du bør være igjen med en komponentklasse som definerer strukturelle ting som høyde, bredde og posisjon. Mens flere modifikator klasser kan brukes til å endre estetiske ting som farge eller typografi. I tillegg, hvis prosjektet ditt bruker en kropps-ID eller en klasse for hver side, kan du stille unike brukssaker på en side på denne måten. Pass på at du ikke bruker denne øvelsen for mye, siden det lett kan legge vekt på din stilguide.

De KISS-prinsipp er et designprinsipp velegnet for den modulære utviklingsprosessen også. Å skrive enkle, vedlikeholdbare koden er vanligvis enklest ved å holde komponentene enkle. Når det kommer til enkelhet, Hvis det er mulig å gjøre ting mer effektivt og / eller bruke mindre kode mens du oppnår det samme resultatet, bør komponentene skrives for å gjøre det. Endemålene for en vedlikeholdbar kodestruktur er å ha noe gjenbrukbart, lite og langt mer effektivt enn en ikke-vedlikeholdbar motpart.

Oppgi konvensjoner i CSS

Når det gjelder å jobbe med en vedlikeholdbar kodestruktur, blir navnekonvensjoner svært viktige. Skriving beskrivende CSS klasser vil gå langt for å sikre opprettholde koden din vil være en enkel oppgave. Det er ingen grense på CSS klasse lengder, så bruk dette til din fordel. Sørg for å holde fast i en klar navngivningskonvensjon, men som blandingsstrekk vs understreker eller kamel tilfelle vs alle små bokstaver kan lett bli forvirrende. Det er vanligvis en god ide å gjøre komponentklassene svært beskrivende, samtidig som modifikasjonsklassene blir mindre. Nedenfor er et eksempel på en knapp, en unik brukstilstandsregel og modifiserings klasser.

  / * Dette er en komponent klasse, den bør bare inneholde grunnleggende strukturelle regler * /. Knapp {display: blokk; bredde: 250px; høyde: 48px; linjehøyde: 48px;} / * Denne unike brukssaken skisserer en knapp som brukes på hjemmesiden * /. hjemmeside-cta-knappen {display: blockmargin: 0 auto 50px; bredde: 180px; høyde: 60px; linjehøyde: 60px;} / * Nedenfor er modifiserings klasser, disse legges i tillegg til komponenten klasse for å legge til farger eller andre estetiske endringer * /. rødt {bakgrunn: # C54F48} .rounded {border-radius: 5px;} 

Automatiserte løsninger

Automatiserte stilstyringsgeneratorer har begynt å poppe opp til venstre og høyre for å hjelpe push for style guides. Stil Prototype er en SASS generator bygd av Ram Richard og Mason Wendell of Team SASS . Det er en av de bedre alternativene der ute for øyeblikket, med lignende generatorer som hologram , Kalei , StyleDocco , og KSS viser også nyttig.

Automatisert vs håndlaget

Som alltid er det fordeler og ulemper ved å bruke begge metoder her. Automatiserte løsninger er raske og kan brukes etter det faktum, men de er også noen ganger strenge. Håndlagde stilguider gir deg beskjed om innsatsen og utgangene til alt, men ta mer tid. Personlig er den håndlagde tilnærmingen best for meg i de fleste tilfeller, da det er den mest fleksible når det gjelder å jobbe med andre utviklere. Men det er absolutt verdt tiden å prøve ut noen av de automatiserte løsningene, bare for å få en ide om hvordan de fungerer og hva de sier om koden din.

Gjennomgang av koden din

Nettsteder er aldri ferdig. Vi endrer ting, overgang til nye stiler og trender, og til slutt kan vi ende opp med mye kode fra tidligere revisjoner. Det er viktig å ta et øyeblikk og se tilbake på "slutten" av hver revisjon for å sikre at ting er så rene som de kan være. På dette punktet liker jeg også å kaste hver komponent (og modifikasjonsklasser) i en Codepen for å teste nettleserstøtte og lage notater tilsvarende. Dette kan spare tonnevis av tid senere hvis du designer en side med støttebegrensninger. Mens du gjennomgår, må du også være sikker på å holde øye med komponenter som kan være i konflikt med hverandre på ulike måter eller forårsake problemer med bokmodell.

Konklusjon

Som konklusjon, bør stilguider resultere i kode som er veldig manipulativ og fleksibel, men likevel lett å vedlikeholde og lese. Med tanke på hvor mye tid vi må investere for å nå et slikt resultat, har levende stilguider en mye mer kvantifiserbar innvirkning på større prosjekter enn mindre. Komplekse eller store prosjekter drar nytte av all optimalisering og ytelse øker at det er vel verdt tiden å nå resultatene. Å skape en levende stilguide for en liten nettside eller et prosjekt kan ikke vise seg å være verdt investeringen i løpet av tiden.

Til slutt bør vi alle streve etter å skrive ren, vedlikeholdsbar kode som fokuserer på fremtidssikring. Levestilguider har en tendens til å oppmuntre til en slik arbeidsflyt og aide for å gjøre utviklere og seere like mye lykkeligere.

Utvalgt bilde / miniatyrbilde, programmeringsbilde via Shutterstock.