Hello barátok. A tanfolyam indulására várva , hagyományosan hasznos anyagok fordítását osztjuk meg veletek.
A szoftverek egyre több mindennapi problémát oldanak meg, miközben egyre összetettebbé válnak. Ahogy Marc Andreessen mondta egyszer, felemészti a világot.
Ennek eredményeként az alkalmazások fejlesztésének és szállításának módja drámaian megváltozott az elmúlt néhány évben. Ezek tektonikus léptékű elmozdulások voltak, amelyek egy sor alapelvet eredményeztek. Ezek az elvek hasznosnak bizonyultak a csapatépítésben, az alkalmazások tervezésében, fejlesztésében és a végfelhasználókhoz való eljuttatásában.
Az alapelvek a következőkben foglalhatók össze: az alkalmazásnak kicsinek, webalapúnak kell lennie, és fejlesztőközpontú architektúrájúnak kell lennie. E három alapelvre építve robusztus, teljes körű alkalmazást hozhat létre, amely gyorsan és biztonságosan eljuttatható a végfelhasználóhoz, valamint könnyen méretezhető és bővíthető.
A javasolt elvek mindegyike számos szempontot tartalmaz, amelyeket meg fogunk tárgyalni, hogy bemutassuk, hogyan járulnak hozzá az egyes alapelvek a könnyen karbantartható és használható, megbízható alkalmazások gyors szállításának végső céljához. Megvizsgáljuk az alapelveket az ellentétükkel összehasonlítva, hogy tisztázzuk, mit jelent azt mondani: „Győződjön meg róla, hogy kicsinység elve".
Reméljük, hogy ez a cikk arra ösztönzi Önt, hogy használja a javasolt elveket a modern alkalmazások létrehozásához, amelyek egységes tervezési megközelítést biztosítanak az egyre növekvő technológiai halmaz kontextusában.
Ezen elvek alkalmazásával felfedezheti, hogy kihasználja a szoftverfejlesztés legújabb trendjeit, beleértve a alkalmazásfejlesztéshez és szállításhoz, konténerek használatához (pl. ) és konténer hangszerelési keretrendszerek (például ), mikroszolgáltatások használata (beleértve a Microservice Architecture-t is и mikroszolgáltatási alkalmazásokhoz.
Mi az a modern alkalmazás?
Modern alkalmazások? Modern verem? Mit jelent pontosan a "modern"?
A legtöbb fejlesztő csak alapvető ismeretekkel rendelkezik arról, hogy miből áll egy modern alkalmazás, ezért ezt a fogalmat egyértelműen meg kell határozni.
Egy modern alkalmazás több klienst is támogat, legyen az a React JavaScript könyvtárat használó felhasználói felület, Android vagy iOS mobilalkalmazás, vagy olyan alkalmazás, amely API-n keresztül csatlakozik egy másikhoz. Egy modern alkalmazás meghatározatlan számú klienst jelent, akik számára adatokat vagy szolgáltatásokat nyújt.
Egy modern alkalmazás API-t biztosít a kért adatok és szolgáltatások eléréséhez. Az API-nak változtathatatlannak és állandónak kell lennie, és nem kifejezetten egy adott klienstől érkező kéréshez kell írni. Az API HTTP(S)-n keresztül érhető el, és hozzáférést biztosít a GUI-ban vagy a CLI-ben található összes funkcióhoz.
Az adatoknak általános, interoperábilis formátumban, például JSON-ban kell rendelkezésre állniuk. Az API áttekinthető, szervezett formában teszi közzé az objektumokat és a szolgáltatásokat; például a RESTful API vagy a GraphQL megfelelő felületet biztosít.
A modern alkalmazások modern veremre épülnek, a modern verem pedig az ilyen alkalmazásokat támogató verem, ill. Ez a verem lehetővé teszi a fejlesztő számára, hogy könnyen létrehozzon alkalmazást HTTP-felülettel és egyértelmű API-végpontokkal. A választott megközelítés lehetővé teszi, hogy az alkalmazás könnyen fogadjon és küldjön adatokat JSON formátumban. Más szavakkal, a modern verem megfelel a tizenkét tényezős alkalmazás elemeinek .
Az ilyen típusú verem népszerű változatai a , , , , и . Microservice Architecture példát mutat egy modern veremre, amelyet az említett nyelvek mindegyikén megvalósítottak.
Felhívjuk figyelmét, hogy nem támogatjuk a tisztán mikroszolgáltatási megközelítést. Sokan közületek olyan monolitokkal dolgoznak, amelyeknek fejlődniük kell, míg mások olyan SOA-alkalmazásokkal foglalkoznak, amelyek egyre bővülnek, és mikroszolgáltatásokká válnak. Megint mások a szerver nélküli alkalmazások felé mozdulnak el, és néhányan a fentiek kombinációit valósítják meg. Az ebben a cikkben felvázolt elvek ezekre a rendszerekre csak néhány kisebb módosítással vonatkoznak.
Alapelvek
Most, hogy már alapvető ismereteink vannak arról, hogy mi a modern alkalmazás és a modern verem, itt az ideje, hogy fejest ugorjunk az architektúra és tervezési elvekbe, amelyek jól szolgálják Önt egy modern alkalmazások tervezésében, megvalósításában és karbantartásában.
Az egyik alapelv a „build small apps”, nevezzük csak a kicsinység elve. Vannak hihetetlenül összetett alkalmazások, amelyekben sok mozgó alkatrész van. Ha viszont kis, diszkrét komponensekből építünk fel egy alkalmazást, az összességében könnyebbé teszi a tervezést, karbantartást és használatát. (Megjegyzendő, hogy azt mondtuk, hogy „egyszerűsíti”, és nem „egyszerűsíti”).
A második alapelv az, hogy növelhetjük a fejlesztők termelékenységét azáltal, hogy segítjük őket a fejlesztés alatt álló funkciókra összpontosítani, miközben megszabadítjuk őket attól, hogy az infrastruktúra és a CI/CD miatt aggódjanak a megvalósítás során. Dióhéjban tehát a mi megközelítésünk fejlesztő-orientált.
Végül az alkalmazással kapcsolatos mindennek csatlakoznia kell a hálózathoz. Az elmúlt 20 év során nagyot haladtunk a hálózatos jövő felé, mivel a hálózatok gyorsabbak lettek, és az alkalmazások bonyolultabbá váltak. Ahogy már láttuk, egy modern alkalmazást sok különböző kliensnek kell használnia a hálózaton keresztül. A hálózati gondolkodás architektúrára való alkalmazása jelentős, jól illeszkedő előnyökkel jár a kicsinység elve és a megközelítés koncepciója, fejlesztő-orientált.
Ha ezeket az alapelveket szem előtt tartja egy alkalmazás tervezése és megvalósítása során, akkor egyértelmű előnyhöz juthat terméke fejlesztése és szállítása során.
Nézzük meg ezt a három elvet részletesebben.
A kicsinység elve
Az emberi agy nehezen képes egyszerre nagy mennyiségű információt felfogni. A pszichológiában a kognitív terhelés kifejezés azt a teljes mentális erőfeszítést jelenti, amely szükséges ahhoz, hogy az információ a memóriában megmaradjon. A fejlesztőkre nehezedő kognitív terhelés csökkentése prioritás, mert így a probléma megoldására koncentrálhatnak ahelyett, hogy a teljes alkalmazás és a fejlesztés alatt álló funkciók jelenlegi komplex modelljét tartanák a fejükben.
Az alkalmazások a következő okok miatt vannak felbontva:
- A fejlesztők kognitív terhelésének csökkentése;
- A tesztelés felgyorsítása és egyszerűsítése;
- Az alkalmazás módosításainak gyors kézbesítése.
A fejlesztőkre nehezedő kognitív terhelés csökkentésének több módja is van, és itt jön képbe a kicsinység elve.
Tehát három módszer a kognitív terhelés csökkentésére:
- Csökkentse azt az időkeretet, amelyet figyelembe kell venniük egy új funkció kidolgozásakor – minél rövidebb az időkeret, annál kisebb a kognitív terhelés.
- Csökkentse az egyszerre feldolgozott kód mennyiségét - kevesebb kód - kevesebb terhelés.
- Egyszerűsítse az alkalmazás fokozatos módosításának folyamatát.
Csökkentett fejlesztési időkeretek
Térjünk vissza a módszertan korába waterfall a fejlesztési folyamat szabványa volt, és az alkalmazások fejlesztésére vagy frissítésére hat hónaptól két évig terjedő időkeret volt bevett gyakorlat. Általában a mérnökök először elolvassák a vonatkozó dokumentumokat, például a termékkövetelményeket (PRD), a rendszer referenciadokumentumát (SRD), az architektúra tervet, és elkezdik ezeket a dolgokat egyetlen kognitív modellbe integrálni, amely szerint kódot írtak. Ahogy a követelmények, és így az architektúra is megváltoztak, jelentős erőfeszítéseket kellett tenni annak érdekében, hogy a teljes csapatot tájékoztassák a kognitív modell frissítéseiről. A legrosszabb esetben ez a megközelítés egyszerűen megbéníthatja a munkát.
Az alkalmazásfejlesztési folyamatban a legnagyobb változást az agilis módszertan bevezetése jelentette. A módszertan egyik fő jellemzője agile - Ez iteratív fejlesztés. Ez viszont a mérnökök kognitív terhelésének csökkenéséhez vezet. Ahelyett, hogy megkövetelné a fejlesztőcsapattól, hogy egyetlen hosszú ciklusban implementálja az alkalmazást, agile A megközelítés lehetővé teszi, hogy kis mennyiségű kódra összpontosítson, amely gyorsan tesztelhető és telepíthető, miközben visszajelzést is kap. Az alkalmazások kognitív terhelése hat hónapos időkeretről két évre tolódott el, hatalmas mennyiségű specifikációval, egy kéthetes funkció-kiegészítés vagy -módosítás irányába, amely egy nagy alkalmazás szélesebb körű megértését célozza meg.
Jelentős változást jelent, ha a hangsúlyt egy hatalmas alkalmazásról a kéthetes sprint alatt teljesíthető kis funkciókra helyezzük át, és a következő sprintből legfeljebb egy funkcióra tekintünk előre. Ez lehetővé tette a fejlesztési termelékenység növelését, miközben csökkentette a folyamatosan ingadozó kognitív terhelést.
Módszertanban agile a végső alkalmazás várhatóan az eredeti koncepció némileg módosított változata lesz, így a végső fejlesztési pont szükségszerűen nem egyértelmű. Csak az egyes sprintek eredményei lehetnek egyértelműek és pontosak.
Kis kódbázisok
A kognitív terhelés csökkentésének következő lépése a kódbázis csökkentése. A modern alkalmazások általában hatalmasak – egy robusztus, vállalati alkalmazás több ezer fájlból és több százezer sornyi kódból állhat. A fájlok felépítésétől függően a kód és a fájlok közötti kapcsolatok és függőségek nyilvánvalóak vagy nem nyilvánvalóak. Még magának a kódvégrehajtásnak a hibakeresése is problémás lehet, attól függően, hogy milyen könyvtárakat használnak, és hogy a hibakereső eszközök mennyire tesznek különbséget a könyvtárak/csomagok/modulok és a felhasználói kód között.
Egy alkalmazás kódjának működő mentális modelljének felépítése jelentős időt vehet igénybe, ami ismét nagy kognitív terhelést ró a fejlesztőre. Ez különösen igaz a monolitikus kódbázisokra, ahol nagy mennyiségű kód van, a funkcionális komponensek közötti kölcsönhatások nincsenek egyértelműen meghatározva, és a figyelem tárgyainak elkülönítése gyakran elmosódik, mert nem tartják tiszteletben a funkcionális határokat.
A mérnökök kognitív terhelésének csökkentésének egyik hatékony módja a mikroszolgáltatási architektúrára való átállás. A mikroszolgáltatási megközelítésben minden szolgáltatás egy-egy funkciókészletre összpontosít; a szolgáltatás jelentése általában meghatározott és érthető. A szolgáltatás határai is egyértelműek – ne feledje, hogy a szolgáltatással való kommunikáció API-n keresztül történik, így az egyik szolgáltatás által generált adatok könnyen átvihetők a másikba.
Az egyéb szolgáltatásokkal való interakció általában néhány felhasználói szolgáltatásra és néhány szolgáltatói szolgáltatásra korlátozódik, amelyek egyszerű és tiszta API-hívásokat használnak, például a REST-et. Ez azt jelenti, hogy a mérnök kognitív terhelése jelentősen csökken. A legnagyobb kihívás továbbra is a szolgáltatási interakciós modell megértése, valamint a tranzakciók több szolgáltatáson keresztüli történésének megértése. Végső soron a mikroszolgáltatások használata csökkenti a kognitív terhelést azáltal, hogy csökkenti a kód mennyiségét, világos szolgáltatási határokat határoz meg, és betekintést nyújt a felhasználó-szolgáltató kapcsolatba.
Kis fokozatos változtatások
Az elv utolsó eleme egy kis a változásmenedzsment. A fejlesztők számára különösen csábító, hogy egy kódalapot (akár talán a saját, régebbi kódot is) megnézve azt mondják: "Ez baromság, át kell írnunk ezt az egészet." Néha ez a helyes döntés, néha pedig nem. A globális modellváltások terhét a fejlesztőcsapatra hárítja, ami viszont hatalmas kognitív terhelést eredményez. Jobb, ha a mérnökök azokra a változtatásokra koncentrálnak, amelyeket a sprint során végrehajthatnak, hogy aztán időben, bár fokozatosan bevezessék a szükséges funkcionalitást. A végterméknek hasonlítania kell az előre eltervezetthez, de néhány módosítással és teszteléssel, hogy megfeleljen az ügyfél igényeinek.
A kód nagy részének átírásakor néha lehetetlen gyorsan végrehajtani a változást, mert más rendszerfüggőségek lépnek életbe. A változtatások folyamatának szabályozásához használhatja a funkciók elrejtését. Ez alapvetően azt jelenti, hogy a funkcionalitás ott van a termelésben, de nem érhető el a környezeti változó beállításain (env-var) vagy más konfigurációs mechanizmuson keresztül. Ha a kód átment minden minőség-ellenőrzési folyamaton, akkor rejtett állapotba kerülhet a termelésben. Ez a stratégia azonban csak akkor működik, ha a funkció végül engedélyezve van. Ellenkező esetben csak összezavarja a kódot, és kognitív terhelést ad hozzá, amellyel a fejlesztőnek meg kell birkóznia ahhoz, hogy eredményes legyen. A változáskezelés és a fokozatos változtatások maguk is segítenek a fejlesztők kognitív terhelésének elérhető szinten tartásában.
A mérnököknek sok nehézséget kell leküzdeniük még akkor is, ha egyszerűen csak további funkciókat implementálnak. Célszerű lenne, ha a vezetés csökkentené a csapat szükségtelen munkaterhelését, hogy a funkcionalitás kulcsfontosságú elemeire összpontosíthasson. Három dologgal segítheti fejlesztőcsapatát:
- Használjon módszertant
agile, hogy korlátozza azt az időtartamot, amelyen belül a csapatnak a legfontosabb funkciókra kell összpontosítania. - Valósítsa meg alkalmazását több mikroszolgáltatásként. Ez korlátozza a bevezetett funkciók számát, és megerősíti azokat a határokat, amelyek a munka közbeni kognitív terhelést tartalmazzák.
- Inkrementális változtatásokat részesítsen előnyben a nagy, nehézkes változtatásokkal szemben, módosítsa a kis kódrészleteket. Használja a funkciók elrejtését a változtatások végrehajtásához, még akkor is, ha azok nem jelennek meg azonnal a hozzáadásuk után.
Ha a kicsinyesség elvét alkalmazza a munkája során, csapata sokkal boldogabb lesz, jobban összpontosít a szükséges funkciók biztosítására, és nagyobb valószínűséggel gyorsabban hajtja végre a minőségi változtatásokat. Ez azonban nem jelenti azt, hogy a munka ne válhatna bonyolultabbá, néha éppen ellenkezőleg, az új funkcionalitás bevezetése több szolgáltatás módosítását igényli, és ez a folyamat bonyolultabb lehet, mint egy monolitikus architektúra hasonló. Mindenesetre a megközelítés használatának előnyei kissé megérik.
Az első rész vége.
Hamarosan közzétesszük a fordítás második részét, de most várjuk észrevételeiket, és meghívjuk , amelyre ma 20.00 órakor kerül sor.
Forrás: will.com