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

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

Backend y servicios
Middleware
Interfaz

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

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

Nota: estoy preguntando acerca de un único proyecto grande dividido en varios repositorios pequeños. Esto difiere de las preguntas relacionadas que se hacen en este sitio , porque solicitan múltiples proyectos en uno o varios repositorios. Además, elegimos sumergirnos en el proyecto, principalmente porque no estamos dispuestos a invertir un solo depósito privado grande a menos que nos quedemos con él.

project-management team repository

— Plata
fuente

Por repositorio, ¿quiere decir repositorio de código (ala git o svn)?

— Jay Elston

Scant es correcto porque dividir el equipo es un problema mucho más grande que dividir el repositorio. El equipo en el que trabajo tiene unas pocas docenas de repositorios, pero aún somos un equipo.

— Ixrec

Respuestas:

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

Eso es genial. Divide y conquistaras. Divide el esfuerzo en piezas lógicas, entrega cada pieza a un equipo duro diferente, trabaja como loco durante 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. No ahorras dinero escribiendo código más rápido. Esos son los programadores secretos que 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 se ve absolutamente eclipsado por el tiempo dedicado a planificar y hablar y negociar y luchar y hablar y reunirse y hablar un poco más y comprometiéndote y dándote cuenta de que no deberías haber comprometido y prometiendo hacerlo mejor y gritando y deseando y "resolviendo" (eso no es una palabra, maldita sea) y retrocediendo y haciendo ping y hablando y no poder dormir.

Entonces, divide su trabajo en partes discretas y entrega cada parte a un equipo separado. ¿Que acabas de hacer? Agregaste una carga de comunicación. Si tienes suerte ysus equipos son perfectos, no hay absolutamente ninguna diferencia de costo entre un repositorio grande y algunos repositorios pequeños. Si no tiene suerte (pocos lo son), dividirse en equipos separados en realidad costará más. Es bastante 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 forma de corregirlo rápidamente porque no están rompiendo las cosas de los otros equipos), tienen culturas ligeramente diferentes y, al final, son muy motivados para evitar la culpa cuando las cosas van mal, por lo que están más que dispuestos a tirar 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?

Mire, en cualquier enfoque (gran repositorio / muchos repositorios pequeños) tendrá que burlarse 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 irregular, pero es mucho menos irregular que desarrollar de forma independiente con una especificación inestable y un apretón de manos, y luego doblar las cosas tarde.

Mi punto es que los grandes repositorios / pequeños repositorios no son el problema. Lo que importa es cómo estructurar sus equipos. Idealmente, sus equipos tienen pequeñas identidades independientes dentro de una identidad cohesiva más grande. Un poco como órganos en un organismo o tal vez un molde de limo . Independientemente de cómo estructura el código, dé a todos la oportunidad de toparse entre sí. Facilita la comunicación. Cometen errores juntos y corríjalos temprano y con frecuencia.

— Roger escaso
fuente

No estoy de acuerdo con la mayoría de esta respuesta. La comunicación es, por supuesto, importante, pero; solo porque divide la base del código en múltiples repositorios, hay: 1. colaboración: los colaboradores pueden ver la base del código (y modificarla si realmente lo necesitan), 2. documentación . Si está creando una API REST por separado de la interfaz, la API puede estar muy bien documentada y no se producen problemas (a menos que tenga desarrolladores front-end novatos o documentación basura). ¿Cómo puedo saber? Escribo / mantengo una API REST que usan desarrolladores externos, y recibo tal vez un correo electrónico por semana sobre cómo usarlo.

— Chris Cirefice

@ChrisCirefice Ese es otro enfoque completamente. Es un tipo diferente de bestia desarrollar conjuntamente un sistema en lugar de desarrollar una parte de él. En su caso, los desarrolladores de front-end se adaptan a sus decisiones, pero en el caso de op, las decisiones de back-end se toman paralelas a las necesidades y deseos del front-end

— Machinarius

@Machinarius Eso es más o menos cierto. Mi jefe se burla de la interfaz y toma todas las decisiones sobre cómo debería verse / funcionar la aplicación. Los desarrolladores frontend comienzan a trabajar en el esqueleto, yo desarrollo los puntos finales API necesarios en el backend, y los chicos frontend luego conectan las llamadas API para obtener los datos en paralelo. Esto se realiza semana a semana, por lo que no veo mucha diferencia en mi caso, y aún funciona bien. Desarrolladores independientes están trabajando en diferentes aspectos en conjunto, aunque eso obviamente no fue mencionado en mi comentario anterior.

— Chris Cirefice

Nuestro equipo tiene un defensor, un tipo para escribir y mantener los servicios, dos encargados, dos tipos que trabajan en la versión móvil y el líder del equipo, también nuestro jefe, que se encarga de hacer que las cosas funcionen. Casi no tocamos ningún código más allá de su área. Los problemas de comunicación son reales, como con cualquier equipo, pero dividir el equipo no será un problema, ya que ya trabajamos de forma independiente. Gracias por su respuesta, ya que me dio una idea para mostrar al líder del equipo.

— Plata

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

Por ejemplo, si está escribiendo una aplicación web Ruby on Rails sin ninguna API pública (o privada) que su interfaz va a consumir (por AJAX por ejemplo), entonces no veo cómo podría dividir el repositorio sin causando un gran dolor de cabeza a tu equipo. El marco 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 quiere que su interfaz esté escrita en Ember.js o en otra cosa, 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 de Android / iOS). Si planea escribir una API para ser consumida por varios clientes, divida su repositorio. Algunos argumentarían que incluso dividir la API en una aplicación completamente diferente es una mala idea, una con la que estoy totalmente en desacuerdo (¡y lo parece por una buena razón !

Dividir el repositorio si ya planeaba 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 por el código de los demás, debe asegurarse de tener una excelente comunicación , pero aún más importante, documentación . Sin documentar la API, por ejemplo, sus otros dos equipos se enojarán muy rápidamente porque el equipo de API no documentó la arquitectura, y su equipo de API se enojará porque todos siguen haciéndoles preguntas. Esto es aún más cierto para los equipos remotos .

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

— Chris Cirefice
fuente

Un solo repositorio no tiene que ser un monolito. Las capas físicas y lógicas se pueden almacenar en repositorios separados, pero no tienen que ser así. Un único repositorio puede contener una API de back-end y otras capas. La carga de la comunicación (la documentación es parte de la comunicación) no es más o menos con un gran repositorio o varios repositorios pequeños. Ese es mi punto: los repos no importan. Lo que importa es cómo su equipo / equipos piensan acerca de los problemas y trabajan juntos para resolverlos.

— Escaso Roger

Tenemos la aplicación ya separada en distintas entidades. El backend y los servicios están a un lado. El front-end solo consume los servicios a través del cliente. Nuestros encargados solo saben cómo funcionan los servicios. Nuestro equipo tiene un backender, un tipo para escribir los servicios, dos encargados y dos tipos que trabajan en la versión móvil, y apenas tocan ningún código más allá de su área.

— Plata