Principiile de dezvoltare software sunt un set de reguli și recomandări specifice pe care inginerii ar trebui să le urmeze în timpul implementării unui program dacă doresc să scrie un cod frumos, clar și ușor de întreținut. Nu există o baghetă magică care poate transforma un amalgam de variabile, clase și funcții într-un cod perfect, dar există câteva sfaturi și indicații care pot ajuta un inginer să determine dacă face ceea ce trebuie.

Să aruncăm o privire asupra acestor recomandări de bază. Unele dintre principiile de mai jos sunt specifice Python, dar majoritatea nu sunt.

Măsurați de două ori și tăiați o dată

Cred că acesta este cel mai important principiu dintre toate. Dacă învățați un singur principiu din această postare, acesta ar trebui să fie acesta. Noi, dezvoltatorii /arhitecții/ managerii oameni ne luptăm cu lipsa de atenție, cu greșeli stupide și greșeli de tipar, cu probleme personale, cu stări de spirit proaste și cu cafeaua rece. Nimic din toate acestea nu este relevant – problema trebuie să fie rezolvată. Pentru mine, ca inginer, acest principiu înseamnă alegerea soluției corecte la problemă, alegerea abordării corecte a problemei, alegerea instrumentelor potrivite pentru a rezolva problema, încrederea în soluția construită. A alege aici înseamnă să te gândești, să găsești resursele necesare, să formezi echipa potrivită, să te gândești la proiectare, să te gândești la abordare, să stabilești sarcini, să controlezi rezultatul și să îți asumi responsabilitatea pentru acest lucru. Aceasta este „Inginerie așa cum este”. Cred că eu însumi nu sunt pregătit să o descriu cu cuvinte corecte.

Don’t Repeat Yourself (DRY)

Este un principiu destul de simplu, dar foarte util, care spune că repetarea aceluiași lucru în locuri diferite este o idee proastă. În primul rând, este legat de necesitatea susținerii și modificării ulterioare a codului. Dacă un anumit fragment de cod este duplicat în mai multe locuri în interiorul unui program, există o mare probabilitate de apariție a două situații catastrofale:

1. Când faceți chiar și mici modificări ale codului sursă, trebuie să modificați același cod în mai multe locuri. Aceasta va necesita timp, efort și atenție suplimentare(de multe ori nu este ușor).
2. Primul punct urmează celui de-al doilea. Este posibil ca dumneavoastră sau un alt dezvoltator din echipa dumneavoastră să omiteți din greșeală una dintre modificări(se poate întâmpla pur și simplu prin fuzionarea ramurilor în vcs) și să vă confruntați cu bug-uri ulterioare în aplicație. Aceste bug-uri pot fi frustrante pentru dumneavoastră, deoarece ați auzit că un astfel de bug a fost deja rezolvat.

În acest sens, există o recomandare – dacă un cod se găsește în listare de mai mult de două ori, ar trebui să fie plasat într-un mod separat. Aceasta este o recomandare generală. De fapt, ar trebui să vă gândiți să creați o metodă separată chiar dacă întâlniți o repetiție a doua oară.

Occam’s Razor

Este o idee foarte comună, care a venit în programare din filosofie. Principiul și-a primit numele de la călugărul englez William de Oakham. Acest principiu spune: „Entitățile nu trebuie să fie multiplicate fără necesitate”. În inginerie, acest principiu este interpretat în felul următor: nu este necesar să se creeze entități inutile fără necesitate. Astfel, este întotdeauna o idee bună să vă gândiți mai întâi la beneficiile pe care le aduce adăugarea unei alte metode/clase/unelte/procese etc. La urma urmei, dacă adăugați o altă metodă/clasă/instrument/proces etc. și nu obțineți alte avantaje în afară de creșterea complexității, care mai este rostul?

Keep It Simple Stupid (KISS)

Acest principiu este foarte asemănător cu cel de mai sus, dar are o semnificație ușor diferită. Acest principiu spune că codul trebuie să fie cât mai simplu posibil, fără structuri complexe, altfel se va complica depanarea și întreținerea codului. În plus, va fi mai dificil pentru un alt programator să înțeleagă logica codului, ceea ce, la rândul său, va necesita, de asemenea, timp și efort suplimentar. De aceea, ar trebui să încercați întotdeauna să folosiți construcții simple, care să rezolve problema cât mai mult posibil, fără numeroase ramificații, anidare profundă și structuri de clase excesiv de supraîncărcate. Făcând acest lucru, vă veți face viața mai ușoară pentru dumneavoastră și pentru colegii dumneavoastră, deoarece complexitatea generează erori. Amintiți-vă ce a spus Peter Hintiens: „Simplitatea este întotdeauna mai bună decât funcționalitatea”.

You Aren’t Gonna Need It (YAGNI)

O problemă de care suferă mulți programatori. Dorința de a implementa dintr-o dată toate funcționalitățile necesare (și uneori chiar inutile) încă de la începutul proiectului. Adică, atunci când un programator adaugă toate metodele posibile clasei încă de la început și le implementează, și s-ar putea chiar să nu le folosească niciodată în viitor. Astfel, conform acestei recomandări, mai întâi de toate, implementați doar ceea ce aveți nevoie, iar mai târziu, dacă este necesar, extindeți funcționalitatea. În acest fel, veți economisi efort, timp și nervi la depanarea codului care nu este cu adevărat necesar.

Big Design Up Front

Înainte de a începe să dezvoltați funcționalitatea, ar trebui mai întâi să vă gândiți la arhitectura aplicației și să proiectați întregul sistem până la detalii suficient de mici și abia apoi să treceți la implementare conform unui plan predefinit. Principiul are dreptul să existe, dar, în ultima vreme, a fost destul de mult criticat. Aceasta este legată, în primul rând, de obsolescența planului în timpul proiectării și elaborării. În acest sens, este necesar să se facă încă modificările ulterioare. Dar are și avantaje de netăgăduit, la proiectarea corectă, este posibilă reducerea considerabilă a costurilor de depanare și corectare ulterioară a erorilor. În plus, astfel de sisteme informatice, de regulă, sunt mai laconice și mai corecte din punct de vedere arhitectural.

Evitați optimizarea prematură

„Optimizarea prematură este rădăcina tuturor relelor (sau cel puțin a celor mai multe) în programare” – Donald Knuth

Optimizarea este un proces foarte corect și necesar pentru a accelera programul, precum și pentru a reduce consumul de resurse ale sistemului. Dar totul are timpul său. Dacă optimizarea este efectuată în primele etape de dezvoltare, ea poate face mai mult rău decât bine. În primul rând, acest lucru este legat de faptul că dezvoltarea unui cod optimizat necesită mai mult timp și efort pentru dezvoltare și asistență. În acest caz, destul de des trebuie să verificați la început corectitudinea abordării de dezvoltare alese. De aceea, la început este mai profitabil să folosiți o abordare simplă, dar nu cea mai optimă. Iar mai târziu, atunci când estimați cât de mult încetinește această abordare activitatea unei aplicații, treceți la un algoritm mai rapid sau mai puțin consumator de resurse. În plus, atâta timp cât implementați inițial cel mai optim algoritm, cerințele se pot schimba, iar codul se va duce la gunoi. Așadar, nu este nevoie să pierdeți timp cu optimizarea prematură.

Principiul celei mai mici surprize

Acest principiu înseamnă că codul dumneavoastră trebuie să fie intuitiv și evident și să nu surprindă un alt dezvoltator atunci când revizuiește codul. De exemplu, dacă metoda se numește „face fursecuri”, dar obțineți cartofi ca rezultat, acel cod este prost (evident). În plus, ar trebui să încercați să evitați efectele secundare și să le documentați dacă nu le puteți evita.

S.O.L.I.D.

„SOLID” este de fapt un grup de principii de proiectare orientate pe obiecte. Fiecare literă din „SOLID” reprezintă unul dintre aceste principii, care sunt:

• Responsabilitatea unică afirmă că fiecare modul sau clasă ar trebui să aibă responsabilitatea pentru o singură parte a funcționalității furnizate de software și că această responsabilitate ar trebui să fie în întregime încapsulată de clasă;
• Deschidere-închisă afirmă că entitățile software (clase, module, funcții, etc.) ar trebui să fie deschise pentru extindere, dar închise pentru modificare;
• Substituția Liskov afirmă că clasa moștenită ar trebui să completeze, nu să înlocuiască, comportamentul clasei de bază;
• Segregarea interfețelor afirmă că nici un client nu ar trebui să fie forțat să depindă de metode pe care nu le utilizează;
• Inversiunea dependenței afirmă că programatorul ar trebui să lucreze la nivelul interfeței și nu la nivelul implementării.

Când sunt aplicate împreună, aceste principii ajută un programator să creeze cod ușor de întreținut și de extins în timp.

Legea lui Demeter

Ideea de bază a acestui principiu este de a împărți domeniile de responsabilitate între clase și de a încapsula logica în cadrul unei clase, metode sau structuri. Din acest principiu se pot distinge mai multe recomandări:

1. Clasele sau entitățile ar trebui să fie independente
2. Ar trebui să încercați să reduceți numărul de conexiuni între diferite clase (așa-numitul cuplaj).
3. Classele asociate trebuie să se afle într-un singur modul/pachet/director (cunoscută și sub numele de coeziune.

Cu respectarea acestor principii, aplicația devine mai flexibilă, mai ușor de înțeles și mai ușor de întreținut.

Concluzie

Colegii dezvoltatori haideți să fim ingineri! Să ne gândim la proiectare și să construim sisteme robuste și bine implementate, în loc să creștem monștri organici. Principiile enumerate sunt foarte corelate și conectate în esența lor. Desigur, nu le-am creat eu, dar o mică reamintire nu strică, cel puțin memoria mea cu siguranță nu este perfectă.

Cărți recomandate

• Cod curat de Robert C. Martin
• Arhitectură curată de Robert C. Martin

.