¿Qué tan viable es tener una sola aplicación web en varios repositorios pequeños privados?

8

Somos un equipo de bajo presupuesto que trabaja en una aplicación web. Debido a algunas complicaciones, podríamos necesitar trabajar de forma remota a partir de enero y en adelante. Después de algunas consultas y búsquedas en Google, llegamos a la conclusión de que varios repositorios pequeños es la opción más barata. Estamos pensando en:

  • Backend y servicios

  • Middleware

  • Front End

De esta manera podemos separar en equipos relevantes, cada uno trabajando de forma remota en su repositorio. ¿Qué tan viable es tener nuestra aplicación en varios repositorios pequeños privados?

Además, ¿qué consideraciones deberíamos tomar si tuviéramos que trabajar de esta manera?

Nota: estoy preguntando por un solo proyecto grande dividido en varios repositorios pequeños. Esto difiere de las preguntas relacionadas en este sitio , porque están solicitando múltiples proyectos en uno o varios repositorios. Además, optamos por bucear el proyecto, principalmente porque no estamos dispuestos a invertir un solo repositorio privado grande a menos que nos atengamos a él.

    
pregunta Silver 14.12.2015 - 22:08

2 respuestas

4
  

"... concluimos que varios repositorios pequeños es la opción más barata".

Eso es genial. Divide y conquistaras. Rompes el esfuerzo en piezas lógicas, le das cada pieza a un equipo diferente, trabajas como loco por unos meses, reúne todo y ...

y ...

Bueno, será una maldita pesadilla. Definitivamente no será más barato. ¿Por qué sería?

El mayor "costo" en cualquier proyecto de software es la comunicación. Usted no ahorra dinero al escribir el código más rápido. Ese es el secreto que los programadores no admitirán. ( Psst. No se lo digas a nadie. Realmente no importa lo rápido que escribas el código. ) El tiempo dedicado a escribir el código es absolutamente enano por el tiempo empleado en planificar y hablar y negociar y pelear y hablar y reunirme y hablar un poco más y comprometernos y darme cuenta de que no debería haberse comprometido y prometido a hacerlo mejor y gritar y desear y "solucionar" (eso no es una palabra, maldita sea) y regresar y hacer ping y hablar, y no poder dormir .

Entonces, divides tu trabajo en partes discretas y le das cada parte a un equipo separado. ¿Que acabas de hacer? Añadiste carga de comunicación. Si tiene suerte, y sus equipos son perfectos, no hay absolutamente ninguna diferencia de costo entre un gran repositorio y unos pocos repositorios pequeños. Si no tienes suerte (pocos lo son), dividirte en equipos separados costará más. Es lo suficientemente difícil mantenerse sincronizado cuando todos están en la misma base de código, pisando los dedos de los demás. Ahora imagine lo difícil que será cuando tres equipos diferentes piensen que los requisitos significan algo ligeramente diferente (sin manera de corregirlos rápidamente porque no están rompiendo las cosas de los otros equipos), tienen culturas ligeramente diferentes y, al final, son muy motivado para evitar la culpa cuando las cosas van mal, así que están más que dispuestos a lanzar a los otros equipos debajo del autobús.

Lo sé, lo sé ... tus equipos son mejores que eso. ¿Pero son realmente? ¿Tienes la confianza suficiente para apostar dinero en él?

Mira, en ambos enfoques (repo grande / muchos repositorios pequeños) tendrás que burlarte de un montón de basura al principio. Empiezas a trabajar a ciegas. Tan pronto como sea posible, tan pronto como estén disponibles, debe comenzar a usar implementaciones concretas de las otras capas. Esto identificará problemas y malentendidos temprano. Claro, será un poco accidentado, pero es mucho menos accidentado que desarrollarse de forma independiente con una especificación inestable y un apretón de manos, y luego juntar las cosas tarde.

Mi punto es que los grandes repositorios / repositorios pequeños no son el problema. Lo que importa es cómo estructuras tus equipos. Idealmente, sus equipos tienen pequeñas identidades independientes dentro de una identidad cohesiva más grande. Algo así como órganos en un organismo o tal vez un moho de limo . Independientemente de cómo estructure el código, dé a todos la oportunidad de toparse entre sí. Hacer la comunicación fácil. Comete errores juntos y resuélvelos temprano y con frecuencia.

    
respondido por el Scant Roger 15.12.2015 - 05:37
1

En mi opinión, dividir el repositorio depende en gran medida de tus objetivos y las herramientas que estés utilizando.

Por ejemplo, si estás escribiendo una aplicación web de Ruby on Rails sin ninguna API pública (o privada) que tu interfaz consumirá (por ejemplo, por AJAX), entonces realmente no veo cómo usted podría dividir el repositorio sin causar un dolor de cabeza masivo para su equipo. El marco de Rails realmente funciona mejor con una arquitectura de tipo monolítico en ese caso.

Sin embargo, si planea escribir una API en Rails o Node.js, pero desea que su interfaz de usuario esté escrita en Ember.js o algo más, entonces tendría sentido dividir el repositorio. Lo mismo se aplica si los datos de su aplicación web serán compartidos en el futuro por otros clientes (como a través de una aplicación Android / iOS). Si planea escribir una API para ser consumida por varios clientes, divida su repositorio. Algunos dirían que incluso dividir la API en una aplicación diferente por completo es una mala idea, una con la que estoy totalmente en desacuerdo (y parece ser así para buena razón !

Dividir el repositorio si ya planeó separar la aplicación web como describí es la única opción lógica. Sin embargo, tenga en cuenta que debido a que será más difícil para las personas navegar entre los códigos, debe asegurarse de tener una excelente comunicación , pero lo que es más importante es que documentación . Sin documentar la API, por ejemplo, sus otros dos equipos se enojarán muy rápidamente porque el equipo de la API no documentó la arquitectura, y su equipo de API se enojará porque todo el mundo sigue haciéndoles preguntas. Esto es aún más cierto para los equipos remotos .

Entonces, todo depende de cómo deseaba estructurar la aplicación en primer lugar. Si está creando una aplicación web monolítica (y sabe o está seguro de que solo seguirá siendo una aplicación web ), entonces tenga un repositorio. Si planeó crear cosas como microservicios o una API REST consumida por varios clientes (o está planeando esto para el futuro ), divida el repositorio.

    
respondido por el Chris Cirefice 15.12.2015 - 13:22

Lea otras preguntas en las etiquetas