Helló, barátok. A kurzus indulása előtt , hagyományosan megosztjuk veletek egy hasznos anyag fordítását.
A szoftver egyre több mindennapi feladatra talál megoldást, miközben egyre bonyolultabbá válik. Ahogy Mark Andreessen egyszer mondta, „a világot elnyeli”.
Ennek eredményeként az utolsó néhány évben az alkalmazásfejlesztési és -szállítási megközelítések komolyan megváltoztak. Ezek a tectonikus méretű elmozdulások végül egy elvhalmazt eredményeztek. Ezek az elvek hasznosak voltak a csapatok kialakításában, a tervezésben, fejlesztésben és az alkalmazás végfelhasználókhoz való eljuttatásában.
Az elvek a következő módon összefoglalhatók: az alkalmazásnak kicsinek, hálózatra épültnek és a fejlesztők számára orientáltnak kell lennie.. Ezekre a három elvre támaszkodva megbízható, átfogó alkalmazást hozhat létre, amelyet gyorsan és biztonságosan eljuttathat a végfelhasználóhoz, valamint könnyen skálázható és bővíthető.
A javasolt elvek mindegyikének számos aspektusa van, amelyeket meg fogunk vitatni, hogy megmutassuk, miként segítik az egyes elvek a végső cél elérését, amely a megbízható, könnyen karbantartható és használható alkalmazások gyors szállításában rejlik. Az elveket a ellentéteikkel összevetve fogjuk vizsgálni, hogy tisztázzuk, mit is jelent például az, hogy „Győződj meg arról, hogy használod a kicsiség elvet.».
Reméljük, hogy ez a cikk ösztönözni fog arra, hogy alkalmazzátok a modern alkalmazások építéséhez javasolt elveket, amelyek egységes megközelítést biztosítanak a tervezéshez a folyamatosan bővülő technológiai stack kontextusában.
Ezeknek az elveknek a alkalmazásával felfedezheted, hogy a legújabb szoftverfejlesztési trendeket használod, beleértve a megközelítést az alkalmazások fejlesztésére és szállítására, valamint a konténerek használatát (mint például ) és a konténerek irányítását szolgáló keretrendszereket (mint például ), valamint a mikroszolgáltatások alkalmazását (beleértve a Mikroszolgáltatási Architektúrát és mikroszolgáltatásokra épülő alkalmazásokhoz.
Mi az a modern alkalmazás?
Modern alkalmazások? Modern stack? Mit is jelent pontosan a „modern”?
A legtöbb fejlesztő csak általános képet alkot arról, hogy miből áll egy modern alkalmazás, ezért világos definícióra van szükség e fogalom számára.
A modern alkalmazás több klienst támogat, legyen az egy JavaScript React könyvtárra épülő felhasználói felület, egy Android vagy iOS mobilalkalmazás, vagy egy másik alkalmazással API-n keresztüli kapcsolódás. A modern alkalmazás egy meghatározatlan számú klienssel rendelkezik, amelyek számára adatokat vagy szolgáltatásokat biztosít.
A modern alkalmazás API-t biztosít a kért adatokhoz és szolgáltatásokhoz való hozzáféréshez. Az API-nak változatlannak és állandónak kell lennie, nem pedig konkrét kérés alapján egy adott klienshez írva. Az API HTTP(S) protokollon érhető el, és biztosítja az összes funkcióhoz való hozzáférést, ami a GUI-ban vagy CLI-ben elérhető.
Az adatoknak egy közismert, kompatibilis formátumban kell rendelkezésre állniuk, mint például a JSON. Az API objektumokat és szolgáltatásokat biztosít érthető, rendezett formában; például a RESTful API vagy a GraphQL megfelelő interfészt kínál.
A modern alkalmazások a modern technológiai stackre épülnek, és a modern stack olyan stack, amely támogatja az ilyen alkalmazásokat. Ez a stack lehetővé teszi a fejlesztő számára, hogy könnyedén hozzon létre HTTP interfésszel rendelkező alkalmazásokat és világos API végpontokat. A választott megközelítés lehetővé teszi, hogy az alkalmazás egyszerűen fogadjon és küldjön adatokat JSON formátumban. Más szavakkal, a modern stack megfelel a Tizenkét Faktoros alkalmazás elemeinek. .
E technológiai stack népszerű verziói a , , , , és . A Mikroszolgáltatás-Architektúra példázza a modern stack megvalósulását minden említett nyelven.
Vegye figyelembe, hogy nem csak a mikroszolgáltatás-alapú megközelítést népszerűsítjük. Sokuk monolitokkal dolgozik, amelyeknek fejlődniük kell, míg mások SOA alkalmazásokkal foglalkoznak, amelyek kibővülnek és fejlődnek, hogy mikroszolgáltatásokká váljanak. Harmadik felek a serverless alkalmazások irányába haladnak, míg egyesek a fent említett megoldások kombinációját alkalmazzák. A cikkben ismertetett elvek minden egyes rendszerre vonatkoznak, csak néhány apró változtatással.
Elvek
Most már, hogy egyetértettünk abban, mi is az a modern alkalmazás és modern technológiai stack, itt az ideje, hogy belemerüljünk az építési és fejlesztési elvekbe, amelyek jó szolgálatot tehetnek a modern alkalmazás fejlesztésében, megvalósításában és karbantartásában.
Az egyik elv így szól: „készíts kis alkalmazásokat”, nevezzük egyszerűen a kicsiség elvének. Vannak rendkívül bonyolult alkalmazások, amelyek számos mozgó komponensből állnak. Ezzel szemben, egy alkalmazás építése kis diszkrét komponensekből elősegíti a tervezését, karbantartását és a vele való munkát. (Vegyük észre, hogy azt mondtuk: „elősegíti”, nem pedig „egyszerűsíti”).
A második elv az, hogy növelhetjük a fejlesztők termelékenységét úgy, hogy lehetővé tesszük számukra, hogy a fejlesztett funkciókra összpontosítsanak, miközben eltávolítjuk tőlük az infrastruktúrával és a CI/CD-vel kapcsolatos aggályokat a megvalósítás során. Tehát röviden: a megközelítésünk a fejlesztőkre összpontosít.
Végül, mindennek, ami az alkalmazásodhoz kapcsolódik, hálózatra kell csatlakoznia. Az elmúlt 20 évben jelentős lépéseket tettünk a hálózati jövő felé, mivel a hálózatok gyorsabbá váltak, míg az alkalmazások bonyolultabbak lettek. Ahogyan már említettük, a modern alkalmazást számos különböző kliensnek kell használni a hálózaton. A hálózati gondolkodás alkalmazása az architektúrában jelentős előnyöket kínál, amelyek jól kiegészítik a kicsiség elvének és a megközelítést, a fejlesztőkre összpontosítva..
Ha a fejlesztés és az alkalmazás bevezetése során figyelembe veszed ezeket az elveket, vitathatatlan előnyre tehetsz szert a terméked fejlesztésében és kiszolgáltatásában.
Nézzük meg ezeket a három elvet részletesebben.
A kicsiség elve
Az emberi agy nehezen tud egyszerre nagy mennyiségű információt feldolgozni. A pszichológiában a kognitív terhelés kifejezés az információ memóriában való megőrzéséhez szükséges mentális erőfeszítések összegét jelenti. A fejlesztők kognitív terhelésének csökkentése prioritás, mivel így a problémák megoldására tudnak összpontosítani, ahelyett, hogy a teljes alkalmazás aktuális bonyolult modelljét és a fejlesztett funkciókat kellene a fejükben tartaniuk.
Az alkalmazások az alábbi okokból dekomponálódnak:
- A fejlesztők kognitív terhelésének csökkentése;
- A tesztelés felgyorsítása és leegyszerűsítése;
- A változások gyorsan történő szállítása az alkalmazásban.
Többféle mód van a fejlesztők kognitív terhelésének csökkentésére, és itt jön a képbe a kis méret elve.
Tehát három módszer a kognitív terhelés csökkentésére:
- Csökkenteni azokat az időkereteket, amelyeket figyelembe kell venniük egy új funkció fejlesztésekor – minél rövidebb az időkeret, annál alacsonyabb a kognitív terhelés.
- Csökkenteni azt a kódmennyiséget, amellyel egyszerre dolgoznak – kevesebb kód – kevesebb terhelés.
- Egyszerűsíteni a fokozatos változtatások végrehajtását az alkalmazásban.
A fejlesztési időkeretek csökkentése
Térjünk vissza azokra az időkre, amikor a waterfall módszertan standard volt a fejlesztési folyamatban, és a hat hónaptól két évig terjedő időkeretek az alkalmazás fejlesztésére vagy frissítésére általános gyakorlattá váltak. Általában a mérnökök először elolvasták a megfelelő dokumentumokat, mint például a termék követelményeket (PRD), a rendszer hivatkozási dokumentumát (SRD), az architektúra tervet, és elkezdték ezeket összegyúrni egy kognitív modellbe, amely alapján kódot írtak. Ahogy a követelmények és az architektúra változott, komoly erőfeszítéseket kellett tenni az egész csapat informálására a kognitív modell frissítéseiről. Ilyen megközelítés a legrosszabb esetben egyszerűen megbéníthatta a munkát. A legnagyobb változás az alkalmazásfejlesztés folyamatában az agilis módszertan bevezetése volt. Az agilis módszertan egyik alapvető jellemzője az iteratív fejlesztés.
Ez viszont csökkenti a mérnökök kognitív terhelését. Ahelyett, hogy azt várnánk a fejlesztői csapattól, hogy egy hosszú ciklus alatt megvalósítsák az alkalmazást, ez a megközelítés lehetővé teszi, hogy kis mennyiségű kódra összpontosítsanak, amelyet gyorsan tesztelni és telepíteni lehet, miközben visszajelzést is kapnak. Az alkalmazás kognitív terhelése elmozdult a hat hónap és két év közötti időkerettől, figyelembe véve rengeteg specifikációt egy kéthetes funkció hozzáadásához vagy módosításához, amit egy tágabb értelemben vett nagy alkalmazásról való meglátás is kedvezőbbé tesz. agile ez a megközelítés lehetővé teszi, hogy kis mennyiségű kódra összpontosítsanak, amelyet gyorsan tesztelni és telepíteni lehet, miközben visszajelzést is kapnak. Az alkalmazás kognitív terhelése elmozdult a hat hónap és két év közötti időkerettől, figyelembe véve rengeteg specifikációt egy kéthetes funkció hozzáadásához vagy módosításához, amit egy tágabb értelemben vett nagy alkalmazásról való meglátás is kedvezőbbé tesz. approach allows for a focus on small amounts of code that can be quickly tested and deployed, while also receiving feedback. The cognitive load of an application has shifted from a time frame of six months to two years with a huge number of specifications to a two-week addition or change of a feature, oriented toward a more nebulous understanding of a large application.
A fókusz elmozdítása a nagyméretű alkalmazásokról konkrét, kis funkciókra, amelyeket két hét alatt be lehet fejezni, anélkül, hogy többet néznénk előre, mint egy funkció a következő sprintről, jelentős változást jelent. Ez lehetővé tette a fejlesztési produktivitás növelését, miközben csökkentette a folyamatosan ingadozó kognitív terhelést.
A módszertan ez a megközelítés lehetővé teszi, hogy kis mennyiségű kódra összpontosítsanak, amelyet gyorsan tesztelni és telepíteni lehet, miközben visszajelzést is kapnak. Az alkalmazás kognitív terhelése elmozdult a hat hónap és két év közötti időkerettől, figyelembe véve rengeteg specifikációt egy kéthetes funkció hozzáadásához vagy módosításához, amit egy tágabb értelemben vett nagy alkalmazásról való meglátás is kedvezőbbé tesz. feltételezi, hogy a végső alkalmazás egy módosított verziója lesz az eredeti koncepciónak, ezért a fejlesztési folyamat végső pontja szükségszerűen bizonytalan. Csak az egyes sprintek konkrét eredményei lehetnek világosak és egyértelműek.
Kis kódalapok
A kognitív terhelés csökkentésének következő lépése a kódalap csökkentése. Általában a modern alkalmazások nagyméretűek – egy megbízható, vállalati alkalmazás lehet több ezer fájlból és számos ezer sor kódból áll. A fájlok közötti kapcsolatok és a kód fájlok közötti függőségek nyilvánvalóak lehetnek, vagy éppen ellenkezőleg. Még a kód végrehajtásának hibakeresése is problémákat okozhat, attól függően, hogy milyen könyvtárakat használunk, és mennyire jól különböztetik meg a hibakereső eszközök a könyvtárakat/csomagokat/moduleket és a felhasználói kódot.
A program kódjának működési mentális modelljének felépítése jelentős időt is igénybe vehet, és újra nagy kognitív terhelést ró a fejlesztőre. Ez különösen jellemző a monolitikus kódalapokra, ahol a kód mennyisége nagy, és a funkcionális összetevők közötti interakciók nincsenek világosan meghatározva, míg a figyelem szétválasztása gyakran elmosódott, mivel nem tartják be a funkcionális határokat.
Az egyik hatékony módszer a mérnökök kognitív terhelésének csökkentésére a mikroszerviz-architektúrára való áttérés. A mikroszerviz megközelítésében minden szolgáltatás egy funkciócsoportra összpontosít; a szolgáltatás értelme általában meghatározott és érthető. A szolgáltatás határai is világosak – ne feledjük, hogy a szolgáltatással való kommunikáció API-n keresztül történik, így az egy szolgáltatás által generált adatok könnyen átadhatók egy másiknak.
A szolgáltatások közötti interakció általában néhány felhasználói szolgáltatásra és a szolgáltató néhány szolgáltatására korlátozódik, amelyek egyszerű és tiszta API hívásokat használnak, például REST segítségével. Ez azt jelenti, hogy a mérnökök kognitív terhelése jelentősen csökken. A legnehezebb feladat továbbra is a szolgáltatások közötti interakciós modell megértése és annak megértése, hogy az olyan dolgok, mint a tranzakciók, hogyan történnek több szolgáltatásban. Végső soron a mikroszolgáltatások alkalmazása csökkenti a kognitív terhelést azáltal, hogy csökkenti a kód mennyiségét, egyértelmű határokat szab a szolgáltatások között, és biztosítja a felhasználók és szolgáltatók közötti kapcsolatok megértését.
Kis, fokozatos változások
A elv utolsó eleme kicsinyek – ez a változások kezelése. Különösen csábító a fejlesztők számára, hogy rápillantsanak a kódalapra (még a saját, régebbi kódjukra is), és azt mondják: "Ez szemétdomb, ezt mind újra kellene írni." Néha ez helyes döntés, máskor nem. Ez a csapatra hárítja a globális modellváltoztatás terhét, ami viszont fokozott kognitív terhelést eredményez. Jobb, ha a mérnökök arra összpontosítanak, hogy azokat a változtatásokat végezzék el a sprintek során, amelyek révén időben ki tudják adni a szükséges funkciót, még ha fokozatosan is. A végterméknek hasonlítania kell egy előre tervezett termékre, néhány módosítással és teszteléssel, hogy megfeleljen a kliens igényeinek.
Néha lehetetlen gyorsan végrehajtani a változtatásokat nagy kódrészletek átkonvertálásakor, mivel más rendszerszempontok is közbe lépnek. A változások áramlásának ellenőrzésére használható a funkciók elrejtése (feature hiding). Ez lényegében annyit jelent, hogy a funkció aktív a termelési környezetben, de a környezeti változók (env-var) vagy más konfigurációs mechanizmusok beállításai révén nem elérhető. Ha a kód sikeresen teljesítette az összes minőségellenőrzési folyamatot, akkor rejtve kerülhet a termelési környezetbe. Ez a stratégia azonban csak akkor működik, ha a funkció végül be lesz kapcsolva. Ellenkező esetben csak zsúfolttá teszi a kódot, így megnöveli a fejlesztőkre nehezedő kognitív terheket, amelyeket kezelniük kell a hatékony munkához. A változások kezelése és az incrementális módosítások eleve segítenek a fejlesztők kognitív terheinek elérhető szinten tartásában.
A mérnököknek sok nehézséggel kell megküzdeniük még egy új funkció egyszerű bevezetésekor is. A vezetőség részéről ésszerű lesz csökkenteni a csapatra nehezedő felesleges terheket, hogy a kulcsfontosságú funkciókra tudjanak összpontosítani. Három dolgot tehet, hogy segítse fejlesztőcsapatát:
- Használjon módszertant
ez a megközelítés lehetővé teszi, hogy kis mennyiségű kódra összpontosítsanak, amelyet gyorsan tesztelni és telepíteni lehet, miközben visszajelzést is kapnak. Az alkalmazás kognitív terhelése elmozdult a hat hónap és két év közötti időkerettől, figyelembe véve rengeteg specifikációt egy kéthetes funkció hozzáadásához vagy módosításához, amit egy tágabb értelemben vett nagy alkalmazásról való meglátás is kedvezőbbé tesz., hogy korlátozza az időkereteket, amelyekben a csapatnak koncentrálnia kell a kulcsfontosságú funkciókra. - Valósítsa meg alkalmazását több mikroszolgáltatásként. Ez korlátozza a bevezetendő funkciók számát, és megerősíti a határokat, amelyek megakadályozzák a kognitív terhelést munka közben.
- Előnyben részesítse az incrementális változtatásokat a nagyméretű, terjedelmes módosításokkal szemben, és változtasson meg kis kódrészleteket. Alkalmazzon funkcióelrejtést, hogy végrehajthassa a módosításokat, még akkor is, ha azok nem láthatók azonnal a hozzáadás után.
Ha a munkádban a kis lépték elvét alkalmazod, a csapatod sokkal boldogabb lesz, jobban tud fókuszálni a szükséges funkciók megvalósítására, és valószínűbb, hogy gyorsabban képes lesz minőségi változtatásokat bevezetni. De ez nem jelenti azt, hogy a munka nem bonyolódhat, néha éppen ellenkezőleg, az új funkciók bevezetése több szolgáltatás módosítását igényli, és ez a folyamat bonyolultabb lehet, mint a hasonló egy monolitikus architektúrában. Mindenesetre a kis lépték alkalmazásának előnyei megérik az árát.
Az első rész vége.
Hamarosan nyilvánosá tesszük a fordítás második részét, de addig is várjuk a kommentjeiteket és meghívunk a , amely ma 20:00-kor kerül megrendezésre.
Forrás: habr.com
