Vamos entender isso direito.
Algumas perguntas simples para iniciar. A aplicação na qual você trabalha é um software de prateleira? Você está desenvolvendo código específico para um cliente específico? O código no qual sua empresa está trabalhando é alterado por outras empresas? Você trabalha em uma aplicação cuja propriedade é da softwarehouse, e que está em vários clientes, mas um determinado cliente está sempre pedindo customizações?
A aplicação na qual você trabalha é um software de prateleira?
Olha só, se sua aplicação é de prateleira, e há poucos desenvolvedores, esse é o cenário ideal. Nessa situação não há customização. Exemplo, um aplicativo simples para IPhone; um website em que você é o proprietário e o próprio desenvolvedor.
Nesse caso o percentual de merges pode chegar a zero.
Mas e no caso de eu estar em 2013 e estiver preparando a versão de 2014?
Será feito um merge para o lançamento, depois vão existir dois produtos. 2013 e 2014. A versão 2013 sofrerá correções mas não influirá na versão 2014, e eventualmente essa versão será descontinuada (claro isso é um cenário idealizado, não precisa ficar nervoso. É apenas para fins didáticos)
Você está desenvolvendo código específico para um cliente específico?
Até o final do desenvolvimento não há necessidade de merge pois o produto não foi implantado no cliente. Ou "seje" o produto não existe! Então para que ficar fazendo merge em uma coisa que não existe? Como um produto novo, que ainda não foi implantado pode ter mais de uma versão, sem ter nem ao menos a versão alfa? Minha sugestão, faça sobreposição.
E depois que for lançada a versão alfa? Bem aí, aparecerá a versão beta. Mas antes de colocar a versão beta no ar, não vejo necessidade de ter a versão beta1, beta2, beta3, beta4, beta5 e etc... Que tal lançar a versão e depois criar outra e assim por diante. Ao invés de criar uma miríade de versões?
E depois que a aplicação foi implantada no cliente? Daí a coisa muda de figura, pois, dependendo do tamanho da aplicação, o cliente poderá pedir customizações que tem pouca relação umas com as outras. Nesse caso, aparecem várias versões e o merge é inevitável. OU você se planeja, negocia com o cliente e entrega tudo de uma vez. Isso evitár trabalhos de merge que são caros apesar de invisíveis.
O código no qual sua empresa está trabalhando é alterado por outras empresas?
Esse cenário é um potencial causador de cefaleia. Nesse caso todo cuidado é pouco. Mas veja bem. Uma outra empresa, tem uma versão do código que você está alterando, e em algum momento fará o merge com a versão que está em produção. Você também tem uma versão do código que será adicionada ao código principal. Só aí já temos três versões. A sua, a da outra empresa, e a principal. Agora imagine se você tivesse vários baselines deste código? O que você acha que acontece com o risco de algo dar errado na hora do merge.
Neste cenário o merge é inevitável, mas de novo, planeje-se, negocie e entregue todas as suas alterações em uma versão só (claro isso é um cenário idealizado, não precisa ficar nervoso. É apenas para fins didáticos).
Você trabalha em uma aplicação cuja propriedade é da softwarehouse, e que está em vários clientes, mas um determinado cliente está sempre pedindo customizações?
Não quero me torna repetitivo, mas é o seguinte. Agrupe o máximo de requisições possíveis em uma versão e só então faça sua entrega. Fazer uma branch para cada requisição do cliente é a receita para falência (agora pode ficar nervoso, o que eu falei aqui não é para fins didáticos. I mean it!). Nesse caso o merge será provavemente inevitável.
MERGE***
PRÓS**
Possibilidade de desenvolvimento em paralelo de demandas com fraco relacionamento. A não ser que você tenha uma grande equipe de teste que teste vários desenvolvimentos em paralelo na mesma aplicação. Se só existe uma pessoa que homologa, para que fazer desenvolvimento paralelo? Há nexo?
POSSÍVEL CONTRA**
Proliferação infinita de branches.
SOBREPOSIÇÃO DE CÓDIGO***
PRÓS**
Menos código para ser gerenciado. Fluxo de deploy simplificado.
POSSÍVEL CONTRA**
Maior dificuldade de paralelizar desenvolvimento (mas não é impossível).
CONSIDERAÇÕES FINAIS
Há outros prós e contras que não foram mencionados, mas achei esses os principais.
Tenho experiência tanto em empresa que trabalhava com 0% de merge, e com empresa que trabalhava com 0% de sobreposição. Nenhuma das duas coisas é saudável. A sobreposição de código é um mundo ideal com poucos conflitos, não há muito o que dizer à respeito.
Da questão do merge, entretanto, há muito o que se debater. Há por exemplo um mito, estranhíssimo, que parece espalhado pelas TI's do Brasil, de que um merge bem feito implica em um código correto. Qual é a lógica disso? Não, merge por si só não corrige erros de requisito mal feito, ou de codificação displicente. Se você era um desses que achava que o merge tinha o poder que corrigir um requisito mal feito, MYTH BUSTED!
CONCLUSÃO
De tudo que escrevi acima, o que acho mais importante é:
"Planeje-se, negocie e entregue todas as suas alterações em uma versão só!"
Ou seja, mais do que uma questão técnica, esta é uma questão de GERÊNCIA. Mas é claro que um ALM bem implementado também é de suma importância.
PS: Este assunto é muito chato, eu sei. Por conta disso, escolhi esse video para você assistir se refazer dessa chatice toda:
Nenhum comentário:
Postar um comentário