Quelqu'un at-il une alternative valable pour utiliser le code commenté archivé dans le référentiel pour des raisons de trouvabilité?
La raison pour laquelle je demande est parce que j'ai eu une discussion avec un collègue développeur récemment sur la vérification dans le code qui est commenté. Ma position est que commenté le code ne doit jamais être vérifié dans notre VCS, car il est pas techniquement partie de la base de code, et donc ennuyeux cochonneries qui ne mérite pas les octets qu'il prend, pour ainsi dire.
Son contrepoint était que certains des commentaires sur le code qu'il vérifiait dans encore illustré un travail qu'il aimerait fixer à l'avenir (à ce point la en commentaire il y a 2 ans a eu lieu, mais qui est d'ailleurs le point). Il voulait garder dans la base de code afin qu'il puisse facilement trouver, et même si elle ne compilerait pas actuellement, il a montré encore en lignes globales de la bonne façon de le résoudre.
En fin de compte, il a accepté, en quelque sorte, qui commenté le code ne appartiennent. Mais quand nous avons pensé à des alternatives possibles à son nous sommes arrivés assez court.
Les options que je pouvais penser était:
Quelqu'un sait-il de / utiliser des solutions de rechange? Mes deux options de son comme plus de travail qu'il est en fait une valeur, mais qui peuvent être faussées par mon raisonnement que le code commenté est sans valeur de toute façon. Je déteste devoir aller le « Hé, si vous n'avez pas le temps de le corriger maintenant il est pas assez important pour rester dans le code de base de toute façon » la route (mais je le ferai s'il n'y a pas d'alternatives viables).
Désolé pour le titre horrible, je ne pouvais pas trouver un meilleur
7 Réponses :
On dirait que votre ami devrait créer une succursale et essayer ses "améliorations" là-bas. Vous seriez facilement en mesure de différer entre cette branche d'amélioration et la source de courant pour obtenir une représentation claire des changements à l'intention.
Je comprends que le code n'est plus utilisé mais il contient des idées qui pourraient être intéressantes pour l'avenir.
Je stockerais dans le système de version de contrôle, mais je le garderais dans un dossier séparé, quelque chose comme supprimé-code-compriper-la plus tard . Ensuite, je l'enlèverais comme je l'examine.
La ramification peut être utile ici. Un modèle d'utilisation de SCM consiste à créer une branche pour chaque fonctionnalité. Ceci est populaire lorsque la fustigation de la branche est indolore - une facilité non offerte par tous les SCMS ...: -)
L'idée est que chaque fonctionnalité que vous travaillez a une succursale dédiée et travaille entièrement dans cette branche. Lorsque la fonctionnalité est terminée, fonctionnant, testée, documentée et gagné deux or olympiques, etc. La succursale est ensuite fusionnée dans le coffre. Alternativement, la branche reste ouverte indéfiniment si la fonctionnalité n'est jamais terminée ou abandonnée, etc. Mais le code reste visible, prêt à être ramassé par une personne, un jour.
C'est un bon moyen de stocker "travail en cours" - car le code est ramifié, vous pouvez vérifier librement le code provisoire. Il n'a pas besoin d'être commenté car les travaux en cours changements ne sont que dans cette branche isolée, et il n'a même pas besoin de compiler, car ces branches ne sont généralement pas migrées en intégration continue tant qu'elles ont atteint un niveau de maturité.
Contrairement au code commenté, ces modifications de code provisoires sont visibles et consultables, aménagées pour coder les outils d'analyse, refactoring, etc.
Dans certains environnements, la fonctionnalité et la succursale peuvent également avoir un ticket de changement associé ou un identifiant de suivi. Cela garantit que des changements importants ne se perdent pas et fournissent des moyens de hiérarchiser et d'organiser les différentes caractéristiques, des correctifs pour desoppers de ShowStoppers aux expériences de la mise en œuvre d'une manière différente de quelque chose qui ne verra probablement jamais la lumière du jour.
En ce qui concerne la recherche, certains SCM ont une recherche frontale. Par exemple, svn a svnsearch - http://sourceforge.net/projects/svn-search/ . Il y a aussi SVNQUERY , qui peut rechercher l'historique ainsi que la tête.
Dans mon expérience, la principale raison de l'enregistrement du code commenté est que les développeurs détestent de taper tellement qu'ils préfèrent garder le code inutilisé à portée de main au cas où ils devaient jamais saisir un fragment similaire de code à l'avenir. < / p>
Votre cas est un peu différent, mais je dis toujours "l'utiliser ou le perdre". Si la solution commentée fixe quelque chose d'important, ce serait une bonne motivation pour la finition. Il est facile de passer plus de temps à expliquer pourquoi quelque chose n'est pas tout à fait juste et "comment nous n'avons jamais reçu le temps de le réparer" que ce qu'il ne faudrait pour le faire.
Ce dernier point est basé sur l'affirmation selon laquelle le temps de développement est non linéaire et que la mise en route sur quelque chose que vous êtes motivé à effectuer beaucoup plus de valeur que "x heures réservée au projet y" chaque fois.
Il existe des systèmes de contrôle de la version qui sont très bons pour créer et fusionner des branches. Mercurial, Git, etc. serait tout capable de le faire. Même si vous n'utilisez pas l'un d'entre eux comme votre principale VCS, il n'y a rien pour empêcher votre collègue de créer un référentiel local pour conserver ses expériences.
Dans certains scénarios, il est judicieux de documenter des solutions à des problèmes complexes / uniques, à des fins de référence. Je ne pense pas que cela appartienne cependant au code. IMHO, je pense qu'un wiki de quelque sorte est la meilleure option.
Si vous n'avez pas utilisé le code au cours des 2 dernières années, vous l'utiliserez jamais et si vous le faites si vous devriez toujours utiliser le code de 2 ans? Si vous avez besoin d'ajouter cette logique à nouveau au code, il peut être préférable de l'écrire à partir de zéro au fil de cette période aurait changé, vous auriez beaucoup appris que des ressources supplémentaires seraient mises à votre disposition, etc.
Certains du code commenté qu'il a vérifié dans l'ensemble illustré de certains travaux qu'il souhaite réparer dans le futur
Puis il devrait ouvrir un ticket à faible priorité dans votre bugtracker, décrivant que ce qu'il souhaite corriger, et ajouter le code de commenté actuellement comme un commentaire à ce billet. Maintenant, il peut affecter ce billet à lui-même et personne d'autre ne sera jamais dérangé par celui-ci.
Le code commenté est comme n'importe quel autre commentaire: s'il n'est pas correctement maintenu, il a tendance à perdre sa consistance avec le code et donc son utilité.
Votre déclaration "Même s'il ne compilerait pas actuellement, il a toujours montré dans des lignes mondiales la bonne façon de le résoudre."
<>
Votre déclaration "Mon raisonnement qui a commenté le code est sans valeur de toute façon."
Je ne vois pas le préjudice dans la sortie des commentaires, car ils fourniront souvent un aperçu des développeurs futurs sur ce que l'intention des développeurs originales était et toutes les limitations actuelles du code existant. Le stockage dans un système différent augmente les chances de se perdre pour les futurs développeurs. Les octets sont bon marché, le temps nécessaire pour recréer une autre intention des développeurs est $$$.