Cum să treci de la Bun la Mare

Aceasta este o introducere într-o serie cu mai multe părți, în care explorăm eficientizarea și scalabilitatea proceselor de dezvoltare front-end - pentru a face un produs mai bun, mai rapid.

„Un grup de oameni care se plimbă pe un laptop și foi de hârtie” de Štefan Štefančík pe Unsplash

Construirea unui produs excelent nu este adesea un efort individual. Cele mai elaborate setări ar implica mai multe echipe de creație, marketing, produs și tehnologie. Chiar dacă sunteți o companie a unuia, va trebui să interacționați cu utilizatorii, pentru a obține feedbackul lor despre ceea ce funcționează pentru ei. Acest cadru iterativ al procesului de proiectare ciclică pentru a ajuta la îmbunătățirea calității și funcției este denumit în mod obișnuit fluxul de lucru de agerație agilă.

Cu cât sunteți mai repede în stare să iterați, cu atât produsul dvs. va deveni mai bun.
„Flux de lucru cu agerație de agerație” de Smartsheet

La StashAway, când echipa front-end a început să creeze produsul bazat pe web, am fost pe o linie de timp accelerată pentru lansare, iar procesele noastre de dezvoltare și gestionare a produselor au fost mai puțin stricte. Acum că produsul se maturizează și pe măsură ce sunt explorate și adăugate mai multe caracteristici, căutăm să îmbunătățim și să întărim procesul nostru de construire a unei arhitecturi frontale mai bune și mai scalabile pentru produs. Configurația noastră actuală nu ne-ar permite să scalăm eficient în ceea ce privește ofertele de funcții și extinderea țării.

Pentru a face un produs excelent, trebuie să perfecționăm fluxul de lucru de iterație. Există multe literaturi de gestionare a produselor în această privință și aceasta nu este obiectul acestei serii de articole. Ceea ce vrem să explorăm este cum să fim mai rapide cu iterațiile în faza de prototipare și construcție, iar pentru a face acest lucru, va trebui să formalizăm procesele interne de dezvoltare și aprobare ale echipei noastre, astfel încât să putem colabora mai eficient cu echipele noastre creative și de produse. . Considerăm că putem realiza acest lucru folosind integrarea continuă și fluxul de livrare în corelație cu fluxul de lucru mai larg de iterare a produsului, așa cum a fost menționat anterior.

În cele din urmă, ne propunem să abordăm paradigma de programare declarativă care exprimă ceea ce vrem să facem în aplicațiile noastre, în loc să codăm imperativ modul în care. Pentru a face acest lucru, va trebui să punem bazele creării blocurilor noastre de construcție.

Începem prin a ne extinde pe separarea preocupărilor noastre cu UI și logica aplicațiilor, astfel încât dezvoltarea componentelor UI să devină o activitate separată. Acesta va avea propriul depozit central, împreună cu utilitățile comune, suita proprie de teste de unitate, de acceptare și de regresie. Componentele noastre de interfață de utilizator vor fi acum reutilizabile, capabile să compună și teme, pentru variații de site-uri web și aplicații web. Când este folosit cu Storybook, putem crea o bibliotecă de tipare interactive.

Vom avea încrederea că componentele utilizatorului nostru vor arăta și se vor comporta exact așa cum trebuie, astfel încât să ne putem concentra asupra lucrurilor distractive și importante - aplicațiile și modul în care ar trebui să se comporte. Putem aplica același proces cu componentele UI pentru proiectele noastre specifice aplicației, cu apartamente de testare mai specifice pentru a maximiza acoperirea. Doar cu aceste suite de test putem crește încrederea dezvoltatorilor în împingerea și implementarea codului și, în schimb, creșterea vitezei de iterare.

Cu acest depozit central de componente capabile de compunere, putem prototip și idei de testare pe hol, și chiar să oferim funcții noi într-un ritm crescut.

Niveluri de testare software

Veți observa că am lovit acasă mesajul că testarea este importantă. Testarea software este un subiect vast în dezvoltarea de software, dar să ne concentrăm pe cele patru niveluri de testare integrale în buna funcționare a procesului de livrare continuă - unitate, integrare, sistem și acceptare.

Utilizăm teste de unități pentru a valida componente individuale, cele mai mici unități testabile, într-un software. În cazul nostru, acestea sunt de obicei componente UI sau metode de asistență pentru utilități. Testarea integrării are loc atunci când componentele individuale sunt testate ca grup. De exemplu, acest lucru ar putea însemna o caracteristică, cum ar fi un calculator, unde veți avea butoane și un ecran de afișare și asigurarea că numărul corect este afișat ca răspuns la o apăsare de buton. Pentru API, un punct final ar putea crea o conexiune la baza de date pentru a prelua un set de date.

Testările de unitate și de integrare elimină, de regulă, majoritatea erorilor evidente înainte de a intra în desfășurarea în stadiu. Economisește timp pentru testerii interni și externi, care vor evalua sistemul completat și integrat pentru respectarea cerințelor de caracteristici și de afaceri - domenii ale sistemului și testarea acceptării. Odată ce software-ul trece cele patru niveluri de testare, ne putem implementa la producție.

Este o privire uimitoare asupra modului în care intenționăm să facem mai eficiente procesele echipei noastre. Vom intra în mai multe detalii despre implementări în postările ulterioare despre dezvoltarea front-end la StashAway. Rămâneți aproape!

Suntem în permanență în căutarea talentului tehnic deosebit pentru a se alătura echipei noastre - vizitați site-ul nostru web pentru a afla mai multe și pentru a ne simți liber să ne contactăm!