Est-ce une mauvaise pratique de ne pas supprimer les fichiers redondants immédiatement de VCS, mais plutôt de les marquer comme «À supprimer» avec des commentaires en premier?

Je voulais savoir si ma façon de traiter les fichiers source à supprimer du contrôle de version pouvait être considérée comme une mauvaise pratique.

Je veux vous expliquer en vous basant sur cet exemple:

Je me suis récemment mis très en colère parce que je devais trier minutieusement les classes Java dans un programme qui était essentiellement du code mort, mais il n'était nulle part documenté et non commenté dans ces classes Java. Bien sûr, ils devaient être supprimés, mais avant que je supprime ce genre de choses redondantes, j'ai une habitude - certains diront peut-être étrange -:

Je ne supprime pas immédiatement ces fichiers redondants via SVN-> Supprimer (commande de choix du système de contrôle de version de votre système de contrôle de version), mais placez plutôt des commentaires dans ces fichiers (je renvoie à la fois au début et à la fin) auxquels ils vont accéder. être supprimé + mon nom + la date et aussi - plus important encore - pourquoi ils sont supprimés (dans mon cas, car ils étaient morts, code source de confusion). Ensuite, je les enregistre et les engage dans le contrôle de version. La prochaine fois que je devrai valider / archiver quelque chose dans le projet pour le contrôle de version, j'appuierai sur SVN-> Supprimer, puis ils seront finalement supprimés dans Version Control - toujours bien sûr restaurable grâce à des révisions et c'est pourquoi j'ai adopté cette habitude.

Pourquoi faire cela au lieu de les supprimer tout de suite?

Ma raison est, je veux avoir des marqueurs explicites au moins dans la dernière révision dans laquelle ces fichiers redondants existaient, pourquoi ils méritaient d'être supprimés. Si je les supprime tout de suite, ils sont supprimés, mais rien n’indique pourquoi ils ont été supprimés. Je veux éviter un scénario typique comme celui-ci:

"Hmm ... pourquoi ces fichiers ont-ils été supprimés? Je fonctionnais bien avant." (Presses 'revert' -> Le type qui a annulé sa visite est parti pour toujours ou n'est plus disponible dans les prochaines semaines et le prochain cessionnaire doit découvrir fastidieusement ce que sont ces fichiers.)

Mais ne notez-vous pas pourquoi ces fichiers ont été supprimés dans les messages de validation?

Bien sûr, mais un message de validation n’est parfois pas lu par des collègues. Lorsque vous essayez de comprendre le code (dans mon cas, mort), vous ne vérifiez pas d'abord le journal de contrôle de version avec tous les messages de validation associés. Au lieu de parcourir le journal, un collègue peut voir tout de suite que ce fichier est inutile. Cela lui fait gagner du temps et il / elle sait que ce fichier a probablement été restauré pour de mauvais (ou au moins cela soulève une question.

Le problème lié à l'ajout d'un commentaire à un fichier à supprimer, au lieu de le supprimer dans le contrôle de code source et d'y ajouter l'explication, est que si les développeurs ne lisent pas les messages de validation, ils liront sûrement les commentaires dans le code source.

D'un point de vue externe, cette méthodologie semble s'enraciner dans une vision très conservatrice du contrôle à la source.

"Et si je supprime ce fichier inutilisé alors que quelqu'un en a besoin?" quelqu'un pourrait demander.

Vous utilisez le contrôle de source. Annulez la modification ou, encore mieux, parlez à la personne qui a supprimé le fichier (communiquez).

"Et si je supprime le fichier mort, alors quelqu'un recommence à l'utiliser et apporte des modifications?" quelqu'un d'autre pourrait demander.

Encore une fois, vous utilisez le contrôle de source. Vous obtiendrez un conflit de fusion qu'une personne doit résoudre. La réponse ici, comme pour la dernière question, est de communiquer avec vos coéquipiers.

Si vous pensez vraiment qu'un fichier doit être supprimé, communiquez avant de le supprimer du contrôle de source. Peut-être que cela a récemment cessé d'être utilisé, mais une fonctionnalité à venir pourrait en avoir besoin. Vous ne le savez pas, mais l'un des autres développeurs pourrait le faire.

S'il doit être supprimé, supprimez-le. Coupez le gras de la base de code.

Si vous avez créé un "oopsie" et que vous avez réellement besoin du fichier, souvenez-vous que vous utilisez le contrôle de source pour pouvoir le récupérer.

Vincent Savard, dans un commentaire sur la question, a déclaré:

... Si vos collègues ne lisent pas les messages de validation et ressuscitent un fichier qui a été supprimé à juste titre et passe le code en revue, il y a définitivement quelque chose qui ne va pas dans votre équipe et c'est une excellente occasion de mieux leur apprendre.

C'est un conseil judicieux. Les revues de code devraient attraper ce genre de chose. Les développeurs doivent consulter les messages de validation lorsqu'une modification inattendue est apportée à un fichier, ou qu'un fichier est supprimé ou renommé.

Si les messages de validation ne racontent pas l'histoire, les développeurs doivent également rédiger de meilleurs messages de validation.

Avoir peur de supprimer du code ou des fichiers indique un problème systémique plus profond lié au processus:

• Manque de critiques de code précises
• Manque de compréhension sur le fonctionnement du contrôle de source
• Manque de communication d'équipe
• Messages de validation médiocres de la part des développeurs

Ce sont les problèmes à résoudre, vous éviterez ainsi de jeter des pierres dans une maison de verre lorsque vous supprimez du code ou des fichiers.

Oui c'est une mauvaise pratique.

Vous devriez mettre l'explication de la suppression dans le message de validation lorsque vous validez la suppression des fichiers.

Les commentaires dans les fichiers source doivent expliquer le code tel qu'il se présente actuellement . Les messages de validation doivent expliquer pourquoi les modifications ont été apportées à la validation. L'historique des validations du fichier explique donc son historique.

Ecrire des commentaires expliquant les changements directement dans la source elle-même rendra le code beaucoup plus difficile à suivre. Pensez-y: si vous commentez dans le fichier chaque fois que vous modifiez ou supprimez du code, les fichiers seront bientôt submergés de commentaires sur l'historique des modifications.

À mon avis les deux de vos options sont pas les meilleures pratiques , par opposition à une mauvaise pratique:

1. L'ajout de commentaires n'ajoute une valeur que s'il est lu par ceux-ci.
2. La suppression du VCS (avec une raison dans la description du changement) peut avoir un impact sur un produit livrable essentiel et de nombreuses personnes ne lisent pas la description du changement, en particulier sous pression.

Ma pratique préférée - principalement en raison d'avoir été mordu plusieurs fois au fil des ans, en gardant à l'esprit que vous ne savez pas toujours où et par qui votre code est utilisé - consiste à:

1. Ajoutez un commentaire indiquant qu’il s’agit d’un candidat à la suppression et à une dépréciation #warning ou similaire (la plupart des langues ont une sorte de mécanisme, par exemple en Java , dans le pire des cas, une printdéclaration ou similaire suffira), idéalement avec une sorte de délai et avec les coordonnées. Cela alertera tous ceux qui utilisent encore le code. Ces avertissements sont normalement présents dans chaque fonction ou classe si de telles choses existent .
2. Après un certain temps, mettez l'avertissement à niveau avec une étendue de fichier standard #warning(certaines personnes ignorent les avertissements de dépréciation et certaines chaînes d'outils ne les affichent pas par défaut).
3. Remplacez ultérieurement l'étendue du fichier #warningpar un #erroréquivalent ou un équivalent. Le code sera cassé au moment de la construction, mais peut être supprimé si cela est absolument nécessaire, mais la personne qui l'a supprimé ne peut pas l'ignorer. (Certains développeurs ne lisent ni ne traitent les avertissements ou en ont tellement qu'ils ne peuvent pas séparer les plus importants).
4. Enfin, marquez le (s) fichier (s) (après ou à la date d'échéance) comme supprimé dans le VCS.
5. Si la suppression d' un paquet entier / bibliothèque / etc au stade de la mise en garde que je voudrais ajouter un README.txt ou README.html ou similaire avec les informations quand et pourquoi il est prévu de se débarrasser du paquet et il suffit de laisser ce fichier, avec changer pour dire quand il a été supprimé, en tant que seul contenu du package pendant un certain temps après avoir supprimé le reste du contenu.

L'un des avantages de cette approche est que certains systèmes de gestion de versions (CVS, PVCS, etc.) ne suppriment pas un fichier existant à la caisse s'il a été supprimé dans le VCS. Il donne également aux développeurs consciencieux, ceux qui règlent tous leurs avertissements, beaucoup de temps pour résoudre le problème ou faire appel de la suppression. Cela oblige également les développeurs restants à au moins regarder l'avis de suppression et à se plaindre .

Notez que #warning/ #errorest un mécanisme C / C ++ qui provoque un avertissement / une erreur suivi du texte fourni lorsque le compilateur rencontre ce code, java / java-doc possède une @Deprecatedannotation pour émettre un avertissement sur l'utilisation et @deprecatedfournir certaines informations, etc. Recettes à faire de même en python et j'ai vu l' asserthabitude de fournir des informations similaires à #errordans le monde réel.

Oui, je dirais que c'est une mauvaise pratique, mais pas parce que cela se trouve dans les fichiers plutôt que dans le message de validation. Le problème est que vous essayez de faire un changement sans communiquer avec votre équipe.

Chaque fois que vous apportez des modifications au tronc (ajout, suppression ou modification de fichiers, de quelque manière que ce soit), vous devez, avant de vous réengager sur le tronc, en parler directement à un membre (ou aux membres) de l'équipe qui serait directement bien informés à leur sujet (essentiellement, discutez de ce que vous mettriez dans ces en-têtes directement avec vos coéquipiers). Cela garantira que (1) le code que vous supprimez doit vraiment être supprimé et que (2) votre équipe sera beaucoup plus susceptible de savoir que le code est supprimé et ne tentera donc pas de revenir sur vos suppressions. Sans parler du fait que vous obtiendrez également une détection de bogues et autres pour le code que vous ajoutez.

Bien sûr, lorsque vous modifiez des éléments importants, vous devez également les inclure dans le message de validation, mais comme vous en avez déjà parlé, il n'est pas nécessaire que ce soit la source des annonces importantes. La réponse de Steve Barnes aborde également de bonnes stratégies à utiliser si le groupe d'utilisateurs potentiels pour votre code est trop important (par exemple, en utilisant les marqueurs obsolètes de votre langue au lieu de supprimer les fichiers au préalable).

Si vous ne voulez pas rester aussi longtemps sans vous engager (c’est-à-dire que votre modification a plus de sens comme plusieurs révisions), il est judicieux de créer une branche à partir d’une ligne de commande et de la valider dans la branche, puis de fusionner la branche avec celle-ci lorsque la le changement est prêt. De cette façon, le VCS continue de sauvegarder le fichier pour vous, mais vos modifications n’affectent en aucune façon la jonction.

Un problème connexe lié à des projets reposant sur plusieurs plates-formes et configurations. Ce n’est pas parce que j’ai déterminé qu’il est mort que c’est une détermination correcte. Notez que l'utilisation en cours peut toujours signifier une dépendance résiduelle qui doit encore être éliminée, et certaines peuvent avoir été manquées.

Donc (dans un projet C ++) j'ai ajouté

#error this is not as dead as I thought it was

Et vérifié cela. Attendez que la reconstruction de toutes les plates-formes normales soit terminée et que personne ne s'en plaint. Si quelqu'un le trouvait, il serait facile de supprimer une ligne plutôt que d'être dérouté par un fichier manquant.

Je conviens en principe que les commentaires que vous avez mentionnés font double emploi avec la fonctionnalité qui devrait être intégrée au système de gestion des versions . Mais, vous pouvez avoir des raisons spécifiques pour le supplimenter. Ne pas connaître l'outil VCS n'en fait pas partie.

Sur le continuum des mauvaises pratiques, c'est assez mineur. Je le ferai de temps en temps, quand je veux vérifier une branche et pouvoir voir l'ancien code. Cela peut faciliter la comparaison avec le code de remplacement. Je reçois habituellement un commentaire de révision de code "cruft". Avec un peu d'explication, je passe l'examen du code.

Mais ce code ne devrait pas durer longtemps. Je supprime généralement au début du prochain sprint.

Si certains de vos collègues ne lisent pas les messages de validation ou ne vous demandent pas pourquoi vous avez laissé le code dans le projet, le problème ne réside pas dans un mauvais style de codage. Vous avez un problème différent.

vous pouvez également refactoriser la classe et la renommer avec un préfixe UNUSED_Classname avant de tirer votre cascade. Ensuite, vous devez aussi commettre directement l'opération de suppression

• Étape 1: renommez la classe, ajoutez votre commentaire, validez
• Étape 2: supprimer le fichier et commettre

Si c'est du code mort, supprimez-le. N'importe qui en a besoin, il peut revenir en arrière, mais l'étape de changement de nom l'empêchera de l'utiliser directement sans y penser.

Apprenez également aux utilisateurs comment consulter tous les messages de validation d'un fichier. Certaines personnes ne savent même pas que c'est possible.