Guía de desarrollo basada en componentes

La modularidad ha sido uno de los principios clave del desarrollo de software desde la década de 1960. La aplicación de este principio aporta mucha utilidad a la programación. La modularidad contribuye al uso efectivo del principio de separación de responsabilidades, lo que conduce a una mejora en la capacidad de crear, reutilizar, construir código.

Hoy en día, la aplicación del principio de modularidad en el diseño de software ha tomado una nueva forma, incorporada en los componentes. Este es el Desarrollo Dirigido por Componentes (CDD). Las bibliotecas y los marcos modernos para desarrollar interfaces de usuario, como React , Vue y Angular , así como herramientas orientadas a CDD como Bit , le permiten crear aplicaciones basadas en componentes modulares. El programador tiene a su disposición los patrones y herramientas necesarias para desarrollar componentes de forma aislada y construir composiciones de componentes.


Un componente es un fragmento independiente claramente definido de la interfaz de la aplicación. Como ejemplos de componentes, puede citar entidades como botones, controles deslizantes, ventanas para mostrar mensajes de chat. Al comprender las características de CDD y saber cómo aplicar este enfoque al desarrollo, podemos usar componentes como base de las aplicaciones. Esto, al crear proyectos de software, nos da todo lo que es útil, lo que significa aplicar los principios de la programación modular.

Si observa de cerca lo que está sucediendo ahora en el campo de los componentes web , notará que CDD se está convirtiendo en un enfoque estandarizado para el desarrollo frontend.

El material, que publicamos la traducción de hoy, es una guía de desarrollo basada en componentes.

CDD en desarrollo de interfaz de usuario

Trabajar en Bit: crear, aislar, reutilizar y colaborar en componentes

En pocas palabras, el desarrollo basado en componentes es el diseño de aplicaciones mediante la creación de bloques de código independientes poco acoplados. Cada uno de ellos tiene una interfaz diseñada para organizar la interacción con otras partes del sistema. Muchos componentes, combinados entre sí a través de la composición, forman una aplicación modular.

Por ejemplo, el uso de CDD en la creación de aplicaciones React significa que primero crean los componentes que forman la base de la aplicación, y luego proceden a ensamblar a partir de ellos partes más grandes de la aplicación, como páginas enteras y grandes bloques de funcionalidad.

CDD está relacionado con el diseño atómico ( aquí hay material útil sobre este tema) y con el enfoque para desarrollar partes del lado del cliente de proyectos web, conocido como la " micro interfaz ".

CDD ayuda a descomponer el proceso de desarrollo de un proyecto grande en procesos de desarrollo más pequeños para componentes individuales. Cada componente está diseñado independientemente del resto de la aplicación y se crea teniendo en cuenta la posibilidad de interacción con otras partes del sistema. Diseñar cada componente como una entidad independiente le da al desarrollador muchas características útiles.

Eddie Osmani describió algunos de los beneficios clave del uso de CDD. Los diseñó en un conjunto de principios llamados PRIMERO .

Estos principios son:

• Aceleración del desarrollo (desarrollo más rápido). El hecho de que los esfuerzos de los desarrolladores estén dirigidos a crear componentes separados permite crear partes modulares de la aplicación con API altamente especializadas. Esto significa que los componentes pueden, por un lado, desarrollarse rápidamente y, por otro, que es más fácil desarrollarlos al nivel de calidad requerido por el proyecto cuando se desarrollan.
• Simplificación del soporte (mantenimiento más sencillo). Cuando necesite modificar o actualizar una parte de una aplicación, puede expandir o actualizar un componente, en lugar de refactorizar una gran parte de la aplicación. Esto se puede comparar con un procedimiento médico, con una operación en un órgano separado, reemplazando una operación que involucra intervención en casi todas las partes del cuerpo.
• Mejores capacidades de reutilización de código. Al utilizar el principio de separación de responsabilidades, los componentes se pueden reutilizar o ampliar durante la creación de una aplicación final a partir de ellos. Esto es mucho mejor que la necesidad de volver a escribirlos una y otra vez ( aquí está el material sobre este tema).
• Mejora de la capacidad de aplicar la metodología TDD (Better TDD). Durante el desarrollo de componentes modulares, es mucho más fácil que usar otros enfoques para implementar pruebas unitarias destinadas a probar la funcionalidad limitada de un componente. Como resultado, resulta que es más fácil probar sistemas grandes ensamblados a partir de componentes. El hecho es que cuando se utiliza un enfoque modular, es más fácil para un desarrollador comprender de qué es exactamente responsable una u otra parte del sistema.
• Acortar curvas de aprendizaje (curvas de aprendizaje más cortas). Cuando un desarrollador tiene que lidiar con un nuevo proyecto para él, resulta que es mucho más fácil comprender la esencia y la estructura de los componentes individuales que profundizar en las complejidades de todo el proyecto.
• Mejora de las capacidades de los sistemas de modelado (Mejor modelado del sistema). Cuando el sistema se crea a partir de componentes modulares, es más fácil para el desarrollador comprender el dispositivo general del sistema, comprenderlo y aprender a influir en él.

Herramientas de CDD

Si el desarrollo se basa en componentes, esto significa que el programador necesita herramientas especializadas. Dichas herramientas están destinadas a crear componentes, probarlos, organizar el acceso general a ellos y apoyar la colaboración en ellos.

En particular, es importante diseñar y probar componentes de forma aislada. Esto les permite trabajar en forma de unidades independientes que se pueden utilizar en la aplicación. Además, el soporte para la reutilización de componentes y la capacidad de compartirlos son importantes. Esto permite a quien trabaja como parte de un equipo en un proyecto importante no reinventar la rueda, que, en forma de componente, ya ha sido inventada por uno de los miembros del equipo.

Aquí hay algunas herramientas útiles para ayudarlo a organizar su trabajo en proyectos de estilo CDD. En una de las siguientes secciones, hablaremos sobre las arquitecturas de proyectos recomendadas para la implementación práctica de los principios de DDC.

▍Bit: desarrollo individual y en equipo de componentes

Bit es una herramienta de código abierto, creada esencialmente para soportar la aplicación práctica de la metodología CDD. Aquí hay un video sobre Bit. Esta herramienta le ayuda a desarrollar componentes, colaborar en ellos y crear proyectos web utilizándolos.

El punto es que con Bit significa que puede aislar componentes que se están desarrollando como parte de un proyecto. Diga: dentro de una aplicación o biblioteca. Bit admite herramientas de línea de comandos, ayuda a organizar la encapsulación de componentes con todos sus archivos y dependencias. Bit le permite desarrollar y probar representaciones virtuales de componentes encapsulados de forma aislada.

Esto significa que el componente creado dentro de la aplicación puede equiparse con todas sus dependencias, encapsularse y convertirse en una entidad que se puede usar y probar fuera de la aplicación.

Además, Bit le permite empacar componentes encapsulados e independientes y organizar su uso compartido utilizando herramientas en la nube . Esto permite que los equipos que trabajan en proyectos usen todos los componentes que se comparten. La comunidad Bit tiene unos 50,000 desarrolladores. Sus esfuerzos crearon miles de componentes de código abierto disponibles para todos.


Desarrollo de proyectos utilizando componentes encapsulados.

Gracias a las capacidades de la plataforma en la nube, los equipos de desarrollo pueden instalar componentes de código abierto en sus aplicaciones. Los miembros del equipo también pueden ofrecer ideas de autores de componentes para mejorar los componentes al hacerlo directamente desde su entorno de trabajo. Bit extiende la capacidad de Git para rastrear y sincronizar los cambios en el código fuente de los componentes en todos los proyectos. Esto brinda a los desarrolladores la capacidad de administrar cambios y actualizaciones de componentes.

Bit almacena un árbol completo de dependencias de componentes. Esto le da al desarrollador la oportunidad de aprender sobre cómo la actualización de un componente puede afectar a los componentes dependientes, sobre lo que puede estar "roto" en un proyecto cuando se realizan cambios en un componente. Esto significa que, gracias a Bit, el programador tiene a su disposición un entorno completo para organizar el desarrollo basado en componentes, lo que le permite crear componentes, probarlos y organizar el trabajo conjunto sobre ellos y su uso conjunto.


Capacidades en la nube en CDD

Otra característica útil de Bit es que esta plataforma permite a los equipos de desarrollo no solo trabajar con sus componentes usando una única interfaz, sino también usar otros componentes establecidos en el dominio público e interactuar con los autores de estos componentes.

Los diseñadores de interfaces, los representantes de proyectos de clientes y los programadores pueden, en el curso del trabajo conjunto en proyectos, utilizar herramientas visuales comunes. Esto cierra la brecha entre diseñadores y programadores. Además, debe tenerse en cuenta que en esta situación no solo se benefician los diseñadores y programadores, sino también los usuarios finales de las aplicaciones que encuentran menos heterogeneidades y errores. Aquí , aquí y aquí hay algunos materiales sobre varios aspectos del uso de Bit.

▍Desarrollo e investigación de componentes de la interfaz de usuario: StoryBook y Styleguidist

StoryBook y Styleguidist son entornos para desarrollar rápidamente elementos de la interfaz de usuario con React. Ambos proyectos son excelentes herramientas para acelerar el desarrollo de componentes.

Libro de cuentos

StoryBook es un entorno para desarrollar rápidamente componentes de la interfaz de usuario. Le permite trabajar con la biblioteca de componentes, ver los diversos estados de los componentes, participar en el desarrollo interactivo y probar los componentes.


Trabaja en StoryBook

StoryBook ayuda a diseñar componentes aislados de la aplicación. Esto ayuda a mejorar la reutilización de los componentes y mejora la capacidad de prueba de los componentes.

Con StoryBook, puede ver los componentes almacenados en la biblioteca y experimentar con sus propiedades en línea. Se visualizan los cambios realizados en el componente de inmediato, sin volver a cargar la página. Aquí hay algunos ejemplos de componentes creados en StoryBook.

Existen varios complementos que pueden acelerar el desarrollo de componentes con StoryBook. Esto le permite reducir el tiempo transcurrido entre el cambio del código del componente y la formación de su representación visual. Cabe señalar que StoryBook, además de React, también es compatible con React Native y Vue.js.

Reaccionar estiloguidista

React Styleguidist es un entorno de desarrollo de componentes. Este entorno contiene un servidor de desarrollo que admite un arranque en caliente. También tiene un sistema de gestión de estilo interactivo que muestra propTypes componentes propTypes y proporciona a los desarrolladores ejemplos editables del uso de componentes basados ​​en archivos .md.


Reaccionar estiloguidista

Esta plataforma admite JavaScript ES6, Flow y TypeScript. Es capaz, sin configuraciones adicionales, de trabajar con la aplicación Create React. Styleguidist tiene la capacidad de crear automáticamente documentación de componentes. Esto permite que este sistema desempeñe el papel de un portal de documentación visual para los componentes en los que está trabajando algún equipo.

Si está interesado en proyectos como StoryBook y Styleguidist, es posible que desee ver el proyecto React Live , que está siendo desarrollado por Formidable.

Diferencia entre StoryBook y Styleguidist

Mientras trabaja con un StoryBook, un programador escribe "historias" en archivos JavaScript. Cuando trabaja con Stuleguidist, escribe "ejemplos" en los archivos Markdown. Mientras que un StoryBook muestra solo una variación de un componente a la vez, Styleguidist puede mostrar varias variaciones de diferentes componentes. StoryBook es excelente para analizar los diversos estados de los componentes, y Styleguidist es excelente para generar documentación de componentes y demostrar capacidades de componentes.

Decisiones arquitectónicas utilizadas con la metodología CDD

Trabajar al estilo de CDD significa que al desarrollar aplicaciones, los componentes se crean primero. Además, dichos componentes deben ser tan independientes entre sí como sea posible. Esto significa que el desarrollador no solo crea un "conjunto de componentes". También implementa el llamado sistema de diseño de componentes de interfaz de usuario.

Los componentes se pueden crear tanto en el marco de la propia aplicación (es decir, en el mismo proyecto, repositorios) como en el formato de un proyecto separado (repositorio), en forma de una biblioteca de componentes.

Herramientas como Bit le permiten aislar y encapsular componentes. Esto le da al desarrollador una gran oportunidad para crear, probar, reutilizar componentes y les permite finalizarlos en cualquier lugar, independientemente de dónde se crearon.

Si decimos que el uso de CDD proporciona el desarrollo de componentes en la forma del primer paso para trabajar en un proyecto, entonces esto también implica que los componentes tienden a hacerlos adecuados para el uso repetido. Esto le permite aplicarlos al crear varias aplicaciones. Por lo tanto, el desarrollador necesita descubrir exactamente cómo debe hacerlo para crear dichos componentes. No hay nada peor que pasar seis meses para crear una biblioteca , que, al final, nadie usará. Desafortunadamente, esto sucede con muchos equipos.

¿Por qué crear una biblioteca de componentes?

Seré honesto con usted: los repositorios de Git no fueron concebidos teniendo en cuenta la posibilidad de almacenar código de componentes atómicos en ellos, que se planea compartir en varios proyectos. Para resolver este problema, los administradores de paquetes no son adecuados. Ambos fueron creados, lo que es comprensible, para soportar repositorios de código. Los componentes no son repositorios.


Compartir un componente en varios proyectos

Es por eso que, en caso de que necesite tomar un componente de una aplicación y usarlo en otra aplicación, debe crear un nuevo repositorio. Para salvarse del trabajo innecesario de crear un repositorio separado para cada componente, la mayoría de los equipos crean un repositorio compartido diseñado para almacenar 20-30 componentes.

Cuando se utiliza una herramienta como Bit, la biblioteca de componentes como tal no necesita hacerlo. Dichas herramientas le permiten descargar un componente de la aplicación a la nube e implementar este componente en otros proyectos. Si comparamos este esquema de trabajo con los repositorios tradicionales, entonces podemos decir que esto es algo así como comparar un CD de música y Spotify. Es cierto que si está cerca de la idea de desarrollar y usar bibliotecas de componentes, las capacidades de plataformas como Bit y StoryBook le permitirán trabajar con bibliotecas.

Al diseñar una biblioteca, debe tomar varias decisiones clave. A continuación se considerarán algunos principios importantes que lo ayudarán con esto. El punto principal de estos principios es que su tarea es crear componentes independientes. Las etapas restantes del trabajo en el proyecto se asemejan al ensamblaje del constructor de Lego. Si no se respeta el principio de desarrollar componentes independientes, un día puede tener problemas. Los problemas comenzarán cuando alguien necesite algo diferente de lo que está en la biblioteca. De hecho, cuando esto sucede, los equipos dejan de usar bibliotecas de componentes.

Suponga que decide crear una biblioteca de componentes. Si es así, le ofrecemos algunos consejos que lo ayudarán con esto.

7 principios para desarrollar bibliotecas de calidad orientadas a CDD

1. Normas ¿A qué estándares de desarrollo se adhiere al crear su biblioteca? ¿Dónde están ubicados los componentes? ¿Dónde se encuentran las pruebas? ¿Qué hay de los estilos? ¿Qué tecnología estás usando? Por ejemplo, ¿planea usar TypeScript? ¿Cómo se dividen los componentes? ¿El componente "Tabla", por ejemplo, consiste en "Filas" y "Celdas"? ¿El panel con pestañas consta de pestañas separadas (se pueden hacer las mismas preguntas en relación con otras entidades similares)? Supongo que ya entendió el significado de esta recomendación. También es muy importante incluir diseñadores en el proceso de formación de estándares. Esto asegurará que la biblioteca sea lo suficientemente flexible y cumpla con los requisitos de diseño que puedan aparecer en el futuro.
2. Estilización. ¿Cómo planeas diseñar los componentes? ¿Vinculará el código CSS correspondiente a cada componente? Si es así, ¿qué sucede cuando un diseñador necesita cambiar algo solo para una aplicación separada que usa un componente? ¿Quizás para mejorar la separación de componentes de estilos vale la pena usar bibliotecas que implementen CSS en tecnología JS ? ¿Quizás vale la pena buscar algún otro enfoque para el estilo? Por ejemplo, usando Bit, puede resaltar temas como componentes separados. Dichos temas pueden aplicarse a componentes que implementan algún tipo de lógica. Esto le permite crear aplicaciones en las que el diseño y la lógica se combinan exactamente como el desarrollador lo necesita. Aquí hay un ejemplo de la extrema flexibilidad de los sistemas construidos utilizando el principio de modularidad.
3. Pruebas ¿Cómo va a probar los componentes incluidos en la biblioteca? Usando Jest y Enzyme? La selección de una buena combinación de herramientas de prueba de componentes debe abordarse con toda responsabilidad. Esto permitirá que tales herramientas lo ayuden a implementar la metodología CDD. La mala elección de herramientas interferirá con el trabajo. Las pruebas unitarias son buenas. Pero deben verificar las API funcionales de los componentes, no los detalles de su implementación. Las pruebas integrales y de extremo a extremo son tan importantes como las pruebas unitarias. La metodología TDD funciona bien cuando se aplica en proyectos que utilizan CDD.
4. Proceso de ensamblaje de código. El código necesita ser compilado. ¿Cómo va a organizar el proceso de creación de código para su biblioteca? ¿Cómo se implementarán los lanzamientos? ¿Planea simplemente copiar el código de la aplicación y pegarlo en la biblioteca (probablemente modificándolo un poco)? ¿Va a definir configuraciones de ensamblaje para cada componente (Lerna) y aplicar los mecanismos apropiados al código antes de publicarlo? ¿Planea utilizar, digamos, el Bit ya mencionado más de una vez para personalizar los procesos de compilación que se aplican a todos los componentes (o individuales)? Si complica demasiado el proceso de ensamblaje, será más difícil participar en el desarrollo, la modularidad del proyecto se deteriorará. La curva de aprendizaje requerida para participar en el desarrollo será demasiado empinada.
5. Manejo de código. ¿A quién pertenece la biblioteca? En organizaciones bastante grandes, a menudo hay equipos de desarrolladores front-end y, a veces, arquitectos. Están creando un producto llamado "biblioteca compartida". Otros equipos de desarrollo front-end crean aplicaciones utilizando bibliotecas similares. Con este esquema de interacción, es muy importante utilizar un sistema que le permita encontrar convenientemente los componentes necesarios (Bit, Storybook). Quizás lo más importante es el mecanismo por el cual los usuarios de componentes pueden proponer mejoras de componentes. Si no existen tales mecanismos en la organización, los equipos de usuarios componentes no querrán asociar sus aplicaciones con la biblioteca y esperar a que se acepte su RP, lo que bien puede que no esperen. No es necesario obligar a los programadores a hacer nada. Es necesario establecer una cooperación saludable. Si no se esfuerza por esto, nadie usará la biblioteca. Los programadores simplemente copiarán y pegarán el código, y nadie hará nada al respecto. Además, este será tu error. Si trabaja en un equipo pequeño, determine claramente quién administra el código. Incluso si nadie participa en la base del código todo el tiempo, seleccione algunos especialistas que admitirán este código. El resto hará relaciones públicas, al igual que en GitHub.
6. Encontrar componentes. La biblioteca no traerá muchos beneficios si los programadores no pueden encontrar los componentes que necesitan, no pueden aprender cómo funcionan estos componentes y no pueden usarlos en su código. Bit tiene las capacidades integradas que ayudan a los desarrolladores a encontrar componentes. Además de esta plataforma (o en su lugar), puede usar las capacidades de StoryBook o algún tipo de solución propia. La plataforma Codesandbox puede proporcionar algún beneficio al resolver problemas relacionados con la selección de componentes y trabajar con la documentación para ellos.
7. Organización de colaboración en componentes. ¿Qué sucede cuando un desarrollador (quizás de otro equipo, o incluso de otro país) necesita cambiar algo relacionado con un componente de su biblioteca? ¿Necesita profundizar en la creación de un RP para su biblioteca y, cruzando los dedos, esperar los resultados? Para muchos desarrolladores, esto es demasiado complicado, no lo harán incluso si intentas influenciarlos de alguna manera. Será mucho mejor si utiliza una determinada plataforma que simplifica la colaboración en proyectos.

Recuerde que una biblioteca es solo un repositorio que existe para facilitar el intercambio de componentes en varios proyectos. Las bibliotecas no se escalan muy bien, el código en ellas se vuelve obsoleto, sufren varios problemas. Podría ser mejor simplemente proporcionar acceso directo a los componentes destinados a compartir, utilizando algún tipo de plataforma en la nube.

Beneficios del equipo de CDD

Los equipos que utilizan el principio de CDD se benefician del desarrollo acelerado, una mayor reutilización del código, TDD mejorado y una interfaz de sistema de diseño consistente.

Los programadores pueden escribir código con acceso a componentes ya escritos y trabajar juntos para realizar cambios en los componentes. El desarrollo de nuevas funciones o aplicaciones se reduce a personalizar y expandir los componentes básicos. Esto, además, ayuda a prevenir errores que solo se encuentran en la producción.

Compartir código significa, entre otras cosas, reducir la cantidad de código que debe ser compatible. Esto permite a los programadores centrarse en crear algo nuevo. Cuando las aplicaciones se desarrollan en base a componentes, esto estandariza el trabajo debido al hecho de que todos usan una base única de bloques de construcción de aplicaciones. El enfoque de componentes también contribuye a la flexibilidad laboral.

Algunos equipos informan que sus flujos de trabajo se han vuelto hasta un 60% más rápidos gracias al uso de componentes modulares basados ​​en sistemas de diseño implementados como conjuntos de componentes React. Algunas organizaciones han descubierto que a través de la introducción de CDD, pueden eliminar aproximadamente el 30% del código de sus bases de código.

Empresas como Uber, Airbnb, Shopify y otras están introduciendo un enfoque de componentes.

Resumen

Personalmente, no me sorprende que el uso de CDD mejore la eficiencia del desarrollo de software. Según Brad Frost, autor del libro sobre diseño atómico, modularidad y composición, son los conceptos más importantes en biología, economía y en muchas otras áreas. La modularidad en la aplicación al desarrollo de software proporciona velocidad, confiabilidad y facilidad de desarrollo. Promueve la reutilización de entidades, mejora la capacidad de prueba y la extensibilidad del código. La modularidad le da al desarrollador la capacidad de usar la composición al crear sistemas complejos. Todo esto afecta muy bien el proceso y los resultados del desarrollo de la aplicación.

Estimados lectores! ¿Utiliza la metodología CDD cuando trabaja en sus proyectos?