Dezvoltarea web-ului Cele 10 coduri antipattern pe care trebuie să le evitați
Proiectarea arhitecturii unui site web sau a unei aplicații sau crearea unui flux de lucru eficient de codificare ne fac frecvent să facem față problemelor recurente. Nu este neapărat necesar să rezolvăm problemele de proiectare software de la zero, cum ar fi soluțiile la nivel arhitectural pot fi refolosite în același mod ca fragmente de cod de la micro-nivel.
Modelele de design sunt în general soluții reutilizabile pentru anumite scenarii, poate veniți la îndemână pentru a rezolva problemele întâlnite frecvent, și ne poate ajuta foarte mult să optimizăm codul nostru.
În timp ce modelele de design sunt mijloace excelente de îmbunătățire a procesului nostru de dezvoltare prin folosirea unor formule bine testate, uneori putem merge și cu ele. Acestea se numesc antipatterni.
Ce sunt Antipatterns?
Termenul “antipattern” a fost inventat într-o carte numită AntiPatterns în 1998. Se referă la aceasta soluții reutilizate care inițial par a fi utile, dar mai târziu se dovedește să facă mai mult rău decât bine.
Acest lucru se poate întâmpla din diferite motive, de exemplu dacă nu folosim modelele în contextul, setarea sau timpul potrivit (soluțiile care au fost eficiente în trecut nu pot funcționa întotdeauna în prezent) sau, în alte cazuri, întreaga paradigmă a fost rău de la început.
Antipatternii sunt, de asemenea, frecvent numiți modele de eșec. Vestea bună este că este posibil să le recunoască și să le evite.
În acest post vom analiza 10 coduri antipatterniste comune în dezvoltarea web-ului, care ne pot înșela să ne gândim că avem un cod bine optimizat. (Rețineți că antipatronii enumerați în acest post nu sunt neapărat identici cu ceea ce puteți găsi în cartea menționată mai sus.)
1. Optimizarea prematura
Calendarul bun este un factor crucial în optimizarea codului. Putem reproduce cu ușurință antipatternul lui “optimizarea prematura”, dacă acordăm atenție eficiențelor reduse și le optimizăm prea devreme în procesul de dezvoltare, înainte să știm exact ce vrem să facem.
Conform celebrului citat al lui Donald Knuth “optimizarea prematura este rădăcina tuturor răului“, care poate fi o exagerare, dar arată încă cât de serioase pot apărea probleme premature de optimizare.
Dacă optimizăm performanța înainte de a crea o arhitectură eficientă, putem citire mai redusă a codului, face depanare și întreținere mai greu, și adăugați părți inutile la codul nostru.
Pentru a preveni optimizarea prematură, este o idee bună să urmăriți principiul de programare YAGNI (nu aveți nevoie de ea), care vă sfătuiește să “puneți mereu în aplicare lucrurile când aveți nevoie de ele, niciodată când vă dați seama că aveți nevoie de ele.”
2. Reinventarea roții
“reinventezi roata” antipatternă este uneori menționată, de asemenea, ca “proiectarea într-un vid”. Se întâmplă când vrem face totul prin noi înșine și scrie totul de la zero, fără a căuta metode deja existente, API sau biblioteci.
Reinventarea roții nu este doar o pierdere de timp de făcut, dar soluțiile personalizate, în special pentru funcționalitățile de bază, sunt rareori la fel de bune ca cele standard care au fost deja testate de mulți dezvoltatori și utilizatori.
3. Iadul de dependență
Opusul “reinventezi roata” antipattern este un alt antipattern comun numit “dependență iad”.
Dacă, în loc să scriem totul de la zero, vom folosi prea multe biblioteci terțe părți care se bazează pe versiuni specifice ale altor biblioteci, se poate întâmpla cu ușurință într-o situație greu de gestionat când vrem să ne actualizăm, deoarece aceste dependențe subsidiare sunt în multe cazuri incompatibile unul cu altul.
Dependența iad poate fi rezolvată prin utilizarea managerilor de pachete care sunt capabili să actualizați inteligent dependențele interdependente. Dacă suntem copleșiți prea mult de problemă, refactorizarea poate fi, de asemenea, o idee bună.
4. Codul spaghetelor
“Codul spaghetti” este probabil cel mai faimos codator antipattern. Descrie o aplicație greu de depanat sau modificată din cauza lipsei unei arhitecturi corecte.
Rezultatul designului de software slab este o grămadă de cod care este similar în structură cu un castron de spaghete, adică. încurcat și încurcat. Lizibilitatea codului de spaghete este foarte scăzută și de obicei este o misiune aproape imposibilă de a înțelege cum funcționează exact.
Codul spaghetti, de obicei, provine din combinarea diferitelor practici de codificare proaste, cum ar fi codul care nu conține blocuri condiționale adecvate, având o mulțime de instrucțiuni, excepții și fire, care conține părți care aparțin altundeva, au relații minime între obiecte, au funcții sau metode care nu pot fi reutilizate sau nu sunt documentate corespunzător sau deloc.
5. Programarea prin permutare
“Programarea prin permutare” sau “programarea accidentală” se întâmplă atunci când încercăm să găsim o soluție pentru o problemă prin experimentarea succesivă cu mici modificări, testarea și evaluarea acestora unul câte unul și, în final, implementarea celui care funcționează la început.
Programarea prin permutare poate fi ușor introduceți bug-uri noi în codul nostru, mai rău, sunt bug-uri pe care nu le recunoaștem neapărat. În multe cazuri, este imposibil de anticipat dacă soluția va funcționa pentru toate scenariile posibile sau nu.
6. Copierea și inserarea programării
“Copiați și lipiți programarea” apare atunci când nu respectăm principiul de codare Do not Repeat Yourself (DRY) și, în loc de a crea soluții generice, inserăm fragmente de cod deja existente în diferite locuri și apoi le editați pentru a se potrivi contextului dat.
Această practică rezultă într-un cod care este foarte repetitiv, deoarece piesele de cod inserate diferă, de obicei, doar prin discrepanțe minore.
Programarea copierii și lipirii este nu numai comisă de dezvoltatorii novici, ci și de programatori experimentați, deoarece mulți dintre ei sunt predispuși utilizați propriile fragmente de cod pre-scrise și bine testate pentru anumite sarcini, care poate duce cu ușurință la repetări neintenționate.
7. Programare în cargo-cult
Numele de “încărcare-cult de programare” provine dintr-un anumit fenomen etnografic numit “cultul de marfă”. Cărțile de cargouri au apărut în Pacificul de Sud după cel de-al doilea război mondial, când contactul forțat cu civilizații avansate îi determină pe indigeni să creadă că produsele fabricate, cum ar fi Coca-Cola, televizoarele și frigiderele aduse de nave de marfă pe insule, au fost create de supranatural metode; și dacă vor efectua ritualuri magice asemănătoare obiceiurilor occidentale, încărcătura plină cu bunuri va veni din nou.
Când comitem antipatternul de programare a cultului de marfă, practicăm același lucru. Folosim cadre, biblioteci, soluții, modele de design etc. care au funcționat bine pentru alții, fără să înțelegem de ce facem acest lucru, sau cum au spus exact tehnologiile.
În multe cazuri, dezvoltatorii doar să faci ritual ceea ce este șoldul în acel moment fără vreun scop real. Această practică este nu numai rău, deoarece face ca aplicația noastră să fie umflată superfluu, dar poate introduce și noi bug-uri în codul nostru.
8. Lava Flow
Vorbim despre “lava flux” antipattern când trebuie se ocupă de codul care are componente redundante sau de calitate redusă acea par să fie integral la program, dar nu înțelegem cu desăvârșire ce anume face și cum influențează întreaga aplicație. Acest lucru îl face riscant să îl eliminați.
De obicei se întâmplă cu codul vechi, sau atunci când codul a fost scris de altcineva (de obicei, fără o documentație adecvată) sau atunci când proiectul sa mutat prea repede de la dezvoltare până la faza de producție.
Numele antipatternului provine din asemănarea cu lava provenită de la vulcani, adică la început se mișcă rapid și fluid fără a lua prea multe măsuri de precauție, dar mai târziu se solidifică și devine greu de îndepărtat.
În teorie, putem scăpa de fluxurile de lavă teste extinse și refactoring, dar în practică, implementarea este frecvent dificilă sau chiar imposibilă. Deoarece fluxurile de lavă au, de obicei, costuri ridicate de performanță, este mai bine să le împiedicăm prin crearea unei arhitecturi bine concepute și a unui flux de lucru solid de la început.
9. Hard Coding
“Codare greu” este un bine cunoscut antipattern împotriva căruia majoritatea cărților de dezvoltare web ne avertizează chiar în prefață. Codarea greu este practica nefericită în care stocăm datele de configurare sau de intrare, cum ar fi o cale de fișier sau un nume gazdă la distanță, în codul sursă mai degrabă decât obținerea acestuia dintr-un fișier de configurare, o bază de date, o intrare de utilizator sau o altă sursă externă.
Principala problemă cu codul greu este aceea funcționează corect numai într-un anumit mediu, și la oricând condițiile se schimbă, trebuie să modificăm codul sursă, de obicei în mai multe locuri separate.
10. Soft Coding
Dacă încercăm foarte mult să evităm capcana codării grele, putem rula ușor într-un alt antipattern numit “soft codificare”, care este exact opusul său.
În codificarea soft, am pus lucrurile care ar trebui să fie în codul sursă în surse externe, de exemplu, stocăm logica de afaceri în baza de date. Cel mai frecvent motiv pentru care facem acest lucru este temerea că regulile de afaceri se vor schimba în viitor, prin urmare, va trebui să rescriem codul.
În cazuri extreme, un program moale codat poate să devină atât de abstractă și convinsă că este aproape imposibil să o înțelegi (în special pentru noii membri ai echipei) și extrem greu de întreținut și depanare.
