Unity Dashboard - a tanulságok a frontendek, a fejlesztési kultúra és a folyamatok méretezéséhez

A Unitynél a közelmúltban a műszerfalak fejlesztését tűztük ki célul - ez olyan vállalkozás, amely drámai módon megváltoztatta nemcsak a frontend technikai veremünket, hanem a munkánk és az együttműködés módját is.

Bevált módszereket és eszközöket dolgoztunk ki, amelyek elősegítik a frontend architektúra méretezését, nagyszerű felhasználói felületű és teljesítményű termékek gyártását, valamint az új funkciók gyorsabb szállítását.

Ez a cikk összegyűjti ezeket a gyakorlatokat, és célja, hogy minél több indokot szolgáltasson az egyes döntések mögött. De először néhány összefüggés.

Az örökség

A mérnökök számát tekintve az Unity az elmúlt 4 évben több mint négyszeresére növelte létszámát. Mivel a vállalat szervesen és akvizíciók révén is növekedett, termékkínálata is nőtt. Míg az eredetileg a Unity-nél kifejlesztett termékek technikailag és formatervezési nyelven nagyrészt egységesek voltak, az újonnan beszerzett termékek természetesen nem.

Ennek eredményeként több, vizuálisan elkülönülő műszerfalunk volt, amelyek másképp működtek és viselkedtek, és amelyeken nem voltak közös navigációs elemek. Ez gyenge felhasználói élményt és csalódott felhasználókat eredményezett. A szó szoros értelmében a termékeink előtér-helyzete bevételbe került.

A termékeink portfóliójának elemzése után három külön szakaszt hoztunk létre, amelyekre a Unity Dashboard felosztható: Fejlesztés, Működtetés és Beszerzés, amelyek mindegyike különböző üzleti igényeket elégít ki, és különböző ügyfélcsoportok számára készült, így tartalmaznak egymástól nagyban független funkciókészleteket .

Ez az új struktúra és a közös navigációs elemek bevezetése a felhasználók első első problémájának megoldására irányult - hol találják meg a keresett információkat és konfigurációs lehetőségeket, és bár papíron mindez jól nézett ki, az út hogyan messze nem voltak nyilvánvalóak.

Megfontolások

Sok fejlesztőnk nagyon izgatott volt a React-re és annak modernebb technikai veremére való áttérés lehetősége miatt. Mivel ezeket a megoldásokat nagy alkalmazásokban csatában tesztelték, és bevált gyakorlataikat és szokásaikat többnyire kiegyensúlyozták, a dolgok nagyon ígéretesnek tűntek.

Ennek ellenére, amit fejlesztőink tudtak a legjobban, és amibe az aktívan fejlesztett alkalmazásaink többségét írták, az az AngularJS volt. Ha úgy döntünk, hogy mindent egy mozdulattal kezdünk el migrálni, az bekövetkezett eseményekre váró katasztrófa lett volna. Ehelyett arra vállalkoztunk, hogy először sokkal kisebb skálán teszteljük feltételezéseinket.

Talán a leginkább szétválasztott termékcsoport a Monetization irányítópultjai voltak . Ezek a projektek, amelyek végül az Operate műszerfal égisze alá kerülnek, szinte minden lehetséges módon jelentősen különböztek egymástól: alkalmazott technológiák, az UI / UX megközelítése, fejlesztési gyakorlatok, kódolási konvenciók - ön megnevezi.

A helyzet nagyjából így nézett ki:

Némi ötletelés után meghatároztuk azokat a fő területeket, amelyeken meg kell dolgozni, hogy az összes terméket összehozzuk:

1. Egyetlen termék

Szükségünk volt ezekre az irányítópultokra (több alkalmazásra, tartományra és technológiai halmazra osztva):

  • Úgy érzi magát, mint egy termék (nincs teljes oldal átirányítás, amikor a felhasználó az összes alkalmazás oldalain mozog)
  • Legyen következetes megjelenés és érzés
  • Tartalmazza a közös navigációs elemeket, amelyek mindig láthatók és ugyanúgy néznek ki, függetlenül attól, hogy az irányítópult melyik részét látogatja a felhasználó

2. Örökölt támogatás

Míg tiszta palánk volt az új frontend megoldásunk technológiai választásánál, be kellett számolnunk a régi projektekkel, amelyeket be kellett építeni az új rendszerbe. Olyan megoldás, amely nem igényelt nagy visszafogási erőfeszítéseket, és amely nem állította le a funkciók fejlesztését, vagy hónapokig húzódott anélkül, hogy vége lett volna.

3. Gyakorlatok és eszközök

Míg szinte az összes csapat használta az AngularJS-t, különböző eszközöket használtak ugyanazok a kihívások. Különböző tesztfuttatók és állítási könyvtárak, állapotkezelési megoldások vagy azok hiánya, jQuery vs natív böngészőválasztók, SASS vs LESS, könyvtárak ábrázolása stb.

4. Fejlesztői termelékenység

Mivel minden csapatnak megvolt a maga megoldása az alkalmazás fejlesztésére, tesztelésére és felépítésére, a fejlesztői környezetet gyakran tele voltak hibák, kézi lépések és hatékonysághiány.

Ezen túlmenően sok csapatunk 10 órás különbséggel elválasztott helyeken dolgozik (Helsinki, Finnország és San Francisco), ami valódi kihívást jelent a megosztott darabok hatékony döntéshozatalában.

Az új

A főbb területek a következők voltak:

  1. Ösztönözze és őrizze meg agilis munkamódszereinket csapatainkban, és hagyja, hogy a csapatok nagyrészt függetlenek legyenek egymástól
  2. Használja ki és fejlessze a lehető legtöbbször a közös szerszámokat és konvenciókat, dokumentálja azokat, és könnyen hozzáférhetővé és használhatóvá tegye őket

Úgy gondoltuk, hogy ezeknek a céloknak az elérése jelentősen megnöveli a piaci és fejlesztői termelékenységünket. Ehhez olyan megoldásra volt szükségünk, amely:

  • Építsen termékjellemzőket jobb felhasználói élmény mellett
  • Javítsa a kód minőségét
  • Lehetővé teszi a jobb együttműködést anélkül, hogy bárki akadályozná a munka folyamatát.

Arra is törekedtünk, hogy ösztönözzük és könnyedén lépjünk át egy modern technológiai verembe, hogy fejlesztőink elégedettebbek legyenek munkájukkal, és idővel eltávolodhassunk elavult kereteinktől és eszközeinktől.

Munkánk folyamatosan fejlődő eredménye egy React-alapú SPA, amely egy monoraktárba épül, ahol az összes oldal és nagyobb funkciók beépülnek nagyrészt független, igény szerint betöltött kódcsomagokba, amelyeket egyszerre több csapat is kifejleszthet és telepíthet. .

Annak érdekében, hogy az összes régi alkalmazást homokozóba helyezzük, de továbbra is ugyanazon új alkalmazás keretében jelenítsük meg őket, egy iframe-be töltjük be őket, ahonnan az postMessage()API segítségével megvalósított üzenetbusz segítségével kommunikálhatnak a fő SPA- val.

A monoraktár

Itt van a könyvtárstruktúra, amellyel elindultunk:

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

A package.jsongyökérkönyvtárban található egy sor devDependencies felelősség, amely az egész alkalmazás fejlesztéséért, teszteléséért és felépítéséért felelős, de tartalmazza dependenciesaz alkalmazás magját is (erről bővebben egy kicsit később).

Az összes nagyobb felhasználói felület darabokat jeleneteknek nevezzük . Minden jelenet tartalmaz package.json, ahol dependencieshasználják, hogy jelenet alkotó elemeit. Ez két dolgot tesz lehetővé:

  1. A telepítés csak a megváltozott fájlokat frissíti

    A felépítési lépés külön-külön gyártói és alkalmazáscsomagokat állít össze minden jelenethez, és kivonatokat használ egy kivonat használatával, amely csak akkor változik, ha a fájl tartalma megváltozik. Ez azt jelenti, hogy felhasználóink ​​csak azokat a fájlokat töltik le, amelyek a legutóbbi látogatásuk óta megváltoztak, és semmi mást.

  2. A jelenetek csak szükség esetén töltődnek be

    Az összes jelenetet aszinkron módon és igény szerint töltjük be, ami drasztikusan javítja az egész alkalmazás betöltési idejét. Az „igény szerint” itt általában egy adott útvonal meglátogatását vagy egy felhasználói felület művelet végrehajtását jelenti, amely dinamikus modulimportot hajt végre.

Így néz ki az ilyen beállítás a gyakorlatban (az olvashatóság érdekében leegyszerűsítve):

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

Ez AsyncLoadComponentegy vékony burkolat React.lazy(), amely kiegészítõen elfogad egy elõtöltõ komponenst, ugyanazon átment egy tartalékon React.Suspense(), és egy késleltetés, amely után az elõtöltõt renderelni kell, ha a jelenet még nem fejezõdött be.

Ez akkor hasznos, ha megbizonyosodunk arról, hogy felhasználóink ​​ugyanazt az előfeltöltőt látják-e megszakítás vagy tartalom villogása nélkül, attól kezdve, hogy a jelenetet kérik, az összes fájl letöltésének, az összes kritikus API-kérés befejezésének és az összetevőnek a megjelenésétől kezdve. befejezte a megjelenítést.

Alkatrészszintek

Az egyes alkalmazások növekedésével a könyvtárstruktúra és az absztrakciók együtt fejlődnek vele. Körülbelül fél évig tartó újjáépítés és az új kódbázisra való áthelyezés után az egyetlen komponens könyvtár megléte nem bizonyult elégségesnek.

Szükségünk volt a könyvtárstruktúránkra, hogy tájékoztasson minket a következőkről:

  • Az alkatrészeket általánosnak fejlesztették-e, vagy csak egy adott felhasználási esetre szánják őket?
  • Elég általánosak-e ahhoz, hogy az összes alkalmazásban felhasználhatók legyenek, vagy csak bizonyos összefüggésekben kell használniuk?
  • Ki felelős a kódért és a legjobban tud róla?

Ennek alapján meghatároztuk a következő komponensszinteket :

1. Alkalmazás-specifikus (src / app)

Egyszer használatos komponensek, amelyek az alkalmazáson belül egyedi felhasználási esetekre szolgálnak, és amelyeket nem kívánnak újrafelhasználni vagy kibontani az alkatrészkönyvtárba (útvonalak, lábléc, oldalfejléc stb.).

2. Általános (src / components)

Általános többcélú komponensek, amelyek az alkalmazás és a jelenetek egészében használhatók. Amint elérkeztünk egy stabil API-hoz ezekhez az összetevőkhöz, azokat áthelyezhetik a közös komponens könyvtárba (erről bővebben alább)

3. Egy jelenet alkotóelemei (src / jelenetek / saját jelenetem / alkatrészek)

Egy adott felhasználási esetet szem előtt tartva kifejlesztett alkatrészek; nem célja más jelenetekben felhasználni. Azokban az esetekben, amikor az egyik jelenet egyik összetevőjét egy másikban kell használni, a következőket használjuk:

4. Több jelenet alkotóelemei (src / jelenetek / komponensek / saját funkcióm)

A többszörös jeleneteknél használt alkatrészek, de nem voltak elég általánosak ahhoz, hogy bárhol másutt használhassák őket. Annak illusztrálására, hogy miért src/componentsnem elég jó az egyszerű mozgatás :

Képzelje el, hogy eddig egyetlen jelenete volt, amely meglehetősen specifikus adatdiagramok készítéséhez használt komponenseket tartalmazott. Csapata most épít egy második jelenetet, amely különböző adatokat fog felhasználni a diagramokhoz, de vizuálisan a kettő nagyjából ugyanúgy fog kinézni.

Komponensek egyik jelenetről a másikra történő importálása megtörné a jelenet befogadását, és azt jelentené, hogy már nem lehetünk biztosak abban, hogy az egyetlen jelenet összetevőin végrehajtott változtatások csak az adott jelenetet érintik-e.

Erre a célra bármely összetevőt vagy alkotóelem-csoportot, amelyet durván jellemzőnek neveznek, abba helyeznék, src/scenes/componentsahonnan bármely más csapat importálhatja és felhasználhatja:

Amikor egy csapat el akarja kezdeni egy másik csapat által kifejlesztett jelenet-összetevők használatát, a legjobb gyakorlat az lenne, ha először az adott csapathoz fordulna, hogy kiderítse, a jövőben biztonságosan támogatható-e az a felhasználási eset, amelyre ezeket az összetevőket szánja. Ha a kódot eredetileg kifejlesztő csapatnak odafigyelünk, megakadályozzuk a meghibásodott szolgáltatások szállítását a jövőben, amikor a használatba vett kód elkerülhetetlenül megváltozik olyan módon, amire nem számítottatok (persze, hogy is lehetne!), És amit nem mindig tudnak elkapni az egységtesztek.

5. Közös könyvtár

Azok a komponensek, amelyeket a gyártás során csatában teszteltünk, és amelyeket a Unity más irányítópult-csapatai által használt megosztott komponens-könyvtárunkba szeretnénk kinyerni.

Oda a megosztott függőségekhez

Noha nagyon kényelmes lenne az alkalmazásunk minden részét teljesen elszigetelt környezetben felépíteni és telepíteni, bizonyos függőségeket - mind a külső könyvtárakat, mind a belső alkalmazáskódokat - egyszerűen csak a kódbázis egészében használni fogjuk. Olyan dolgok, mint maga a React, a Redux és az összes, a reduxhoz kapcsolódó logika, közös navigációs elemek stb.

A változások bevezetése

Jelenleg a jelenetek teljes beágyazása nem praktikus, és sok esetben egyszerűen lehetetlen. Vagy sok függőség sokszoros szállítása és az oldalak betöltésének lelassítása, vagy absztrakciók kiépítése kellene, hogy bizonyos könyvtárak olyan utakon működjenek, amelyekre még nem tervezték őket.

Amint a webfejlesztés és annak ökoszisztémája fejlődik, úgy tűnik, a könyvtárak egyre önállóbbá és beágyazottabbá válnak, ami reményeink szerint a jövőben alig vagy egyáltalán nem fog jelenteni megosztott függőségeket és az összes modul közötti valódi elszigeteltséget.

A nagyszabású alkalmazások készítésének talán legnagyobb hátránya a kódváltoztatások és a függőségi frissítések végrehajtása anélkül, hogy valamit megszakítana a folyamat során

A monoraktár használata lehetővé teszi (bár nem kötelező) a kód módosításainak és frissítéseinek fokozatosabb és biztonságosabb bevezetését - ha egy változás problémákat okoz, ezek a problémák csak az alkalmazás kis részét érintik, nem pedig az egész rendszert.

És bár egyesek számára előnyös lenne a kódbázis több, egymással nem összefüggő területének frissítése egyszerre, az a tény, hogy több csapat dolgozik ugyanazon a kódbázison, és nem ismeri a többi csapat összes funkcióját, alaposan azt jelenti, hogy nagy óvatosságra van szükség az alkalmazás állványainak megépítésekor és a törés kockázatának minimalizálása érdekében.

Hogyan lehet elkerülni a dolgok megtörését

Talán a legalapvetőbb stratégia, amely ebben segít, kivéve a jelenetek elkülönítését, az, hogy magas az egység teszt lefedettsége .

  1. Tesztelés

Az egységtesztek természetesen nem mindenek - sok érett termék, még mérsékelt léptékben is, mégis az integrációs csomagokba és az e2e tesztekbe fektet be, amelyek jobb munkát végeznek annak ellenőrzésében, hogy az alkalmazás a várakozásoknak megfelelően működik-e. A szolgáltatások számának növekedésével azonban növekszik a karbantartási költségek és a futtatáshoz szükséges idő is - ez a költség nem mindig igazolható kevésbé fontos, de mégis fontos jellemzőkre.

Néhány tanulság, amelyet különböző tesztelési stratégiákból tanultunk:

  • Próbálja meg a lehető legtöbb kódot tesztelni egységesen, különösen: feltételes logikát, adatátalakításokat és függvényhívásokat
  • Fektessen be és teljes mértékben kihasználja az integrációs teszteket, mielőtt az e2e tesztek megírása mellett dönt. Az integrációs tesztek kezdeti költsége sokkal magasabb, de halványabb, mint az e2e csomag fenntartásának ára
  • Ne próbáljon túl reagálni azzal, hogy elkezdi írni az e2e teszteket olyan dolgokról, amelyeket nem fogtak el egység vagy integrációs tesztek. Néha a folyamatok vagy a szerszámok hibásak
  • A tesztesetek magyarázzák a felhasználói felület viselkedését, nem pedig a megvalósítás részleteit
  • Az automatizált tesztek nem pótolhatják teljes mértékben a kézi tesztelést

2. Minimalizálja a megosztott kód felületét

A tesztelésen kívül az egész alkalmazásban újra használt kódot ésszerű minimumon tartják. Az egyik leghasznosabb stratégia eddig az volt, hogy a leggyakrabban használt komponenseket és kódokat egy megosztott komponens könyvtárba helyezte át, ahonnan függőségként használják azokat a jeleneteket, amelyekre szükségük van. Ez lehetővé teszi számunkra a változások nagy részének fokozatos bevezetését, csapatonként vagy oldalanként.

3. elszámoltathatóság

Végül, de nem utolsósorban, óriási tényező abban, hogy több csapat képes együttműködni ugyanazon a kódbázison belül, az a bátorítás és a fejlesztők személyes felelősségének és elszámoltatásának ösztönzése , ahelyett, hogy a megfelelő tesztelés felelősségét a QA-nak, a tesztelőknek vagy a tesztelőknek terhelnék. automatizálás.

Ez átvisz a kódellenőrzésekre is. Annak biztosítása, hogy minden változtatást gondosan felülvizsgáljanak, nehezebb, mint a felszínen tűnhet. Mivel a csapat szorosan együttműködik, egészséges bizalom alakul ki tagjai között. Ez a bizalom azonban néha azt eredményezheti, hogy az emberek kevésbé szorgalmasak a tapasztaltabb vagy más szempontból megbízhatóbb fejlesztők változásaihoz.

A szorgalom ösztönzése érdekében hangsúlyozzuk, hogy a PR szerzője és a bíráló egyformán felelős azért, hogy minden működjön .

Alkatrészkönyvtár

Az irányítópultok összes oldalán azonos megjelenés és érzés érdekében kifejlesztettünk egy összetevő könyvtárat. A mi megközelítésünkben az áll, hogy a könyvtárban szinte soha nem fejlesztenek új komponenseket.

A műszerfal kódbázisán belüli fejlesztés után minden komponenst először a kódbázison belül egy csomó funkcióban használnak fel. Általában néhány hét múlva kezdünk magabiztosabbnak lenni abban, hogy az alkatrész áthelyezhető, tekintve, hogy:

  • Az API elég rugalmas ahhoz, hogy támogassa az előrelátható felhasználási eseteket
  • Az alkatrészt különféle körülmények között tesztelték
  • A teljesítményt, az érzékenységet és az UX-t mind elszámolják

Ez a folyamat a Harmadik szabályt követi, és célja, hogy csak olyan alkatrészeket szabadítson fel, amelyek valóban újrafelhasználhatók, és amelyeket különféle körülmények között használtak fel, mielőtt a közös könyvtárunkba költöztettek volna.

Néhány olyan példa az összetevőkre, amelyeken átkerülnénk: lábléc, oldal fejléc, oldalsó és felső navigációs elemek, elrendezés építőkockák, szalaghirdetések, gombok bekapcsolt verziói, tipográfiai elemek stb.

A kezdeti időkben a komponens könyvtár ugyanabban a kódbázisban volt elhelyezve, mint maga az alkalmazás. Azóta kibontottuk egy külön lerakatba, hogy demokratikusabbá tegyük a fejlesztési folyamatot a Unity többi csapata számára - ami fontos annak elfogadásához.

Moduláris alkatrész tervezés

A leghosszabb ideig az újrafelhasználható alkatrészek építése több kihívás kezelését jelentette, amelyek közül soknak gyakran nem voltak jó megoldásai:

  • Hogyan lehet egyszerűen importálni az összetevőt a stílusaival együtt, és csak azt
  • Hogyan lehet felülírni az alapértelmezett stílusokat a választóspecifikus háborúk nélkül
  • Nagyobb, több kisebb alkatrészből álló alkatrészekben hogyan lehet felülírni a kisebb alkatrészek stílusát

Irányítópultunk, valamint alkatrészkönyvtárunk nagymértékben függ az Anyag felhasználói felületétől és használja azt. A Material UI stílusmegoldásában egyedülállóan meggyőző a JSS és az egységes stílusnyelvük által rejlő lehetőség (érdemes elolvasni), amelyek lehetővé teszik a dizájn által bezárt UI-k kifejlesztését, mint a CSS modulok esetében, és megoldják a fentieket kérdéseket lépésről lépésre.

Ez jelentősen eltér az olyan megközelítésektől, mint a BEM, amelyek konvencionálisan kapszulázást biztosítanak , amelyek általában kevésbé nyújthatók és kevésbé kapszulázottak.

Élő stílusvezető

Az alkatrészkönyvtár nem lenne teljes, ha nincs mód bemutatni a benne lévő összetevőket, és nem lehet látni az összetevőket, ahogy változnak a kiadások során.

Nagyon jó tapasztalataink voltak a Storybookkal kapcsolatban, amelyet nevetségesen könnyű beállítani és elkezdeni, de egy idő után rájöttünk, hogy robusztusabb és végpontok közötti megoldásra van szükség. Elég közel ahhoz, amit a Styleguidist kínál, de jobban megfelel az igényeinknek.

Meglévő tervdokumentumok

A legfrissebb tervezési specifikáció legfőbb információforrásaként szolgáló dokumentáció a Confluence-ban található, ahol a tervezők naprakész specifikációt tartottak minden egyes alkatrészről képernyőképek segítségével, amelyek bemutatták az engedélyezett felhasználási eseteket, állapotokat és variációkat, amelyekben az összetevő megtalálható. bevált gyakorlatok, valamint olyan részletek, mint a méretek, a használt színek stb. Ezt a megközelítést követve számos kihívással szembesültünk:

  • Az anyagtervezési specifikáció folyamatosan fejlődik, és emiatt gyakran tapasztaltuk, hogy vagy időt töltünk az összes képernyőkép és irányelv frissítésére, vagy hagyjuk, hogy a tervezési irányelveink elavultak legyenek
  • Kideríteni, hogy melyik a helyes: a megvalósítás vagy a specifikáció nem volt mindig könnyű feladat. Mivel minden alkatrészről és minden könyvtári verzióról közzétettük a Storybook bemutatóit, láthattuk, mi és hogyan változott. Nem tehettük meg ugyanezt a tervezési specifikációnál.
  • A képernyőképek és videók csak annyit kommunikálhatnak . Kiváló minőségű és több csapat által is használható alkatrészek biztosításához ellenőrizni kell, hogy az egyes komponensek minden felbontásban működnek-e, hibamentesek-e és jó-e az UX-je - ez nehéz volt anélkül, hogy a tervező szó szerint melletted ült volna, hogy lássa a megvalósítási bemutató jelenik meg a képernyőn

Alkatrészdokumentációs alkalmazás

Dokumentációs alkalmazásunk célja a tervezők és mérnökök közötti hatékony együttműködés eszközeinek biztosítása, hogy egyszerűbbé és kevésbé időigényessé tegye mindkét fél számára az alkatrészek dokumentálását, felülvizsgálatát és fejlesztését. Pontosabban:

  • Legyen egyetlen referenciapont, amely bemutatja az összetevőket , hogyanha kinéznek, viselkednek és használják őket - minden kiadáshoz biztosítva -, a részletes leírásokat élő demókra cserélik
  • Könnyítse meg a tervezők és fejlesztők együttműködését az alkatrészekkel és dokumentumaikkal, és tegye meg ezt még az alkatrészek kiadása előtt - videók, képernyőképek megosztása vagy fizikailag ugyanazon a helyen való részvétel nélkül
  • Válassza szét a terveket arra nézve, hogy mit tervezünk tenni, és mit csinálunk

A korábbiakhoz hasonlóan a komponens könyvtár minden egyes kiadása az élő stílusvezetés új verziójának közzétételét eredményezi. Ezúttal azonban van néhány különbség:

  1. A tervezők közvetlenül hozzájárulnak az alkatrészdokumentációhoz a dokumentációs fájlok Github felhasználói felületen keresztüli szerkesztésével, a legújabb kiadás módosításainak végrehajtásával.
  2. Component demók WYSIWYG - ugyanazt a kódot látsz, mint egy példát, hogyan hajtsák végre a komponenst alkalmaznak, hogy a demo, beleértve bármely köztes fájlt import, változó nyilatkozatok stb Mint egy hozzáadott bónusz, alkatrészek csomagolva withStyles()helyesen jelennek meg (kérdés jelen jelenleg a Mesekönyvben).
  3. A dokumentumok és a kód változásai szinte azonnal láthatók anélkül, hogy helyben megnéznék a fiókot és elindítanák a dokumentációs alkalmazást - az alkalmazás újjáépül és közzétételre kerül minden elkötelezettségnél.

Fejlesztési tapasztalat

A kódellenőrzések egyik fő célja annak biztosítása, hogy minden egyes változtatást gondosan átnézzenek, megfontoljanak és teszteljenek az összevonás és telepítés előtt.

Annak érdekében, hogy ez a feladat a lehető legkevesebb akadálymentes legyen, kifejlesztettünk egy olyan előnézeti kiszolgálót, amely képes létrehozni az alkalmazás új verzióját minden egyes PR létrehozásakor vagy frissítésekor.

Tervezőink, termékmenedzsereink és mérnökeink tesztelhetik az egyes változásokat az egyesítés előtt, mind a rendezési, mind a gyártási környezetben, és a változtatástól számított néhány percen belül.

Záró szavak

Közel egy év telt el azóta, hogy összefogjuk az irányítópultokat. Azt az időt töltöttük el, hogy megtanuljuk, hogyan lehet nagy, de egészséges szoftverprojektet fejleszteni, hogyan lehetünk jobbak az együttműködés és a kommunikáció terén, és hogyan emelhetnénk a minőségi sávot önmagunk számára.

A frontend projektet nemcsak a kódsorok, hanem a kódalapon belül dolgozó mérnökök számát is méreteztük - ez a szám a kezdetek óta megnégyszereződött.

180 fokos változtatást hajtottunk végre a csapataink közötti időbeli különbségek kezelésében, eltávolodva egy olyan modelltől, ahol csapataink teljes elszigeteltségben dolgoztak, olyan modellre, ahol a szoros együttműködés és kommunikáció mindennapos esemény.

Noha még hosszú utat várunk annak biztosítására, hogy több csapatot és nagyobb kihívásokat tudjunk megközelíteni, számos javulást észleltünk már:

  • Menetrend és a munka láthatósága

    Annak köszönhetően, hogy egy helyen van az összes munka, nyomon követhető az előrehaladás, és minden kérdés összegyűlik

  • Fejlesztési sebesség és a piacra jutás ideje

    Új funkciók nagyrészt már meglévő és jól tesztelt összetevőkből hozhatók létre - dokumentációs alkalmazásunkon keresztül könnyen megtalálhatók

  • Kódminőség és teszt lefedettség

    Új dolgok felépítésekor egy hasonló problémára általában már létezik megoldás, és kéznél van, valamint a tesztelésének példáival együtt

  • Általános minőség és UX

    A funkciók tesztelése és minőségük biztosítása most könnyebb, mint valaha, mivel a tervezők, a termékmenedzserek és más érdekeltek minden változtatást saját gépükön, saját számlájukkal és adathalmazaikkal tesztelhetnek.

Természetesen az út során számos olyan kihívással szembesültünk, amelyeket meg kell oldanunk, vagy amelyeket a jövőben meg kell oldanunk:

  • Építés és CI teljesítmény

    A függőségek, a csomagok és a tesztek számának növekedésével, valamint a telepítéshez szükséges idő növekedésével. A jövőben olyan eszközöket kell kifejlesztenünk, amelyek csak a megváltozott darabok felépítésében, tesztelésében és telepítésében nyújtanak segítséget.

  • Fejlesztési kultúra

    Az egészséges szoftverek felépítéséhez folyamatosan dolgoznunk kell a kommunikáció és az eszmecsere egészséges módjain, és a szöveges kommunikáció megnehezíti ezt a feladatot. Dolgozunk ezen a kérdésen, rendszeres vezetői tréningek révén, egy nyílt forráskódú munkamódszer felvételével, valamint évente néhány összejövetel megszervezésével, hogy a csapatok négyszemközt találkozzanak egymással.

  • Töréselkülönítés és frissítések

    Amint a funkciók és az oldalak száma növekszik, erőteljesebb módszerre lesz szükségünk az alkalmazási moduljaink elkülönítésére, hogy megakadályozzuk a károk terjedését, ha a dolgok rosszra fordulnak. Ezt úgy érhetjük el, hogy az összes megosztott kódot (redux logic, src / components) verzióvá alakítjuk, vagy szélsőséges esetekben egyes funkciók önálló buildjeit állítjuk elő.

Állítson akkor, most és a jövőben

A migráció magában foglalja az AngularJS-től a React felé való elmozdulást. Így változott a helyzet az elmúlt évben:

Ez egy pakolás! Köszönöm, hogy elolvasta! Itt találsz a LinkedIn-en.

Ha hasonló kihívásokkal való munka érdekesnek tűnik számodra, mindig tehetséges mérnököket keresünk, hogy csatlakozzanak csapatainkhoz a világ minden tájáról.