Conservation de l'historique des validations du contrôle de version vs Refactoring et documentation

Il ne coûte presque rien d'utiliser l'historique de validation maintenu par le système de contrôle de version. Cependant, lors d'un effort de refactorisation (ou de réorganisation / nettoyage) d'un projet majeur, les fonctions et les classes et même les espaces de noms seront déplacés; parfois, plusieurs fichiers seront fusionnés et d'autres fichiers seront divisés. Ces modifications entraînent souvent la perte de l'historique de validation d'origine de quelques fichiers.

À mon avis, la mise à jour de l'organisation du projet est plus importante que la conservation de l'historique du code source. Une bonne organisation du projet permet d'ajouter de nouvelles fonctionnalités en continu avec un effort raisonnable, tandis que la valeur de l'historique du code source semble douteuse.

De plus, avec l'utilisation des tests unitaires, les problèmes de régression sont rapidement identifiés. Tant que la dernière version continue de satisfaire à toutes les exigences logicielles, devons-nous réellement conserver l'historique du code source?

Je comprends que tout code source expédié doit être conservé en raison de la nécessité de fournir une assistance aux clients sans les obliger à effectuer une mise à niveau de version majeure. Mais à part cela, est-il utile de conserver l'historique des validations de code source?

L'historique de validation du code source joue-t-il un rôle dans les communications entre les membres de l'équipe? Que se passe-t-il si nous supprimons l'historique des validations, mais que nous nous appuyons plutôt sur le "code source" + "le code de test unitaire" pour la communication?

L'existence de l'historique des validations rend-elle complaisante la documentation à long terme d'informations importantes sur le projet, telles que les principaux changements de conception / exigences et les courants de pensée qui ont conduit à ces changements?

Pour utiliser l'historique des validations pour plus de commentaires de type "modifications apportées" ou "bogue corrigé", il doit être lié à votre système de suivi des problèmes. Chaque changement, chaque commit, devrait avoir un problème qui lui est associé afin que vous sachiez ce qui a changé, par qui et pourquoi.

Tant que la dernière version continue de satisfaire à toutes les exigences logicielles, devons-nous réellement conserver l'historique du code source?

Un logiciel suffisamment complexe a rarement toutes les exigences implémentées et tous les bugs corrigés pour une multitude de raisons, donc je pense que votre affirmation ici est, disons, optimiste.

Supposons que vous soyez sur la version 7.8 de votre programme. Mais vous soutenez, sur le terrain, 12 versions actives différentes, comme 1.6, 2.2, 2.8, etc. Chacun de ceux-ci ne sera pas mis à niveau vers la dernière version pour diverses raisons, vous les supportez donc tous avec des corrections de bugs. Un client trouve un bogue dans votre dernière version 7.8. Vous le corrigez dans 7.8. Comment savez-vous combien d'autres versions doivent être corrigées? Sans l'historique des sources et le suivi des problèmes, vous ne le faites pas.

la valeur de l'historique du code source semble douteuse.

J'ai eu des ingénieurs qui remontent plusieurs années dans le code source à la recherche de réponses pour expliquer pourquoi quelque chose est comme ça. Parfois, la façon dont les choses ont évolué au fil du temps est importante pour comprendre un bogue, mais ce n'est généralement pas quelque chose auquel on pense lors de la documentation des choses (ni même nécessairement documentable).

En outre, il peut y avoir de très bonnes raisons juridiques de conserver l'historique du code source. La plupart des plongées dans les bennes à ordures que j'ai eu à faire (en tant qu'ingénieur build / SCM) l'ont été à la demande du service juridique de mon entreprise.

Tant que la dernière version continue de satisfaire à toutes les exigences logicielles, devons-nous réellement conserver l'historique du code source?

Mais à part cela, est-il utile de conserver l'historique des validations de code source?

Oui aux deux. Il peut être utile de savoir quand quelque chose a été changé, par qui et pourquoi. Si vous perdez votre historique, votre capacité à le faire est affectée.

L'historique de validation du code source joue-t-il un rôle dans les communications entre les membres de l'équipe? Que se passe-t-il si nous supprimons l'historique des validations, mais que nous nous appuyons plutôt sur le "code source" + "le code de test unitaire" pour la communication?

Oui. L'approche "code source" + "code de test unitaire" ne vous dit pas qui / quand / pourquoi.

L'existence de l'historique des validations rend-elle complaisante la documentation à long terme d'informations importantes sur le projet, telles que les principaux changements de conception / exigences et les courants de pensée qui ont conduit à ces changements?

Je suppose que vous pourriez dire que oui. Mais peu de développeurs documentent à fond les changements dans les exigences / conception. Et certainement, presque personne n'enregistre le courant de pensée qui a conduit au développement initial ou aux modifications ultérieures. Avoir l'historique de validation (et en particulier les messages du journal de validation) et les liens croisés avec le système de suivi des problèmes / bogues vous fournissent au moins quelque chose à partir duquel vous pouvez partir. Et c'est mieux que rien, ou un ensemble d'instantanés de versions.