10 Principii de bază de programare Fiecare programator trebuie să urmeze

Oricine poate scrie cod. Dar cod bun? Acolo este greu.

Am auzit cu toții povesti de groază despre codul de spaghete, lanțuri masive dacă altundeva, programe întregi care se pot rupe doar prin schimbarea unei variabile, funcții care arată ca și cum ar fi fost umbrite și așa mai departe. Asta se intampla cand incerci sa faci un produs vandabil cu doar un semestru de experienta de programare sub centura ta.

Nu vă mulțumiți pentru scrierea codului lucrări. Scopul de a scrie codul care poate fi menținut - nu numai de dvs., ci de oricine altcineva care ar putea sfârși să lucreze la software-ul la un moment dat în viitor. În acest scop, iată câteva principii care vă ajută să vă curățați actul.

1. KISS

“păstrați-l simplu, prost” principiu se aplică aproape toată viața, dar este în mod special necesar în proiecte de programare de la mijloc la mare.

Începe calea la început când definiți domeniul de aplicare a ceea ce doriți să creați. Doar pentru că sunteți pasionat de dezvoltarea jocurilor nu înseamnă că puteți crea următorul World of Warcraft sau Marele Furt Auto. Când credeți că ați simplificat suficient, simplificați-l la un nivel mai înalt - fluajul caracteristicilor este inevitabil, deci începeți puțin.

Dar chiar și după ce codificarea a început, păstrați-o simplă. Codul complex necesită mai mult timp pentru a proiecta și a scrie, este mai predispus la erori și bug-uri și este mai greu de modificat mai târziu pe drum. În cuvintele înțelepte ale lui Antoine de Saint-Exupery, “Perfecțiunea se realizează, nu când nu mai este nimic de adăugat, dar când nu mai este nimic de luat.”

2. Uscat

“nu te repeta” principiu este crucial pentru codul curat și ușor de modificat. Când scrieți cod, doriți să evitați duplicarea datelor și duplicarea logicii. Dacă observați că aceeași parte a codului este scrisă din nou și din nou, încălcați acest principiu.

Opusul codului DRY este codul WET: “scrieți totul de două ori” (sau “pierde timpul pentru toți”). Una dintre cele mai bune modalități de a diagnostica codul WET este să vă întrebați: pentru a modifica comportamentul programului într-un fel, câte domenii de cod ar trebui să modificați?

Să presupunem că scrieți o aplicație de director podcast. Pe pagina de căutare, aveți un cod pentru preluarea detaliilor unui podcast. Pe pagina podcast, aveți un cod pentru a prelua detaliile despre podcast. Pe pagina de favorite, același cod de preluare. Luați în considerare abstractizarea tuturor acestor aspecte într-o funcție, astfel încât, dacă aveți nevoie să o editați mai târziu, puteți face totul într-un singur loc.

3. Deschidere / Închidere

Fie că scrieți obiecte Ce este programarea orientată pe obiecte? Bazele explicate în termeni de Layer Ce este programarea orientată pe obiecte? Elementele de bază explicate în termeni de laici Cele mai multe limbi de programare moderne sprijină paradigma "programare orientată pe obiect" (OOP). Dar ce este exact OOP și de ce este atât de util? Citiți mai multe în Java sau module în Python, ar trebui să încercați să faceți codul deschis spre extindere, dar închis pentru modificare. Acest lucru se aplică tuturor tipurilor de proiecte, dar este deosebit de important atunci când se eliberează o bibliotecă sau un cadru destinat utilizării altora.

De exemplu, să presupunem că mențineți un cadru GUI. Ați putea să-l eliberați așa cum este, așteptând ca utilizatorii finali să modifice și să integreze în mod direct codul dvs. lansat. Dar ce se întâmplă atunci când lansați o actualizare majoră patru luni mai târziu? Cum pun în aplicare toate adăugările dvs., fără a elimina toată munca pe care au făcut-o?

În schimb, eliberați acest cod previne modificarea directă și încurajează extensie. Aceasta separă comportamentul de bază de comportamentul modificat. Beneficiile? Stabilitate mai mare (utilizatorii nu pot rupe în mod accidental comportamentul de bază) și o mai mare întreținere (utilizatorii se îngrijesc doar de codul extins). Principiul deschis / închis este cheia pentru a face un API bun Ce sunt API-urile și cum sunt API-urile deschise Schimbarea internetului Ce sunt API-urile și cum sunt API-urile deschise Schimbarea internetului V-ați întrebat vreodată cum sunt programele de pe computerul dvs. și pe site-urile pe care le vizitați "vorbiti unul cu celalalt? Citeste mai mult .

4. Compoziție> Moștenire

“compoziție asupra moștenirii” principiu afirmă că obiectele cu comportamente complexe ar trebui să facă acest lucru, conținând instanțe de obiecte cu comportamente individuale, mai degrabă decât moștenind o clasă și adăugând noi comportamente.

Supremația privind moștenirea poate duce la două probleme majore. În primul rând, ierarhia de moștenire poate deveni dezordonată în clipi de ochi. În al doilea rând, aveți mai puțină flexibilitate pentru definirea comportamentelor speciale, în special atunci când doriți să implementați comportamentul dintr-o ramură de mostenire într-o altă ramură de mostenire:

Compoziția este mult mai curată pentru a scrie, mai ușor de întreținut și permite o flexibilitate aproape infinită în ceea ce privește tipurile de comportamente pe care le puteți defini. Fiecare comportament individual este clasa proprie și creați comportamente complexe prin combinarea comportamentelor individuale.

5. Responsabilitatea unică

principiu de responsabilitate unică spune că fiecare clasă sau modul dintr-un program ar trebui să se ocupe doar de asigurarea unui anumit număr de funcționalități specifice. După cum spune Robert C. Martin, “O clasă ar trebui să aibă doar un singur motiv pentru a se schimba.”

Clasele și modulele încep de multe ori în acest fel, dar pe măsură ce adăugați caracteristici și comportamente noi, este ușor pentru ei să evolueze în clasele lui Dumnezeu și în modulele lui Dumnezeu care să ia sute sau chiar mii de linii de cod. În acest moment, ar trebui să le distrugeți în clase și module mai mici.

6. Separarea preocupărilor

principiul separației preocupărilor este ca principiul responsabilității unice, dar la un nivel mai abstract. În esență, un program ar trebui proiectat astfel încât să aibă multe încapsulări diferite care nu se suprapun, iar aceste încapsulări nu ar trebui să știe unul despre altul.

Un exemplu binecunoscut este paradigma model-view-controller (MVC), care separă un program în trei domenii distincte: datele (“model”), logica (“controlor”) și ceea ce vede utilizatorul final (“vedere”). Variațiile MVC sunt frecvente în cele mai populare cadre web de astăzi.

De exemplu, codul care gestionează încărcarea și salvarea datelor într-o bază de date nu trebuie să știe cum să facă aceste date pe web. Codul de randare poate lua intrare de la utilizatorul final, dar apoi trece acea intrare codului logic pentru procesare. Fiecare parte se ocupă de ea însăși.

Acest lucru duce la codul modular, ceea ce face ca intretinerea sa fie mult mai usoara. Și în viitor, dacă vreodată trebuie să rescrieți tot codul de redare, puteți face acest lucru fără să vă faceți griji cu privire la modul în care datele sunt salvate sau logica este prelucrată.

7. YAGNI

“nu vei avea nevoie de ea” principiu este ideea că nu trebuie să codificați niciodată funcționalitatea pe care o aveți Mai nevoie în viitor. Sunt șanse, tu nu va nevoie de ea și va fi o pierdere de timp - și nu numai asta, dar va crește în mod inutil complexitatea codului.

Puteți vedea acest lucru ca o aplicație specifică a principiului KISS și un răspuns la cei care iau principiul DRY prea în serios. Deseori, programatorii neexperimentați încearcă să scrie codul cel mai abstract și generic posibil pentru a evita codul WET, dar abstracția prea mult se termină cu un cod imposibil de întreținut.

Trucul este de a aplica principiul DRY numai atunci când trebuie. Dacă observați că bucățile de cod sunt scrise mereu și repede, atunci le abstractezi - dar niciodată când tu gândi o bucată de cod va fi scrisă mereu. De multe ori, nu va fi.

8. Evitați optimizarea prematură

niciun principiu de optimizare prematur este similar cu principiul YAGNI. Diferența este că YAGNI abordează tendința de a implementa comportamente înainte de a fi necesare, în timp ce acest principiu abordează tendința accelerați algoritmi înainte de a fi necesar.

Problema cu optimizarea prematură este că niciodată nu poți ști cu adevărat unde vor avea loc blocajele unui program până după acest fapt. Poți ghici, bineînțeles, și uneori chiar ai dreptate. Dar, de cele mai multe ori, veți pierde timp prețios încercând să accelerați o funcție care nu este atât de lentă cum credeți sau nu este chemată la fel de des cum v-ați aștepta.

Ajungeți la etapele cele mai simple, după cum puteți profilați-vă codul pentru a identifica blocajele adevărate.

9. Refactor, Refactor, Refactor

Unul dintre cele mai grele adevăruri de a accepta ca un programator neexperimentat este asta codul rar iese imediat la prima vedere. Acesta poate simți atunci când implementezi acea caracteristică strălucitoare nouă, dar pe măsură ce programul tău crește într-o complexitate, caracteristicile viitoare pot fi împiedicate de modul în care ai scris acel moment timpuriu.

Bazele de coduri sunt în continuă evoluție. Este complet normal să revizuiți, să rescrieți sau chiar să reprogramați întregi bucăți de cod - și nu doar normal, ci și sănătos să faceți acest lucru. Știți mai multe despre nevoile proiectului dvs. acum decât atunci când ai făcut-o la start, și ar trebui să utilizați în mod regulat această cunoaștere nou dobândită pentru a refactor codul vechi.

Rețineți că nu trebuie întotdeauna să fie un proces mare. Luați o pagină de la cercetașii americani, care trăiesc prin aceste cuvinte: “Lasă campul de campare mai curat decât ai găsit-o.” Dacă vreodată trebuie să verificați sau să modificați codul vechi, curățați-l întotdeauna și lăsați-l într-o stare mai bună.

10. Clean Code> Clever Code

Vorbind de codul curat, lasă-ți eul la ușă și uitați să scrieți un cod inteligent. Știți despre ce vorbesc: genul de cod care arată mai mult o enigmă decât o soluție și există doar pentru a arăta cât de inteligent ești. Adevărul este că nimănui nu-i pasă.

Un exemplu de cod inteligent este de a împacheta cât mai multă logică într-o singură linie. Un alt exemplu este exploatarea intricaciilor unei limbi pentru a scrie afirmații ciudate, dar funcționale. Orice ar putea face pe cineva să spună “Stai ce?” când te porți peste codul tău.

Programatorii buni și codul lizibil merg mână în mână. Lăsați comentarii atunci când este necesar. Adere la ghidurile de stil, indiferent dacă sunt dictate de o limbă (cum ar fi Python) sau de o companie (cum ar fi Google). Observați idiomurile per-limbă și opriți scrierea codului Java în Python sau invers. Vedeți articolul nostru despre sfaturi pentru scrierea codului curat 10 sfaturi pentru scris mai curat și cod mai bun 10 sfaturi pentru scris mai curat și cod mai bun Codul curat pare mai ușor decât este de fapt, dar beneficiile sunt în valoare de ea. Iată cum puteți începe să scrieți un cod mai curat astăzi. Citeste mai mult .

Ce face un programator bun?

Întrebați cinci persoane și veți primi 10 răspunsuri diferite. Pentru mine, un programator bun este cel care înțelege că codarea ar trebui să servească în cele din urmă utilizatorului final, cu care este ușor să lucreze într-o echipă și care își finalizează proiectele la specificații și la timp.

Dacă tocmai începeți, nu vă faceți griji prea multe despre asta încă. Concentrați-vă pe învățarea cum să codificați fără stres. Dacă vă simțiți blocați, consultați articolul despre depășirea blocului programatorului. Și dacă nu sunteți fericit scriind cod, citiți articolul nostru despre semnele pe care nu sunteți menite a fi un programator 6 Semne că nu înseamnă să fii programator 6 semne pe care nu vrei să le fii programator Nu toată lumea este a fost tăiat ca programator. Dacă nu sunteți sigur că sunteți menit să fii programator, iată câteva semne care vă pot îndruma în direcția cea bună. Citeste mai mult .

Cum ați defini un bun programator? Aveți vreo sfat pentru programatorii neexperimentați care doresc să se îmbunătățească? Trimiteți-ne cu noi în comentariile de mai jos!

Explorați mai multe despre: Programare.