Ola amigos. Á espera da posta en marcha do curso , tradicionalmente compartimos contigo a tradución de material útil.
O software resolve cada vez máis problemas cotiáns, ao tempo que se fai cada vez máis complexo. Como dixo Marc Andreessen unha vez, está consumindo o mundo.
Como resultado, a forma en que se desenvolven e entregan as aplicacións cambiou drasticamente nos últimos anos. Estes foron cambios a escala tectónica que deron lugar a un conxunto de principios. Estes principios resultaron útiles para construír un equipo, deseñar, desenvolver e entregar a túa aplicación aos usuarios finais.
Os principios poden resumirse do seguinte xeito: a aplicación debe ser pequena, baseada na web e ter unha arquitectura centrada no desenvolvedor. A partir destes tres principios, pode crear unha aplicación robusta de extremo a extremo que se poida entregar ao usuario final de forma rápida e segura e que sexa facilmente escalable e extensible.
Cada un dos principios propostos ten unha serie de aspectos que analizaremos para mostrar como cada principio contribúe ao obxectivo final de ofrecer rapidamente aplicacións fiables que sexan fáciles de manter e usar. Observaremos os principios en comparación cos seus opostos para aclarar o que significa dicir: "Asegúrate de usar principio de pequenez».
Agardamos que este artigo che anime a utilizar os principios propostos para crear aplicacións modernas que proporcionarán un enfoque de deseño unificado no contexto dunha pila de tecnoloxía en constante crecemento.
Ao aplicar estes principios, atoparase aproveitando as últimas tendencias no desenvolvemento de software, incluíndo o ao desenvolvemento e entrega de aplicacións, o uso de contedores (por exemplo, ) e marcos de orquestración de contedores (por exemplo, ), uso de microservizos (incluída a arquitectura de microservizos и para aplicacións de microservizos.
Que é unha aplicación moderna?
Aplicacións modernas? Pila moderna? Que significa exactamente "moderno"?
A maioría dos desenvolvedores só teñen unha comprensión básica do que consiste unha aplicación moderna, polo que é necesario definir claramente este concepto.
Unha aplicación moderna admite varios clientes, xa sexa unha interface de usuario mediante a biblioteca React JavaScript, unha aplicación móbil para Android ou iOS ou unha aplicación que se conecta a outra mediante unha API. Unha aplicación moderna implica un número indefinido de clientes para os que proporciona datos ou servizos.
Unha aplicación moderna proporciona unha API para acceder aos datos e servizos solicitados. A API debe ser inmutable e constante, e non debe estar escrita especificamente para unha solicitude específica dun cliente específico. A API está dispoñible a través de HTTP(S) e proporciona acceso a todas as funcións que se atopan na GUI ou na CLI.
Os datos deben estar dispoñibles nun formato común e interoperable, como JSON. Unha API expón obxectos e servizos nunha forma clara e organizada; por exemplo, unha API RESTful ou GraphQL proporcionan unha interface decente.
As aplicacións modernas están construídas sobre unha pila moderna, e unha pila moderna é a pila que admite tales aplicacións, respectivamente. Esta pila permite ao programador crear facilmente unha aplicación cunha interface HTTP e borrar os puntos finais da API. O enfoque que elixas permitirá que a túa aplicación acepte e envíe facilmente datos en formato JSON. Noutras palabras, a pila moderna corresponde aos elementos da aplicación de doce factores .
As versións populares deste tipo de pila baséanse , , , , и . Arquitectura de microservizos representa un exemplo de pila moderna implementada en cada unha das linguas mencionadas.
Teña en conta que non defendemos un enfoque puramente de microservizos. Moitos de vostedes están a traballar con monólitos que necesitan evolucionar, mentres que outros están lidando con aplicacións SOA que se están expandiendo e evolucionando para converterse en aplicacións de microservizos. Outros aínda están avanzando cara a aplicacións sen servidor, e algúns están implementando combinacións dos anteriores. Os principios descritos neste artigo aplícanse a cada un destes sistemas con só algunhas pequenas modificacións.
Principios
Agora que temos unha comprensión básica do que son unha aplicación moderna e unha pila moderna, é hora de mergullarse nos principios de arquitectura e deseño que che servirán para deseñar, implementar e manter unha aplicación moderna.
Un dos principios é "construír pequenas aplicacións", chamémoslle o principio de pequenez. Hai aplicacións incriblemente complexas que teñen moitas partes móbiles. Á súa vez, a construción dunha aplicación a partir de compoñentes pequenos e discretos facilita o deseño, o mantemento e o uso en xeral. (Ten en conta que dixemos "fai sinxelo" e non "faino sinxelo").
O segundo principio é que podemos aumentar a produtividade dos desenvolvedores axudándoos a centrarse nas funcións que están a desenvolver, ao tempo que os liberamos de preocuparse pola infraestrutura e o CI/CD durante a implementación. Entón, en poucas palabras, o noso enfoque orientado a desenvolvedores.
Finalmente, todo sobre a súa aplicación debe estar conectado á rede. Durante os últimos 20 anos, avanzamos moito cara a un futuro en rede, xa que as redes fixéronse máis rápidas e as aplicacións facíanse máis complexas. Como xa vimos, unha aplicación moderna debe ser usada nunha rede por moitos clientes diferentes. Aplicar o pensamento de rede á arquitectura ten importantes beneficios que se adaptan ben o principio de pequenez e o concepto do enfoque, orientado a desenvolvedores.
Se tes estes principios presentes ao deseñar e implementar unha aplicación, terás unha clara vantaxe no desenvolvemento e entrega do teu produto.
Vexamos estes tres principios con máis detalle.
O principio de pequenez
É difícil para o cerebro humano percibir grandes cantidades de información á vez. En psicoloxía, o termo carga cognitiva refírese á cantidade total de esforzo mental necesario para reter a información na memoria. Reducir a carga cognitiva dos desenvolvedores é unha prioridade porque poden concentrarse en resolver o problema en lugar de manter na súa cabeza o modelo complexo actual de toda a aplicación e as funcións que se están a desenvolver.
As solicitudes descompóñense polas seguintes razóns:
- Reducir a carga cognitiva dos desenvolvedores;
- Aceleración e simplificación das probas;
- Entrega rápida de cambios na aplicación.
Hai varias formas de reducir a carga cognitiva dos desenvolvedores, e aquí é onde entra en xogo o principio de pequeñez.
Así, hai tres formas de reducir a carga cognitiva:
- Reducir o período de tempo que teñen que considerar ao desenvolver unha nova función: canto máis curto sexa o período de tempo, menor será a carga cognitiva.
- Reduce a cantidade de código no que se está traballando á vez - menos código - menos carga.
- Simplifique o proceso de facer cambios incrementais na súa aplicación.
Redución dos prazos de desenvolvemento
Volvamos aos tempos nos que a metodoloxía waterfall era o estándar para o proceso de desenvolvemento, e os prazos de seis meses a dous anos para desenvolver ou actualizar unha aplicación eran unha práctica común. Normalmente, os enxeñeiros lerían primeiro documentos relevantes, como requisitos de produto (PRD), documento de referencia do sistema (SRD), plan de arquitectura e comezaban a integrar todas estas cousas nun só modelo cognitivo segundo o cal escribiron código. A medida que os requisitos, e polo tanto a arquitectura, cambiaron, houbo que facer importantes esforzos para manter informado a todo o equipo sobre as actualizacións do modelo cognitivo. No peor dos casos, este enfoque podería simplemente paralizar o traballo.
O maior cambio no proceso de desenvolvemento de aplicacións foi a introdución da metodoloxía áxil. Unha das principais características da metodoloxía agile - Este é un desenvolvemento iterativo. Á súa vez, isto leva a unha redución da carga cognitiva dos enxeñeiros. En lugar de esixir ao equipo de desenvolvemento que implemente a aplicación nun ciclo longo, agile O enfoque permítelle centrarse en pequenas cantidades de código que se poden probar e implementar rapidamente, ao mesmo tempo que recibe comentarios. A carga cognitiva dunha aplicación pasou dun período de tempo de seis meses a dous anos, cunha gran cantidade de especificacións, a unha adición ou cambio de funcións de dúas semanas, orientada a unha comprensión máis difusa dunha aplicación grande.
Cambiar o foco dunha aplicación masiva a pequenas funcións específicas que se poden completar nun sprint de dúas semanas, mirando cara adiante a non máis que unha función do próximo sprint en mente é un cambio significativo. Isto permitiu aumentar a produtividade do desenvolvemento á vez que se reduciu a carga cognitiva, que fluctúa constantemente.
En metodoloxía agile espérase que a aplicación final sexa unha versión lixeiramente modificada do concepto orixinal, polo que o punto de desenvolvemento final é necesariamente ambiguo. Só os resultados de cada sprint específico poden ser claros e precisos.
Pequenas bases de código
O seguinte paso para reducir a carga cognitiva é reducir a base de código. Normalmente, as aplicacións modernas son masivas: unha aplicación empresarial robusta pode constar de miles de ficheiros e centos de miles de liñas de código. Dependendo da organización dos ficheiros, as conexións e dependencias entre o código e os ficheiros poden ser ou non obvias. Mesmo depurar a propia execución do código pode ser problemático, dependendo das bibliotecas utilizadas e do ben que as ferramentas de depuración diferencien entre bibliotecas/paquetes/módulos e código de usuario.
Construír un modelo mental que funcione do código dunha aplicación pode levar unha cantidade significativa de tempo, poñendo de novo unha gran carga cognitiva para o programador. Isto é especialmente certo para as bases de código monolíticas, onde hai unha gran cantidade de código, as interaccións entre os compoñentes funcionais non están claramente definidas e a separación dos obxectos de atención adoita ser borrosa porque non se respectan os límites funcionais.
Unha forma eficaz de reducir a carga cognitiva dos enxeñeiros é pasar a unha arquitectura de microservizos. Nun enfoque de microservizos, cada servizo céntrase nun conxunto de funcións; o significado do servizo adoita ser definido e comprensible. Os límites do servizo tamén están claros: lembra que a comunicación co servizo realízase mediante unha API, polo que os datos xerados por un servizo pódense transferir facilmente a outro.
A interacción con outros servizos adoita limitarse a algúns servizos de usuario e algúns servizos de provedores que usan chamadas de API simples e limpas, como REST. Isto significa que a carga cognitiva do enxeñeiro redúcese seriamente. O maior desafío segue sendo comprender o modelo de interacción do servizo e como ocorren cousas como as transaccións en varios servizos. En definitiva, o uso de microservizos reduce a carga cognitiva ao reducir a cantidade de código, definir límites claros do servizo e proporcionar información sobre a relación usuario-provedor.
Pequenos cambios incrementais
O último elemento do principio un pouco é a xestión do cambio. É especialmente tentador para os desenvolvedores mirar unha base de código (incluso quizais o seu propio código máis antigo) e dicir: "Isto é unha merda, necesitamos reescribir todo isto". Ás veces é a decisión correcta, e ás veces non. Coloca a carga dos cambios globais de modelos sobre o equipo de desenvolvemento, o que á súa vez resulta nunha carga cognitiva masiva. É mellor que os enxeñeiros se centren nos cambios que poden facer durante o sprint, para que despois poidan implementar a funcionalidade necesaria de forma oportuna, aínda que de forma gradual. O produto final debe parecerse ao pre-planeado, pero con algunhas modificacións e probas para adaptarse ás necesidades do cliente.
Ao reescribir grandes porcións de código, ás veces é imposible realizar un cambio rapidamente porque entran en xogo outras dependencias do sistema. Para controlar o fluxo de cambios, pode usar a ocultación de funcións. Basicamente, isto significa que a funcionalidade está aí en produción, pero non está dispoñible mediante a configuración das variables de ambiente (env-var) ou calquera outro mecanismo de configuración. Se o código pasou todos os procesos de control de calidade, pode acabar na produción nun estado oculto. Non obstante, esta estratexia só funciona se finalmente se activa a función. En caso contrario, só desordenará o código e engadirá carga cognitiva á que o programador terá que facer fronte para ser produtivo. A xestión do cambio e os cambios incrementais en si mesmos axudan a manter a carga cognitiva dos desenvolvedores nun nivel accesible.
Os enxeñeiros teñen que superar moitas dificultades mesmo cando simplemente implementan funcionalidades adicionais. Sería prudente que a dirección reduza a carga de traballo innecesaria do equipo para que este poida centrarse nos elementos clave da funcionalidade. Hai tres cousas que podes facer para axudar ao teu equipo de desenvolvemento:
- Utilizar a metodoloxía
agile, para limitar o período de tempo no que o equipo debe centrarse nas características clave. - Implementa a túa aplicación como varios microservizos. Isto limitará o número de funcións introducidas e reforzará os límites que conteñen a carga cognitiva mentres se traballa.
- Prefire cambios incrementais aos grandes e difíciles de manexar, cambie pequenos fragmentos de código. Usa a función ocultar para implementar cambios aínda que non sexan visibles inmediatamente despois de engadilos.
Se aplicas o principio de pequeñez no teu traballo, o teu equipo estará moito máis feliz, estará mellor centrado en ofrecer as funcións necesarias e terá máis probabilidades de implementar cambios de calidade máis rápido. Pero isto non quere dicir que o traballo non poida chegar a ser máis complexo; en ocasións, pola contra, a introdución de novas funcionalidades require a modificación de varios servizos e este proceso pode ser máis complexo que outro similar nunha arquitectura monolítica. En calquera caso, os beneficios de usar o enfoque valen un pouco a pena.
Fin da primeira parte.
En breve publicaremos a segunda parte da tradución, pero agora agardamos os vosos comentarios e invitámosvos a , que terá lugar hoxe ás 20.00 horas.
Fonte: www.habr.com