Kuidas luua oma reaalajas meeskond?

Otsustasite minna koos React Native'iga. Mis nüüd?

Hiljuti olen rääkinud mõne kasvava ettevõttega, kes on loonud React Native rakenduse või plaanivad selle loomist. Nad tahavad välja mõelda, kuidas meeskond kokku panna ja kuhu pärast seda minna. Olles viimasel töökohal olnud React Native juhtiv arendaja, soovin jagada oma mõtteid mõningatest tehnilistest ja korralduslikest asjadest, mis selle vastuvõtmisega kaasnevad. See artikkel on mõeldud alustava ettevõtte asutajale või CTO-le, kes on juba otsustanud React Native'i kasuks. Puudutan 1) eeliseid ja puudusi, 2) kuidas moodustada teie meeskond ja 3) kuidas oma projektiga edasi minna.

1. React Native eeliste ja puuduste mõistmine

Mõne neist punktidest on surmaga räägitud, kuid neid on hea meeles pidada, kui teete oma ettevõtte jaoks otsuseid.

Ettevõtted kasutavad rakendust React Native rakenduste kiiremaks loomiseks:

  • Ainuüksi React on kasutajaliideste loomisel suur paradigma muutus. Muinasaja ajal pidid arendajad kohmakalt malle kontrolleritega siduma ja tingimata muutma ekraani elemente. React võimaldab teil UI luua deklaratiivselt oma rakenduse oleku esitusena. See kõlas tõenäoliselt kogu tehniliselt, kuid see tähendab lihtsalt seda, et kui rakenduse olek muutub, joonistab React automaatselt kasutajaliidese ümber, sest see on 2018. aasta.
  • Iteratsioonid arenduse ajal on kiiremad. Noor päevil pidid arendajad muudatuste nägemiseks rakenduse uuesti üles ehitama. Rakenduses React Native on teil kuummooduli uuesti laadimine, mis võimaldab teil rakendust selle töötavaks muuta. Veelgi parem, kui kasutate rakendust Storybook, saate luua kasutajaliidese komponente isoleeritult. Enam ei pea te 3 ekraanil navigeerima, et näha, kas olete mõnda nuppu vajutanud.
  • Saate kasutada olemasolevat Javascripti koodi ja veebiarenduse meeskonda. Teil ei pea olema spetsialiseerunud mobiiliarendajate meeskonda. Sõlmes saab luua ja testida palju UI-väliseid koode, ilma et peaksite rakendust käivitama.
  • Javascript on keel, mis on nii halb, et see on hea. Kuna Javascript imetas nii palju, sai transpilatsioon kaasaegse Javascripti arengu põhiosa. See tähendab, et arendajad saavad tänapäevaseid keelefunktsioone kiiremini kui teised keeled.

Kuid React Native'iga koos käimine on kompromiss. Need on puudused, mida ma olen kogenud:

  • React Native pole nii hästi toetatud kui natiivsed iOS ja Android. Nendel platvormidel on ettevõtteid, kelle äri toetab nende platvorme. React Native on peamiselt sisemine Facebooki arendustööriist, mis juhtub avatud hankimisel. Facebook ei pühenda sellele platvormile nii palju ressursse kui Apple ja Google. Seetõttu peate pidevalt jahti pidama. Suur osa minu teadmistest RN-i kohta pärineb blogipostitustest, Githubi väljaannetest, säutsudest ja konverentsidel vestlustest.
  • Samal ajal areneb React Native väga kiiresti. Kuuväljaannetes on sageli olulisi muudatusi ja kui need ei riku teie rakendust, võivad nad purustada teie sõltuva tööriista või teegi. React Native'i versiooniuuendus on natuke valus. Võite iOS-i või Androidi rakenduse arendamise kuue kuu jooksul unarusse jätta ja see poleks vananenud. See ei kehti React Native'i puhul.
  • Kui teil on mobiilimeeskond, on React Native'i tutvustamine kultuuriline muutus. On palju põliselanike arendajaid, kes Javascripti üldse ei huvita, ja teie meeskonnas võib olla mõni (ma vaatan teid, iOS-i arendaja, kes arvab, et Objective-C / Swift on jumalate nektar).

Kui teil on juba mõlemale platvormile ehitatud rakendused ja olemasolev arendusmeeskond selle toetamiseks, pole React Native tõenäoliselt teie jaoks. Seda võime õppida AirBnB-lt. Kuna seal peetakse üheks austatumaks insenerimeeskonnaks, panustavad nad React Native'is juba varakult, kuid pidid loobuma pingutusest nn pruunivälja arendamise tehniliste ja kultuuriliste raskuste tõttu. Leland Richardson (@intelligibabble) räägib React Native'ist siinsel pruuniväljal. Gabriel Peal (@ gpeal8) kirjutab siin React Native päikeseloojangust.

Mõni olemasolevate rakendustega ettevõte otsustab siiski luua ühe loomuliku, ühe rakenduse React Native. Kui olete juba iOS-i rakenduse käivitanud ja soovite luua selle jaoks Androidi, minge koos React Native'iga. Kuid see valik sõltub teie arenguvajadustest. Erica Cooksey (@EricaCooksey) räägib suurepäraselt Androidi loomuliku arenduse valimisest, kui kasutate React Native'i iOS-is.

2. Oma meeskonna moodustamine

Alustan kellegagi, kes tuleb React Native'i sisse arendaja loomuliku taustaga. React Native meelitab palju veebiarendajaid, kes soovivad rakendusi luua. Kuid React Native ei asenda looduslikku arengut, vaid muudab asja tegelikult keerukamaks, kuna peate olema reaalajas reaalajas, iOS ja Android. Teie rakenduse arendamine puutub loomulikus kihis kokku paljude tõketega, nii et on hea alustada kellegagi, kellel on kindel alus.

Ideaalses maailmas soovite, et teie meeskonnas oleks iOS-i ekspert ja Androidi-ekspert. Kui saate endale lubada ainult ühte omamaist arendajat, minge Androidile. IOS-is on reaalajas reaalajas lihtsam hallata kui Androidis. iOS pole nii killustatud ja enamik tehnoloogiaga seotud inimesi (USA-s) on iPhone'i kasutajad. Need kaks tegurit tähendavad, et iOS React Native arendamine saab palju rohkem tähelepanu ja on stabiilsem. Android annab teile probleeme ja soovite, et keegi, kes sellest platvormist aru saaks.

iOS vs Androidi killustatus, september 2018

Pärast oma React Native pliiarendaja palkamist peaksite palkama veel kaks inimest, kellel on Reaktis mugav. Neil ei pea olema omamaist mobiilikogemust ja neil ei pea olema konkreetset vanemustaset. Kuid palgake kindlasti inimesed, kellel on mõte mobiilirakenduse ehitamisest - ärge kaasake skeptilisi veebiarendajaid. React Native arendaja kogemus pole nii tore kui veebi jaoks ja nad kaotavad oma mugavused kiiresti.

Arvan, et kolmest pühendunud arendajast koosnevast meeskonnast peaks piisama, kuid ilmselt sõltub see teie ettevõtte kasvustaadiumist. Teie juhtiv arendaja veedab tõenäoliselt poole oma ajast funktsioonide kirjutamiseks ja poole oma ajast projekti säilitamiseks ja teiste arendajate toetamiseks.

Lisaks tahaksin palgata veebispetsiifiliste disainerite kaasamise asemel kindlasti disainerit, kes mõistab mobiilirakendusi. Pole tähtis, kui hea on teie arendusmeeskond, kui teie kasutajatel on rakendust keeruline kasutada. Rakendusel peaks olema väga erinev UX kui teie veebirakenduse mobiilisuuruses versioonil. Te ei soovi, et sellel oleks pisikese ekraani kerimisvaate sees 10 sisestusvälja. On oluline, et teil oleks disainer, kes sellest aru saaks. React Native võimaldab teil hõlpsasti ka žestide ja animatsioonidega uuenduslikke asju teha, nii et hankige disainer, kes soovib seda kasutada.

Vältige oma arendajate mullis hoidmist. Soovitan saata nad vähemalt ühele konverentsile aastas. See on tõesti hea viis olla kursis ja luua suhteid teadlike inimestega. Teie seadmed tulevad tagasi tööle koos hulga uute teadmiste, tehnikate ja siseringiteabega, mida nad soovivad tööl rakendada. Ma pole kindel, miks enamik ettevõtteid paneb vastutuse kasvatamise eest arendajatele, kuid kui olete isekas ja soovite parimat meeskonda, investeerige nende kasvu.

3. Teie projekti juhtimine

Kasutage olemasolevaid Javascripti ja veebiarendajaid.

Kui olete oma projekti ja meeskonna üles seadnud, võite hakata kasutama olemasolevat veebikoodidebaasi ja veebiarenduse meeskonda. Kui teil on autori ja API kliendikood juba veebi jaoks kirjutatud, jagage see oma projektiks, nii et saate seda oma rakendusega kasutada. Teie veebimeeskonna arendajad loovad põnevusega funktsioone mobiilseadmete jaoks, kuid nad saavad muret ehitamise probleemide või loodusliku kihi vigade pärast. Laske oma RN juhtl kirjutada tõeliselt häid juhendeid ja tegutseda loodusliku kihi tehnilise toena.

Seadistage TypesScript.

Olen ECMAScripti trükkimise fänn olnud juba alates ActionScript 3 päevast (dem good ol 'päevad), kuid seisin TypeScripti vastu pikka aega, kuna see tundus pisut valus ja ebastabiilne. See on muutunud. Ühendus on arveldada masinakirjas kui kirjutades Standard: Babel 7 on esimese klassi masinakirjas toetust, ja reageerima Native 57 laevade masinakirjas (peksmise läbi ̶F̶a̶c̶e̶b̶o̶o̶k̶'̶s̶ enda voolu) ̶ (Lorenzo Sciandra - @Kelset üks Lasta Native avatud allika hooldajad, täpsustab, et React Native saatmine TypeScripti toega ei tähenda selle kinnitamist, see tähendab lihtsalt seda, et Flow ja TS on mõlemad võrdselt hõlpsasti integreeritavad. Tänud Lorenzo!) Ma tean, et seal on Javascripti puristid, kuid kahe aasta pärast tõenäoliselt on imelik kodeerida ilma TypeScriptita. Ja tüüpide omamine on nagunii hea. Tüüpidesse ja ühiktestidesse investeerimine säästab teid hiljem vältimatust reageerimisest. See Microsofti artikkel näitab teile, kuidas seadistada TypeScripti rakenduses React Native.

Ehitage projekteerimissüsteem.

Kui soovite minna naeruväärsel kiirusel, looge oma rakendusele kujundussüsteem. Kujundussüsteem on korduvkasutatavate komponentide kogum, mis järgib selgeid juhiseid. See on arendajate ja disainerite koostöö ühise UX-keele loomisel ning aitab luua ühtset kasutajakogemust.

Kujundussüsteem on arenduskiiruse jaoks oluline, kuna see hoiab disainereid ja arendajaid samal lehel (). Mõnikord ehitavad disainerid ekraani kõigepealt, mitte esimese komponendi. Kui disainerid keskenduvad tervetele ekraanidele, võib esineda erinevusi vahede, fondi suuruse, värvide jms osas. Kui arendajad peavad terved ekraanid nullist üles ehitama, võivad nad detailide suhtes rabeleda (või olla laiskad). Ilma kujundussüsteemita muutub aja jooksul vanu ekraane raske ajakohastada ja teie rakendus kaotab ühetaolisuse.

Selliselt töötavad meeskonnad süüdistavad arendajaid selles, et nad pole piisavalt detailsed. Kui olete detailidest vaeva näinud, tehke tööd oma disainilahenduste keerukuse vähendamiseks. Ekraanide määratlemine komponentide kogudena koos selgelt määratletud juhistega on palju lihtsam. Projekteerimissüsteemi kasutamine viitena lihtsustab teie meeskondade vahelist suhtlust, hoiab kõik ausana ja kiirendab funktsioonide arendamist.

Kui teil on juba olemasolev rakendus, võib teie kujunduse taasloomise kujundussüsteemi käivitamine tunduda liiga palju vaeva. Usaldage mind, lõpetage see, mida teete, ja looge see nüüd. Teil pole aimugi, kui palju aega olete raisanud. Saate hõlpsalt oma kujundussüsteemi visandilt Storybooki abil koodiks võtta. Samantha Bretous (@samanthabretous) peab komponentide komplekti ehitamisest palju juttu.

Aga universaalsed komponendid? Veebis reageerimine ja reaalajas Native on väga sarnased, kuid neil on olulised erinevused (nt `

` vs ``, CSS vs StyleSheet, erinevad platvormi võimalused). Universaalsed komponendid on mõlemal platvormil töötamiseks loodud React komponendid. Kui loote toote mõlemale platvormile, võib teil tekkida kiusatus seda teed minna. Minu sõnul ei ole Reaxi komponendi kaks korda valmistamine valus ja ma pole seda tundnud. Kurtis Kemple (@kurtiskemple) rakendas neid MLS-is töötamise ajal ja tema kogemuste kohta saate lugeda siit.

Seadistage oma ehitamisprotsess.

Soovite, et teie RN-plii looks rakenduse beeta- ja tootmisversioon. Beetaversioon osutab teie tootmisele mittekuuluvale taustaprogrammile ja selles on teie meeskonna jaoks proovimiseks kõige värskemad muudatused. Saate rakenduse Fastlane abil rakenduste poodidesse automaatselt juurutada. Gant Laborde (@GantLaborde) kirjutas selle üles seadmise juhendi. Saate seda veelgi kaugemale viia, kasutades Githubi veebihoosid beetarakenduse automaatseks juurutamiseks alati, kui peaharu muutub, ja vabastades tootmisrakenduse, kui uus väljaanne on sildistatud.

Tootmisvigade haldamiseks on kaks viisi: pärast väljaandmist saate käigultparanduse teha ja kõigepealt saate vältida nende loomist. Ma eelistan viimast, aga sitt teatavasti lööb fänni. Juhul, kui vabastasite oma kasutajatele vea ja peate selle kohe parandama, on CodePush teie sõber. React Native töötab, käivitades Javascripti paketist, mis pakitakse rakendusse. CodePush võimaldab teil uue komplekti otse välja lükata, ilma et peaksite uut versiooni App / Play poodidesse välja laskma. See on piiratud, kuna sellega saab parandada ainult Javascripti vigu. Kui teil on loomulik viga, vajate täielikku väljalaset.

Kui soovite esiteks vältida vigu saatmisel, siis investeerige Detoxi testimiseks otsast lõpuni. Kõige tavalisemad vead, millega ma olen kokku puutunud, on regressioonid. Arendusfunktsioonid saavad enne väljalaskmist kõige rohkem QA-tähelepanu ning mõnikord võivad uute funktsioonide muudatused vanu lõhkuda. Eriti halb on see siis, kui regressioonid jäävad kuude jooksul märkamata. Detoxi rakendamisel oma ehitamisprotsessis võite omada meelerahu ja säästa oma kvaliteedi tagamise meeskonda palju aega. Siin on kiire selgitus ja demo E2E testimise kohta Detoxiga. Siin on palju mahukamat Rotem Mizrachi-Meidani (@rotemmiz) artiklit.

Märkus CodePushi kohta: kui automatiseerisite oma väljaanded FastLane'i abil, võiksite mõnikord CodePushi kaudu vabastamiseks kasutada poolversiooniskeemi. Alaealise versiooni näpunäide võib näidata täielikku väljalaset (teise nimega, teil on muudatusi natiivkoodis) ja plaastri versioonipaus osutada CodePussi väljalasele. Näiteks kui kasutate oma rakenduse versiooni 2.3.1, saab versiooni 2.3.2 sildistamine CodePush-i töötluse, samal ajal kui versiooni `2.4.0` sildistamine rakenduse / Play poodi.

Hoidke oma rakendusest põrgu.

Nagu varem mainisin, areneb RN endiselt väga kiiresti. See on nagu metsik hobune. Võite sellega sõita ja kiiresti minna, kuid kui te pole tähelepanu pööranud, võib see teid jälitada ja maha jätta. Nii et iga kuu, kui ilmub React Native'i uus versioon, peab teie meeskond tegema strateegilise otsuse selle kohta, millal kavatsete versiooniuuenduse teha. Kas täiendamisel on asju, mida vajate? Kas see mõjutab teie kolmanda osapoole sõltuvusi? Kui halvad on murrangulised muudatused ja kuidas tasakaalustada seda oma projekti ajakavaga? Kindlasti on platvormihooldust rohkem kui natiivsetes rakendustes, kuid kiiruse eelis rohkem kui korvab selle.

Loodetavasti leidsite selle artikli kasulikuks, kui otsustate, kuhu React Native'i minna. Kui vajate rohkem nõuandeid, võite kirjutada mulle e-posti aadressil [email protected]