Quão viável é ter um único webapp em vários pequenos repositórios particulares?

Somos uma equipe de baixo orçamento trabalhando em um aplicativo da web. Devido a algumas complicações, talvez seja necessário trabalhar remotamente a partir de janeiro. Após algumas consultas e pesquisas no Google, concluímos que vários repositórios pequenos são a opção mais barata. Estamos pensando em:

Back-end e serviços
Middleware
a parte dianteira

Dessa forma, podemos separar em equipes relevantes, cada uma trabalhando remotamente em seu repositório. Quão viável é ter nosso aplicativo em vários pequenos repositórios particulares?

Além disso, que considerações devemos tomar se trabalharmos dessa maneira?

Nota: Estou perguntando sobre um único grande projeto dividido em vários pequenos repositórios. Isso difere das perguntas relacionadas feitas neste site , porque eles estão solicitando vários projetos em um ou vários repositórios. Além disso, optamos por mergulhar no projeto, principalmente porque não estamos dispostos a investir em um único repositório particular grande, a menos que continuemos com ele.

project-management team repository

— Prata
fonte

Por repositório, você quer dizer repositório de código (ala git ou svn)?

— Jay Elston

A Scant está correta, pois dividir a equipe é um problema muito maior do que dividir o repo. A equipe em que trabalho tem algumas dezenas de repositórios, mas ainda somos uma equipe.

— Ixrec

Respostas:

"... concluímos que vários repositórios pequenos são a opção mais barata".

Isso é ótimo. Dividir e conquistar. Você divide o esforço em peças lógicas, entrega cada peça a uma equipe diferente, trabalha como louca por alguns meses, reúne tudo e ...

e...

Bem, será um maldito pesadelo. Definitivamente não será mais barato. Por que seria?

O maior "custo" em qualquer projeto de software é a comunicação. Você não economiza dinheiro escrevendo código mais rapidamente. Esses são os programadores secretos que não admitem. ( Psst. Não conte a ninguém. Realmente não importa a rapidez com que você escreve código. ) O tempo gasto escrevendo código é absolutamente diminuído pelo tempo gasto planejando, conversando, negociando, lutando, conversando, conhecendo e conversando um pouco mais. comprometer e perceber que você não deveria ter comprometido e prometer fazer melhor, gritando, desejando e "resolvendo" (isso não é uma palavra, caramba) e dando voltas, pingando, conversando e não conseguindo dormir.

Então, você divide seu trabalho em partes discretas e entrega cada parte para uma equipe separada. O que você acabou de fazer? Você adicionou um fardo de comunicação. Se você tiver sorte esuas equipes são perfeitas, não há absolutamente nenhuma diferença de custo entre um grande repositório e alguns pequenos repositórios. Se você não tiver sorte (poucas são), dividir equipes separadas custará mais. Já é bastante difícil ficar sincronizado quando todos estão na mesma base de código, pisando nos dedos uns dos outros. Agora imagine como será difícil quando três equipes diferentes acharem que os requisitos significam algo um pouco diferente (sem nenhuma maneira de corrigir rapidamente porque não estão quebrando o material das outras equipes), tiverem culturas um pouco diferentes e, no final, muito motivados para evitar culpas quando as coisas dão errado, então eles estão mais do que dispostos a jogar as outras equipes embaixo do ônibus.

Eu sei, eu sei ... suas equipes são melhores que isso. Mas eles são mesmo? Você está confiante o suficiente para apostar dinheiro nisso?

Veja, em qualquer uma das abordagens (grandes acordos de recompra / muitos acordos de recompra), você terá que zombar de um monte de porcaria no começo. Você começa a trabalhar às cegas. Assim que possível, assim que estiverem disponíveis, você deverá começar a usar implementações concretas das outras camadas. Isso identificará problemas e mal-entendidos cedo. Claro, será um pouco acidentado, mas é muito menos acidentado do que se desenvolver independentemente com uma especificação instável e um aperto de mão, e depois dobrar as coisas tarde.

O que quero dizer é que grandes repositórios / pequenos repositórios não são o problema. O que importa é como você estrutura suas equipes. Idealmente, suas equipes têm pequenas identidades independentes, dentro de uma identidade coesa maior. Como órgãos em um organismo ou talvez um mofo . Independentemente de como você estrutura o código, dê a todos a chance de se depararem. Facilite a comunicação. Cometer erros juntos e corrigi-los cedo e frequentemente.

— Roger escasso
fonte

Discordo da maior parte desta resposta. A comunicação é obviamente importante, mas; só porque você divide a base de código em vários repositórios, existe: 1. colaboração - os colaboradores podem visualizar a base de código (e modificar se realmente precisam), 2. documentação . Se você estiver criando uma API REST separadamente do front-end, a API poderá ser muito bem documentada e sem complicações (a menos que você tenha realmente desenvolvedores front-end novatos ou documentação ruim). Como eu sei? Escrevo / mantenho uma API REST usada por desenvolvedores de terceiros e recebo talvez um e-mail por semana sobre como usá-la.

— Chris Cirefice

@ ChrisCirefice Essa é outra abordagem completamente. É um tipo diferente de fera co-desenvolver um sistema em vez de desenvolver uma parte dele. No seu caso, os desenvolvedores de front-end se adaptam às suas decisões, mas no caso das operações, as decisões de back-end são tomadas paralelamente às necessidades e desejos do front-end.

— Machinarius

@Machinarius Isso é mais ou menos verdade. Meu chefe zomba do front-end e toma todas as decisões sobre a aparência / funcionamento do aplicativo. Os desenvolvedores de front-end começam a trabalhar no esqueleto, desenvolvo os pontos de extremidade da API necessários no back-end e os caras do front-end então ligam as chamadas da API para obter os dados em paralelo. Isso é feito semanalmente, então não vejo muita diferença no meu caso e ainda funciona muito bem. Desenvolvedores separados estão trabalhando em diferentes aspectos em conjunto, embora isso obviamente não tenha sido mencionado no meu comentário anterior.

— Chris Cirefice

Nossa equipe tem um backender, um responsável por escrever e manter os serviços, dois front-end, dois funcionários trabalhando na versão móvel e o líder da equipe, também nosso chefe, responsável por fazer as coisas funcionarem. Quase não tocamos nenhum código além da área deles. Os problemas de comunicação são reais, como em qualquer equipe, mas dividir a equipe não será um problema, pois já trabalhamos de forma independente. Obrigado pela sua resposta, pois me deu algumas dicas para mostrar ao líder da equipe.

— Silver

A meu ver, dividir o repositório depende muito de seus objetivos e das ferramentas que você está usando.

Por exemplo, se você estiver escrevendo um aplicativo Web Ruby on Rails sem nenhuma API pública (ou privada) que seu front-end consumirá (por AJAX, por exemplo), não vejo como você pode dividir o repositório sem causando uma enorme dor de cabeça para sua equipe. A estrutura do Rails realmente funciona melhor com uma arquitetura do tipo monolítico nesse caso.

No entanto, se você planeja escrever uma API no Rails ou no Node.js, mas deseja que o seu front-end seja escrito no Ember.js ou em qualquer outra coisa, faria sentido dividir o repositório. O mesmo se aplica se os dados do seu aplicativo da web forem compartilhados no futuro por outros clientes (como por meio de um aplicativo Android / iOS). Se você planeja escrever uma API para ser consumida por vários clientes, divida seu repositório. Alguns argumentam que mesmo dividir a API em um aplicativo completamente diferente é uma péssima idéia, com a qual eu discordo totalmente (e parece que sim por um bom motivo !

Dividir o repositório, se você já planejou desmembrar o aplicativo Web, como descrevi, é a única opção lógica. No entanto, lembre-se de que, como será mais difícil para as pessoas procurarem o código uma da outra, é necessário garantir uma excelente comunicação , mas ainda mais importante na documentação . Sem documentar a API, por exemplo, suas outras duas equipes ficarão irritadas muito rapidamente porque a equipe da API não documentou a arquitetura, e sua equipe da API ficará irritada porque todo mundo continua fazendo perguntas. Isso é ainda mais verdadeiro para equipes remotas .

Portanto, tudo depende de como você deseja estruturar o aplicativo em primeiro lugar. Se você estiver construindo um aplicativo Web monolítico (e souber ou tiver certeza de que ele continuará sendo um aplicativo Web ), tenha um repositório. Se você planejou criar coisas como microsserviços ou uma API REST consumida por vários clientes (ou planeja isso para o futuro ), divida o repositório.

— Chris Cirefice
fonte

Um único repo não precisa ser um monólito. Camadas físicas e lógicas podem ser armazenadas em repositórios separados, mas não precisam. Um único repositório pode conter uma API de back-end e outras camadas. O ônus da comunicação (a documentação faz parte da comunicação) não é mais ou menos com um grande repositório ou vários pequenos repositórios. Esse é o meu ponto - os repositórios não importam. O que importa é como sua equipe pensa em problemas e trabalha em conjunto para resolvê-los.

— quer

Já temos o aplicativo separado em entidades distintas. O back-end e os serviços estão de um lado. O front end consome apenas os serviços via cliente. Nossos front-end sabem apenas como os serviços funcionam. Nossa equipe tem um back-end, um responsável por escrever os serviços, dois front-end e dois trabalhando na versão móvel, e eles dificilmente tocam em nenhum código além de sua área.

— Silver