Thursday Feb 03, 2022

Principii de proiectare software DRY și KISS

În acest articol, voi explora principiile de proiectare software și beneficiile lor, de ce sunt utile principiile de proiectare pentru noi și cum să le implementăm în programarea noastră zilnică. Vom explora principiile de proiectare software DRY și KISS.

Principiul DRY: Don’t Repeat Yourself

DRY este acronimul de la „Don’t Repeat Yourself” (Nu te repeta), un principiu de bază al dezvoltării software care are ca scop reducerea repetării informațiilor. Principiul DRY este enunțat astfel: „Fiecare element de cunoaștere sau de logică trebuie să aibă o reprezentare unică, lipsită de ambiguitate în cadrul unui sistem.”

Violări ale DRY

„Ne place să batem la mașină” (sau, „Pierdem timpul tuturor.”): „Ne place să tastăm”, înseamnă să scriem același cod sau aceeași logică din nou și din nou. Va fi dificil de gestionat codul, iar dacă logica se schimbă, atunci trebuie să facem modificări în toate locurile în care am scris codul, pierzând astfel timpul tuturor.

Cum se realizează DRY

Pentru a evita încălcarea principiului DRY, împărțiți-vă sistemul în bucăți. Împărțiți codul și logica în unități reutilizabile mai mici și utilizați acel cod apelându-l acolo unde doriți. Nu scrieți metode lungi, ci împărțiți logica și încercați să folosiți bucata existentă în metoda dumneavoastră.

Beneficii DRY

Codul mai puțin este bun: economisește timp și efort, este ușor de întreținut și, de asemenea, reduce șansele de apariție a bug-urilor.

Un bun exemplu al principiului DRY este clasa helper din bibliotecile de întreprindere, în care fiecare bucată de cod este unică în biblioteci și în clasele helper.

KISS: Keep It Simple, Stupid

Principiul KISS este descriptiv pentru a păstra codul simplu și clar, făcându-l ușor de înțeles. La urma urmei, limbajele de programare sunt pentru ca oamenii să le înțeleagă – computerele pot înțelege doar 0 și 1 – așa că păstrați codarea simplă și directă. Păstrați-vă metodele mici. Fiecare metodă nu ar trebui să aibă niciodată mai mult de 40-50 de linii.

Care metodă ar trebui să rezolve doar o mică problemă, nu multe cazuri de utilizare. Dacă aveți o mulțime de condiții în metodă, împărțiți-le în metode mai mici. Nu numai că va fi mai ușor de citit și de întreținut, dar vă poate ajuta să găsiți bug-urile mult mai repede.

Violări ale KISS

Am experimentat cu toții, probabil, situația în care primim treabă de făcut într-un proiect și am găsit niște coduri dezordonate scrise. Acest lucru ne determină să ne întrebăm de ce au fost scrise aceste linii inutile. Aruncați doar o privire la cele două fragmente de cod prezentate mai jos. Ambele metode fac același lucru. Acum trebuie să vă decideți pe care dintre ele să o folosiți:

public String weekday1(int day) { switch (day) { case 1: return "Monday"; case 2: return "Tuesday"; case 3: return "Wednesday"; case 4: return "Thursday"; case 5: return "Friday"; case 6: return "Saturday"; case 7: return "Sunday"; default: throw new InvalidOperationException("day must be in range 1 to 7"); }}public String weekday2(int day) { if ((day < 1) || (day > 7)) throw new InvalidOperationException("day must be in range 1 to 7"); string days = { "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" }; return days;}

Cum să obțineți KISS

Pentru a evita încălcarea principiului KISS, încercați să scrieți cod simplu. Gândiți-vă la mai multe soluții pentru problema dumneavoastră, apoi alegeți-o pe cea mai bună, cea mai simplă și transformați-o în codul dumneavoastră. Ori de câte ori găsiți un cod lung, împărțiți-l în mai multe metode – faceți clic dreapta și refactorizați-l în editor. Încercați să scrieți blocuri mici de cod care îndeplinesc o singură sarcină.

Beneficiul KISS

Dacă avem o funcționalitate scrisă de un dezvoltator și a fost scrisă cu un cod dezordonat, iar dacă cerem ca un alt dezvoltator să facă modificări în acel cod, atunci, mai întâi, trebuie să înțeleagă codul. Evident, dacă codul este scris simplu, atunci nu va exista nicio dificultate în înțelegerea acelui cod și, de asemenea, va fi ușor de modificat.

Rezumat

În timp ce scrieți orice cod sau modul, păstrați în minte principiile de proiectare software și folosiți-le cu înțelepciune, faceți din ele un obicei, astfel încât să nu mai fie nevoie să vă amintiți de fiecare dată. Aceasta va economisi timp de dezvoltare și va face ca modulul dvs. software să fie robust, care ar putea fi ușor de întreținut și extins.

.

Lasă un răspuns

Adresa ta de email nu va fi publicată.

Back to Top