Școala Web

Cum se face web development în 2021?

Cum se face web development în 2021?

Lumea web-development-ului s-a schimbat în ultimii ani. În acest articol, prezint cum este structurată o echipă modernă și ce tehnologii folosește un proiect actual.

Dacă ai ceva ani de experiență în Web-Development, e foarte ușor să te blochezi la un mod de lucru învechit. Poate ai un șef care vrea doar lucruri noi pe care le poate vedea. Poate ai urcat în ierarhie la tine în echipă și nimeni nu îndrăznește să te contrazică.

Am să încerc să sintetizez în acest articol ce înseamnă Web Development în 2021, de la structura echipei, la tehnologiile actuale.

Dacă ești veteran în domeniu, vezi dacă ai rămas în urmă.
Dacă ești nou, poate te inspiră să știi ce trebuie să înveți.


Structura echipei

Într-un proiect serios, există oameni specializați în fiecare aspect al dezvoltării. Poți să găsești foarte ușor proiectele neserioase atunci când se postează job-uri de „Full-Stack Developer”, care înseamnă că îți asumi mai multe roluri, fiind plătit doar pentru unul.

Dacă nu îți permiți să ai pretenții (adică ai nevoie de job urgent), va trebui să iei în considerare și roluri combinate.

La unele roluri, nu sunt destul de bine familiarizat, așa că orice feedback e bine primit.

Legături în interiorul unei echipe.

Developer Front End

Programatorul de Front-End construiește interfața folosind HTML, CSS, și JavaScript.

Folosește librăriile aprobate de arhitectul de Front-End, implementează design-ul dat de designer, și ține cont de necesitățile SEO.

Poate lucra atât la zona publică a proiectului, cât și la zona de administrare.

Developer Back End (API)

Programatorul de Back-End construiește API-ul ce va fi consumat de front-end.

Limbajul nu prea contează. Poate fi PHP, Node.js, .NET (C#), Java.

Folosește librăriile aprobate de arhitectul de Back-End.
Dacă se lucrează la un API personalizat, se va ține cont de nevoile Front-End-ului.

Arhitect Front End

Arhitectul de Front-End decide ce librării sunt folosite și cum este organizat proiectul.

Arhitect Back End

Arhitectul de Back-End decide ce limbaje și librării vor fi folosite, și cum va arăta API-ul.

De asemenea, decide ce servicii adiacente sunt necesare (Bază de date, Sistem de cache)

Designer UI/UX

Designer-ul este responsabil de cum arată interfața.

Front-end-ul colaborează permanent cu designer-ul, pentru orice culoare, dimensiune, sau animație.

DevOps

Inginerul DevOps este responsabil de cum rulează aplicația în producție și în mediile de testare.

E un domeniu foarte complex și neapreciat suficient.

Database expert

Programatorul sau Expertul în Baze de date construiește și optimizează bazele de date. Când e vorba de SQL, poate construi view-uri și proceduri stocate ce permit back-end-ului să acceseze datele mai eficient.

De foarte multe ori, acest rol e greșit contopit cu cele de Back-End.

SEO expert

Expertul SEO stă la curent cu nevoile Google și ghidează Front-End-ul astfel încât site-ul să ajungă cât mai sus în rezultate.

QA

Testează noile funcții și rezolvarea problemelor (bug-urilor) înainte să ajungă în producție.

Testarea se poate face manual – încercând să folosești aplicația ca un user. Sau se poate face automat, rulând și scriind scripturi de testare în aplicații precum Selenium.

Product Owner

Termenul vine de la Scrum, dar poate fi folosit și în alte metodologii.
Este persoana care se ocupă de organizarea sarcinilor.
Nu este o funcție de conducere și cu siguranță nu e vorba de „patronul” firmei.

Trebuie să folosească un sistem de „issue tracking” precum Jira, la care toate părțile au acces.


Tehnologii

În ultimii ani, am văzut o separare mai accentuată între front-end și back-end. Dacă pe vremuri, site-urile dinamice se obțineau prin interpolarea unui limbaj de programare în HTML, în 2021 și deja de câțiva ani zona de front-end este construită exclusiv în JavaScript.
Se folosește un framework (Vue, React, Angular), iar datele dinamice vin de la un API accesat prin AJAX.
Atâta timp cât serverul poate să livreze acest API, devine irelevant ce limbaj de programare rulează în spate.

Front-End

Sunt doar 3 limbaje necesare pentru front-end, iar acestea nu se vor schimba prea curând: HTML, CSS, și JavaScript.
Însă codul scris în acestea nu mai este folosit direct, ci trece prin compilări.

Site-urile moderne pornesc de la un framework de JavaScript care include și un mod de a construi codul HTML.
Preferatul meu sete Vue.js, dar cel mai popular este React. Mai există și Angular, care a pierdut teren în ultimii ani.

Codul JavaScript scris de către programator diferă de cel rulat de browser. Este trecut printr-un compilator precum Babel, ce îți permite să scrii cod modern (ES – EcmaScript) fără să te preocupe ce browsere suportă acel standard.
Alt compilator popular este TypeScript, ce permite definirea de tipuri de date în JavaScript/EcmaScript.
În urmă cu câțiva ani, TypeScript era considerat un limbaj diferit, dar multe din particularitățile sale au fost preluate de ES.

Codul CSS este generat din cod SCSS (Sass), dar tendința pare să fie revenirea la CSS, prin folosirea PostCSS și modulelor în React și Vue.

Pentru a ușura compilarea, se folosește WebPack, care folosește Babel sau TypeScript pentru a compila codul JavaScript, și mai folosește Sass pentru a compila CSS.
În proiectele noi de Vue sau React, create cu tool-urile oficiale, Webpack este deja instalat, dar puțin ascuns.

Layout

Când am învățat eu HTML, se făcea trecerea de la Layout-uri făcute cu tabele, la layout-uri în CSS, în special bazate pe float.
Acestea au rezistat până în zilele noastre, dar proiectele moderne nu le mai folosesc pentru că toate browserele suportă Flexbox, inclusiv ultimul Internet Explorer de acum câțiva ani.

Dacă nu te interesează browserele mai puțin folosite, precum Opera Mini sau IE, se poate folosi și Grid Layout sau o combinație între Grid și Flex.

Evident, layout-ul trebuie să fie scalabil în funcție de ecran. Primul design trebuie să fie pentru mobil, apoi pentru ecrane mai mari.

SSR

O mare problemă de la a construi site-uri exclusiv în JavaScript este legată de SEO. Google nu rulează JavaScript și nu va putea să indexeze corect paginile.

Soluția se numește SSR, care în general înseamnă Server-Side-Rendering.
Serverul rulează Node.js, care parsează o parte din codul JavaScript suficientă încât să redea codul HTML.
Atunci când Google indexează pagina, „vede” codul HTML.
Browserul încarcă același cod HTML, dar apoi se trece la Client-Side-Rendering. Client-Side-Rendering înseamnă că paginile se încarcă dinamic cu JavaScript.

Utilizatorul nu ar trebui să vadă nicio diferență, în afară de faptul că site-ul pare să se încarce mai repede.

Mai există un concept asemănător, care poate e confundat de unii programatori: Static-Site-Generation. Efectiv, la compilare se generează fișierul HTML, ce poate fi încărcat de orice browser, chiar și de cele care nu au JavaScript activat.

Avantajul SSG față de SSR este viteza: E mult mai ușor pentru server să livreze un fișier HTML complet randat, decât să ruleze randarea de fiecare dată când este cerută o pagină.
Dezavantajul este că paginile sunt complet statice și e nevoie de o recompilare pentru a le schimba.
La fel ca în cazul SSR, odată ce browser-ul a încărcat pagina, se trece la CSR.

Se pot folosi, însă, amândouă, SSR+SSG. E trivial să configurezi un server ca nginx să livreze SSG atunci când există fișierul HTML, dar să treacă la SSR atunci când se accesează pagini noi.

Back-End+DevOps

Tehnologiile de back-end/API nu mai sunt atât de clare și depind de factori precum limbajul și mediul în care se lucrează.

Dacă aplicația trebuie să ruleze pe Windows Server, probabil trebuie folosit .NET, scris în C#. Orice artificiu de a rula PHP, Node.js, sau altceva pe Windows, în producție, probabil nu merită efortul.

Dacă aplicația de API poate să ruleze pe Linux, trebuie folosit Docker în dezvoltare locală, și Kubernetes în producție sau alte medii.
Ar fi ideal ca aceleași imagini de Docker folosite în producție să fie folosite și de către programatori în timpul dezvoltării.

În privința limbajelor și framework-urilor, nu îmi permit să dau recomandări. Eu sunt mai familiar cu PHP și Laravel, dar nu pot să garantez că sunt cele mai bune opțiuni.

Code Style

Toate limbajele folosite în proiect trebuie să aibă un sistem de verificare a codului (lint). Asta face ca stilul de codare să fie cât-de-cât uniform, dar ajută și la evitarea unor probleme comune.

Uneori se pot găsi standarde pre-definite de la companii mari. Aceste standarde pot fi adoptate integral, sau pot constitui un punct de plecare.

Pentru JavaScript, cel mai folosit este ESLint. Cele mai cunoscute standarde sunt cele de la AirBNB, Google, și „Standard”.

Pentru CSS, sau preprocesoare precum Sass


Structura proiectului

Din ce am povestit până acum, ar putea să fie oarecum conturat cum este organizat un proiect modern.

Din punct de vedere al codului, un proiect ar trebui să aibă cel puțin 4 componente:

  1. Front-end public. Aceasta este partea vizibilă, cu care utilizatorii interacționează. Trebuie construită într-un framework modern (Vue, React, Angular). Dacă e nevoie de SEO, se va face SSR sau SSG.
  2. API public. Este API-ul la care se conectează front-end-ul public.
  3. Interfața de administrare. Este partea din care se configurează site-ul. Este construită într-un framework modern, probabil același ca la front-end-ul public.
    E important ca această interfață să fie protejată de un VPN, astfel încât doar persoanele autorizate au acces.
    Nefiind indexat de Google, se poate folosi CSR.
  4. API pentru interfața de administrare. Este API-ul la care se conectează interfața de administrare.