Desarrollo frontend en la empresa: qué es y cómo hacerlo efectivo
En KORUS Consulting CIS llevamos más de diez años organizando el desarrollo de servicios web para nuestros clientes. Ya tenemos varias docenas de proyectos serios en el sector bancario, algunos de los cuales han recibido reconocimiento internacional.En los últimos dos años, el número de equipos y proyectos en nuestra compañía ha aumentado varias veces, mientras que la efectividad del desarrollo frontend también ha crecido muchas veces. Aprendimos a crear aplicaciones en unas pocas semanas en lugar de unos meses.Estamos trabajando constantemente en el desarrollo de la infraestructura de nuestro desarrollo front-end, y hoy compartiré algunos desarrollos sobre la organización de la unidad front-end, que pueden ser útiles para aquellos que organizan el front-end en su empresa.En este artículo, aprenderá sobre nuestro camino para responder las siguientes preguntas:La parte frontend de un sitio o aplicación es lo que ve en su navegador, esta parte interactúa activamente con la parte del servidor (back-end), que se encuentra en cualquier servidor, intercambiando datos constantemente con él.Desde un punto de vista técnico, el front-end de la aplicación es un conjunto de archivos, entre los que se encuentran archivos HTML, CSS y JavaScript, imágenes, etc. El trabajo con CSS y HTML está relacionado con la composición tipográfica, JavaScript, con la programación. Ambas áreas ofrecen una gran cantidad de herramientas y tecnologías para el trabajo, se están desarrollando activamente y requieren mucho conocimiento. Esto es especialmente cierto para JavaScript, que ha escrito una gran cantidad de marcos y bibliotecas para la creación "más y más eficiente" de aplicaciones web.De alguna manera me preguntaron qué necesito ahora para hacer aplicaciones para que no se vuelvan obsoletas por varios años más.Como programador, puedo dar una respuesta completamente precisa y completamente inútil: HTML, CSS y JavaScript. Qué elegir exactamente, jQuery, Angular o React: estos son los detalles.Si profundiza en estos detalles, puede dar otra respuesta igualmente correcta e inútil: sobre cualquier cosa. Sí, es cierto. La aplicación se puede escribir en cualquier cosa, funcionará, se puede cambiar y desarrollar.¿Cuál es la diferencia?Para encontrar la respuesta, veamos qué quiere el negocio desde el principio. Creo que no sorprenderé a nadie si digo que el negocio quiere obtener un resultado de alta calidad de manera rápida y económica.Entonces, ¿en qué necesita hacer aplicaciones ahora, para que el desarrollo sea rápido, eficiente y no arruine al cliente?Velocidad de desarrollo
Un programador con amplia experiencia con React podrá escribir rápidamente una aplicación en React, tener experiencia con Angular le da la velocidad de trabajar con Angular, y así sucesivamente. Todo es bastante obvio. Los propios marcos ahorran tiempo de desarrollo al proporcionar soluciones a problemas y tareas comunes. En esencia, estas soluciones pueden estar muy cerca una de la otra, y la diferencia entre ellas puede estar en la sintaxis o en el paradigma de programación.La velocidad de desarrollo utilizando un marco particular depende de la experiencia y las calificaciones de los programadores que escriben sobre él, el marco en sí es de importancia secundaria.Calidad del producto
Aquí es lo mismo: es bueno y malo que puedas escribir en cualquier marco. Puede colocar la arquitectura correcta e incorrecta en cualquier lugar.Todo depende de la experiencia y el conocimiento del desarrollador.Costo
Todos los marcos modernos principales son gratuitos, por lo que si omite los detalles, el costo de desarrollo es el costo del tiempo que los desarrolladores dedicaron a estudiar los requisitos, las tecnologías, la elaboración de la arquitectura y la escritura del código. Además del costo de encontrar / capacitar a estos desarrolladores.De ahí la conclusión: no es necesario confiar tanto en la tecnología como en los desarrolladores y la organización de su trabajo.Casi cualquier marco popular moderno es lo suficientemente bueno como para crear casi cualquier aplicación que las empresas modernas puedan necesitar.Por lo tanto, se tratará más sobre la efectividad del front end en términos de la organización del desarrollo.Como fue con nosotros
Para 2017, teníamos aplicaciones en casi todo lo que merecía atención en el mundo de JavaScript: desde jQuery hasta diferentes versiones de Angular y React on Typecript y Flow. Los diseños y los desarrolladores de backend / fullstack trabajaron en el lado del cliente de nuestras aplicaciones. Cada desarrollador eligió herramientas para sus tareas, dependiendo de su conocimiento de las tecnologías front-end.Ahora solo puedo especular, pero me parece que la elección de frameworks y bibliotecas por parte de los desarrolladores de fullstack / backend fue algo como esto:"Veamos qué escriben en Internet ..."
Bueno, entiendes.Al elegir un marco / biblioteca, el desarrollador tiene un tiempo limitado, a menudo no tiene tiempo para implementar independientemente nuevos marcos para él y realizar aplicaciones de prueba. Por lo tanto, de alguna manera toma una decisión más o menos razonada y luego sigue en la dirección elegida.En diferentes momentos, esta elección puede ser diferente incluso para el mismo desarrollador (ver las ilustraciones anteriores). Al mismo tiempo, no se vuelve menos razonado. ¿Qué esperar de diferentes desarrolladores con diferentes experiencias?Sin el conocimiento de 2017, nos convertimos en un verdadero zoológico de tecnología front-end.Frontend como una unidad separada
Una gran cantidad de tecnologías diferentes en la empresa es una fuente de riesgo. Un desarrollador con el conocimiento necesario puede estar ocupado en otro proyecto, puede abandonar por completo la empresa. Contratar especialistas con amplia experiencia en diversos campos tampoco es una tarea fácil.La documentación de alta calidad puede mitigar los efectos negativos de dicha diversidad, pero por lo general lleva mucho tiempo estudiar y sumergirse en tecnología desconocida.En 2017, apareció una división front-end en nuestra empresa, que fue una respuesta a las crecientes demandas sobre la calidad de la parte front-end de nuestros proyectos y su cantidad, así como un intento de estabilizar la diversidad de tecnologías y aumentar la eficiencia del desarrollo.Esta fue una etapa importante para el desarrollo de nuestra empresa: lo que estamos haciendo ahora, sería imposible hacerlo con la ayuda de los desarrolladores sin especializarnos en el front-end.¿Cómo curar el zoológico?
Una variedad incontrolada de tecnologías hace que sea difícil predecir la velocidad y la calidad del desarrollo en general, mientras que el desarrollo comercial requiere precisamente eso.Por lo tanto, nuestro siguiente paso fue unificar la pila de la compañía con la ayuda de expertos de la nueva división.
Una pila unificada es un conjunto estrictamente limitado de bibliotecas y herramientas que los desarrolladores pueden usar para resolver problemas comerciales. También incluye políticas relacionadas con diferentes enfoques de programación, por ejemplo, el uso de un enfoque predominantemente funcional, o viceversa, el rechazo del mismo.Una sola pila le da al desarrollador la capacidad de cambiar rápidamente de un proyecto a otro, realizar una revisión entre equipos y compartir de manera efectiva la experiencia y las mejores prácticas con sus colegas.La tarea principal aquí no es decidir qué estamos escribiendo en React o Angular, sino hacer que los desarrolladores usen las mismas herramientas para crear aplicaciones y los mismos enfoques para resolver problemas comunes.Como referencia: nuestra herramienta principal es React, pero también estamos desarrollando experiencia en Angular.Aquí es donde comienza la diversión. Forzar en el mundo de la programación funciona muy mal.
Por lo tanto, en lugar de la coerción, debe asegurarse de que los propios desarrolladores quieran seguir ciertas reglas de desarrollo.Para hacer esto, necesitas:- de alguna manera arreglar, formalizar los requisitos de desarrollo;
- Anime a los desarrolladores a seguir estas pautas.
Formalizar una pila es una actividad que requiere la capacidad de mantener un equilibrio. No es necesario elaborar regulaciones detalladas para todo a fin de transmitir las ideas básicas a los desarrolladores. Además, crear y mantener especificaciones detalladas consume muchos recursos.Resolvimos el problema de la motivación de la siguiente manera: es mejor que cualquier documentación darle al desarrollador una aplicación (plantilla) semiacabada.Esto permite a los desarrolladores resolver tareas más rápido e impresionar a sus colegas con su productividad y, al mismo tiempo, los alienta a adherirse a las reglas básicas que ya están protegidas en el código.Por un lado, las aplicaciones similares al final dan un aumento significativo en la velocidad de desarrollo debido a la acumulación de experiencia, soluciones preparadas, una revisión más profunda y la capacidad de cambiar de un proyecto a otro. Por otro lado, cada proyecto tiene sus propias peculiaridades, por lo tanto, también es importante no exagerar con la estandarización.Lo que necesita colocar en la plantilla de la aplicación
Al comenzar nuevos proyectos, los desarrolladores suelen resolver las siguientes tareas típicas:- definición de arquitectura, selección de tecnologías / herramientas;
- creación de marcos de aplicación, montaje;
- creación y configuración de mecanismos comunes: manejo de errores, ventanas modales, notificaciones, enrutamiento, solicitudes del servidor;
- definición de un conjunto de elementos de interfaz;
- búsqueda / creación, personalización, estilización de componentes de interfaz con las funciones necesarias;
- procesamiento de formularios, validación;
- diseño;
- implementación de funcionalidad por orden de un cliente (lógica de negocios);
- revisión de código;
- gestión de registros.
¿Cuáles de estas tareas pueden resolver sus desarrolladores en unos minutos?La plantilla de aplicación que desarrollamos cierra los primeros tres elementos de esta lista. En esta plantilla, expresamos no solo nuestros deseos de una sola pila para el desarrollo, sino también las reglas básicas de la arquitectura de la aplicación.En comparación con las soluciones populares que están en el dominio público (por ejemplo, create-react-app), nuestra plantilla ya contiene:- estructura de carpetas preparada;
- enrutador configurado (rutas);
- Almacenamiento redux configurado
- módulo de solicitud del servidor;
- mecanismos listos para mostrar varios tipos de cargadores, notificaciones y ventanas modales a través de redux;
- módulo de procesamiento de errores (servidor y usuario) con la salida de mensajes al usuario;
- páginas de plantilla;
- Módulos de plantilla de lógica de negocios a los que se conectan los controladores de error, cargador y notificación.
En esencia, esta es una aplicación lista para producción con una página que dice hola mundo. Comenzando con el café de la mañana, a la hora del almuerzo, el desarrollador puede mostrar la primera página de un proyecto de trabajo.Pero luego, una gran cantidad de otras tareas interesantes (y no tan) esperan al desarrollador.
Selección de biblioteca de componentes
Todo lo que se refiere al diseño, los componentes de la interfaz (listas desplegables, calendarios, etc.), formularios y validación, decidimos usar nuestra propia biblioteca. Fue la parte más difícil.En 2017, la biblioteca principal de la compañía era la biblioteca de componentes Kendo de pago, que proporcionaba soluciones de interfaz de usuario para diversas tecnologías, comenzando con jQuery. Por varias razones, no nos convenía, y decidimos considerar bibliotecas alternativas, incluida la opción de crear la nuestra.Este es un punto muy importante en el que debe tomar la decisión correcta: encontrar otra biblioteca que sea mejor para nosotros o crear la suya propia. La distribución adicional de los recursos de desarrollo y el tiempo que los equipos dedican a crear y finalizar elementos de interfaz dependen de esta elección. En nuestra elección, procedimos de las siguientes consideraciones.::::De hecho, las soluciones preparadas no están tan preparadas. Casi todas las bibliotecas deben estar preparadas en un grado u otro. Si necesita hacer un proyecto pequeño, es posible que no encuentre tal necesidad, pero si está haciendo algún tipo de proyecto grande, o muchos proyectos pequeños y diferentes, entonces el costo de las mejoras puede ser mayor que el costo de crear su propia biblioteca, que satisface plenamente sus necesidades.Resulta que debe elegir entre instalar inmediatamente la funcionalidad lista para usar con un montón de limitaciones y desarrollar sus propias soluciones con la necesidad de esperar y gastar recursos adicionales en el desarrollo. Ninguna de las opciones nos satisfizo completamente, y encontramos otra solución.Decidimos hacer nuestro complemento para la biblioteca terminada.
Permítanme recordarles que en ese momento ya usábamos la biblioteca Kendo en su forma pura, una alternativa que queríamos encontrar. Eso es lo que decidimos tomar como base de nuestra biblioteca principal de componentes para aplicaciones en React. Y nuestra nueva biblioteca en sí era una fachada sobre Kendo. Omitiré los detalles técnicos, solo diré que tal solución nos permitió obtener de inmediato toda la funcionalidad de Kendo, e hicimos lo que nos faltaba, incluida la solución rápida de errores, en la capa entre la API del cliente de la biblioteca y Kendo. Esta arquitectura nos permitió expandir rápidamente el número de componentes debido a otras bibliotecas y módulos, simplemente incrustándolos en nuestra capa. Para los clientes de la biblioteca (para los desarrolladores de aplicaciones), esto parecía un aumento rápido en la funcionalidad de una biblioteca (lo discutiré en detalle en un artículo separado).Con el tiempo, reemplazamos todos los componentes con nuestras propias implementaciones y lanzamos la segunda versión de la biblioteca, donde tomamos en cuenta toda la experiencia previa, revisamos la API e hicimos nuestra propia documentación. Decidimos poner nuestros logros en el dominio público, pronto podrán ser descargados y utilizados en nuestros proyectos, siga los anuncios.¿Qué obtuvimos al final?
Ahora tenemos más de 10 desarrolladores front-end en varios equipos que trabajan en la misma pila y con un conjunto de tecnologías. En una pila, ya hemos creado una veintena de proyectos.Las estadísticas muestran que la eficiencia del trabajo se ha más que triplicado en dos años. Los proyectos en los que solíamos pasar de 4 a 6 meses, ahora lo hacemos en 1 a 2 meses (estamos hablando de la parte inicial).Comenzamos a reducir el tiempo de desarrollo cambiando la estructura de las tareas de los programadores. Veamos cómo han cambiado.Ya di una lista de tareas que los desarrolladores resolvieron hace dos años:- definición de arquitectura, selección de tecnologías / herramientas;
- creación de marcos de aplicación, montaje;
- creación y configuración de mecanismos comunes: manejo de errores, ventanas modales, notificaciones, enrutamiento, solicitudes del servidor;
- definición de un conjunto de elementos de interfaz;
- búsqueda / creación, personalización, estilización de componentes de interfaz con las funciones necesarias;
- procesamiento de formularios, validación;
- diseño;
- implementación de funcionalidad por orden de un cliente (lógica de negocios);
- revisión de código;
- gestión de registros.
De estos, en nuestra empresa hoy, los desarrolladores se dedican solo a los últimos tres:- implementación de funcionalidad por orden de un cliente (lógica de negocios);
- revisión de código;
- mantenimiento de la documentación del proyecto.
El resto ya está decidido en la plantilla de la aplicación y la biblioteca de componentes.Esto afectó no solo la velocidad del trabajo, sino también en general el estado de ánimo de los desarrolladores. De todos modos, la implementación de la lógica de negocios es mucho más interesante que configurar listas desplegables. También es mucho más fácil para el gerente de proyecto explicarle al cliente que se dedicó una semana de tiempo de trabajo al desarrollo de características comerciales importantes, y no al hecho de que requirió completar un pequeño elemento de interfaz, aunque pueden ser bastante equivalentes en términos de costos laborales.Continuamos trabajando en la dirección elegida y una de las tareas principales para el futuro cercano es aumentar la motivación de los desarrolladores para profundizar sus competencias en la pila seleccionada y buscar nuevas soluciones efectivas. Escalar estas soluciones en toda la empresa ahora es fácil gracias a una biblioteca común y una plantilla de aplicación.Con deseos de eficiencia y hasta pronto!Source: https://habr.com/ru/post/undefined/
All Articles