Preservando o histórico de confirmação do controle de versão x Refatoração e documentação

Não custa quase nada usar o histórico de consolidação mantido pelo sistema de controle de versão. No entanto, durante um grande projeto de refatoração (ou reorganização / limpeza), funções, classes e até espaços para nome serão movidos; às vezes, vários arquivos serão mesclados e outros serão divididos. Essas alterações geralmente levam à perda do histórico de consolidação original de alguns arquivos.

Na minha opinião pessoal, a manutenção da organização do projeto é mais importante do que manter o histórico do código fonte. Uma boa organização do projeto permite que novos recursos sejam adicionados continuamente com um esforço razoável, enquanto o valor do histórico do código fonte parece duvidoso.

Além disso, com o uso de testes de unidade, os problemas de regressão são rapidamente identificados. Enquanto a versão mais recente continuar atendendo a todos os requisitos de software, precisamos preservar o histórico do código-fonte?

Entendo que qualquer código fonte enviado deve ser preservado devido à necessidade de fornecer suporte aos clientes sem exigir que eles executem uma atualização de versão principal. Mas, além disso, há algum valor em manter o histórico do código-fonte confirmado?

O histórico de confirmação do código-fonte desempenha algum papel na comunicação entre os membros da equipe? E se abolirmos o histórico de consolidação, mas confiarmos no "código fonte" + "código de teste de unidade" para comunicação?

A existência do histórico de confirmação torna complacente a documentação de longo prazo de informações importantes sobre o projeto, como as principais mudanças de design / requisito e as correntes de pensamento que conduziram essas mudanças?

Para usar o histórico de confirmação para mais do que comentários do tipo "alterações feitas" ou "bug corrigido", ele deve estar vinculado ao seu sistema de rastreamento de problemas. Toda mudança, toda confirmação deve ter algum problema associado a ela, para que você saiba o que mudou, por quem e por quê.

Enquanto a versão mais recente continuar atendendo a todos os requisitos de software, precisamos preservar o histórico do código-fonte?

Softwares suficientemente complexos raramente têm todos os requisitos implementados e todos os bugs corrigidos por várias razões, então acho que sua afirmação aqui é, digamos, otimista.

Suponha que você esteja na versão 7.8 do seu programa. Mas você está apoiando, em campo, 12 versões ativas diferentes, como 1.6, 2.2, 2.8 e assim por diante. Cada um desses itens não será atualizado para a versão mais recente por vários motivos; portanto, você oferece suporte a todas as correções de bugs. Um cliente encontra um erro na versão 7.8 mais recente. Você o corrige em 7.8. Como você sabe quantas outras liberações precisam ser corrigidas? Sem histórico de origem e rastreamento de problemas, você não.

o valor do histórico do código fonte parece duvidoso.

Eu tive engenheiros voltando vários anos para o código fonte procurando respostas para o porquê de algo ser do jeito que é. Às vezes, a maneira como as coisas evoluíram ao longo do tempo é importante para entender um bug, mas não é algo que normalmente é pensado ao documentar as coisas (nem mesmo necessariamente documentáveis).

Além disso, pode haver boas razões legais para manter o histórico do código-fonte. A maior parte do mergulho em lixeira de código fonte que eu tive que fazer (como engenheiro de build / SCM) foi a pedido do departamento jurídico da minha empresa.

Enquanto a versão mais recente continuar atendendo a todos os requisitos de software, precisamos preservar o histórico do código-fonte?

Mas, além disso, há algum valor em manter o histórico do código-fonte confirmado?

Sim para ambos. Pode ser útil saber quando algo foi alterado, por quem e por quê. Se você perder seu histórico, sua capacidade de fazer isso será afetada.

O histórico de confirmação do código-fonte desempenha algum papel na comunicação entre os membros da equipe? E se abolirmos o histórico de consolidação, mas confiarmos no "código fonte" + "código de teste de unidade" para comunicação?

Sim. A abordagem "código fonte" + "código de teste de unidade" não informa quem / quando / por quê.

A existência do histórico de confirmação torna complacente a documentação de longo prazo de informações importantes sobre o projeto, como as principais mudanças de design / requisito e as correntes de pensamento que conduziram essas mudanças?

Suponho que você poderia dizer que sim. Mas poucos desenvolvedores documentam minuciosamente as alterações nos requisitos / design. E certamente quase ninguém registra o fluxo de pensamento que impulsionou o desenvolvimento inicial ou as modificações subseqüentes. Ter o histórico de confirmação (e especialmente as mensagens de log de confirmação) e as ligações cruzadas com o sistema de rastreamento de problemas / bugs pelo menos fornece algo para você. E isso é melhor que nada, ou um conjunto de instantâneos de lançamento.