Sådan bruges GitHub-mærker for at stoppe med at føle dig som en noob

Impostor Syndrome er reel, og det plager nye udviklere. Vi kommer hele vejen igennem en tutorial, bootcamp eller endda en grad, men alligevel viger vi stadig væk fra at dele vores kode. Vi frygter negativ feedback om vores kodes kvalitet. Ingen lider mere af dette end selvlærede udviklere. Fordi vi ikke har nogen "ægte" eller "officiel" erfaring eller træning, betragter vi vores kode som sub-par.

Jeg var der for et par måneder siden. Jeg arbejdede igennem Harry Percivals testdrevne udvikling med Python . E elv om jeg fulgte lige sammen med den lærer, jeg var selvbevidst om at dele min kode. Selvom min app fungerede som forventet, ville jeg ikke dele mine fremskridt. Jeg ville ikke have nogen til at ringe til mig på en åbenlyst fejltagelse, som jeg ikke var opmærksom på. Jeg ville have andre mennesker til at nyde mit produkt, men jeg ville ikke have dem til at se, hvor dårlig en udvikler jeg var.

Efter at have taget en pause fra mit eget projekt begyndte jeg at se på nogle andre projekter på GitHub. Jeg fandt et par, der havde et lille billede på deres README-sider.

Nu da jeg var den noob, jeg troede, var dette simpelthen et billede, som Linus Torvalds gav dig på et flashdrev, da du dimitterede fra "Real Developer" -skolen. Aldrig en gang kom det mig i tankerne at klikke på det. Jeg troede, det var et statisk billede, der var vært et eller andet sted i arkivet. Senere snublede jeg over et projekt, der viste, at bygningen mislykkedes.

Hvorfor ville nogen tage sig tid til at tilføje et billede, der siger, at deres build ikke passerer? Hvorfor gå igennem bestræbelserne på at tage det andet billede ned, sætte dette billede op? Et billede, der siger, at dit projekt er brudt og viser det for verden at se? Af ren nysgerrighed trak jeg råformatet til README op. Jeg så denne kode:

[![Build Status](//travis-ci.com/username/projectname.svg?branch=master)](//travis-ci.com/username/projectname)

Jeg var klog nok med markdown til at erkende, at dette var et klikbart link. Så jeg klikkede på knappen, og det tog mig til Travis-CI. Med det samme gav det mening for mig. Denne knap blev ikke opdateret af projektudvikleren, Travis-CI opdaterede den. Det er en dynamisk knap.

Min første badge

Så når jeg først fandt ud af build-badget fra Travis-CI, måtte jeg have det til mit projekt. Hele mit projekt handlede trods alt om at skrive og bruge tests. Så hvorfor ikke have noget, der kørte dem automatisk?

Så jeg oprettede Travis-CI til at køre mine enhedstest, når jeg skubbede ændringer til GitHub. Lige øverst på siden, hvor Travis-CI kører dem, er der badgen. Jeg klikkede på den og fik markdown. Jeg tilføjede det til min README. Jeg navigerede til projektsiden på GitHub og VOILA! Der var mit første badge. Jeg var hooked!

Jagten

Jeg nød at badgen var et tydeligt tegn på den aktuelle status for mit projekt. Jeg ønskede at lære mere, så jeg gik på jagt efter andre badges. Et andet almindeligt badge, jeg fandt, var kodedækning. Dækningsrapporten kunne sendes af Travis-CI til et værktøj kaldet CodeCov. Du kan få et badge, der angiver dækningen af ​​dine tests, hvilket korrelerer med, hvor godt din app er testet.

Jeg fandt også licensbadges, og det var kun fornuftigt at have et licensbadge, hvis jeg havde en licens. Så jeg valgte en licens og tilføjede den til repoen. At få badgen til det tog en hurtig Google-søgning, og jeg fandt denne kerne med alle de almindelige licensbadges.

Jeg kommer fra en sikkerhedsbaggrund i militæret og ved, at de fleste sårbarheder kommer fra forældet software. Som ny udvikler ved jeg, at dette også gælder software, som din software er afhængig af. Jeg hørte om PyUp gennem Michael Kennedys Talk Python to Me podcast. Da jeg navigerede til stedet, så jeg de ord, jeg var begyndt at elske at se, "Gratis til open source". Da jeg var på jagt efter nye badges, havde jeg held og lykke. Sikker nok giver de et badge, så selvfølgelig tilføjer jeg det til README.

Endelig opdagede jeg, at du kunne have et badge for stil. Jeg havde rodet rundt med Black før, og jeg fandt et eksempel på stilbadget, og jeg vidste, at jeg måtte have det. Af hensyn til min egen integritet ønskede jeg at sikre, at min kode altid var i overensstemmelse med Black's stil. Jeg fandt ud af om pre-commit, som jeg kunne bruge til at formatere min kode, før jeg overhovedet begik den. Efter at have dykket ned i det pre-commit kaninhul (som også kører min kode mod bandit for sikkerhed og sorterer mine importer og krav), følte jeg mig sikker på at tilføje det sorte badge til min README.

Slutresultatet

Det første resultat af jagtmærker er, at jeg har et projekt af bedre kvalitet . Jeg tilføjede en licens til mit projekt, sørgede for, at mine afhængigheder var opdaterede og holdt min projektstil kompatibel, fordi jeg ønskede badges.

Mere især er jeg mere sikker på mit projekt. Jeg kan tale om det vel vidende, at der ikke er nogen huller i hullet. Jeg ved, at jeg er meget mindre tilbøjelig til at modtage feedback på min uansvarlighed med hensyn til sikkerhed eller min manglende overholdelse af stil.

For at sige det enkelt føler jeg mig bedre med min kode, fordi jeg har disse GitHub-badges.