Cómo mantener los mismos fragmentos de código en múltiples proyectos [cerrado]

Soy un desarrollador independiente que trabaja en múltiples proyectos de Android. Tengo problemas para mantener la misma funcionalidad en diferentes proyectos. Por ejemplo, tres de mis aplicaciones usan las mismas 2 clases; Como son proyectos diferentes, cuando necesito hacer un cambio en esas clases, necesito hacerlo tres veces. ¿Existe una solución simple para este tipo de problema común?

Separe el código compartido en una biblioteca e incluya la biblioteca en los proyectos.

Como desarrollador de Android, presumiblemente está utilizando Java. Considere usar una herramienta de administración de dependencias como Maven o Ivy .

Un efecto secundario es que esto ayudará a mantener la separación de las preocupaciones al imponer la modularidad. El costo es que puede tomar algo de trabajo separarlo; El beneficio es una mejor mantenibilidad futura. Además, si alguna vez lo decide, puede liberar la biblioteca por separado (ya sea comercialmente o como fuente abierta) de sus aplicaciones.

Control de versiones. Git Submódulos Git.

Ponga sus proyectos bajo control de versiones, usando un dvcs como git o mercurial, etc. Ponga el código compartido en un submódulo en git. Use el submódulo en los proyectos que lo necesiten. Cuando actualiza el submódulo, puede extraer los cambios a otros proyectos con un solo comando.

Nadie más mencionó la espada de doble filo todavía, así que agregaré mis 2 centavos. Si tiene varios proyectos y todos comparten código reutilizable, de acuerdo con las buenas prácticas / principios de programación (DRY, por ejemplo), debe colocar el código en un lugar global y estructurarlo de tal manera que todos puedan compartirlo. sus proyectos sin modificaciones. En otras palabras, defina las interfaces para que sean genéricas y lo suficientemente comunes como para adaptarse a todos.

Hay pocas opciones para hacer esto: 1) Crear un proyecto base del que otros dependan. Este proyecto puede crear una distribución binaria que consumen otros proyectos. 2) Tire de un modelo de código abierto dentro de su organización. Haga que el código común sea su propia rama de código y que otros proyectos extraigan el código de la misma manera que tomaría el código fuente de cualquier OSS en línea.

Ahora aquí es donde entra la espada ...

Colocar el código en un lugar común del que dependen otros proyectos / personas puede resultar bastante costoso. Digamos que tiene un código y otros 4 proyectos dependen de él. Uno de sus clientes que usa el proyecto A encuentra un error y usted tiene que corregirlo. Usted apura el arreglo y ese cliente está contento. Pero acaba de modificar un código del que dependen otros 3 proyectos. ¿Has vuelto a probar todos para asegurarte de que no se introdujeron condiciones de borde?

El código común también debe diseñarse con mucho más cuidado y las interfaces de los módulos deben estar mucho mejor diseñadas porque ese código debe acomodar no solo a 4 clientes y cada uno de ellos podría usar este código con una diferencia muy leve.

Si sus proyectos se encuentran en diferentes ciclos de lanzamiento, debe tener aún más cuidado al administrar el código común. No puede simplemente realizar cambios en el código común porque el proyecto B necesita una nueva funcionalidad, si le faltan 3 días para cortar la imagen final para el proyecto C.

No digo que la biblioteca común no sea la solución correcta. Soy un gran defensor de DRY y he creado y soportado código común antes y continúo haciéndolo. Solo quería decir que hacer que el código sea común tendrá sus propios gastos.

Si usted es el único que reutiliza este código, esto no es tan malo. Si tiene un equipo de ingenieros y comienzan a usar el código común, los gastos se disparan aún más. Si hay otros involucrados, espere colocar el código en una biblioteca común que tome 3 veces más tiempo que el necesario para llegar a un punto en el que cree que está "completo". Deberá a) hacer que la biblioteca sea más robusta para protegerla contra todo tipo de condiciones de borde y uso no válido, b) proporcionar documentación para que otros puedan usar la biblioteca yc) ayudar a otras personas a depurar cuando usan la biblioteca de una manera que usted no se anticipó y su documentación no cubrió su caso de uso específico.

Pocas sugerencias que puedo ofrecer:

1. Tener un código común cubierto por las pruebas unitarias automatizadas puede ser muy útil y le dará cierta tranquilidad de que cuando realiza un cambio, no acaba de romper algún otro proyecto.
2. Solo colocaría una funcionalidad muy estable en un código común. Si escribió una clase el año pasado para administrar el temporizador y no la ha cambiado en 9 meses y ahora tiene otros 3 proyectos que necesitan temporizadores, entonces seguro que es un buen candidato. Pero si acabas de escribir algo la semana pasada, bueno ... no tienes tantas opciones (y odio copiar / pegar el código probablemente más que el siguiente), pero me lo pensaría dos veces antes de hacerlo común.
3. Si el código es trivial pero lo ha usado en varios lugares, tal vez sea mejor morder la bala, dejar solo DRY y dejar vivir varias copias.
4. A veces vale la pena no solo poner código común en una ubicación común y hacer que todos lo consulten. En lugar de eso, trata el código común como si fuera liberable con versiones, fechas de lanzamiento y todo. De esta forma, el proyecto C puede decir: "Uso la biblioteca común v1.3" y si el proyecto D necesita una nueva funcionalidad, deja solo la v1.3, la versión v1.4 y el proyecto C no se ve afectado. Tenga en cuenta que es MUCHO MUCHO más costoso tratar el código común como su propio producto en lugar de simplemente tenerlo registrado en una ubicación común.

Esta es una solución idealizada, y puede tomar algún esfuerzo para comenzar a trabajar.

El principio DRY establece que debería haber una única fuente autorizada de verdad. Esto dicta el uso de un único repositorio de origen para toda la lógica del programa, sin duplicación; archivos organizados para promover el intercambio y la reutilización de documentos.

Los requisitos pragmáticos de comunicación en un entorno distribuido de varios equipos sugieren que debe haber múltiples repositorios independientes, uno para cada proyecto o colaboración.

Abordaría este problema sometiéndome a lo inevitable: necesitará adoptar ambos enfoques al mismo tiempo, y utilizaremos secuencias de comandos y automatización para suavizar el hecho de que los enfoques son contradictorios.

:-)

El único repositorio unificado será su única fuente autorizada. El proceso de compilación para cada proyecto copiará todos los archivos utilizados por ese proyecto (y solo esos archivos) en una ubicación intermedia, luego compilará desde esa ubicación intermedia. (Se puede utilizar Unison o alguna herramienta similar para mover deltas en lugar de archivos completos).

Estas ubicaciones intermedias se pueden usar como copias de trabajo locales para el conjunto de repositorios secundarios, derivados o posteriores. Las secuencias de comandos de enlace posteriores a la confirmación en el repositorio autorizado actualizarán todas las ubicaciones intermedias y, para cada una, comprobarán si ha cambiado y realizarán la misma confirmación en el repositorio secundario correspondiente si se detecta un cambio.

De esta manera, los múltiples repositorios secundarios se mantienen sincronizados con el único repositorio de origen autorizado, y el proceso de compilación garantiza que los repositorios secundarios contengan todos los documentos (posiblemente compartidos) y otros archivos necesarios para que la compilación tenga éxito. Finalmente, y lo más importante, el proceso de desarrollo y construcción garantiza que los archivos se editen en un solo lugar y en un solo lugar, y que todas las copias se mantengan consistentes y actualizadas.