Hola amics. En previsió de la posada en marxa del curs , tradicionalment comparteix amb tu la traducció de material útil.
El programari resol cada cop més tasques quotidianes, alhora que esdevé cada vegada més complex. Com va dir Marc Andressen, consumeix el món.
Com a resultat, la forma en què es desenvolupen i es distribueixen les aplicacions ha canviat dràsticament durant els últims anys. Aquests van ser canvis d'escala tectònica que van donar lloc a un conjunt de principis. Aquests principis han demostrat ser útils per crear equips, dissenyar, desenvolupar i lliurar la vostra aplicació als usuaris finals.
Els principis es poden resumir de la següent manera: l'aplicació ha de ser petita, basada en web i tenir una arquitectura centrada en el desenvolupador. Tenint en compte aquests tres principis, podeu crear una aplicació robusta d'extrem a extrem que es pugui lliurar de manera ràpida i segura a l'usuari final i que sigui fàcilment escalable i extensible.
Cadascun dels principis proposats té una sèrie d'aspectes que parlarem per mostrar com cada principi contribueix a l'objectiu final, que és el lliurament ràpid d'aplicacions fiables que siguin fàcils de mantenir i utilitzar. Mirarem els principis en relació amb els seus oposats per tal d'aclarir què vol dir, per exemple, "Assegureu-vos que feu servir principi de petitesa».
Esperem que aquest article us encoratgi a utilitzar els principis proposats per crear aplicacions modernes, que proporcionaran un enfocament unificat del disseny en el context d'una pila tecnològica en constant creixement.
En aplicar aquests principis, us trobareu aprofitant les últimes tendències en desenvolupament de programari, inclòs el al desenvolupament i lliurament d'aplicacions, l'ús de contenidors (per exemple, ) i marcs d'orquestració de contenidors (per exemple, ), l'ús de microserveis (inclosa l'Arquitectura de microserveis и per a aplicacions de microservei.
Què és una aplicació moderna?
Aplicacions modernes? Pila moderna? Què vol dir exactament "modern"?
La majoria dels desenvolupadors només tenen una idea general de en què consisteix una aplicació moderna, per la qual cosa cal definir clarament aquest concepte.
Una aplicació moderna admet diversos clients, ja sigui una interfície d'usuari de la biblioteca React JavaScript, una aplicació mòbil per a Android o iOS o una aplicació que es connecti a una altra API. Una aplicació moderna implica un nombre indefinit de clients als quals proporciona dades o serveis.
Una aplicació moderna proporciona una API per accedir a les dades i serveis sol·licitats. L'API ha de ser immutable i constant, i no ha de ser escrita específicament per a una sol·licitud específica d'un client específic. L'API està disponible a través d'HTTP(S) i proporciona accés a totes les funcionalitats disponibles a la GUI o CLI.
Les dades han d'estar disponibles en un format interoperable comunament acceptat, com ara JSON. Una API exposa objectes i serveis d'una manera neta i organitzada, com ara l'API RESTful o GraphQL proporcionen una interfície decent.
Les aplicacions modernes es basen en la pila moderna, i la pila moderna és la pila que admet aquestes aplicacions, respectivament. Aquesta pila permet a un desenvolupador crear fàcilment una aplicació amb una interfície HTTP i esborrar els punts finals de l'API. L'enfocament escollit permetrà que la vostra aplicació rebi i enviï dades fàcilment en format JSON. En altres paraules, la pila moderna correspon als elements de l'aplicació de dotze factors .
Es basen les versions populars d'aquest tipus de pila , , , , и . Arquitectura de microserveis representa un exemple de pila moderna implementada en cadascun dels idiomes esmentats.
Tingueu en compte que no defensem un enfocament exclusivament de microserveis. Molts de vosaltres esteu treballant amb monòlits que necessiten evolucionar, mentre que altres tracten amb aplicacions SOA que s'estan expandint i evolucionant per convertir-se en aplicacions de microservei. Altres encara estan avançant cap a aplicacions sense servidor i alguns estan implementant combinacions de les anteriors. Els principis descrits a l'article s'apliquen a cadascun d'aquests sistemes amb només algunes modificacions menors.
Principis
Ara que tenim una comprensió comuna del que són una aplicació moderna i una pila moderna, és hora d'aprofundir en l'arquitectura i els principis de desenvolupament que us serviran bé per desenvolupar, implementar i mantenir una aplicació moderna.
Un dels principis sona a "fer petites aplicacions", diguem-ne principi de petitesa. Hi ha aplicacions increïblement complexes que estan formades per moltes parts mòbils. Al seu torn, la creació d'una aplicació a partir de components petits i discrets facilita el disseny, el manteniment i el treball amb ella en conjunt. (Tingueu en compte que hem dit "simplifica" no "fa simple").
El segon principi és que podem augmentar la productivitat dels desenvolupadors ajudant-los a centrar-se en les funcions que estan desenvolupant, alhora que els alliberem de les preocupacions d'infraestructura i CI/CD durant la implementació. Per tant, en poques paraules, el nostre enfocament centrat en els desenvolupadors.
Finalment, tot el relacionat amb la vostra aplicació ha d'estar connectat a la xarxa. Durant els últims 20 anys, hem fet grans avenços cap a un futur en xarxa a mesura que les xarxes es fan més ràpides i les aplicacions més complexes. Com ja hem vist, una aplicació moderna ha de ser utilitzada a través d'una xarxa per molts clients diferents. Aplicar el pensament de xarxa a l'arquitectura té avantatges significatius que van bé principi de petitesa i el concepte d'enfocament, orientat al desenvolupador.
Si tens presents aquests principis a l'hora de dissenyar i implementar una aplicació, tindreu un avantatge innegable en el desenvolupament i lliurament del vostre producte.
Vegem aquests tres principis amb més detall.
Principi de petitesa
És difícil per al cervell humà percebre una gran quantitat d'informació al mateix temps. En psicologia, el terme càrrega cognitiva es refereix a la quantitat total d'esforç mental necessari per retenir la informació a la memòria. Reduir la càrrega cognitiva dels desenvolupadors és una prioritat perquè els permet centrar-se a resoldre el problema en lloc de mantenir al cap el model complex actual de tota l'aplicació i les característiques que s'estan desenvolupant.
Les aplicacions es descomponen pels motius següents:
- Reducció de la càrrega cognitiva dels desenvolupadors;
- Acceleració i simplificació de les proves;
- Entrega ràpida de canvis a l'aplicació.
Hi ha diverses maneres de reduir la càrrega cognitiva dels desenvolupadors, i aquí és on entra en joc el principi de petitesa.
Així que aquí hi ha tres maneres de reduir la càrrega cognitiva:
- Reduïu el període de temps que han de tenir en compte a l'hora de desenvolupar una funció nova: com més curt sigui el període de temps, menor serà la càrrega cognitiva.
- Reduïu la quantitat de codi en què es fa un treball únic - menys codi - menys càrrega.
- Simplifica el procés de fer canvis incrementals a una aplicació.
Reducció del temps de desenvolupament
Tornem a l'època en què la metodologia waterfall era l'estàndard per al procés de desenvolupament, i els terminis de sis mesos a dos anys per desenvolupar o actualitzar una aplicació eren una pràctica habitual. Normalment, els enginyers llegeixen primer documents rellevants, com ara els requisits del producte (PRD), el document de referència del sistema (SRD), el pla d'arquitectura, i començaven a combinar totes aquestes coses en un sol model cognitiu, segons el qual codificaven. A mesura que els requisits i, en conseqüència, l'arquitectura van canviar, es va haver de fer un esforç seriós per informar a tot l'equip sobre les actualitzacions del model cognitiu. Aquest enfocament, en el pitjor dels casos, podria simplement paralitzar el treball.
El canvi més important en el procés de desenvolupament d'aplicacions va ser la introducció de la metodologia àgil. Una de les característiques principals de la metodologia agile és un desenvolupament iteratiu. Al seu torn, això comporta una reducció de la càrrega cognitiva dels enginyers. En lloc d'exigir que l'equip de desenvolupament implementi l'aplicació en un cicle llarg, agile L'enfocament us permet centrar-vos en petites quantitats de codi que es poden provar i desplegar ràpidament, alhora que rebeu comentaris. La càrrega cognitiva de l'aplicació ha canviat d'un període de temps de sis mesos a dos anys amb una gran quantitat d'especificacions per a una addició de dues setmanes o un canvi de funció orientat a una comprensió més borrosa d'una aplicació gran.
Canviar l'enfocament d'una aplicació massiva a petites funcions específiques que es poden completar en un sprint de dues setmanes, amb no més d'una funció abans del següent sprint, és un canvi important. Això ens va permetre augmentar la productivitat del desenvolupament alhora que reduïm la càrrega cognitiva, que fluctuava constantment.
En metodologia agile s'espera que l'aplicació final sigui una versió lleugerament modificada del concepte original, de manera que el punt final del desenvolupament és necessàriament ambigu. Només els resultats de cada sprint específic poden ser clars i precisos.
Petites bases de codi
El següent pas per reduir la càrrega cognitiva és reduir la base del codi. Per regla general, les aplicacions modernes són massives: una aplicació empresarial robusta pot constar de milers de fitxers i centenars de milers de línies de codi. Segons com estiguin organitzats els fitxers, els enllaços i les dependències entre el codi i els fitxers poden ser evidents, o viceversa. Fins i tot l'execució del codi de depuració en si pot ser problemàtica, depenent de les biblioteques utilitzades i de com distingeixen les eines de depuració entre biblioteques/paquets/mòduls i codi personalitzat.
La construcció d'un model mental que funcioni del codi d'una aplicació pot trigar una quantitat de temps impressionant i, una vegada més, suposa una gran càrrega cognitiva per al desenvolupador. Això és especialment cert per a les bases de codi monolítics, on hi ha una gran quantitat de codi, la interacció entre els components funcionals del qual no està clarament definida i la separació dels objectes d'atenció sovint es difumina perquè no es respecten els límits funcionals.
Una de les maneres efectives de reduir la càrrega cognitiva dels enginyers és passar a una arquitectura de microservei. En un enfocament de microservei, cada servei se centra en un conjunt de funcions; mentre que el significat del servei sol estar definit i comprensible. Els límits d'un servei també són clars: recordeu que la comunicació amb un servei es fa mitjançant una API, de manera que les dades generades per un servei es poden passar fàcilment a un altre.
La interacció amb altres serveis normalment es limita a uns quants serveis d'usuari i uns quants serveis de proveïdor que utilitzen trucades d'API simples i netes, com ara REST. Això significa que la càrrega cognitiva de l'enginyer es redueix seriosament. El repte més gran continua sent entendre el model d'interacció del servei i com succeeixen coses com les transaccions en diversos serveis. Com a resultat, l'ús de microserveis redueix la càrrega cognitiva reduint la quantitat de codi, definint límits clars del servei i proporcionant una comprensió de la relació entre usuaris i proveïdors.
Petits canvis incrementals
L'últim element del principi petitesa és la gestió del canvi. És una temptació particular per als desenvolupadors mirar la base de codi (fins i tot potser el seu propi codi més antic) i dir: "Això és una merda, hem de reescriure-ho tot". De vegades aquesta és la decisió correcta, i de vegades no. Posa la càrrega del canvi de model global a l'equip de desenvolupament, que al seu torn comporta una càrrega cognitiva massiva. És millor que els enginyers se centren en els canvis que poden fer durant l'esprint, de manera que puguin desplegar la funcionalitat necessària de manera oportuna, encara que de manera gradual. El producte final s'ha de semblar al pre-planificat, però amb algunes modificacions i proves per adaptar-se a les necessitats del client.
Quan es reescriu grans porcions de codi, de vegades no és possible lliurar el canvi ràpidament perquè entren en joc altres dependències del sistema. Per controlar el flux de canvis, podeu utilitzar l'ocultació de funcions. En principi, això significa que la funcionalitat està en producció, però no està disponible mitjançant la configuració de la variable d'entorn (env-var) o algun altre mecanisme de configuració. Si el codi ha passat tots els processos de control de qualitat, pot acabar en producció en estat latent. Tanmateix, aquesta estratègia només funciona si finalment s'habilita la funció. En cas contrari, només desordenarà el codi i afegirà una càrrega cognitiva que el desenvolupador haurà de fer front per ser productiu. La gestió del canvi i els canvis incrementals en si mateixos ajuden a mantenir la càrrega cognitiva dels desenvolupadors a un nivell assequible.
Els enginyers han de superar moltes dificultats fins i tot amb la simple introducció de funcionalitats addicionals. Per part de la direcció, seria prudent reduir la càrrega innecessària de l'equip perquè es pugui centrar en elements funcionals clau. Hi ha tres coses que podeu fer per ajudar el vostre equip de desenvolupament:
- Utilitzar la metodologia
agileper limitar el període de temps en què l'equip s'ha de centrar en les característiques clau. - Implementeu la vostra aplicació com a diversos microserveis. Això limitarà el nombre de funcions que es poden implementar i reforçarà els límits que mantenen la càrrega cognitiva en el treball.
- Preferiu els canvis incrementals a grans i difícils de manejar, canvieu petits fragments de codi. Utilitzeu l'ocultació de funcions per implementar canvis encara que no siguin visibles immediatament després d'haver-se afegit.
Si apliqueu el principi de petitesa en el vostre treball, el vostre equip estarà molt més feliç, més centrat en la implementació de les funcions necessàries i tindrà més probabilitats de desplegar canvis qualitatius més ràpidament. Però això no vol dir que el treball no es pugui complicar, de vegades, al contrari, la introducció de noves funcionalitats requereix la modificació de diversos serveis, i aquest procés pot ser més difícil que semblant en una arquitectura monolítica. En qualsevol cas, els beneficis d'adoptar l'enfocament de la petitesa valen la pena.
Final de la primera part.
Aviat publicarem la segona part de la traducció, i ara esperem els vostres comentaris i us convidem a , que tindrà lloc avui a les 20.00 hores.
Font: www.habr.com