Refactorizarea codului - Cum se scrie un cod mai bun

Pur și simplu sunt atât de multe de învățat în lumea programării.

După 3 ani de dezvoltare web front-end, mă simt la fel de rău la codare ca oricând. Sunt pur și simplu atât de multe de învățat în lumea programării, încât un dezvoltator suficient de umil nu ar îndrăzni niciodată să spună că codul său este perfect.

Mi-am perfecționat abilitățile CSS în cea mai mare parte a carierei mele și asta mă face să nu am încredere în abilitățile mele JavaScript din motive întemeiate. Fiind o persoană pozitivă, care caută creșterea tot timpul, am ales să transform acest sentiment de inadecvare în motivație în loc să ne autodepășească.

Mai jos este un test de cod elaborat de colegii mei superiori elaborat pentru procesul de angajare. El a împărtășit cu alți coechipieri, astfel încât să putem oferi feedback cu privire la eficiența utilizării acestui test de cod pentru a determina abilitățile de programare ale candidaților. Am profitat de această ocazie pentru a-mi îmbunătăți abilitățile JavaScript, dedicând toată ziua să mă gândesc la cod.

Intrebarea

Scrieți o funcție care, atunci când este dat un șir de numere de versiune, adică. „1.12.4” și un șir de intervale de semver, adică. „~ 1.12.0”, întoarceți dacă versiunea dată se încadrează în intervalul de semver dat ca un boolean.
Gama de semver trebuie să suporte următoarele trei modele:
 1) Potrivirea exactă
 2) ^ Versiuni mai mari în același interval de versiuni majore
3) ~ Versiuni mai mari în același interval de versiuni minore

Prima incercare

În prima încercare, am parcurs cel mai simplu mod de a finaliza sarcina, folosind .substring (), cutie de schimbare, pentru bucle și dacă sunt condiții. Deși codul arată urât, funcționează și este foarte simplu să închei această soluție, deoarece toate acestea sunt elementele de bază din JavaScript. Obiceiul meu de a codifica este să-l fac să funcționeze mai întâi, apoi să-l refactorizez până când sunt mulțumit și, în sfârșit, îl consider completat. Probabil nu este cea mai bună cale pentru majoritatea oamenilor, dar sunt obișnuit să lucrez în acest mod. (În viitor, mi-ar plăcea să schimb modul în care lucrez și să petrec mai mult timp gândirii înainte de a începe să codez.)

A doua încercare

Știu partea carcasei comutatorului și condițiile dacă sunt foarte urâte, așa că am încercat să le rescriu. Am vrut să găsesc o funcție care să se poată bucla peste tablă în shouldMatch, cum ar fi .forEach (), dar una care pot rupe bucla când rezultatul === true, așa că am mers și am găsit .some (), ceea ce este exact ceea ce doream. Mai degrabă mi-a fost rușine că nu mi-am amintit această funcție, dar m-am iertat. Până la urmă, există funcții pe care nu le folosim des și este firesc să le uităm. Atitudinea mea este: folosește-le mai mult dacă le găsești utile și, în cele din urmă, le vei aminti.

A treia încercare

Am împărtășit codul cu inginerul superior, iar el mi-a dat un feedback constructiv. El mi-a cerut să mă gândesc la o modalitate mai bună de a obține gameSymbol și să încerc să nu modific gameNumArr după declarație. Nu în ultimul rând, mi-a spus să folosesc .every (), care este destul de similar cu .some (), dar în schimb bucla s-ar rupe atunci când valoarea returnării este falsă. I-am luat sfatul și am făcut alte modificări și a rezultat o bucată de cod frumoasă:

Concluzie

Este foarte important să recunoști că nu ești bun la ceva și să cauți îmbunătățiri.

Cereți ajutor dacă aveți nevoie. Este întotdeauna bine să avem o perspectivă diferită, deoarece toată lumea are un proces de gândire diferit. Uneori opiniile altora te pot inspira!

Nu vă temeți că pierdeți timpul cu o funcție simplă atunci când faceți exerciții de codare. Amintiți-vă că programarea este un proces creativ care consumă o cantitate corectă de putere a creierului atunci când este finalizat!

Aplaudați și urmați-mă dacă vă place acest articol!

Mi-aș împărtăși experimentele front-end și gândurile mele despre programare ori de câte ori am timp;)