Unity Dashboard - saadut kokemukset skaalaavat käyttöliittymiä, kehityskulttuuria ja prosesseja

Unityssä olemme äskettäin pyrkineet parantamaan kojelautoja - yritys, joka muutti dramaattisesti paitsi käyttöliittymämme teknisen pino, myös tapamme työskennellä ja tehdä yhteistyötä.

Olemme kehittäneet parhaita käytäntöjä ja työkaluja, jotka auttavat meitä laajentamaan käyttöliittymämme arkkitehtuuria, rakentamaan tuotteita erinomaisella käyttöliittymällä ja suorituskyvyllä sekä toimittamaan uusia ominaisuuksia aikaisemmin.

Tämä artikkeli kerää nämä käytännöt ja pyrkii tarjoamaan mahdollisimman paljon perusteluja jokaisen päätöksen takana. Mutta ensin jokin asiayhteys.

Perintö

Insinöörien lukumäärää tarkasteltaessa Unity yli nelinkertaisti henkilöstömääränsä viimeisten 4 vuoden aikana. Kun yritys kasvoi orgaanisesti ja yritysostojen kautta, myös sen tuotetarjonta kasvoi. Vaikka Unityssä alun perin kehitetyt tuotteet olivat teknisesti ja muotoilukielellä suurelta osin yhtenäisiä, uudet hankitut eivät luonnollisesti olleet.

Tämän seurauksena meillä oli useita visuaalisesti erillisiä kojelautoja, jotka toimivat ja käyttäytyivät eri tavalla ja joilla ei ollut yhteisiä navigointielementtejä. Tämä johti huonoon käyttökokemukseen ja turhautuneisiin käyttäjiin. Tuotteiden käyttöliittymien tila kirjaimellisesti merkitsi meille tuloja.

Kun olemme analysoineet tuotevalikoimamme, olemme saaneet kolme erillistä osaa, jotka Unity Dashboard jaetaan: Kehitä, Hallitse ja Hanki, jokainen täyttää erilaiset liiketoimintatarpeet ja on tarkoitettu erilaisille asiakasryhmille, ja sisältää siten suuresti toisistaan ​​riippumattomia ominaisuusjoukkoja .

Tämän uuden rakenteen ja yhteisten navigointielementtien käyttöönoton tarkoituksena oli ratkaista ensimmäinen suuri ongelma, jonka käyttäjillä oli edessään - mistä löytää etsimäsi tiedot ja kokoonpanovaihtoehdot, ja vaikka kaikki näytti hyvältä paperilla, matka miten sinne pääseminen oli kaukana ilmeisestä.

Huomioita

Monet kehittäjistämme olivat erittäin innoissaan mahdollisuudesta siirtyä Reactiin ja sen nykyaikaisempaan tekniikkapinoon. Koska näitä ratkaisuja oli testattu taisteluissa suurissa sovelluksissa ja niiden parhaat käytännöt ja käytännöt olivat enimmäkseen siloitettuja, asiat näyttivät erittäin lupaavilta.

Siitä huolimatta, mitä kehittäjämme tiesivät parhaiten ja mihin suurin osa aktiivisesti kehitetyistä sovelluksistamme kirjoitettiin, oli AngularJS. Päätös aloittaa kaiken siirtäminen yhdellä kertaa olisi ollut tapahtumaa odottava katastrofi. Sen sijaan aloitimme testata oletuksiamme ensin paljon pienemmässä mittakaavassa.

Ehkä kaikkein epäyhtenäisimmät tuoteryhmämme ovat kaupallistamisen hallintapaneelit . Nämä projektit, jotka lopulta päätyivät Operate-kojelaudan sateenvarjoon , olivat huomattavasti erilaisia ​​lähes kaikin mahdollisin tavoin: käytetyt tekniikat, lähestymistapa käyttöliittymään / käyttöjärjestelmään, kehityskäytännöt, koodauskäytännöt.

Tällöin tilanne näytti karkeasti:

Aivoriihien jälkeen tunnistimme pääalueet, joilla meidän on työskenneltävä kaikkien tuotteiden yhdistämiseksi:

1. Yksi tuote

Tarvitsimme näitä koontinäyttöjä (jaettuina useisiin sovelluksiin, verkkotunnuksiin ja teknisiin pinoihin)

  • Tuntuu yhdeltä tuotteelta (ei kokonaisia ​​sivuja uudelleenohjata, kun käyttäjä selaa kaikkien eri sovellusten sivuja)
  • On tasainen ulkoasu
  • Sisällytä tavalliset navigointielementit ovat aina näkyvissä ja näyttävät samoilta riippumatta siitä, missä kojelaudan osassa käyttäjä vierailee

2. Vanha tuki

Vaikka meillä oli puhdas pöytä uuden frontend-ratkaisumme tekniikan valinnassa, jouduimme ottamaan huomioon perintöprojektit, jotka oli integroitava uuteen järjestelmään. Ratkaisu, joka ei edellyttänyt suuria korjaustöitä ja joka ei pysäyttänyt ominaisuuksien kehittämistä tai vetäisi kuukausia ilman loppua näkyvissä.

3. Harjoitukset ja työkalut

Vaikka melkein kaikki joukkueet käyttivät AngularJS-tekniikkaa, samojen haasteiden ratkaisemiseen käytettiin erilaisia ​​työkaluja. Eri testijuoksijat ja väitekirjastot, tilanhallintaratkaisut tai niiden puuttuminen, jQuery vs natiiviselaimen valitsimet, SASS vs LESS, karttakirjastot jne.

4. Kehittäjien tuottavuus

Koska jokaisella tiimillä oli oma ratkaisunsa sovellusten kehittämiseen, testaamiseen ja rakentamiseen, kehitysympäristö oli usein täynnä vikoja, manuaalisia vaiheita ja tehottomuutta.

Lisäksi monet tiimimme työskentelevät 10 tunnin erolla erotetuissa paikoissa (Helsinki, Suomi ja San Francisco), mikä tekee tehokkaasta päätöksenteosta jaettujen kappaleiden suhteen todellisen haasteen.

Uusi

Tärkeimmät painopistealueemme olivat:

  1. Kannusta ja säilytä ketterät työskentelytavat tiimeissämme ja anna joukkueiden olla suurelta osin riippumattomia toisistaan
  2. Hyödynnä ja kehitä mahdollisimman paljon yhteisiä työkaluja ja käytäntöjä, dokumentoi ne ja tee niistä helposti saatavissa ja käyttökelpoisia

Uskoimme, että näiden tavoitteiden saavuttaminen parantaisi merkittävästi aikaa markkinoida ja kehittäjien tuottavuutta. Tätä varten tarvitsimme ratkaisun, joka:

  • Rakenna tuoteominaisuuksia paremmalla käyttökokemuksella
  • Paranna koodin laatua
  • Salli parempi yhteistyö estämättä kenenkään työn etenemistä prosessissa.

Halusimme myös kannustaa ja siirtyä nykyaikaiseen tekniikkapinoon, jotta kehittäjämme olisivat tyytyväisempiä työhönsä ja siirtyisivät ajan myötä vanhentuneisiin kehyksiin ja työkaluihin.

Työmme jatkuvasti kehittyvä tulos on React-pohjainen SPA, joka on rakennettu monosäilöön, jossa kaikki sivut ja isommat ominaisuudet rakennetaan suurimmaksi osaksi itsenäisiksi koodipaketeiksi, jotka ladataan tarpeen mukaan ja joita useita tiimejä voidaan kehittää ja käyttää samanaikaisesti .

Keinona kaikkien vanhojen sovellusten hiekkalaatikkoon asettaminen, mutta silti niiden näyttäminen saman uuden sovelluksen yhteydessä, lataamme ne iframe-kehykseen, josta he voivat kommunikoida pää SPA: n kanssa postMessage()sovellusliittymän avulla toteutetulla viestiväylällä .

Monorakennus

Tässä on hakemistorakenne, jonka kanssa aloitimme:

/src /components /scenes /foo /components package.json foo.js /bar /components package.json bar.js package.json index.js

package.jsonJuurihakemistoon sisältää joukon devDependencies vastaavan kehitys-, testaus ja rakennetun ympäristön koko sovelluksen, mutta sisältää myös dependenciesytimen sovelluksen (enemmän, että vähän myöhemmin).

Kaikkia suurempia käyttöliittymäpalasia kutsutaan kohtauksiksi . Jokainen kohtaus sisältää paikan,package.json jossa dependencieskyseisen kohtauksen komponentit on määritelty. Tämä tekee mahdolliseksi kaksi asiaa:

  1. Käyttöönotto päivittää vain muuttuneet tiedostot

    Koontivaihe kokoaa erilliset toimittaja- ja sovelluspaketit jokaiselle kohtaukselle ja nimeää kukin hashilla, joka muuttuu vasta, kun tiedoston sisältö on muuttunut. Tämä tarkoittaa, että käyttäjät lataavat vain tiedostoja, jotka ovat muuttuneet edellisen vierailunsa jälkeen, eikä mitään muuta.

  2. Kohtaukset ladataan vain tarvittaessa

    Ladataan kaikki kohtaukset asynkronisesti ja tarvittaessa, mikä parantaa huomattavasti koko sovelluksen latausaikoja. "On demand" tarkoittaa tässä yleensä tietyn reitin vierailua tai käyttöliittymän toimintaa, joka suorittaa moduulien dynaamisen tuonnin.

Näin asennus näyttää käytännössä (yksinkertaistettu luettavuuden vuoksi):

// In src/routes.jsconst FooLoader = AsyncLoadComponent( () => import(‘src/scenes/foo/foo’), GenericPagePreloader,);
// In src/scenes/foo/foo.js 

Se AsyncLoadComponenton ohut kääre React.lazy(), joka hyväksyy lisäksi esikuormaajakomponentin, sama kulkee varavoiman läpi React.Suspense()ja viive, jonka jälkeen esikuormaaja tulisi renderöidä, jos kohtaus ei ole vielä latautunut loppuun.

Tämä on hyödyllistä, kun varmistamme, että käyttäjät näkevät saman esilataimen ilman keskeytyksiä tai sisällön välähdystä siitä hetkestä, kun kohtaus pyydetään, siihen hetkeen, kun kaikki sen tiedostot on ladattu, kaikki kriittiset API-pyynnöt on suoritettu ja komponentti on lopettanut renderoinnin.

Komponenttitasot

Kunkin sovelluksen kasvaessa sen hakemistorakenne ja abstraktit kehittyvät sen mukana. Noin puoli vuotta kestäneen rakentamisen ja ominaisuuksien siirtämisen uuteen koodikantaan yhden komponentin hakemiston osoittaminen osoittautui riittämättömäksi.

Tarvitsimme hakemistorakenteen ilmoittaaksemme meille:

  • Onko komponentit kehitetty yleisiksi vai onko ne tarkoitettu vain tiettyyn käyttötarkoitukseen?
  • Ovatko ne riittävän yleisiä käytettäväksi kaikissa sovelluksissa vai pitäisikö niitä käyttää vain tietyissä yhteyksissä?
  • Kuka on vastuussa koodista ja tietää siitä eniten?

Sen perusteella olemme määrittäneet seuraavat komponenttitasot :

1. Sovelluskohtainen (src / app)

Kertakäyttöiset komponentit, jotka soveltuvat tämän sovelluksen erityisiin käyttötapauksiin ja joita ei ole tarkoitettu käytettäväksi uudelleen tai purettaviksi komponenttikirjastoon (reitit, alatunniste, sivun otsikko jne.).

2. Yleinen (src / komponentit)

Yleiset monikäyttöiset komponentit, joita käytetään kaikkialla sovelluksessa ja sen kohtauksissa. Kun olemme saavuttaneet vakaan API: n näille komponenteille, ne voidaan siirtää yhteiseen komponenttikirjastoon (lisätietoja alla)

3. Yhden kohtauksen komponentit (src / kohtaukset / oma kohtaukseni / komponentit)

Komponentit, jotka on kehitetty tietyn käyttötapauksen kannalta; ei ole tarkoitettu käytettäväksi missään muussa kohtauksessa. Tapauksissa, joissa yhden kohtauksen komponenttia on käytettävä toisessa, käytämme:

4. Usean kohtauksen komponentit (src / kohtaukset / komponentit / oma ominaisuus)

Komponentit, joita käytetään useissa kohtauksissa, mutta joiden ei ole tarkoitus olla riittävän yleisiä käytettäväksi missään muualla. Havainnollistaaksesi, miksi yksinkertainen siirtäminen heidän luokseen src/componentsei ole tarpeeksi hyvä:

Kuvittele, että sinulla on toistaiseksi ollut yksi kohtaus, joka sisälsi komponentteja, joiden avulla rakennettiin melko spesifisiä tietokaavioita. Tiimisi rakentaa nyt toisen kohtauksen, joka käyttää erilaisia ​​tietoja kaavioissa, mutta visuaalisesti nämä kaksi näyttävät melkein samoilta.

Komponenttien tuominen yhdestä kohtauksesta toiseen rikkoo kohtauksen kapseloinnin ja tarkoittaisi, että emme voi enää olla varmoja siitä, vaikuttavatko yksittäisen kohtauksen osiin tehdyt muutokset vain kyseiseen kohtaukseen.

Tätä tarkoitusta varten kaikki komponentit tai komponenttiryhmät, joihin karkeasti viitataan ominaisuutena, sijoitettaisiin src/scenes/componentssieltä, mihin muut tiimit voivat tuoda ja käyttää niitä:

Aina kun joukkue haluaa alkaa käyttää toisen ryhmän kehittämiä kohtauskomponentteja, paras käytäntö olisi ensin ottaa yhteyttä kyseiseen joukkueeseen selvittääkseen, voidaanko käyttötapausta, johon aiot käyttää näitä komponentteja, turvallisesti tukea tulevaisuudessa. Tunnustaminen tiimille, joka alun perin kehitti koodin, estää rikkoutuneiden ominaisuuksien lähettämisen tulevaisuudessa, kun käyttöön ottamasi koodi väistämättä muuttuu tavoilla, joita et odottanut (tietysti, miten voisit!), Ja joita yksikötestit eivät välttämättä aina tartu.

5. Yhteinen kirjasto

Komponentit, jotka olemme testanneet tuotannossa ja jotka haluamme purkaa jaettuun komponenttikirjastoon, jota muut Unityn hallintapaneelitiimit käyttävät.

Ode jaetuille riippuvuuksille

Vaikka olisi erittäin kätevää pystyä rakentamaan ja ottamaan käyttöön kaikki sovelluksemme osat täysin eristetyssä ympäristössä, tiettyjä riippuvuuksia - sekä ulkoisia kirjastoja että sisäisiä sovelluskoodeja - käytetään yksinkertaisesti kaikkialla koodipohjassa. Sellaisia ​​asioita kuin itse React, Redux ja kaikki Reduxiin liittyvät logiikat, tavalliset navigointikomponentit jne.

Muutosten käyttöönotto

Tällä hetkellä kohtausten täydellinen kapselointi ei ole käytännöllistä ja monissa tapauksissa yksinkertaisesti mahdotonta. Se vie joko monien riippuvuuksien lähettämisen useita kertoja ja prosessin aikana hidastaa sivujen latautumista tai rakentaa abstrakteja, joiden tarkoituksena on saada tietyt kirjastot toimimaan sellaisilla alueilla, joihin niitä ei ole vielä suunniteltu.

Kun verkkokehitys ja sen ekosysteemi kehittyvät, kirjastot näyttävät kuitenkin yhä itsenäisemmiksi ja kapseloiduiksi, mikä toivomme tulevaisuudessa tarkoittavan vain vähän tai ei lainkaan yhteisiä riippuvuuksia ja todellista eristäytymistä kaikkien moduulien välillä.

Ehkä suurin haittapuoli suurten sovellusten laatimisessa on koodimuutosten ja riippuvuuspäivitysten tekeminen rikkomatta jotain prosessissa

Monivaraston käyttö mahdollistaa koodin muutosten ja päivitysten käyttöönoton (vaikkakaan ei pakollista) asteittaisemmalla ja turvallisemmalla tavalla - jos muutos aiheuttaa ongelmia, nämä ongelmat vaikuttavat vain pieneen osaan sovellusta, eivät koko järjestelmään.

Ja vaikka joillekin kyky suorittaa päivityksiä useille toisistaan ​​riippumattomille koodipohjan alueille samanaikaisesti hyötyisi, tosiasia, että useat tiimit työskentelevät samalla koodipohjalla ja eivät tunne kaikkia muiden joukkueiden ominaisuuksia, tarkkaan tarkoittaa, että Suuri varovaisuus on tarpeen rakennustelineiden rakentamisessa ja murtumisriskin minimoimiseksi.

Kuinka välttää rikkomasta asioita

Ehkä kaikkein perustavanlaatuisin strategia, joka auttaa meitä siinä, lukuun ottamatta kohtauksen eristämistä, on korkea yksikkötesti .

  1. Testaus

Yksikkötestit eivät tietenkään ole kaikki - monet kypsät tuotteet jopa kohtuullisessa mittakaavassa investoivat loppujen lopuksi integraatio- ja e2e-testeihin, jotka tekevät parempaa työtä sen varmistamiseksi, toimiiko sovellus yleisesti odotetusti. Ominaisuuksien määrän kasvaessa kasvaa kuitenkin myös ylläpitokustannukset ja niiden suorittamiseen tarvittava aika - kustannukset, joita ei aina voida perustella vähemmän tärkeillä mutta silti tärkeillä ominaisuuksilla.

Joitakin kokemuksia olemme oppineet erilaisista testausstrategioista:

  • Yritä testata mahdollisimman suuri osa koodista, erityisesti: ehdollinen logiikka, tiedonmuunnokset ja toimintokutsu
  • Investoi integraatiotesteihin ja hyödynnä niitä täysimääräisesti ennen kuin päätät kirjoittaa e2e-testejä. Integraatiotestien alkukustannukset ovat paljon korkeammat, mutta ne menevät hukkaan verrattuna e2e-paketin ylläpitohintaan
  • Yritä olla reagoimatta liikaa aloittamalla e2e-testien kirjoittaminen asioille, joita yksikön tai integraatiotestit eivät ole löytäneet. Joskus prosessit tai työkalut ovat vikoja
  • Anna testitapausten selittää käyttöliittymän käyttäytymistä toteutustietojen sijaan
  • Automaattiset testit eivät voi täysin korvata manuaalista testausta

2. Minimoi jaetun koodin pinta

Testauksen lisäksi koko sovelluksessa uudelleen käytetty koodi pidetään kohtuullisessa minimissä. Yksi tähän mennessä hyödyllisimmistä strategioista on ollut siirtää yleisimmin käytetyt komponentit ja koodi jaettuun komponenttikirjastoon, josta niitä käytetään riippuvuuksina niitä tarvitsevissa kohtauksissa. Tämän ansiosta voimme ottaa suurimman osan muutoksista käyttöön asteittain tiimikohtaisesti tai sivukohtaisesti.

3. Vastuu

Viimeisenä mutta ei vähäisimpänä, valtava tekijä, että useat tiimit pystyvät tekemään yhteistyötä saman koodipohjan sisällä, johtuu kannustamisesta ja kehittäjien ottamisesta henkilökohtaiseen vastuuseen ja vastuuseen tuotteesta sen sijaan, että vastuun testaaminen siitä, että kaikki toimii, on laadunvalvonnalle, testaajille tai muille automaatio.

Tämä siirtää myös koodiarvostelut. Kunkin muutoksen huolellisen tarkistamisen varmistaminen on vaikeampi kuin se saattaa tuntua pinnalta. Kun tiimi tekee tiivistä yhteistyötä, sen jäsenten keskuudessa syntyy terveellistä luottamusta. Tämä luottamus voi kuitenkin joskus johtaa siihen, että ihmiset ovat vähemmän ahkeria kokeneempien tai muuten luotettavien kehittäjien tekemien muutosten suhteen.

Huolellisuuden rohkaisemiseksi korostamme, että PR: n kirjoittaja ja arvostelija ovat yhtä vastuussa siitä, että kaikki toimii .

Komponenttikirjasto

Saavuttaaksemme saman ilmeen ja tuntuman hallintapaneelien kaikilla sivuilla olemme kehittäneet komponenttikirjaston. Lähestymistavassamme on, että uusia komponentteja ei melkein koskaan kehitetä kyseisessä kirjastossa.

Jokainen komponentti, sen jälkeen kun se on kehitetty kojelautaan. Yleensä muutaman viikon kuluttua olemme varmempia siitä, että komponentti voidaan siirtää, kun otetaan huomioon, että:

  • API on riittävän joustava tukemaan ennakoitavia käyttötapauksia
  • Komponenttia on testattu erilaisissa yhteyksissä
  • Suorituskyky, reagointikyky ja käyttömukavuus otetaan huomioon

Tämä prosessi noudattaa kolmen säännön sääntöjä ja pyrkii auttamaan meitä vapauttamaan vain komponentteja, jotka ovat todella uudelleenkäytettäviä ja jotka on otettu käyttöön useissa yhteyksissä ennen siirtämistä yhteiseen kirjastoon.

Joitakin esimerkkejä komponenteista, joihin siirrymme, sisältäisivät alatunnisteen, sivun ylätunnisteen, sivun ja yläosan navigointielementit, asettelun rakennuspalikat, bannerit, painikkeiden käynnistetyt versiot, typografiaelementit jne.

Alkuvuosina komponenttikirjasto sijaitsi aiemmin samassa kooditukissa kuin itse sovellus. Olemme sen jälkeen purkaneet sen erilliseen arkistoon, jotta kehitysprosessi olisi demokratisoitunut muiden Unityn joukkueiden kannalta - tärkeää kun ajatellaan sen hyväksymistä.

Modulaarinen komponenttisuunnittelu

Pisin aikaa uudelleenkäytettävien komponenttien rakentaminen tarkoitti useita haasteita, joista monilla ei usein ollut hyviä ratkaisuja:

  • Kuinka tuoda komponentti helposti sen tyylien kanssa, ja vain se
  • Oletustyylien ohittaminen ilman valintakohtaisia ​​sotia
  • Kuinka suuremmissa komponenteissa, jotka koostuvat useista pienemmistä, miten pienemmän komponentin muotoilu ohitetaan?

Kojelautamme ja komponenttikirjastomme riippuvat suuresti materiaalikäyttöliittymästä ja käyttävät sitä. Ainutlaatuisen pakottavaa Material UI: n muotoiluratkaisussa on JSS: n ja heidän yhtenäisen muotoilukielensä (lukemisen arvoinen) tuomat mahdollisuudet, jotka mahdollistavat suunnittelun kapseloimien käyttöliittymien kehittämisen kuten CSS-moduulien tapauksessa, ja ratkaisemaan yllä mainitut asioita hitaasti.

Tämä eroaa merkittävästi BEM: n kaltaisista lähestymistavoista, jotka tarjoavat kapseloinnin tavan mukaan, jotka ovat yleensä vähemmän laajennettavissa ja vähemmän kapseloituja.

Elävä tyylinohjain

Komponenttikirjasto ei olisi täydellinen ilman tapaa esitellä sen sisältämiä komponentteja ja kykyä nähdä komponentit niiden muuttuessa julkaisujen ajan.

Meillä on ollut melko hyvä kokemus Storybookista, joka oli naurettavan helppo asentaa ja aloittaa, mutta jonkin ajan kuluttua tajusimme, että tarvitaan vankempi ja kattava ratkaisu. Melko lähellä Styleguidistin tarjoamia, mutta räätälöityjä tarpeisiimme.

Olemassa olevat suunnitteludokumentit

Viimeisimmän suunnitteluspesifikaation pääasiallisena tietolähteenä toimiva dokumentaatio sijaitsi Confluencessa, jossa suunnittelijat pitivät jokaisen komponentin ajan tasalla olevaa eritelmää käyttämällä kuvakaappauksia, jotka kuvaavat sallittuja käyttötapauksia, tiloja ja muunnelmia, joissa komponentti voi olla, lueteltuina parhaat käytännöt sekä yksityiskohdat, kuten mitat, käytetyt värit jne. Tämän lähestymistavan mukaisesti olemme kohdanneet useita haasteita:

  • Materiaalisuunnittelun spesifikaatiot kehittyvät jatkuvasti, ja siksi olemme usein huomanneet, että olemme joko viettäneet aikaa kaikkien kuvakaappausten ja ohjeiden päivittämiseen tai antaneet suunnitteluohjeidemme vanhentua
  • Oikeimman selvittäminen: toteutus tai määrittely ei aina ollut helppo tehtävä. Koska olemme julkaisseet Storybook-demoja jokaisesta komponentista ja jokaisesta kirjastoversiosta, voimme nähdä, mitä ja miten muuttui. Emme voineet tehdä samaa suunnitteluprosessille.
  • Kuvakaappaukset ja videot voivat kommunikoida vain niin paljon . Jos haluat tarjota korkealaatuisia komponentteja, joita useat tiimit voivat käyttää, on tarkistettava, toimivatko kaikki komponentit kaikilla resoluutioilla, ovatko virhetön ja hyvä UX - tämä oli vaikeaa ilman, että suunnittelija istui kirjaimellisesti vieressäsi nähdäksesi toteutusdemo näytetään ruudulla

Komponenttien dokumentaatio -sovellus

Dokumentointisovelluksemme tarkoituksena on tarjota keinot suunnittelijoiden ja insinöörien väliseen tehokkaaseen yhteistyöhön, jotta komponenttien dokumentointi, tarkastelu ja kehittäminen olisi molemmille osapuolille yksinkertaisempaa ja vähemmän aikaa vievää. Tarkemmin sanottuna meidän piti:

  • Pyydä yhtä vertailupistettä esittelemään komponentit , mitenPitäisikö heidän näyttää, käyttäytyä ja käyttää - jokaisessa julkaisussa - korvaamalla yksityiskohtaiset kuvaukset live-esittelyillä
  • Tee suunnittelijoiden ja kehittäjien kanssa yhtä helppoa tehdä yhteistyötä komponenttien ja heidän asiakirjojensa kanssa ja tehdä se ennen komponenttien julkaisua ilman, että sinun tarvitsee jakaa videoita, kuvakaappauksia tai olla fyysisesti samassa paikassa
  • Erota mallit siihen, mitä aiomme tehdä verrattuna siihen, mitä on tehty

Samoin kuin aikaisemmin, jokainen komponenttikirjaston julkaisu aiheuttaa uuden version elävästä tyylinohjaimesta. Tällä kertaa on kuitenkin muutamia eroja:

  1. Suunnittelijat osallistuvat komponenttien dokumentointiin muokkaamalla dokumentaatiotiedostoja Github-käyttöliittymän kautta tekemällä muutoksia uusimpaan julkaisuun.
  2. Komponenttidemot WYSIWYG-muodossa - samaa koodia, jonka näet esimerkkinä komponentin toteuttamisesta, käytetään esityksen renderointiin, mukaan lukien mahdolliset välitiedostojen tuonnit, muuttujailmoitukset jne. Lisäbonuksena pakatut komponentit withStyles()näytetään oikein (ongelma läsnä Storybookissa tällä hetkellä).
  3. Asiakirjoihin ja koodiin tehdyt muutokset ovat melkein heti näkyvissä tarkistamatta haaraa paikallisesti ja käynnistämättä dokumentointisovellusta - sovellus rakennetaan uudelleen ja julkaistaan ​​jokaisessa sitoutumisessa.

Kehityskokemus

Yksi kooditarkastusten päätavoitteista on varmistaa, että jokainen muutos tarkistetaan huolellisesti, otetaan huomioon ja testataan ennen yhdistämistä ja käyttöönottoa.

Tehdäksemme tämän tehtävän mahdollisimman esteettömäksi olemme kehittäneet esikatselupalvelimen, joka pystyy luomaan sovelluksemme uuden version aina, kun PR luodaan tai päivitetään.

Suunnittelijamme, tuotepäälliköt ja insinöörit voivat testata jokaisen muutoksen ennen yhdistämistä sekä lavastus- että tuotantoympäristöissä ja muutamassa minuutissa muutoksen tekemisestä.

Viimeiset sanat

On kulunut melkein vuosi siitä, kun olemme sitoutuneet koontamaan kojelautamme. Olemme viettäneet tuon ajan oppimalla kuinka kasvattaa suurta mutta terveellistä ohjelmistoprojektia, kuinka parantaa yhteistyötä ja viestintää ja kuinka nostaa laatupalkki itsellemme.

Mittasimme käyttöliittymän projektin paitsi koodiriveillä myös sen koodipohjassa työskentelevien insinöörien lukumäärällä - määrä, joka nelinkertaistui alusta alkaen.

Teimme 180 asteen muutoksen käsitellessämme joukkueidemme aikaeroja siirtymällä mallista, jossa tiimimme työskentelivät täysin erillään, malliin, jossa tiivis yhteistyö ja viestintä ovat arkipäivää.

Vaikka edessämme on vielä pitkä tie, jotta voimme laajentaa lähestymistapamme useampiin joukkueisiin ja suurempiin haasteisiin, olemme huomanneet jo useita parannuksia:

  • Etenemissuunnitelma ja työn näkyvyys

    Koska kaikki työt ovat yhdessä paikassa, edistymistä seurataan ja kaikki asiat kootaan yhteen

  • Kehityksen nopeus ja markkinoille tulon aika

    Uusia ominaisuuksia voidaan luoda suurelta osin jo olemassa olevista ja hyvin testatuista komponenteista - ne löytyvät helposti dokumentointisovelluksestamme

  • Koodin laatu ja testialue

    Uusia asioita rakennettaessa ratkaisu samankaltaiseen ongelmaan on yleensä jo olemassa ja se on käden ulottuvilla sekä esimerkkejä sen testaamisesta.

  • Kokonaislaatu ja UX

    Ominaisuuksien testaaminen ja laadun varmistaminen on nyt helpompaa kuin koskaan, koska suunnittelijat, tuotepäälliköt ja muut sidosryhmät voivat testata jokaisen muutoksen omalla koneellaan, omilla tileillään ja tietojoukoillaan

Tietysti matkan varrella olemme kohdanneet useita haasteita, jotka meidän on ratkaistava tai jotka on ratkaistava tulevaisuudessa:

  • Rakenna ja CI: n suorituskyky

    Kun riippuvuuksien, koontikokonaisuuksien ja testien määrä kasvaa, samoin kuin käyttöönoton suorittamiseen tarvittava aika. Tulevaisuudessa meidän on kehitettävä työkaluja, jotka auttavat meitä vain rakentamaan, testaamaan ja ottamaan käyttöön muuttuvia kappaleita.

  • Kehityskulttuuri

    Terveiden ohjelmistojen rakentamiseksi meidän on jatkuvasti kehitettävä terveellisiä tapoja kommunikoida ja vaihtaa ideoita, ja tekstipohjainen viestintä vaikeuttaa tätä tehtävää. Työskentelemme tämän ongelman ratkaisemiseksi säännöllisten johtajien koulutustilaisuuksien avulla ja omaksumalla avoimemman lähdekoodin työskentelytavat sekä järjestämällä muutama kokoontumisistunto vuodessa, jotta joukkueet voivat tavata toisensa kasvokkain.

  • Rikkoutumisen eristäminen ja päivitykset

    Kun ominaisuuksien ja sivujen määrä kasvaa, tarvitsemme vankemman tavan eristää sovellusmoduulimme, jotta vahingot eivät leviä, kun asiat menevät pieleen. Tämä voidaan saavuttaa versiolla kaikki jaetut koodit (redux logic, src / components) tai äärimmäisissä tapauksissa tuottamalla itsenäisiä tiettyjen ominaisuuksien rakennelmia.

Ilmoita sitten, nyt ja tulevaisuudessa

Siirtyminen on merkinnyt siirtymistä AngularJS: stä Reactiin. Näin tilanne muuttui kuluneen vuoden aikana:

Se on siinä! Kiitos, että luit! Löydät minut LinkedInistä täältä.

Jos samanlaisten haasteiden parissa työskentely kuulostaa mielenkiintoiselta, etsimme aina lahjakkaita insinöörejä joukkueihimme ympäri maailmaa.