Está cometendo / verificando código todos os dias uma boa prática?

Eu não concordo com essa regra e concordo com o que Mason Wheeler disse. Eu gostaria gostaria de adicionar algumas ideias.

Eu tento me comprometer toda vez que tenho uma significativa mude para commit: isso pode ser várias vezes por dia se eu corrigir vários pequenos bugs, ou uma vez por semana, se eu estou trabalhando em um grande pedaço de software que não pode ser usado pelo resto do código de qualquer maneira significativa até atingir um estado consistente.

Além disso, eu interpreto confirmando como publicando uma revisão significativa que contribui com nova funcionalidade para a base de código. Eu acho que se deve tentar limpar o código antes de cometer para que outros desenvolvedores podem entender o significado e o propósito da mudança quando eles olham para o histórico de revisão. Quanto menos mudanças outros desenvolvedores ver na história, o melhor: quando eu olho para a história de revisão que eu quero para ver incrementos que adicionam alguma funcionalidade significativa; eu não estou interessado em cada pequena idéia que cada desenvolvedor tinha e queria experimentar antes que eles alcançou a solução.

Além disso, não acho que seja uma boa ideia usar o servidor SVN (ou qualquer sistema de controle de versão) como um recurso de backup para o qual o instantâneo atual do código é confirmado (desde que seja compilado): você pode usar um pendrive ou uma unidade USB externa ou um disco de rede para espelhar seu código atual para que ele não se perca se o seu computador quebra. Controle de revisão e backup de dados são dois diferentes coisas. Publicar uma revisão não é o mesmo que salvar um instantâneo do seu código.

Finalmente, acho que não deve ser um problema comprometer todos os dias e então (isto é, somente quando alguém está realmente satisfeito com o estado atual de o código) e evitar conflitos de mesclagem não é uma boa justificativa para cometer (também) com freqüência. Muitos conflitos de mesclagem acontecem quando pessoas diferentes trabalham nos mesmos arquivos ao mesmo tempo, o que é uma prática ruim (veja, por exemplo, este artigo , aponte 7). Os conflitos de mesclagem devem ser reduzidos dividindo um projeto em módulos com interfaces claras e com o menor número de dependências possível, e coordenando o trabalho dos desenvolvedores para que o código em que eles trabalham se sobreponha quanto possível.

Apenas meus 2 centavos.

EDITAR

Outra razão contra os comprometimentos prematuros que me veio à mente é que uma versão (muito) com bugs não pode ser testada. Se você está cometendo no tronco e sua equipe de teste está testando todos os dias, eles podem não ter versão testável por algumas horas (ou por um dia). Mesmo se você não tentar consertar o bug e Apenas reverta suas alterações, uma reconstrução pode levar algumas horas. Com, digamos cinco testadores trabalhando em sua equipe, você desperdiçou 5 x 2 = 10 horas de o tempo da equipe devido a inatividade. Aconteceu comigo uma vez, então eu realmente tento para evitar commits prematuros em nome de commit o mais rápido possível .

Eu confirmo o código várias vezes ao dia . Sempre que chego a um ponto em que o código está completo o suficiente para compilar e não quebra outras coisas, ele entra.

Você deve procurar dividir seu trabalho para que possa fazer check-in com segurança algumas vezes por dia.

As justificativas para isso são duas:

1. Qualquer trabalho que não esteja marcado pode ser perdido - o seu computador pode ter uma falha catastrófica. Nesse caso, quanto mais você esperar, mais trabalho perderá.
2. Quanto mais trabalho você fizer sem fazer o check-in, mais código os outros precisarão integrar quando você finalmente decidir que ele é ativado. Isso apresenta mais chances de conflitos e problemas de mesclagem.

Aderir a qualquer metodologia ou prática sem entender as razões por trás disso nunca é uma boa ideia. É daí que vem a programação de cultos de carga.

Portanto, "eu deveria me comprometer todos os dias porque Martin Fowler disse isso" é simplesmente estúpido. E às vezes é impraticável também. Se você estiver trabalhando em um novo recurso complicado, talvez não chegue a um ponto em que valha a pena fazer o check-in até que já tenha trabalhado nele por alguns dias.

Isso não significa que você deve ter certeza de que tudo está perfeito antes de fazer o check-in. Essa é uma boa maneira de perder o trabalho se algo der errado. A coisa certa a fazer é desenvolver e usar o bom senso sobre o assunto. Regras básicas só podem ajudá-lo muito.

Oded deu dois motivos importantes para confirmar o código com a maior frequência possível. Vou adicionar mais alguns:

1. Enquanto trabalha no seu código, outro pode precisar de algumas funções nesse código. Eles não devem esperar 6 dias para obtê-lo. Neste caso, meus colegas geralmente criam um protótipo no meu código, o comprometem, adiciono o corpo e o faço novamente. E isso geralmente é feito em poucas horas.

2. O código "comum" é para que todos vejam todas as alterações o mais rápido possível. Se a parte do código em que você está trabalhando estiver totalmente separada do trabalho dos outros e você não quiser que eles esperem, então é recomendável criar uma ramificação para você trabalhar e, se tudo for bem-sucedido, mesclá-la a linha principal.

Acredito firmemente em cometer todas as mudanças lógicas que vale a pena manter. Confirme com frequência e, se não vale a pena manter o código, reverta-o para um estado limpo. Quanto mais tempo você esperar para enviar / publicar seu código de volta, mais difícil será implementar, e mais problemas você encontrará. Você também receberá feedback sobre suas contribuições muito mais rápido:

• eles quebram a construção?
• você está duplicando os esforços de outro membro da equipe?
• você está fazendo algo incorreto?
• ou as pessoas estão esperando por você?

Pequenas alterações são muito mais fáceis de gerenciar.

Além disso, vale a pena notar a diferença entre os diferentes sistemas de controle de versão. Alguns, como o Git (distribuído), permitem que você confirme e controle todo o seu histórico localmente, apenas pressionando quando estiver pronto para publicar. Outros, como o SVN (centralizado), combinam as duas etapas tornando os pequenos commits ineficientes.

Não esqueça que seus commits são essencialmente documentação de alterações. Quando as coisas dão errado, você ficará feliz em ter mais história do que o suficiente. Um único commit para um trabalho de semanas parece inútil para mim. Eu acabaria lendo todas as linhas de código alteradas em vez do resumo de cada parte lógica.

Acho que a maioria das respostas aqui erra um dos principais pontos da declaração de Martin Fowlers. Isso está relacionado a Integração Contínua . O código que não foi verificado (enviado / publicado / mesclado) para a linha principal não foi testado.

Isso não deve ser lido como um incentivo para se comprometer com qualquer código que você tenha em sua máquina local sempre que for hora de sair do escritório. Como apontado por vários outros aqui que seria ruim, quebraria a construção e causaria uma linha principal instável.

No entanto, é um incentivo tentar fazer suas alterações em pequenos passos que podem ser verificados na linha principal sem causar problemas. Isso encoraja a evolução do código em vez de rasgá-lo e reescrevê-lo.

Agora, o que há de bom nessa maneira de trabalhar?

1. Não comprometer grandes blocos de código ou alterações revolucionárias reduz a chance de quebrar a compilação.
2. Se a sua consolidação quebra a compilação, é bastante trivial identificar quais são os problemas, revertê-la e, em seguida, confirmar uma versão corrigida rapidamente.
3. Ao garantir que todos os testes sejam executados em cada pequena alteração no código, você garante que não introduza erros sutis ou regressões que possam resultar de um código crescer fora do esquema de integração contínua.

É claro que nem todas as mudanças se prestam a essa abordagem. Como outros salientaram, nenhuma regra é absoluta. No entanto, para alterações que devem permanecer fora do mainline por um longo tempo, configure um mainline alternativo com seu próprio esquema de integração contínua e siga a mesma abordagem em relação a ele. Com os VCS distribuídos de hoje, é uma coisa bastante fácil de fazer.

Argumentos para o check-in todos os dias:

• O código é armazenado e armazenado em backup com falha no disco rígido
• A atividade pode ser gravada em notas de compromisso ( o que eu fiz na quinta-feira ...? )
• A integração com a base de código existente ocorre mais cedo e em partes menores, identificando, com sorte, conflitos ou problemas de mesclagem mais cedo
• Sua equipe tem visibilidade do que você está trabalhando
• Seus colegas podem trabalhar contra suas interfaces mais rapidamente, dando a eles mais tempo para se integrarem ao seu "grande e complexo código"
• O seu código será testado no mundo real mais cedo, ou pelo menos exposto a mais uso do que você vai dar, levando à identificação antecipada de erros ou omissões.

Argumentos contra o check-in todos os dias:

• Não precisa ou não quer
• Ainda não "limpei" meu código, é uma bagunça
• Não tem tempo

Eu não acredito que haja uma boa razão para checar menos do que diariamente, além da preguiça ou desorganização. Nada pior do que ver o código em execução no ambiente de desenvolvimento não corresponde ao código na ramificação de desenvolvimento porque alguém "ainda não terminou" e, portanto, não fez check-in.

Eu adoraria estar errado nisso, então, por favor, deixe-me saber qualquer argumento legítimo contra o check-in diário.

Se você está querendo dizer "commit" como "merge into mainline", então você definitivamente não deveria estar fazendo isso todos os dias em um projeto de software que está sendo liberado para os clientes. Você deve estar mesclando as alterações feitas e testadas, para que a linha principal esteja sempre funcionando e liberada, e não em algum estado quebrado com recursos semiacabados.

No entanto, o luxo de trabalhar com o controle de versão distribuído de hoje é que você pode manter a linha principal estável e ao mesmo tempo fazer seu git/hg/whatever commit sempre que achar que deseja preservar o estado das coisas. Eu faço isso uma vez a cada poucas horas e, definitivamente, no final de cada dia.

Com o DVCS, você pode publicar seu trabalho, colaborar nele com outras pessoas da sua equipe e mantê-lo atualizado com as alterações na ramificação da linha principal. Você pode fazer tudo isso sem poluir a estabilidade de código da qual seus clientes e / ou outras equipes dependem.

Em tempos em que o Subversion era a tecnologia mais recente e não havia maneira de bifurcar e mesclar ramificações de recursos sem extrema dor, ter uma linha principal em que vários recursos diferentes estivessem em construção simultânea poderia ter sido a melhor abordagem. Mas essa superioridade não aumenta além de 2010.

No Team Foundation Server você pode 'Shelve', que não é o mesmo que um check-in, mas apenas faz um backup do seu código para que, se sua máquina morrer, você não tenha perdido as alterações.

Eu também vi casas de software que têm uma 'linha de desenvolvedor' e uma 'linha principal'. Devs são livres para fazer check-in na linha de desenvolvedores sempre que acharem adequado e somente o líder da equipe tem acesso à linha principal, então eles são responsáveis por copiar o código do dev para main quando estiver pronto para a produção.