U Unityu smo nedavno krenuli u poboljšanje nadzornih ploča - pothvat koji je dramatično izmijenio ne samo naš tehnološki skup, već i načine na koji radimo i surađujemo.
Razvili smo najbolje prakse i alate koji će nam pomoći da prilagodimo našu frontend arhitekturu, izgradimo proizvode s izvrsnim UX-om i performansama te da nove značajke ugradimo prije.
Ovaj članak okuplja ove prakse i ima za cilj pružiti što više obrazloženja iza svake odluke. Ali prvo, neki kontekst.
Ostavština
Gledajući broj inženjera, Unity je više nego učetverostručio broj svojih zaposlenih u posljednje 4 godine. Kako je tvrtka rasla i organski i akvizicijama, rasla je i ponuda proizvoda. Iako su proizvodi koji su prvotno razvijeni u Unityju uglavnom bili jednoliki u pogledu tehnologije i jezika dizajna, novonabavljeni prirodno nisu.
Kao rezultat toga imali smo više vizualno različitih nadzornih ploča koje su radile i ponašale se drugačije i koje nisu imale zajedničke navigacijske elemente. To je rezultiralo lošim korisničkim iskustvom i frustriranim korisnicima. U doslovnom smislu, stanje naših proizvoda koštalo nas je prihoda.
Nakon analize portfelja naših proizvoda, izvukli smo tri različita odjeljka koja će se podijeliti na Nadzornu ploču Unity: Razviti, upravljati i stjecati, svaki udovoljava različitim poslovnim potrebama i namijenjen je različitim skupinama kupaca, što sadrži skupove značajki koji su uglavnom neovisni jedni od drugih .
Ova nova struktura i uvođenje uobičajenih navigacijskih elemenata imali su za cilj riješiti prvo glavno pitanje s kojim su se suočili naši korisnici - gdje pronaći informacije i opcije konfiguracije koje traže, a iako je sve to na papiru izgledalo dobro, putovanje kako doći tamo bili su daleko od očitog.
Razmatranja
Mnogi su naši programeri bili vrlo uzbuđeni zbog mogućnosti prelaska na React i njegovu moderniju tehnologiju. Budući da su ta rješenja bila testirana u velikim primjenama i uglavnom su im se glačale najbolje prakse i konvencije, stvari su izgledale vrlo obećavajuće.
Ipak, ono što su naši programeri najbolje znali i u čemu je napisana većina naših aktivno razvijenih aplikacija bio je AngularJS. Odluka o pokretanju migracije svega u jednom potezu bila bi katastrofa koja čeka da se dogodi. Umjesto toga, krenuli smo prvo testirati svoje pretpostavke u mnogo manjem mjerilu.
Možda najneučvršćenija grupa proizvoda koju smo imali bile su nadzorne ploče za unovčavanje . Ti su se projekti, koji bi na kraju završili pod kišobranom nadzorne ploče Operate, uvelike razlikovali na gotovo svaki mogući način: korištene tehnologije, pristup UI / UX-u, razvojne prakse, konvencije kodiranja - samo vi.
Evo kako je otprilike izgledala situacija:
Nakon neke moždane pameti identificirali smo glavna područja na kojima bismo trebali poraditi kako bismo povezali sve proizvode:
1. Jedan proizvod
Trebale su nam ove nadzorne ploče (podijeljene na više aplikacija, domena i tehnoloških hrpa) da bismo:
- Osjećajte se kao jedan proizvod (nijedna puna stranica ne preusmjerava dok korisnik kreće stranicama svih različitih aplikacija)
- Imajte dosljedan izgled i dojam
- Uključite uobičajene navigacijske elemente uvijek su vidljivi i izgledaju isto, bez obzira koji dio nadzorne ploče korisnik posjećuje
2. Podrška naslijeđa
Iako smo imali čisti pristup kada je riječ o tehnološkom izboru našeg novog frontend rješenja, morali smo se prilagoditi naslijeđenim projektima koji su trebali biti integrirani u novi sustav. Rješenje koje nije uključivalo velike napore na prerađivanju i koje ne bi zaustavilo razvoj značajki ili se povuklo mjesecima bez kraja.
3. Vježbe i alati
Iako su gotovo svi timovi koristili AngularJS, različiti alati koristili su se za rješavanje istog skupa izazova. Različite testne pokretačke knjižnice i knjižnice tvrdnji, rješenja za upravljanje stanjem ili nedostatak istih, jQuery u odnosu na odabir izvornog preglednika, SASS u odnosu na MANJE, knjižnice grafikona itd.
4. Produktivnost programera
Budući da je svaki tim imao vlastito rješenje za razvoj, testiranje i izgradnju svoje aplikacije, razvojno okruženje često je bilo prožeto programskim pogreškama, ručnim koracima i neučinkovitošću.
Uz to, mnogi naši timovi rade na mjestima odvojenim razlikama od 10 sati (Helsinki, Finska i San Francisco), što učinkovito donošenje odluka o dijeljenim dijelovima čini pravim izazovom.
Novi
Naša glavna područja fokusiranosti bila su:
- Potaknite i sačuvajte agilne načine rada u našim timovima i omogućite da timovi budu uglavnom neovisni jedni od drugih
- Iskoristite i razvijte zajedničke alate i konvencije što je više moguće kako biste ih dokumentirali i učinili lako dostupnima i upotrebljivima
Vjerovali smo da će postizanje ovih ciljeva značajno poboljšati naše vrijeme za tržište i produktivnost programera. Da bi se to dogodilo, tražili smo rješenje koje bi:
- Izgradite značajke proizvoda s boljim korisničkim iskustvom
- Poboljšati kvalitetu koda
- Omogućite bolju suradnju bez blokiranja bilo čijeg napretka u radu u tom procesu.
Također smo željeli potaknuti i olakšati prelazak na modernu tehnološku hrpu kako bi naši programeri bili zadovoljniji svojim radom i kako bi se s vremenom odmaknuli od naših zastarjelih okvira i alata.
Rezultat našeg rada koji se neprestano razvija je SPA baziran na Reactu, izgrađen unutar monorepozitorija, gdje se sve stranice i veće značajke ugrađuju u uglavnom neovisne snopove koda učitane na zahtjev, a koje više timova može istovremeno razvijati i raspoređivati .
Kao sredstvo za izoliranje svih naslijeđenih aplikacija, ali i dalje prikazujući ih u kontekstu iste nove aplikacije, učitavamo ih unutar iframea unutar kojeg mogu komunicirati s glavnim SPA-om pomoću sabirnice poruka implementirane pomoću postMessage()API-ja.
Monorepozitorij
Evo strukture direktorija s kojom smo započeli:
/src /components /scenes /foo /components package.json foo.js /bar /components package.json bar.js package.json index.jspackage.jsonU root direktorij sadrži skup devDependencies odgovoran za razvoj, testiranje i graditi okoliš prijave u cjelini, ali također sadrži dependenciesjezgre prijave (više o tome malo kasnije).
Svi veći dijelovi korisničkog sučelja nazivaju se scenama . Svaka scena sadrži package.jsongdje dependenciessu definirane komponente te scene. To omogućuje dvije stvari:
- Implementacija ažurira samo datoteke koje su se promijenile
Korak gradnje sastavlja zasebne snopove dobavljača i aplikacija za svaku scenu, imenujući svaku pomoću hasha koji će se promijeniti samo kad se promijeni sadržaj datoteke. To znači da naši korisnici preuzimaju samo datoteke koje su se promijenile od posljednjeg posjeta, i ništa više.
- Scene se učitavaju samo po potrebi
Sve scene učitavamo asinkrono i na zahtjev, što drastično poboljšava vrijeme učitavanja cijele aplikacije. Ovdje "na zahtjev" obično znači posjećivanje određene rute ili izvođenje radnje korisničkog sučelja koje izvode uvoz dinamičkog modula.
Evo kako takva postavka izgleda u praksi (pojednostavljena radi čitljivosti):
// In src/routes.jsconst FooLoader = AsyncLoadComponent( () => import(‘src/scenes/foo/foo’), GenericPagePreloader,);// In src/scenes/foo/foo.js To AsyncLoadComponentje tanki omot okolo React.lazy(), koji dodatno prihvaća komponentu predopterećivača, onu istu koja je prošla kroz rezervni sustav React.Suspense()i odgodu nakon koje bi se predopremač trebao prikazati ako scena nije završila s učitavanjem.
Ovo je korisno kada osiguravamo da naši korisnici vide isti predzaštitnik bez ikakvih prekida ili bljeska sadržaja od trenutka kada se traži scena do trenutka kada su preuzete sve njene datoteke, dovršeni svi kritični API zahtjevi i komponenta je završio s prikazivanjem.
Razine komponenata
Kako svaka aplikacija raste, zajedno s njom razvijaju se i struktura direktorija i apstrakcije. Nakon otprilike pola godine izgradnje i premještanja značajki u novu bazu kodova, postojanje jednog direktorija komponenata pokazalo se nedovoljnim.
Trebala nam je struktura imenika kako bi nas informirala o:
- Jesu li komponente razvijene tako da su generičke ili su namijenjene samo određenom slučaju upotrebe?
- Jesu li dovoljno generički za upotrebu u svim aplikacijama ili bi se trebali koristiti samo u određenom kontekstu?
- Tko je odgovoran za kôd i najbolje ga poznaje?
Na temelju toga definirali smo sljedeće razine komponenata :
1. Specifično za aplikaciju (src / app)
Komponente za jednokratnu uporabu koje udovoljavaju određenim slučajevima upotrebe u ovoj aplikaciji i kojima nije namijenjena ponovna upotreba ili izdvajanje u biblioteku komponenata (rute, podnožje, zaglavlje stranice itd.).
2. Općenito (src / komponente)
Općenite višenamjenske komponente koje će se koristiti u cijeloj aplikaciji i njezinim scenama. Kad dođemo do stabilnog API-ja za ove komponente, one bi se mogle premjestiti u zajedničku biblioteku komponenata (više o tome u nastavku)
3. Komponente jedne scene (src / scene / my-scene / components)
Komponente razvijene s posebnim slučajem uporabe; nije namijenjen za upotrebu u bilo kojim drugim scenama. U slučajevima kada komponentu s jedne scene treba upotrijebiti u drugoj, koristili bismo:
4. Komponente s više scena (src / scene / components / my-feature)
Komponente koje se koriste u više scena, ali nisu namijenjene da budu dovoljno generičke za upotrebu bilo gdje drugdje. Da ilustriramo zašto jednostavno premještanje na njih src/componentsnije dovoljno dobro:
Zamislite da ste do sada imali jednu scenu koja je sadržavala komponente korištene za izgradnju nekih prilično specifičnih grafikona podataka. Vaš tim sada gradi drugu scenu koja će koristiti različite podatke za ljestvice, ali vizualno će izgledati približno isto.
Uvoz komponenata iz jedne scene u drugu prekinuo bi enkapsulaciju scene i značio bi da više ne možemo biti sigurni utječu li promjene napravljene na komponentama jedne scene samo na jednu scenu.
U tu svrhu bilo koja komponenta ili skupina komponenata, koja se grubo naziva značajkom, smjestila bi se src/scenes/componentsodakle je može uvesti i koristiti bilo koji drugi tim, međutim:
Kad god bi tim želio početi koristiti komponente scene koje je razvio drugi tim, najbolja bi praksa bila prvo obratiti se tom timu kako bi se utvrdilo može li se slučaj upotrebe za koji namjeravate ove komponente sigurno podržati u budućnosti. Davanje informacija timu koji je izvorno razvio kôd spriječit će isporuku pokvarenih značajki u budućnosti kada se kod koji ste koristili neizbježno promijeni na načine na koje niste očekivali (jer, naravno, kako biste mogli!), I što možda neće uvijek biti obuhvaćeno jediničnim testovima.
5. Zajednička knjižnica
Komponente koje smo testirali u proizvodnji i želimo ih izdvojiti u našu zajedničku biblioteku komponenata, koje koriste drugi timovi nadzornih ploča u Unityu.
Oda zajedničkim ovisnostima
Iako bi bilo vrlo povoljno moći graditi i implementirati svaki dio naše aplikacije u potpuno izoliranom okruženju, određene ovisnosti - i vanjske knjižnice i interni kod aplikacije - jednostavno će se koristiti u cijeloj bazi koda. Stvari poput samog React-a, Redux-a i svih vezanih uz redux logiku, uobičajene navigacijske komponente itd.
Uvođenje promjena
Trenutno potpuno inkapsuliranje scena nije praktično i u mnogim slučajevima jednostavno nemoguće. Bilo bi potrebno ili isporučivanje mnogih ovisnosti više puta, a u procesu usporavanje učitavanja stranica, ili izrada apstrakcija namijenjenih određenim knjižnicama da rade onako kako nisu predviđene.
Kako se web razvoj i njegov ekosustav razvijaju, čini se da knjižnice postaju sve više samostalne i zatvorene, što se nadamo da će u budućnosti značiti malo ili nimalo zajedničkih ovisnosti i istinska izolacija između svih modula.
Možda je najveći nedostatak stvaranja velikih aplikacija izvršavanje promjena koda i ažuriranja ovisnosti, a da se pritom nešto ne slomiKorištenje monorepozitorija omogućuje (iako nije obavezno) postupno i sigurnije uvođenje promjena i ažuriranja koda - ako promjena uzrokuje probleme, ti će problemi utjecati samo na mali dio aplikacije, a ne na cijeli sustav.
I dok bi se nekima mogućnost izvođenja ažuriranja na više nepovezanih područja baze kodova istodobno oduzela kao prednost, stvarnost postojanja više timova koji rade na istoj bazi podataka i ne poznavanja svih značajki ostalih timova znači da potreban je velik oprez pri gradnji aplikacijske skele i poduzimanju mjera kako bi se rizik od loma sveo na najmanju moguću mjeru.
Kako izbjeći lomljenje stvari
Možda najosnovnija strategija koja nam pomaže u tome, osim izolacije scene, jest velika pokrivenost jediničnim testom .
- Testiranje
Jedinstveni testovi nisu naravno sve - mnogi zreli proizvodi u čak i umjerenim razmjerima ipak ulažu u pakete integracije i e2e testove koji bolje rade u provjeri radi li aplikacija onako kako se očekuje. Međutim, kako raste broj značajki, tako raste i trošak održavanja i vrijeme potrebno za njihovo pokretanje - trošak koji se ne može uvijek opravdati za manje ključne, ali još uvijek važne značajke.
Neke smo lekcije naučili iz različitih strategija testiranja:
- Pokušajte jedinstveno testirati što više koda, posebno: uvjetnu logiku, transformacije podataka i pozive funkcija
- Uložite u integracijske testove i iskoristite ih u punoj mjeri prije nego što se odlučite za pisanje bilo kakvih e2e testova. Početna cijena integracijskih testova mnogo je veća, ali blijedi u usporedbi s cijenom održavanja paketa e2e
- Pokušajte ne reagirati pretjerano tako što ćete početi pisati e2e testove za stvari koje nisu uhvaćene kod jedinstvenih ili integracijskih testova. Ponekad su krivi postupci ili alati
- Neka test slučajevi objasne ponašanje korisničkog sučelja, a ne pojedinosti o implementaciji
- Automatizirani testovi ne mogu u potpunosti zamijeniti ručno testiranje
2. Minimizirajte površinu zajedničkog koda
Osim testiranja, kod koji se ponovno upotrebljava u cijeloj aplikaciji sveden je na razumni minimum. Jedna od najkorisnijih strategija do sada bila je premještanje najčešće korištenih komponenti i koda u zajedničku biblioteku komponenata, odakle se koriste kao ovisnosti u scenama koje ih trebaju. To nam omogućuje da većinu promjena uvodimo postupno, po timu ili stranici.
3. Odgovornost
I na kraju, ali ne najmanje važno, ogroman faktor u tome što više timova može surađivati u istoj bazi kodova dolazi od poticanja i navođenja programera da preuzmu osobnu odgovornost i odgovornost za proizvod , umjesto da preuzmu odgovornost za pravilno testiranje da sve funkcionira na QA, testere ili automatizacija.
To se prenosi i na recenzije koda. Osiguravanje da se svaka promjena pažljivo pregleda je teže nego što bi se moglo činiti na površini. Kako tim usko surađuje, među članovima se razvija zdrav stupanj povjerenja. To povjerenje, međutim, ponekad može rezultirati time da ljudi budu manje marljivi prema promjenama koje su napravili iskusniji ili na drugi način pouzdani programeri.
Da bismo potaknuli marljivost, ističemo da su autor PR-a i recenzent podjednako odgovorni za osiguravanje da sve funkcionira .
Biblioteka komponenata
Da bismo postigli isti izgled i izgled na svim stranicama naših nadzornih ploča, razvili smo biblioteku komponenata. Ono što stoji u našem pristupu je da se nove komponente gotovo nikad ne razvijaju u toj knjižnici.
Svaka komponenta, nakon što se razvije unutar baze kodova nadzorne ploče, prvo se koristi u hrpi značajki unutar te baze podataka. Obično se nakon nekoliko tjedana počinjemo osjećati sigurnije da bi se komponenta mogla premjestiti, s obzirom na to da:
- API je dovoljno fleksibilan da podrži predvidljive slučajeve uporabe
- Komponenta je testirana u raznim kontekstima
- Izvedene su performanse, odziv i UX
Ovaj postupak slijedi Pravilo trojice i ima za cilj pomoći nam da oslobodimo samo one komponente koje se istinski mogu ponovno upotrijebiti i koje su korištene u raznim kontekstima prije premještanja u našu zajedničku knjižnicu.
Neki od primjera komponenata koje bismo premjestili uključuju: podnožje, zaglavlje stranice, bočni i gornji navigacijski elementi, građevni blokovi izgleda, natpisi, pokrenute verzije gumba, tipografski elementi itd.
U ranim danima knjižnica komponenata nekada se nalazila u istoj bazi kodova kao i sama aplikacija. Od tada smo ga izdvojili u zasebno spremište kako bismo razvojni proces učinili demokratiziranijim za ostale timove u Unityju - što je važno kada se traži njegovo usvajanje.
Dizajn modularnih komponenata
Najduže vrijeme gradnja komponenata za višekratnu upotrebu značila je suočavanje s višestrukim izazovima, od kojih mnogi često nisu imali dobra rješenja:
- Kako jednostavno uvesti komponentu zajedno sa njenim stilovima i samo to
- Kako nadjačati zadane stilove bez ratova specifičnosti selektora
- U većim komponentama koje se sastoje od više manjih, kako nadjačati stil manje komponente
Naša nadzorna ploča, kao i naša biblioteka komponenata uvelike ovise o korisničkom sučelju za materijal i koriste ga. Ono što je jedinstveno uvjerljivo u styling rješenju Material UI-a jest potencijal koji donosi JSS i njihov objedinjeni jezik za oblikovanje (vrijedno čitanja), koji omogućuju razvoj korisničkih sučelja obuhvaćenih dizajnom, kao u slučaju CSS modula, i rješavanje gore spomenutog pitanja u korak.
To se značajno razlikuje od pristupa poput BEM-a koji omogućavaju inkapsulaciju prema konvenciji koja je obično manje proširiva i manje inkapsulirana.
Vodič dnevnog stila
Biblioteka komponenata ne bi bila potpuna bez načina da se prikažu komponente koje sadrži i ako se mogu vidjeti komponente dok se mijenjaju tijekom izdanja.
Imali smo prilično dobro iskustvo sa Storybookom, koje je bilo smiješno jednostavno postaviti i započeti, ali nakon nekog vremena shvatili smo da je potrebno robusnije i cjelovito rješenje. Prilično blizu onoga što Styleguidist nudi, ali prilagođeniji našim potrebama.
Postojeći dokumenti o dizajnu
Dokumentacija koja služi kao glavni izvor informacija o najnovijim specifikacijama dizajna nalazila se u mjestu Confluence, gdje su dizajneri održavali ažurnu specifikaciju za svaku komponentu koristeći snimke zaslona koji ilustriraju dopuštene slučajeve upotrebe, stanja i varijacije u kojima bi komponenta mogla biti navedena. najbolje prakse, kao i detalji poput dimenzija, korištenih boja itd. Slijedom tog pristupa suočili smo se s nizom izazova:
- Specifikacije dizajna materijala neprestano se razvijaju i zbog toga smo se često našli ili trošimo vrijeme na ažuriranje svih snimaka zaslona i smjernica ili dopuštamo da naše smjernice za dizajn zastarjevaju
- Otkriti što je točnije: implementacija ili specifikacija nije uvijek bio lak zadatak. Budući da objavljujemo prezentacije Storybooka svake komponente i za svaku verziju knjižnice, mogli smo vidjeti što se i kako promijenilo. Nismo mogli učiniti isto za specifikacije dizajna.
- Snimke zaslona i videozapisi mogu komunicirati samo toliko . Da bismo osigurali komponente visoke kvalitete i koje mogu koristiti više timova, potrebno je provjeriti radi li svaka komponenta u svim rezolucijama, ne sadrži greške i ima dobar UX - to je bilo teško bez da dizajner sjedi doslovno pored vas da vidi demonstracija implementacije koja se prikazuje na ekranu
Aplikacija za dokumentaciju komponenata
Naša aplikacija za dokumentaciju ima za cilj pružiti sredstva za učinkovitu suradnju između dizajnera i inženjera kako bi obje strane učinile jednostavnijim i vremenski zahtjevnijim za dokumentiranje, pregled i razvoj komponenata. Da bismo bili precizniji, trebali smo:
- Imajte jednu referentnu točku koja prikazuje komponente , kakotrebaju li izgledati, ponašati se i koristiti - predviđeno za svako izdanje - zamjenjujući detaljne opise živim demonstracijama
- Olakšajte dizajnerima i programerima lakšu suradnju na komponentama i njihovim dokumentima i to prije izdavanja komponenata - bez potrebe za dijeljenjem videozapisa, snimaka zaslona ili fizičkog boravka na istom mjestu
- Odvojite dizajn od onoga što planiramo učiniti od onoga što je učinjeno
Slično kao i prije, svako izdanje biblioteke komponenata uzrokuje objavljivanje nove verzije živog stilskog vodiča. Međutim, ovoga puta postoji nekoliko razlika:
- Dizajneri izravno doprinose dokumentaciji komponenata uređivanjem datoteka dokumentacije putem korisničkog sučelja Github, izvršavajući promjene u najnovijem izdanju.
- Demonstracije komponenata kao WYSIWYG - isti kôd koji vidite kao primjer kako implementirati komponentu koristi se za prikazivanje demonstracije, uključujući bilo koji uvoz srednje datoteke, deklaracije varijabli itd. Kao dodatni bonus, komponente zamotane
withStyles()prikazuju se ispravno (izdanje prisutno trenutno u Storybook-u). - Izmjene dokumenata i koda gotovo su trenutno vidljive bez lokalnog provjeravanja grane i pokretanja aplikacije za dokumentaciju - aplikacija se obnavlja i objavljuje za i za svako urezivanje.
Razvojno iskustvo
Jedan od glavnih ciljeva pregleda koda je osiguravanje da se svaka promjena pažljivo pregleda, razmotri i testira prije spajanja i primjene.
Da bismo ovaj zadatak učinili što bez prepreka, razvili smo Preview Server koji može stvoriti novu verziju naše aplikacije svaki put kada se PR stvori ili ažurira.
Naši dizajneri, menadžeri proizvoda i inženjeri mogu testirati svaku promjenu prije nego što je spoje, kako u početnom tako i u proizvodnom okruženju te u roku od nekoliko minuta od promjene.
Završne riječi
Prošlo je gotovo godinu dana otkako smo se obvezali konsolidirati svoje nadzorne ploče. Proveli smo to vrijeme učeći kako razviti velik, ali zdrav softverski projekt, kako poboljšati suradnju i komunikaciju i kako podići razinu kvalitete za sebe.
Skalirali smo frontend projekt ne samo u smislu linija koda, već i u smislu broja inženjera koji rade unutar njegove baze koda - broja koji se od početka učetverostručio.
Napravili smo promjenu od 180 stupnjeva u rješavanju vremenskih razlika između naših timova, prelazeći od modela u kojem su naši timovi radili potpuno izolirano do modela u kojem su bliska suradnja i komunikacija svakodnevna pojava.
Iako je pred nama još dug put kako bismo osigurali da svoj pristup možemo proširiti na više timova i na veće izazove, primijetili smo već niz poboljšanja:
- Plan puta i vidljivost rada
Zbog jednog mjesta na kojem se odvija sav posao, napredak se prati i skupljaju se svi problemi
- Brzina razvoja i vrijeme do izlaska na tržište
Nove značajke mogu se stvoriti velikim dijelom od već postojećih i dobro testiranih komponenata - do kojih se lako može doći pomoću naše aplikacije za dokumentaciju
- Kvaliteta koda i pokrivenost testom
Kada se grade nove stvari, rješenje za sličan problem obično već postoji i nadohvat ruke, zajedno s primjerima kako ga testirati
- Ukupna kvaliteta i UX
Testiranje značajki i osiguravanje njihove kvalitete sada je lakše nego ikad, jer dizajneri, voditelji proizvoda i drugi dionici mogu svaku promjenu testirati na svom stroju, sa svojim računima i skupovima podataka
Naravno, tijekom puta susreli smo se s nizom izazova koje moramo riješiti ili koji će ih trebati riješiti u budućnosti:
- Izgradnja i izvedba CI-ja
Kako raste broj ovisnosti, snopova izrade i testova, tako raste i vrijeme potrebno za implementaciju. U budućnosti ćemo morati razviti alate koji će nam pomoći da samo gradimo, testiramo i implementiramo dijelove koji su se promijenili.
- Kultura razvoja
Da bismo izgradili zdrav softver, moramo kontinuirano raditi na zdravim načinima komunikacije i razmjene ideja, a komunikacija temeljena na tekstu otežava ovaj zadatak. Radimo na rješavanju ovog problema kroz niz redovitih treninga vodstva i prihvaćanja načina rada otvorenijeg koda, kao i na organiziranju nekoliko okupljanja godišnje kako bi se timovi susreli licem u lice.
- Izolacija i ažuriranja prekida
Kako broj funkcija i stranica raste, trebat će nam robusniji način izolacije naših aplikacijskih modula kako bismo spriječili širenje štete kada stvari krenu po zlu. To se može postići inačicama svih zajedničkih kodova (redux logika, src / komponente) ili u ekstremnim slučajevima samostalnim izradbama određenih značajki.
Država tada, sada i u budućnosti
Migracija je uključivala preseljenje iz AngularJS-a u React. Evo kako se situacija promijenila tijekom prošle godine:
To je omot! Hvala na čitanju! Možete me pronaći na LinkedInu ovdje.
Ako vam rad na sličnim izazovima zvuči zanimljivo, uvijek tražimo nadarene inženjere koji će se pridružiti našim timovima širom svijeta.