Codul defect funcționează până la anul 2.000. Codul greșit este dificil de înțeles, mai complex decât ar trebui, nu este ușor de testat și îi face pe ceilalți dezvoltatori să fierb de frustrare. Deși s-ar putea să dureze mai mult timp pentru a scrie cod curat pe termen scurt, este dincolo de stabilirea faptului că scrierea unui cod curat va economisi pe toată lumea timp, efort și, în final, bani.

câteva

Dar întotdeauna există loc de învățat. Nimeni nu scrie cod curat de la început. Recent, X-Teamers au discutat despre cele mai importante principii ale acestora pentru a-și păstra codul curat și am decis să împărtășim cele mai bune cu lumea.

Principiile Codului Curat

Codul curat nu se bazează pe reguli specifice limbii. În schimb, se bazează pe principiile agnostice lingvistice agreate de comunitatea dezvoltatorilor. Ca atare, chiar dacă întrebarea inițială pe canalul nostru Slack a fost despre cum să vă păstrați codul JavaScript/TypeScript curat, X-Teamers a răspuns cu câteva dintre principiile generale de proiectare ale codului curat.

SĂRUT: Păstrați-l simplu prost. Un principiu de proiectare originar din S.U.A. Navy care se întoarce deja în 1960. Se afirmă că majoritatea sistemelor ar trebui păstrate cât mai simple posibil (dar nu mai simple, așa cum ar fi spus Einstein). Ar trebui evitată complexitatea inutilă. Întrebarea care trebuie pusă atunci când scrieți codul este „se poate scrie acest lucru într-un mod mai simplu?”

USCAT: Nu te repeta. Strâns legat de KISS și de filosofia minimalistă a designului. Se afirmă că fiecare cunoștință (cod, în acest caz) trebuie să aibă o reprezentare unică, fără echivoc, autoritară într-un sistem (bază de cod). Încălcările DRY sunt denumite umede: ne bucurăm de tastare, scriem totul de două ori, pierdem timpul tuturor.

YAGNI: Nu ai nevoie. Un dezvoltator nu ar trebui să adauge funcționalități decât dacă se consideră necesar. YAGNI face parte din metodologia de programare extremă (XP), care dorește să îmbunătățească calitatea software-ului și să crească capacitatea de răspuns la cerințele clienților. YAGNI trebuie utilizat împreună cu refactorizarea continuă, testarea unității și integrarea.

Compoziția asupra moștenirii: Nu este un acronim, din păcate. Este un principiu în care îți proiectezi tipurile în funcție de ceea ce fac în loc de ceea ce fac. Este explicat mai detaliat în acest videoclip. Una dintre modalitățile de implementare a acestui principiu este folosirea metodei Object.assign () în ES6.

Compoziția este favorizată față de moștenire de mulți dezvoltatori, deoarece moștenirea te obligă să construiești o taxonomie a obiectelor la începutul unui proiect, făcând codul tău inflexibil pentru modificările ulterioare.

Favorizarea lizibilității: Nu pentru că o mașină îți poate citi codul pe care alt om îl poate citi. În special atunci când lucrați cu mai multe persoane într-un proiect, favorizați întotdeauna lizibilitatea decât concizia. Nu are rost să ai un cod concis dacă oamenii nu-l înțeleg.

Există mai multe modalități de a face codul mai ușor de citit. Două exemple sunt plasarea numerelor comune în constante bine numite (de exemplu, const CACHE_TIME = 200;) și crearea de nume lungi în loc de altele mai scurte (de exemplu, userHasFormAccess peste canAccess, care nu spune atât de mult).

Practicați consistența: Acesta este, fără îndoială, principiul general al tuturor principiilor codului curat. Dacă decideți să faceți ceva într-un anumit mod, rămâneți la el pe parcursul întregului proiect. Dacă nu ai de ales decât să te îndepărtezi de alegerea inițială, explică de ce în comentarii.

Desigur, aceasta nu este în niciun caz o listă cuprinzătoare. Există atât de mult mai mult pentru a curăța codul. De fapt, dacă doriți o carte excelentă despre codul curat, vă recomandăm The Art of Readable Code de D. Boswell și T. Foucher.

Vreau mai mult? Citiți despre cele mai bune practici de programare pentru a îmbunătăți modul în care scrieți codul.