De proyecto en proyecto, notamos que nuestro código realiza las mismas funciones y se ve casi igual. Esto nos hace preguntarnos: ¿no estamos haciendo el trabajo extra al reescribir lo mismo? Comenzamos a copiar clases de proyectos anteriores y aún entendemos que estamos haciendo algo mal y estamos en lo correcto: simplemente copiando clases de un proyecto a un proyecto, fácilmente podemos perder / reemplazar / borrar algo, y si nuestro equipo lidera un poco más proyectos simultáneamente, luego la detección de errores en clases prestadas requerirá cambios manuales en todos los proyectos. Cansados ​​de pisar este rastrillo, decidimos que necesitamos un código común que se compartirá en todos nuestros proyectos y que cualquier cambio en él se extraerá fácilmente. ¡Sí, estamos creando nuestra biblioteca de componentes reutilizables! Aprenderá sobre las diferentes formas de organizar su biblioteca, sobre todos los pros y los contras de los enfoques bajo cat :)

Hay varias formas de organizar nuestra base de código común:

1. Biblioteca de Android (aar / jar)
2. Submódulo Git
3. Subárbol Git

Biblioteca de Android (aar / jar)

Cualquier biblioteca para nuestra aplicación es solo una gran cantidad de clases organizadas de cierta manera. Cada vez que conectamos algunos Retrofit o Dagger en build.gradle , cargamos la biblioteca como un archivo aar / jar desde una de las plataformas de publicación de la biblioteca. Las plataformas de publicación de bibliotecas más populares son JCenter y MavenCentral. Los desarrolladores de la biblioteca trabajan en su repositorio en la nueva versión, y cuando la versión está lista para salir al mundo, la publican en una de las plataformas y dicen "¡Hola, lanzamos una nueva versión de nuestra biblioteca superior!". Todo lo que queda por hacer para los desarrolladores que usan esta biblioteca en sus proyectos es cambiar la versión en build.gradle y disfrutar de nuevas funciones. ¿Es conveniente? ¡Palabra equivocada!

Pero, ¿qué tan conveniente es este enfoque si nuestra biblioteca se está desarrollando y cada día se actualiza con nuevas características de diferentes desarrolladores de diferentes proyectos de nuestro equipo? Veamos cómo se ve en la práctica.

Creamos un repositorio de nuestra biblioteca, aportamos algunas funciones allí, lo depuramos y estamos listos para compartirlo con nuestro equipo. Luego aprenderemos sobre palabras como JCenter, MavenCentral, Bintray, Jitpack.io ... todas estas son plataformas para publicar bibliotecas. Ahora la plataforma principal para proyectos de Android es JCenter. Si crea un proyecto, verá que en build.gradle (nivel de proyecto) en los repositorios, se especifica JCenter

repositories { google() jcenter() } 

Es decir, si el desarrollador quiere conectar su biblioteca, entonces será suficiente para que la conecte al nivel del módulo build.gradle .

La forma más fácil de publicar la biblioteca para mí parece ser Jitpack.io, un par de pasos y su biblioteca está lista para usar.

Cómo organizar el trabajo en equipo en la biblioteca

Si creamos una biblioteca y la subimos al repositorio, el resto de nuestro equipo solo tiene el archivo jar / aar recibido. Para que todo el equipo pueda trabajar en cualquiera, cada desarrollador debe desinflar el repositorio de la biblioteca y realizar cambios en él.

Versionado

Al desarrollar y usar bibliotecas, uno tiene que lidiar con un concepto como el control de versiones. Es decir, el conjunto de cambios en la biblioteca que queremos publicar debe ser corregido por la versión. Esto ayudará al actualizar la biblioteca a una nueva versión para comprender cómo se han realizado cambios serios / importantes, gracias al esquema de versiones adoptado.

Comprobando la biblioteca en el proyecto

Para verificar que los cambios realizados hacen lo que pretendíamos, es necesario verificar el comportamiento del código escrito en el proyecto. Elevamos la versión de la biblioteca y ... aquí está uno de los cuellos de botella de este enfoque. Nuestra biblioteca y el proyecto están en diferentes repositorios, lo que significa que no podemos simplemente obtener clases de biblioteca en el proyecto. Tenemos 2 opciones para revisar el nuevo código de la biblioteca:

1. Cree un módulo en el proyecto de biblioteca de muestra en el que se escribirá el código que verifica la funcionalidad de la biblioteca. La opción es simple, pero hay 2 desventajas: 1. Escribimos código adicional; 2. El entorno del módulo de prueba es diferente del proyecto real en el que utilizaremos la biblioteca, y si cometemos errores, aparecerá cuando obtengamos una nueva versión del proyecto.
2. Publicar cambios en el repositorio local mavenLocal . Gracias a este enfoque, puede obtener un nuevo código en el proyecto, pero no se publicará para todo el equipo (pero debe modificar un poco la configuración).

Submódulo Git

En el enfoque anterior, nos enfrentamos con la dificultad de obtener nuevo código en la etapa de desarrollo / depuración del proyecto, ya que la biblioteca y el código del proyecto se encuentran en diferentes repositorios y proyectos de estudio. El enfoque del submódulo Git también implica el uso de repositorios separados, pero permite que el proyecto principal obtenga la biblioteca como un módulo usando Git. ¡Esto significa que el código de la biblioteca estará disponible en el proyecto y todos los cambios estarán disponibles inmediatamente en el proyecto!

Como funciona

Los submódulos le permiten contener un repositorio Git como subdirectorio de otro repositorio Git. Esto permite clonar otro repositorio dentro del proyecto, almacenando los commits para este repositorio por separado.

En pocas palabras, tenemos 2 repositorios: un proyecto y una biblioteca. El repositorio del proyecto almacena el código de la biblioteca y un enlace al estado del repositorio de la biblioteca. Entonces Git entiende qué estado (versión) de la biblioteca necesita el proyecto.

Lea más sobre cómo funciona Git Submodule aquí.

Cómo organizar el trabajo en equipo.

En el enfoque del submódulo Git, el trabajo en equipo en la biblioteca se organiza de la siguiente manera:

1. Al crear un nuevo proyecto o conectar una biblioteca a un proyecto existente, se crea una nueva rama Git del maestro con el nombre del proyecto.
2. Cuando llega el momento de reponer la biblioteca con alguna funcionalidad, se crea una rama para la tarea (desde la rama del proyecto) y se realizan cambios allí.
3. Se está realizando una revisión, se están vertiendo piscinas en la rama del proyecto. Cuando se escriben suficientes cambios para liberar la versión, se crea un grupo al fusionar la rama del proyecto en la rama maestra de la biblioteca.
4. Después de que el grupo pasa la revisión por el equipo responsable de la biblioteca y se vierte en la rama maestra, los equipos restantes del proyecto serán notificados de la actualización de la biblioteca que ha aparecido y decidirán sobre la actualización.

Versionado

Cuando el grupo se vertió en el maestro , y los equipos son notificados de la actualización de la biblioteca, no son conscientes de cuán globales son los cambios en la nueva versión. Después de todo, el enfoque con Git Submodule no requiere ningún esquema de versiones. Pero este problema se resuelve fácilmente mediante la introducción de un esquema de versiones. Todo lo que se requiere es escribir una versión y una descripción de lo que se ha cambiado y agregado a la descripción de la solicitud del grupo en la rama maestra . Entonces, los desarrolladores comprenderán cuánto pueden realmente actualizar a la nueva versión de la biblioteca. Suena genial, pero la pregunta es:

Sí, el estudio no sabe cómo comprometerse por separado a la biblioteca conectada por el submódulo. Yo uso SourceTree para resolver este problema. Esta aplicación es para Windows y Mac, y para Linux hay GitKraken.

Subárbol Git

Git Subtree es una versión mejorada de Git Submodule. En Git Subtree intentamos resolver los problemas que los desarrolladores encontraron al trabajar con Git Submodule; hay un buen artículo en el centro que describe las diferencias entre las herramientas. Aunque funcionan de manera diferente, resuelven un problema.

Conclusión

Las herramientas Git Submodule / Subtree son excelentes para resolver el problema de crear una base de código común para un equipo involucrado en varios proyectos. Una de las ventajas importantes es la verificación instantánea de nuevo código en el proyecto después de realizar cambios en la biblioteca. En esto, el enfoque estándar de publicar una biblioteca en JCenter o MavenCentral es inferior. Si decide llevar el Git Submodule / Subtree a su equipo, piense de antemano en el esquema de control de versiones y cree reglas / complementos para controlar el control de versiones.

¡Gran reutilización para todos!