Quando confirmar o código?

Ao trabalhar em um projeto, o código pode ser desenvolvido razoavelmente rápido em um único dia ou pouco a pouco por um período prolongado de algumas semanas / meses / anos. Como as confirmações de código estão sendo consideradas como uma medida do desenvolvimento do projeto, isso realmente não significa que tenha mais código escrito do que um projeto que tenha confirmações menores.

Portanto, a questão é quando realmente fazer um commit no repositório para que o commit seja justificável?

Como complemento: É uma prática correta medir o desenvolvimento de um projeto com base em seus commits?

Você confirma quando atinge um estado da base de código que deseja lembrar. Existem várias razões pelas quais você pode se lembrar de um estado específico da base de código, portanto, não pode haver regras rígidas sobre quando confirmar. No entanto, o número de confirmações definitivamente não é uma medida de qualidade ou progresso.

Eu gosto de pensar em codificação como escalada neste contexto. Você sobe um pouco e depois coloca uma âncora na rocha. Se você cair, a última âncora que você plantou é o ponto que o protege, para que você nunca caia mais do que alguns metros. Mesmo com controle de origem; você codifica um pouco e quando atinge uma posição um pouco estável, comete uma revisão. Se você falhar terrivelmente, sempre poderá voltar para a última revisão e saberá que é estável.

Dito isto, se você trabalha em equipe, é habitual garantir que tudo o que você comprometa seja completo, faça sentido, construa de forma limpa e não quebre as coisas de outras pessoas. Se você precisar fazer alterações maiores que possam interferir no trabalho de outras pessoas, faça um ramo para poder se comprometer sem incomodar ninguém.

Também depende do sistema SCM que você está usando. Os sistemas distribuídos normalmente tornam a fusão e a bifurcação simples e rápidas, e você pode confirmar localmente; isso significa que você deve comprometer muito e pressionar / mesclar quando tiver realizado uma quantidade substancial de trabalho. Com sistemas centralizados como svn ou cvs, o comprometimento é mais caro e afeta a todos. A ramificação resolve parcialmente esse problema, mas, como acontece no servidor, pode ser dolorosamente lento e a fusão pode ser complicada. Portanto, com os SCMs centralizados, geralmente há uma cultura mais cuidadosa, na qual você só se compromete depois de realizar uma quantidade significativa de trabalho.

Quanto ao complemento: por favor, não faça isso. Linhas de código, número de confirmações, número de bugs encontrados / resolvidos etc. são medições muito ruins de qualidade ou quantidade.

Se você estiver usando DVCS como Mercurial ou Git, deverá se comprometer com seu repositório local sempre que tiver realizado uma quantidade significativa de trabalho. No entanto, apenas envie-o para o repositório compartilhado somente depois que estiver funcionando, uma mudança independente que foi testada.

Para VCS não distribuídos (como, por exemplo, SVN), a mesma lógica se aplica. Em vez de repositório local, use branch privado, em vez de push - merge para o branch principal.

Você deve se comprometer cedo e com frequência.

Conheço pessoas que cometem tantas vezes quanto a cada 90 segundos. A sério. Parece funcionar para eles. Eu experimentei confirmar sempre que salvar um arquivo, que provavelmente é mais frequente que 90 segundos. Hoje, eu provavelmente me comprometo a cada 15 minutos. Um VCS que permite compactar várias confirmações em uma e que permite confirmações locais (como git) facilita muito isso.

Com que frequência você deve se comprometer? Difícil dizer, mas provavelmente mais frequentemente do que você é agora. Continue cometendo cada vez mais, encontre um ponto que pareça absurdo demais e depois recue um pouco. É provável que você acabe com algo razoável.

Você mede o desenvolvimento de um produto com base no valor entregue aos seus usuários. Não há outra medida precisa.

As confirmações são os componentes de qualquer código / dado controlado por versão. Cada confirmação deve fazer exatamente um dos seguintes:

• Adicionar uma nova peça de dados ou função
• Corrija um ou mais erros (um commit para cada correção, se possível) onde a correção pode ser:
  • Melhoria de desempenho
  • Corrigindo o comportamento incorreto do código
  • Removendo erros tipográficos
• Refatorando código ou dados sem alterar a semântica. Isso inclui:
  • Reescrevendo código que se comporta idêntico ao original
  • Alterando a representação dos dados para um formato diferente
  • Formatar código ou dados para atender às diretrizes de formatação do projeto
• Mesclar alterações de outra ramificação (upstream / downstream)

Além disso, ao trabalhar em ramificações, as confirmações devem ir para uma ramificação mais adequada. Duas confirmações não devem ter a mesma mensagem de confirmação (implicando alterações semelhantes), mas em ramificações diferentes, pois confunde os colaboradores. Uma maneira melhor é confirmar a ramificação principal e mesclar com a ramificação do recurso.

Se os confirmadores seguem a regra acima, torna-se trivial para:

• Reverter uma alteração específica sem efeitos colaterais
• Identificar comportamento que altera as alterações de código das alterações de formatação de código
• Mesclar entre diferentes ramos, evitando a maioria dos conflitos
• Colabore com outros desenvolvedores que podem fazer suas alterações com facilidade

Em relação à medição do progresso do projeto com base em confirmações, é possível se a refatoração de confirmações e a correção de erros não forem levadas em consideração.

Confirme somente quando você tiver testado com êxito a função / módulo / funcionalidade fornecida e tiver certeza razoável de que ela está pronta para integração ou teste do sistema.

E para responder às suas perguntas adicionais - NÃO !! a medida de onde o projeto está nunca deve ser determinada pelo número de confirmações ... quem sabe o que realmente foi comprometido? Foi testado com sucesso no sistema ou mesmo testado em unidade. Só porque está comprometido - não significa que esteja pronto para produção.

Como complemento: É uma prática correta medir o desenvolvimento de um projeto com base em seus commits?

Não. Havia uma WTF diária sobre por que essa é uma idéia horrível.

Minha regra geral de confirmação de código é fazer check-in quando tiver concluído um pedaço de código e ele for compilado. Chunk não está realmente definido. Se for uma tarefa pequena, talvez não faça o check-in até terminar. Se for maior, posso fazer check-in após a conclusão de cada parte lógica.

Mas nunca faça check-in se não compilar. Eu sei que parece uma coisa estúpida dizer em voz alta, mas eu já tive que explicar isso para as pessoas antes.

Faça uma confirmação quando o código estiver pronto para ser compartilhado com outros usuários do código - quando estiver relativamente estável, seguro e testado corretamente.

E não, eu não acho que as confirmações são uma ótima métrica para o desenvolvimento de um projeto, porque conheço alguns desenvolvedores que confirmarão todas as alterações pequenas e pequenas e outros que confirmarão apenas grandes alterações na funcionalidade. Como você mede quantitativamente o valor de um commit em detrimento de outro?

Assim que a tarefa correspondente for concluída . Uma tarefa faz parte de uma história de usuário .

Uma tarefa é concluída quando:

• os testes unitários correspondentes passam,
• código está devidamente documentado e
• código é confirmado.

Você pode ter uma definição diferente de concluído .

Não vejo o valor em medir o número de confirmações. No entanto, se você vir alguém trabalhando por um longo período na mesma história de usuário (ou pior, histórias), isso é um cheiro.

Confirme todas as mudanças significativas que você acha que quebram alguma coisa. A única coisa que você não deve confirmar são as mudanças de estilo, porque elas não incorporam alterações na lógica. Mas, caso contrário, quanto menores as alterações que você confirmar, melhor.

Quanto menor a consolidação, mais detalhado você pode documentar o processo de reflexão, que é um aspecto de um bom registro de consolidação. Uma boa revisão de código não deve ser apenas sobre o resultado do código, mas também o processo de reflexão.

Além disso, ter muitos commits pequenos facilita a divisão, um recurso muito pouco usado do controle de versão, que me salvou muitas horas procurando bugs de agulhas nas bases de código do palheiro.

Dividindo em resumo; Descubra um problema na base de código atual. Em seguida, escolha uma confirmação no changelog em que você tem certeza de que o problema específico não existia. Comece verificando o commit no meio, entre a versão "boa" e a "ruim". Teste para verificar se o problema ainda está presente. Se for, você precisa olhar mais para trás, no meio do "bom" e do commit testado anteriormente. Se o problema desaparecer, ele foi introduzido após essa alteração específica; portanto, é necessário verificar o meio entre o commit "ruim" e o commit testado anteriormente. Repetir. Eventualmente, você terminará com o commit que introduziu o problema. Mas somente se você tiver pequenas confirmações, caso contrário, você saberá em que grande pilha de mudanças o problema ocorreu.

Aqui está como ele funciona com o Git, mas o principal se aplica a qualquer controle de versão.

Quando:

• constrói (SEMPRE)
• testes de unidade passam
• funciona (a menos que esteja claramente marcado como "trabalho em andamento")
• os benefícios de salvar o estado do código superam os problemas de executar os testes, pensar em uma boa mensagem de confirmação e resolver qualquer conflito de mesclagem durante o processo de confirmação