Sådan gør du din kode nemt vedligeholdt med Living Style Guides

Style guides of yesteryear anses typisk som designorienterede dokumenter med fokus på branding og farveforbrug. Men med fremkomsten af ​​sindssygt store kodebaser til websteder som Facebook eller Googles mange produktgrupper, har stilguider siden udviklet sig.

Disse dage indeholder levende stilguider altid ajourført dokumentation for den nuværende kodebase og dens brugssager. Med disse dokumenter kan vi skrive meget mere vedligeholdelig og genanvendelig kode, mens vi øjeblikkeligt ser, hvordan optimeret vores kodebase er.

Hvad er der i en levende stil guide?

Leve stil guider ligner de ældre kolleger; de indeholder logo og branding information, farve brug, samt en generel oversigt over kode brug. Kodeoversigtsafsnittet er, hvor du nemt kan finde duplikat eller tæt lignende kode og kombinere den for at optimere din kodebase eller se komponenter, der allerede er i brug. De fleste guider viser enten en "log" stil tilgang, hvor hver kode forekomst er dokumenteret, eller kun den bevidst modulære kode er dokumenteret.

Ikke kun gør disse guider fokus på HTML og CSS, men også andre sprog, der kan moduleres til ydeevne som JavaScript og PHP. Et par solide eksempler på levende stil guider kan findes på Github , Mozilla , og MailChimp . Som du kan se fra disse eksempler, er det almindeligt at have enten en side eller en underside at vise brugssager side ved side med koden for hver komponent. Dette gør det nemt at gå og greb dem, når du har brug for dem, og for uvant designere eller udviklere at se, hvordan komponenter fungerer på en interaktiv måde.

Start din egen levende stil guide

Begynd din egen levende stil guide dokumentation fra bunden kan virke skræmmende, især for større projekter. Men typisk er der et afkast på investeringen af ​​den tid, der kræves for at få det gjort. Større projekter har stor gavn af en levende dokumentation af stedsstile og kode struktur. Mindre projekter har en mindre mærkbar, men nogle gange stadig umagen værd, returnerer på din tid investering. I begge tilfælde, hvis du arbejder på et projekt, der en dag kan afleveres til en anden designer eller udvikler, vil det gøre deres dag at se sådan dokumentation.

Start med fundamentet

Komponenter, du bruger ofte, er den bedste brugs-sag til en levende stil guide, knapper kommer straks i tankerne. En kort liste over ting, du måske vil overveje at dokumentere, er layoutmuligheder (muligvis omtalt et gittersystem), typografi, farveanvendelse, knapper og linkformater, form styling, underretninger eller advarsler og listestyling. Næsten alt, der kan have gavn af at blive genanvendeligt, kan tilføjes væsentligt. Husk at holde tingene fleksible, når du beskriver det. Stil aldrig en advarsel eller knap, der er specifik for en side eller brugs-tilfælde, medmindre det er absolut nødvendigt. I stedet skal du tilføje ændringsklasser for at bygge videre på det grundlæggende fundament for ting som farve, typografi eller æstetiske ændringer. På denne måde kan du altid regne med .knappen klasse for at angive en ensartet bredde-, højde- og tekststørrelse, samtidig med at modifikatorklasserne ændrer ting, der er specifikke for hver brugskasse.

Målene for vedligeholdelig kode

Formålet med vedligeholdelig kode er at gøre tingene genanvendelige og fremtidssikre. Komponenter som underretningslinjer, knapper, overskrifter og footers er gode eksempler på genanvendelig kode - Ting du må bruge flere gange på tværs af webstedet eller på samme side. Hvis du bryder gamle eller allerede skrevet kode ned for at gøre det mere vedligeholdeligt efter det faktum, er det faktisk ret simpelt. Start med at fjerne CSS ned til det grundlæggende. Du bør overlades til en komponentklasse, der definerer strukturelle ting som højde, bredde og position. Mens yderligere modifikator klasser kan bruges til at ændre æstetiske ting som farve eller typografi. Hvis dit projekt bruger et krops-id eller en klasse til hver side, kan du også stile unikke brugssager på en side på denne måde. Sørg for ikke at bruge denne praksis for meget, da det nemt kan lægge vægt på din stilguide.

Det KISS-princippet er et designprincip også velegnet til den modulære udviklingsproces. At skrive enkle, vedligeholdelige kode er normalt nemmest ved at holde dine komponenter enkle. Når det kommer til enkelhed, hvis det er muligt at gøre tingene mere effektive og / eller bruge mindre kode, samtidig med at det samme resultat opnås, skal vores komponenter skrives for at gøre det. Slutmålene for en vedligeholdelig kodestruktur er at have noget genanvendeligt, lille og langt mere effektivt end en ikke-vedligeholdelig modstykke.

Navngivningskonventioner i CSS

Når det kommer til at arbejde med en vedligeholdelig kodestruktur, bliver navngivningskonventioner meget vigtige. Skrivning beskrivende CSS klasser vil gå langt for at sikre opretholdelse af din kodebase vil være en nem opgave. Der er ingen grænse på CSS klasse længder, så brug dette til din fordel. Sørg for at holde fast i en klar navngivningskonvention, men som blandestreger vs understreger eller kamel tilfælde vs alle små bogstaver kan nemt blive forvirrende. Det er normalt en god ide at gøre dine komponent klasser meget beskrivende, samtidig med at modifikator klasserne mindre. Nedenfor er et eksempel på en knap, en unik brugsregel regel og modifikator klasser.

  / * Dette er en komponent klasse, den bør kun indeholde grundlæggende strukturelle regler * /. Knap {display: blok; bredde: 250px; højde: 48px; liniehøjde: 48px;} / * Denne unikke brugssituation beskriver en brugt knap på hjemmesiden * /. hjemmeside-cta-knap {display: blockmargin: 0 auto 50px; bredde: 180px; højde: 60px; liniehøjde: 60px;} / * Herunder er modifikator klasser, disse tilføjes ud over komponenten klasse for at tilføje farve eller andre æstetiske ændringer * /. rød {baggrund: # C54F48} .rounded {border-radius: 5px;} 

Automatiserede løsninger

Automatiserede stilstyringsgeneratorer er begyndt at poppe op til venstre og højre for at hjælpe push for style guides. Style Prototype er en SASS generator bygget af Ram Richard og Mason Wendell of Team SASS . Det er en af ​​de bedre muligheder derude i øjeblikket, med lignende generatorer som Hologram , Kalei , StyleDocco , og KSS hvilket også viser sig nyttigt.

Automatiseret vs håndlavet

Som altid er der fordele og ulemper ved at bruge begge metoder her. Automatiserede løsninger er hurtige og kan bruges efter det faktum, men de er også nogle gange strenge. Håndlavede stilguider giver dig mulighed for at kende ind og ud af alt, men tage mere tid. Personligt er den håndlavede tilgang bedst for mig i de fleste tilfælde, da det er den mest fleksible med hensyn til samarbejde med andre udviklere. Men det er bestemt værd at prøve nogle af de automatiserede løsninger, bare for at få en ide om, hvordan de arbejder og hvad de siger om din kode.

Gennemgang af din kode

Websites er aldrig færdige. Vi ændrer ting, overgang til nye stilarter og tendenser, og til sidst kan vi ende med en masse kode fra tidligere revisioner. Det er vigtigt at tage et øjeblik og se tilbage på "slutningen" af hver revision for at sikre, at tingene er så rene, som de kan være. På dette tidspunkt kan jeg også smide hver komponent (og modifikator klasser) i en Codepen at teste browser support og lave noter i overensstemmelse hermed. Dette kan spare tid efter senere, hvis du designer en side med støttebegrænsninger. Mens du gennemgår, skal du også holde øje med komponenter, der kan være i konflikt med hinanden på ulige måder eller forårsage problemer med boxmodeller.

Konklusion

Afslutningsvis bør stilguider resultere i kode, der er meget manipulativ og fleksibel, men stadig nem at vedligeholde og læse. I betragtning af hvor meget tid vi skal investere for at nå et sådant resultat, har levende stilguider en langt mere kvantificerbar indflydelse på større projekter end mindre. Komplekse eller store projekter har så stor nytte af optimering og ydeevne, at det er værd at bruge tid til at nå de nævnte resultater. Oprettelse af en levende stil guide til en lille hjemmeside eller projekt kan ikke vise sig værd at investere i tid selv.

Afslutningsvis skal vi alle stræbe efter at skrive ren, vedligeholdelig kode, der fokuserer på fremtidssikkerhed. Levestilguider har tendens til at opmuntre til en sådan workflow og aide for at gøre udviklere og seere både meget lykkeligere.

Fremhævet billede / miniaturebillede, programmeringsbillede via Shutterstock.