Cele mai frecvente 10 greșeli pe care le fac dezvoltatorii web: un tutorial pentru dezvoltatori

Publicat: 2022-03-11

De când termenul de World Wide Web a fost inventat în 1990, dezvoltarea de aplicații web a evoluat de la deservirea de pagini HTML statice la aplicații de afaceri complet dinamice și complexe.

Astăzi avem mii de resurse digitale și tipărite care oferă instrucțiuni pas cu pas despre dezvoltarea a tot felul de aplicații web diferite. Mediile de dezvoltare sunt suficient de „inteligente” pentru a detecta și a remedia multe greșeli cu care dezvoltatorii timpurii s-au luptat în mod regulat. Există chiar și multe platforme de dezvoltare diferite care transformă cu ușurință pagini HTML statice simple în aplicații extrem de interactive.

Toate aceste modele de dezvoltare, practici și platforme împărtășesc un teren comun și toate sunt predispuse la probleme similare de dezvoltare web cauzate de însăși natura aplicațiilor web.

Scopul acestor sfaturi de dezvoltare web este de a face lumină asupra unora dintre greșelile comune făcute în diferite etape ale procesului de dezvoltare web și de a vă ajuta să deveniți un dezvoltator mai bun. Am atins câteva subiecte generale care sunt comune practic tuturor dezvoltatorilor web, cum ar fi validarea, securitatea, scalabilitatea și SEO. Desigur, nu ar trebui să fiți legat de exemplele specifice pe care le-am descris în acest ghid, deoarece acestea sunt enumerate doar pentru a vă oferi o idee despre potențialele probleme pe care le-ați putea întâlni.

Greșeala comună nr. 1: validare incompletă a intrării

Validarea intrărilor utilizatorului pe partea client și server este pur și simplu o necesitate ! Suntem cu toții conștienți de sfatul înțelept „nu aveți încredere în inputul utilizatorului” , dar, cu toate acestea, greșelile care decurg din validare se întâmplă prea des.

Una dintre cele mai frecvente consecințe ale acestei greșeli este SQL Injection , care se află în Top 10 OWASP an de an.

Amintiți-vă că majoritatea cadrelor de dezvoltare front-end oferă reguli de validare ieșite din cutie, care sunt incredibil de simplu de utilizat. În plus, majoritatea platformelor majore de dezvoltare back-end folosesc adnotări simple pentru a se asigura că datele trimise respectă regulile așteptate. Implementarea validării ar putea consuma mult timp, dar ar trebui să facă parte din practica dumneavoastră standard de codificare și să nu fie niciodată pusă deoparte.

Greșeala comună nr. 2: Autentificare fără autorizarea corespunzătoare

Înainte de a continua, să ne asigurăm că suntem aliniați cu acești doi termeni. După cum se menționează în cele mai frecvente 10 vulnerabilități de securitate web:

Autentificare: Verificarea faptului că o persoană este (sau cel puțin pare a fi) un anumit utilizator, deoarece acesta și-a furnizat corect acreditările de securitate (parolă, răspunsuri la întrebări de securitate, scanare a amprentei etc.).

Autorizare: Confirmarea faptului că un anumit utilizator are acces la o anumită resursă sau i se acordă permisiunea de a efectua o anumită acțiune.

Altfel spus, autentificarea înseamnă a ști cine este o entitate, în timp ce autorizarea înseamnă a ști ce poate face o entitate dată.

Permiteți-mi să demonstrez această problemă cu un exemplu:

Luați în considerare că browserul dvs. deține informații despre utilizator înregistrate în prezent într-un obiect similar cu următorul:

 { username:'elvis', role:'singer', token:'123456789' }

Când faceți o schimbare a parolei, aplicația dvs. face POST:

 POST /changepassword/:username/:newpassword

În metoda dvs. /changepassword , verificați dacă utilizatorul este conectat și token-ul nu a expirat . Apoi găsiți profilul de utilizator pe baza parametrului :username și schimbați parola utilizatorului.

Așadar, ați validat că utilizatorul dvs. este conectat corect și apoi i-ați executat solicitarea, schimbându-i astfel parola. Procesul pare OK, nu? Din păcate, răspunsul este NU!

În acest moment, este important să verificați dacă utilizatorul care execută acțiunea și utilizatorul a cărui parolă este schimbată sunt același. Orice informație stocată în browser poate fi modificată și orice utilizator avansat ar putea actualiza cu ușurință username:'elvis' la username:'Administrator' fără a utiliza altceva decât instrumentele de browser încorporate.

Deci, în acest caz, ne-am ocupat doar de Authentication , asigurându-ne că utilizatorul a furnizat acreditările de securitate. Putem adăuga chiar și validarea că metoda /changepassword poate fi executată numai de utilizatorii Authenticated . Cu toate acestea, acest lucru încă nu este suficient pentru a vă proteja utilizatorii de încercări rău intenționate.

Trebuie să vă asigurați că verificați solicitantul real și conținutul cererii în cadrul metodei dvs. /changepassword și implementați Authorization corespunzătoare a cererii, asigurându-vă că utilizatorul își poate schimba numai datele.

Authentication și Authorization sunt două fețe ale aceleiași monede. Nu le tratați niciodată separat.

Greșeala comună nr. 3: Nu este gata de scalare

În lumea actuală a dezvoltării de mare viteză, a acceleratoarelor de pornire și a ideilor grozave la nivel global, apariția pe piață a MVP (produsul minim viabil) cât mai curând posibil este un obiectiv comun pentru multe companii.

Cu toate acestea, această presiune constantă a timpului determină chiar și echipele bune de dezvoltare web să treacă adesea cu vederea anumite probleme. Scalingul este adesea unul dintre acele lucruri pe care echipele le consideră de la sine înțeles. Conceptul MVP este grozav, dar împingeți-l prea departe și veți avea probleme serioase. Din păcate, selectarea unei baze de date scalabile și a unui server web și separarea tuturor straturilor de aplicații pe servere scalabile independente nu este suficientă. Există multe detalii la care trebuie să vă gândiți dacă doriți să evitați să rescrieți mai târziu părți semnificative ale aplicației dvs. - ceea ce devine o problemă majoră de dezvoltare web.

De exemplu, spuneți că alegeți să stocați fotografiile de profil încărcate ale utilizatorilor dvs. direct pe un server web. Aceasta este o soluție perfect validă - fișierele sunt accesibile rapid pentru aplicație, metodele de gestionare a fișierelor sunt disponibile în fiecare platformă de dezvoltare și puteți chiar servi aceste imagini ca conținut static, ceea ce înseamnă încărcare minimă pentru aplicația dvs.

Dar ce se întâmplă atunci când aplicația dvs. crește și trebuie să utilizați două sau mai multe servere web în spatele unui echilibrator de încărcare? Chiar dacă ați scalat frumos stocarea bazei de date, serverele de stare de sesiune și serverele web, scalabilitatea aplicației dvs. nu reușește din cauza unui lucru simplu, cum ar fi imaginile de profil. Astfel, trebuie să implementați un fel de serviciu de sincronizare a fișierelor (care va avea o întârziere și va provoca erori temporare 404) sau o altă soluție pentru a vă asigura că fișierele sunt răspândite pe serverele dvs. web.

Ceea ce trebuia să faceți pentru a evita problema în primul rând a fost doar să utilizați locația de stocare a fișierelor partajate, baza de date sau orice altă soluție de stocare la distanță. Probabil că ar fi costat câteva ore de muncă în plus ca totul să fie implementat, dar ar fi meritat osteneala.

Greșeala comună nr. 4: SEO greșit sau lipsă

Cauza principală a celor mai bune practici SEO incorecte sau lipsă de pe site-urile web este „specialiștii SEO” dezinformați. Mulți dezvoltatori web cred că știu suficient despre SEO și că nu este deosebit de complex, dar nu este adevărat. Stăpânirea SEO necesită timp semnificativ petrecut în cercetarea celor mai bune practici și a regulilor în continuă schimbare despre modul în care Google, Bing și Yahoo indexează web. Cu excepția cazului în care experimentezi în mod constant și ai urmărire + analiză precisă, nu ești un specialist SEO și nu ar trebui să pretinzi că ești unul.

În plus, SEO este prea des amânat ca o activitate care se face la sfârșit. Acest lucru vine la un preț ridicat al problemelor de dezvoltare web. SEO nu este legat doar de setarea unui conținut bun, etichete, cuvinte cheie, meta-date, etichete alternative de imagine, hartă a site-ului etc. Include și eliminarea conținutului duplicat, a avea o arhitectură a site-ului care poate fi accesată cu crawlere, timpi de încărcare eficienți, legături inteligente din spate etc.

La fel ca în cazul scalabilității, ar trebui să vă gândiți la SEO din momentul în care începeți să vă construiți aplicația web sau s-ar putea să descoperiți că finalizarea proiectului de implementare SEO înseamnă să vă rescrieți întregul sistem.

Greșeala comună nr. 5: Acțiuni care consumă timp sau procesor în manipulatorii de cereri

Unul dintre cele mai bune exemple ale acestei greșeli este trimiterea de e-mailuri pe baza unei acțiuni a utilizatorului. De prea multe ori dezvoltatorii cred că efectuarea unui apel SMTP și trimiterea unui mesaj direct de la gestionarea cererilor utilizatorului este soluția.

Să presupunem că ați creat o librărie online și vă așteptați să începeți cu câteva sute de comenzi zilnic. Ca parte a procesului de preluare a comenzii, trimiteți e-mailuri de confirmare de fiecare dată când un utilizator postează o comandă. Acest lucru va funcționa fără probleme la început, dar ce se întâmplă atunci când scalați sistemul și primiți brusc mii de solicitări care trimit e-mailuri de confirmare? Fie obțineți expirări ale conexiunii SMTP, cota depășită, fie timpul de răspuns al aplicației dvs. scade semnificativ, deoarece acum gestionează e-mailurile în loc de utilizatori.

Orice acțiune de consum de timp sau de procesor ar trebui gestionată de un proces extern în timp ce eliberați solicitările HTTP cât mai curând posibil. În acest caz, ar trebui să aveți un serviciu de corespondență extern care preia comenzi și trimite notificări.

Greșeala comună nr. 6: Nu optimizarea utilizării lățimii de bandă

Majoritatea dezvoltării și testării au loc într-un mediu de rețea locală. Deci, atunci când descărcați 5 imagini de fundal, fiecare având 3 MB sau mai mult, este posibil să nu identificați o problemă cu viteza conexiunii de 1 Gbit în mediul dvs. de dezvoltare. Dar când utilizatorii dvs. încep să încarce o pagină de pornire de 15 MB prin conexiuni 3G pe smartphone-urile lor, ar trebui să vă pregătiți pentru o listă de plângeri și probleme.

Optimizarea utilizării lățimii de bandă vă poate oferi un spor de performanță, iar pentru a obține acest spor, probabil că aveți nevoie doar de câteva trucuri. Există câteva lucruri pe care mulți dezvoltatori web buni le fac în mod implicit, inclusiv:

  1. Minimizarea tuturor JavaScript
  2. Minimizarea tuturor CSS
  3. Compresie HTTP pe partea serverului
  4. Optimizarea dimensiunii și rezoluției imaginii

Greșeala comună nr. 7: Nu se dezvoltă pentru diferite dimensiuni de ecran

Designul responsive a fost un subiect important în ultimii ani. Extinderea smartphone-urilor cu diferite rezoluții de ecran a adus multe noi modalități de accesare a conținutului online, care vine și cu o serie de probleme de dezvoltare web. Numărul de vizite pe site-uri web care provin de pe smartphone-uri și tablete crește în fiecare zi, iar această tendință se accelerează.

Pentru a asigura o navigare fără întreruperi și acces la conținutul site-ului web, trebuie să permiteți utilizatorilor să îl acceseze de pe toate tipurile de dispozitive.

Există numeroase modele și practici pentru construirea de aplicații web receptive. Fiecare platformă de dezvoltare are propriile sfaturi și trucuri, dar există unele cadre care sunt independente de platformă. Cel mai popular este probabil Twitter Bootstrap. Este un cadru HTML, CSS și JavaScript cu sursă deschisă și gratuit, care a fost adoptat de fiecare platformă majoră de dezvoltare. Trebuie doar să respectați modelele și practicile Bootstrap atunci când vă construiți aplicația și veți obține o aplicație web receptivă fără probleme.

Greșeala comună nr. 8: Incompatibilitate între browsere

Procesul de dezvoltare este, în cele mai multe cazuri, sub o presiune mare de timp. Fiecare aplicație trebuie să fie lansată cât mai curând posibil și chiar și dezvoltatorii web buni se concentrează adesea pe furnizarea de funcționalități în detrimentul designului. Indiferent de faptul că majoritatea dezvoltatorilor au instalat Chrome, Firefox, IE, ei folosesc doar unul dintre aceștia în 90% din timp. Este o practică obișnuită să utilizați un browser în timpul dezvoltării și, pe măsură ce aplicația se apropie de finalizare, veți începe să o testați în alte browsere. Acest lucru este perfect rezonabil, presupunând că aveți mult timp pentru a testa și remedia problemele care apar în această etapă.

Cu toate acestea, există câteva sfaturi de dezvoltare web care vă pot economisi timp semnificativ atunci când aplicația dvs. ajunge la faza de testare între browsere:

  1. Nu trebuie să testați în toate browserele în timpul dezvoltării; este consumator de timp și ineficient. Cu toate acestea, asta nu înseamnă că nu puteți schimba frecvent browserul. Utilizați un browser diferit la fiecare două zile și veți recunoaște cel puțin problemele majore la începutul fazei de dezvoltare.
  2. Aveți grijă să folosiți statistici pentru a justifica neacceptarea unui browser. Există multe organizații care încetează să adopte software nou sau să actualizeze. Mii de utilizatori care lucrează acolo ar putea avea nevoie în continuare de acces la aplicația dvs. și nu pot instala cel mai recent browser gratuit din cauza politicilor interne de securitate și de afaceri.
  3. Evitați codul specific browserului. În cele mai multe cazuri, există o soluție elegantă care este compatibilă între browsere.

Greșeala comună nr. 9: Nu planificați portabilitatea

Adormirea este mama tuturor problemelor! Când vine vorba de portabilitate, această zicală este mai adevărată ca niciodată. De câte ori ați văzut probleme în dezvoltarea web, cum ar fi căi de fișiere codificate greu, șiruri de conexiune la baze de date sau presupuneri că o anumită bibliotecă va fi disponibilă pe server? Presupunând că mediul de producție se va potrivi cu computerul de dezvoltare local este pur și simplu greșit.

Configurarea ideală a aplicației ar trebui să nu necesite întreținere:

  1. Asigurați-vă că aplicația dvs. poate scala și rula într-un mediu de servere multiple cu încărcare echilibrată.
  2. Permiteți configurarea simplă și clară – eventual într-un singur fișier de configurare.
  3. Gestionați excepțiile atunci când configurația serverului web nu este așa cum se aștepta.

Greșeala comună nr. 10: modele anti-odihnă

API-urile RESTful și-au luat locul în dezvoltarea web și sunt aici pentru a rămâne. Aproape fiecare aplicație web are implementat un fel de servicii REST, fie pentru uz intern, fie pentru integrare cu un sistem extern. Dar vedem în continuare modele RESTful rupte și servicii care nu aderă la practicile așteptate.

Două dintre cele mai frecvente greșeli făcute la scrierea unui API RESTful sunt:

  1. Folosind verbe HTTP greșite. De exemplu, folosind GET pentru scrierea datelor. HTTP GET a fost conceput pentru a fi idempotent și sigur, ceea ce înseamnă că, indiferent de câte ori apelați GET pe aceeași resursă, răspunsul ar trebui să fie întotdeauna același și nu ar trebui să apară nicio modificare a stării aplicației.

  2. Nu se trimit codurile de stare HTTP corecte. Cel mai bun exemplu al acestei greșeli este trimiterea de mesaje de eroare cu codul de răspuns 200.

     HTTP 200 OK { message:'there was an error' }

Ar trebui să trimiteți HTTP 200 OK numai atunci când solicitarea nu a generat o eroare. În cazul unei erori, ar trebui să trimiteți 400, 401, 500 sau orice alt cod de stare care este adecvat pentru eroarea care a apărut.

O prezentare detaliată a codurilor standard de stare HTTP poate fi găsită aici.

Învelire

Dezvoltarea web este un termen extrem de larg care poate cuprinde în mod legitim dezvoltarea unui site web, a unui serviciu web sau a unei aplicații web complexe.

Principala concluzie a acestui ghid de dezvoltare web este reamintirea că ar trebui să fiți întotdeauna atenți la autentificare și autorizare, să planificați scalabilitate și să nu vă asumați niciodată nimic în grabă - sau să fiți gata să faceți față unei liste lungi de probleme de dezvoltare web!