Enregistrement du code "commenté"
Ok, voici quelque chose qui a causé des frictions à mon emploi actuel et je ne m'y attendais pas vraiment à. Organisé dans le développement de logiciels maison est un nouveau concept ici et j'ai élaboré un premier projet de quelques directives de codage.
J'ai proposé que " commenté " le code ne doit jamais être vérifié dans le référentiel. La raison pour laquelle je l'ai dit est que le dépositaire conserve un historique complet des fichiers. Si vous supprimez le code fonctionnel puis le supprimer complètement. Le référentiel conserve vos modifications il est donc facile de voir ce qui a changé.
Cela a provoqué des frictions dans un autre développeur estime que la prise de cette voie est trop restrictive. Ce développeur aimerait être en mesure de commenter un code qu'il travaille sur mais est incomplète. Ce code serait alors jamais été vérifié avant et sauvegardée nulle part. Nous allons utiliser TFS donc je suggère que les étagères changements serait la solution la plus correcte. Il n'a cependant pas été acceptée parce qu'il aimerait être en mesure de checkin changements partiels qui peuvent ou peuvent ne pas être déployées.
Nous voulons finalement arriver à un point où nous tirons pleinement parti de l'intégration continue et de déployer automatiquement sur un serveur Web de développement. À l'heure actuelle il n'y a pas la version de développement de serveurs Web ou des serveurs de base de données, mais qui seront tous bientôt changé.
Quoi qu'il en soit, quelles sont vos pensées? Croyez-vous que le code " commenté " est utile d'avoir dans le dépôt?
Je suis très intéressé d'entendre des autres sur ce sujet.
Edit: Par souci de clarté, nous n'utilisons des branches privées. Si nous avons fait alors je dirais que faire ce que vous voulez avec votre branche privée, mais ne se confondent jamais en commentaire du code avec le tronc ou les branches partagées.
Edit: Il n'y a aucune raison valable, nous n'utiliser des branches privées ou par utilisateur. Ce n'est pas un concept que je suis en désaccord avec. Nous avons tout simplement pas le mettre de cette façon encore. Peut-être est le terrain d'entente éventuelle. Pour l'instant nous utilisons étagères TFS.
Il peut y avoir d'autres expériences différentes, mais dans la vérification de la mine en code à moitié fini est une idée horrible, période.
Voici les principes que j'ai appris et essaie de suivre:
- Vérifiez souvent - au moins une fois, mais de préférence plusieurs fois par jour
- Seulement vérifier la fonctionnalité complète
- Si le premier et le deuxième conflit (par exemple, il faut plus d'une journée pour faire fonctionner les fonctionnalités), la tâche est trop grande - rompez-la dans des tâches plus petites.
Ça signifie:
- Le code commenté ne doit jamais être vérifié car il n'est pas fonctionnel
- Les commentaires ne constituent pas une stratégie d'archivage valide, de sorte que ce soit au code et que le code soit à la retraite, qui soit à la retraite, commentaire et vérification n'a aucun sens.
Donc, en résumé, non! Si le code n'est pas prêt à passer à la prochaine étape (selon ce qui vous convient: IntTest/QA/UAT/PREPROD/PROD), il ne faut pas s'engager dans une branche de tronc ou multi-développeur. Période.
Edit: Après avoir lu les autres réponses et commentaires, je vais ajouter que je ne pense pas que ce soit nécessairement une bonne idée Ban Code commenté (pas sûr Comment vous exécutez-vous de toute façon). Ce que je vais dire, c'est que vous devriez obtenir tout le monde sur votre équipe à acheter dans la philosophie que j'ai décrite ci-dessus. L'équipe que je travaille en l'embrasse de tout coeur. En conséquence, le contrôle de la source est un membre de l'équipe sans fricton, dont une qui nous aide à faire notre travail.
Les personnes qui n'embrassent pas cette philosophie provoquent généralement Windows cassées et sont souvent frustrés par le contrôle de la source. Ils le voient comme un mal nécessaire au mieux et quelque chose à éviter au pire; Ce qui conduit à des checkins peu fréquents, ce qui signifie que les changements sont énormes et difficiles à fusionner, ce qui suscite la frustration, rend les Checkins quelque chose à éviter encore plus, etc. C'est finalement une chose d'attitude, pas vraiment une chose de processus. Il est facile de mettre en place des barrières mentales contre elle; Il est facile de trouver des raisons pour lesquelles cela ne fonctionnera pas, tout comme il est facile de trouver des raisons de ne pas régler si vous ne le souhaitez pas vraiment. Mais quand les gens font veulent le faire et se sont engagés à changer leurs habitudes, les résultats sont dramatiques. Le fardeau est sur vous pour la vendre efficacement.
"Jamais" est rarement un bon mot à utiliser dans les directives.
Votre collègue a un excellent exemple de quand il pourrait être approprié de vérifier le code qui est commenté: lorsqu'il est incomplet et peut casser l'application si elle est enregistrée pendant une activité active.
Pour la plupart, commentant le code morts est inutile dans un système bien géré contrôlé par le changement. Mais tous, tous les indicateurs n'ont pas été "mort".
Le code a commenté devrait jamais être vérifié dans le but de maintenir l'historique. C'est le point de contrôle de la source.
Les gens parlent beaucoup d'idéaux ici. Peut-être que contrairement à tous les autres, je dois travailler sur plusieurs projets avec de multiples interruptions avec le "monde réel" interrompu mon jour de travail.
Parfois, la réalité est que je dois enregistrer du code partiellement complet. C'est soit un risque de perte du code incomplet du code ou de l'enregistrement. Je ne peux pas toujours me permettre de "finir" une tâche, peu importe la petite. Mais je vais non Déconnectez mon ordinateur portable du réseau sans enregistrer tout code.
Si nécessaire, je vais créer ma propre branche de travail pour commettre des changements partiels.
Je pense jamais est une condition trop forte.
J'ai tendance à commenter, à la vérification, à exécuter les tests, à penser, puis à supprimer des commentaires après la prochaine version.
En général, une vérification du code commenté est fausse car elle crée une confusion parmi ceux qui ne sont pas l'auteur d'origine et qui ont besoin de lire ou de modifier le code. En tout état de cause, l'auteur original finit souvent par confus sur le code après 3 mois se sont écoulés.
J'épouse la conviction que le code appartient à la société ou à l'équipe et qu'il est de votre responsabilité de rendre les choses faciles à faciliter vos pairs. Enregistrement dans le code commenté sans aussi ajouter un commentaire sur la raison pour laquelle il est conservé équivaut à dire:
Cela ne vous dérange pas si vous finissez par tout confondre sur la raison pour laquelle ce truc est ici. Mes besoins sont plus importants que ce soit pourquoi j'ai fait cela. Je ne ressens aucun besoin de vous justifier, sinon quelqu'un d'autre, pourquoi j'ai fait cela.
Pour moi, le code commenté est Normalement vu comme un signe de manque de respect Du moins ce collègue de collègue réfléchi.
Je suis d'abord d'accord avec le principe qui a commenté que le code ne devrait pas être vérifié. Le système de contrôle source est une ressource partagée et votre collègue est, dans une certaine mesure, en l'utilisant comme un tampon à gratter personnel. Ce n'est pas très attentionné pour les autres utilisateurs, surtout si vous vous abonnez à l'idée de propriété partagée du codeBase.
Le prochain développeur pour voir que le code commenté n'aurait aucune idée de ce que c'est un travail en cours. Est-il libre de le changer? Est-ce le code mort? Il ne sait pas.
Si le changement de votre collègue n'est pas dans un état où il peut être vérifié, il doit la terminer, et/ou apprendre à apporter des changements plus petits et incrémentiels.
"Vérification des changements partiels pouvant être déployés ou non" - vraisemblablement, cela signifie également que cela puisse être testé ou non? C'est une pente glissante à une base de code très ropey.
Lorsque vous devez ajouter une petite fonctionnalité ou une petite corrective comme maintenant, dans les 3 minutes suivantes et que vous devez corriger un fichier, vous avez un code à moitié développé, je dirais que c'est bien, les besoins pratiques se produisent sur des idéaux pragmatiques sur le champ de bataille.
Cela montre une différence fondamentale dans deux écoles de pensée: Ceux qui ne vérifient que le code de travail qu'elles sont satisfaites et que la sensation est digne d'économiser et ceux qui vérifient leur travail afin que le contrôle de la révision soit là pour les reculer contre la perte de données.
J'avais charabiliser ce dernier comme "ceux qui aiment utiliser leur système de contrôle de révision en tant que sauvegarde de la bande de pauvres-homme", mais cela te guiderait de la main sur quel camp je suis. :-)
Je suppose que vous êtes du camp "Good Code" et il est du camp "Code de travail".
[ÉDITER]
Des commentaires, oui, je devinais bien.
Comme je l'ai dit, je suis avec vous, mais aussi près que possible de dire que c'est une opinion minoritaire, ici sur Stackoverflow et où je travaille. En tant que tels, je ne pense pas que vous puissiez vraiment l'inscrire dans vos normes de développement comme le seul moyen d'utiliser. Pas si vous voulez que les normes suivies sont de toute façon. Une chose qu'un bon leader sait, c'est de ne jamais donner une commande qu'ils savez ne sera pas suivie.
bTW: Good Les éditeurs vous aideront à garder les anciennes versions. Par exemple, dans Emacs, je définis les anciennes versions et les anciennes versions conservées à 10, ce qui permet de rester au cours des 10 dernières économies de mes fichiers. Vous pouvez examiner cela comme un moyen d'aider votre argument contre la foule de la révision-Control-Sackup. Cependant, vous ne gagnerez jamais l'argument.
Une autre raison de l'enregistrement du code commenté:
Vous modifiez le code existant et vous avez trouvé un bogue subtil, celui qui est facile à négliger, et peut-être peut-être même avoir l'air correct au premier abord. Commencez-le, mettez le correctif à sa place et ajoutez des commentaires pour ce qui se passe et pourquoi il a été modifié. Vérifiez que dans, afin que vos commentaires sur le correctif soient dans le référentiel.
Dans mon expérience, les commutateurs de développeurs sont commentés sur le code.
Parfois, de nouvelles back-extrémités sont construites en parallèle, avec les commutateurs d'activation commentés dans le contrôle de la source.
Certaines fonctionnalités bizarres dont nous avons besoin une fois sur une lune bleue, mais aucun client n'aura jamais besoin est souvent mis en œuvre de cette façon. Ces choses comportent généralement un risque élevé de contournement de sécurité ou d'intégrité des données afin que nous ne le souhaitons pas actifs en dehors du développement. Nécessitant un développeur qui l'utiliserait pour entraîner le code d'abord semble être le moyen le plus simple de l'obtenir.
Ça dépend. S'il est laissé là-bas à des fins d'illustration, peut-être. Cela pourrait éventuellement être utile pendant le refactoring. Sinon, et généralement, non. En outre, commenter le code non fini est voué à être à la fois encombrant et un évier de temps. Mieux il brise le code en petits morceaux et les vérifier quand ils travaillent.
Mon point de vue: si les développeurs travaillent sur leurs propres succursales ou dans leur propre zone de sable, ils devraient pouvoir vérifier ce qu'ils veulent. C'est lorsqu'il s'agit de cocher le code dans une branche partagée (une branche de fonctionnalité ou une succursale d'une équipe, ou bien sûr principal/tronc) que le code doit être aussi vierge que possible (aucun code commenté, plus de correctifs, etc.).
Je suis absolument d'accord que le code commenté ne doit pas être vérifié dans le référentiel, c'est quel contrôle de code source est pour.
Dans mon expérience lorsqu'un programmeur vérifie le code commenté, c'est parce qu'il/elle n'est pas sûr de la bonne solution et est plus heureuse laissant la solution alternative de la source dans l'espoir que quelqu'un d'autre prendra cette décision.
Je trouve que cela complique le code et rend difficile la lecture.
Je n'ai aucun problème avec la vérification de la moitié du code fini (vous bénéficiez donc du contrôle de la source) qui n'est pas appelé par le système en direct. Mon problème est avec la recherche de sections de code commenté sans explication que le dilemme était celui qui a abouti au code exclu.
Je pense que "jamais" est une règle trop forte. Je voterais pour laisser une marge de manœuvre personnelle autour de savoir si les gens vérifient le code commenté dans le référentiel. L'objectif ultime devrait être la productivité du codeur, pas "un référentiel vierge".
Pour équilibrer cette laxisme, assurez-vous que tout le monde sait que le code commenté a une date d'expiration. N'importe qui est autorisé à supprimer le code commenté s'il existe une semaine complète et n'a jamais été active. (Remplacez "une semaine" avec tout ce qui vous convient.) De cette façon, vous réservez le droit de tuer l'encombrement lorsque vous le voyez, sans interférer trop directement avec les styles personnels des gens.
Je pense que le code de commenté est considéré comme "déchets".
Je suppose que vous travaillez dans un environnement d'équipe. Si vous travaillez seuls et que vous commencez le code avec un 'TODO "et vous y reviendrez alors c'est différent. Mais dans un environnement d'équipe, vous pouvez assumer en toute sécurité une fois que le code de commenté est vérifié, il est là pour rester et cela entraînera probablement plus de douleur que la satisfaction.
Si vous faites des critiques de code de pair, cela pourrait répondre à votre question. Si un autre développeur passe en revue votre code et dit: "Pourquoi ce code a-t-il commenté de faire" bla "" alors que votre code a échoué à l'examen du code et vous ne devez pas le vérifier de toute façon.
Le code de commenté ne posera simplement des questions avec d'autres développeurs - donc la gaspillage de temps et d'énergie.
Vous devez poser la question " pourquoi" Le code est commenté. Quelques suggestions:
Si vous commencez à commenter le code parce que vous êtes "incertain des règles de l'entreprise", vous avez probablement un problème avec "Scope Creep" - Mon mieux ne pas sale votre base de code avec des exigences que "serait bien d'avoir mais nous n'avons pas de temps mettre en œuvre "- gardez-le propre avec un code clair et des tests autour de ce qui est en fait là-bas.
Si vous commenciez le code parce que vous êtes "Je ne sais pas si c'est le meilleur moyen de le faire", demandez votre code de code! Les temps changent, vous regarderez le code que vous écrivez aujourd'hui dans 2 ans et pense que c'est horrible! Mais vous ne pouvez pas faire le tour des bits que vous "savez" peut être fait mieux, mais vous ne pouvez pas trouver un chemin en ce moment. Que quiconque maintient le code de code à long terme déterminer s'il existe une meilleure façon - obtenez simplement le code écrit, testé et travailler et passer à autre chose.
Si vous commencez le code parce que "quelque chose ne fonctionne pas", alors corrigez-le ! Un scénario courant est "Tests brisés" ou "TODO'S" . Si vous en avez, vous sauverrez plus de temps vos ancienslf en les fixant ou en vous en débarrassant. S'ils peuvent être "cassés" pendant une période de temps, ils peuvent très probablement être cassés pour toujours.
Tous ces scénarios potentiels (et ceux que je n'ai pas mentionnés ici) sont gaspillés du temps et des efforts. Le code commenté peut sembler un petit problème, mais pourrait être un indicateur d'un problème plus important dans votre équipe.
L'idée de permettre l'historique de contrôle des sources d'illustrer la "vieille façon" de faire quelque chose plutôt que de le commenter et de vérifier le commentaire, ainsi que d'une explication, c'est une bonne idée en théorie.
Dans le monde réel, cependant, personne ne regarde jamais l'historique de contrôle de la source sur les fichiers qu'ils travaillent à moins que cela ne fait partie d'un processus d'examen officiel de certaines sorte (fait uniquement périodiquement), ou si quelque chose ne fonctionne pas, et le développeur ne peut pas comprendre pourquoi.
Même alors, en regardant plus d'environ 3 versions d'environ 3 versions n'arrivent pas.
En partie, cela est dû au fait que les systèmes de contrôle des sources ne font pas ce genre de critique occasionnel facile. Habituellement, vous devez consulter une ancienne version ou diff sur une ancienne version, vous voyez simplement deux versions, et il n'ya pas de bonne vue concise sur ce qui change peut vous donner une idée à une idée de ce qui a changé.
Partiellement, c'est la combinaison de la nature humaine et des besoins de l'équipe. Si je dois réparer quelque chose, et je peux le réparer dans quelques heures, je ne suis pas susceptible de passer une heure à enquêter sur les anciennes versions du code qui n'ont pas été "en direct" dans un mois (qui, avec chaque vérification du développeur Cela signifie souvent de nombreuses révisions), à moins que je sache que je sache qu'il y a quelque chose à cet endroit (comme si je me souviens si je me souviens d'une discussion sur la modification de quelque chose en rapport avec ce que je fais maintenant).
Si le code est supprimé et vérifié, alors, à toutes fins utiles (à l'exception de l'objectif limité d'un retour-arrière complet), il cesse d'exister. Oui, il est là à des fins de sauvegarde, mais sans personne dans le rôle du bibliothécaire de code, il va se perdre.
Mon arborescence de contrôle source sur mon projet actuel est d'environ 10 semaines, une équipe de 4 ingénieurs seulement, et il y a environ 200 listes de modifications engagées. Je sais que mon équipe ne fait pas comme bon d'emploi car il devrait s'enregistrer dès qu'il y a quelque chose de solide et prêt à partir. Cela rend assez difficile de lire l'historique du code pour chaque partie du code pour attraper tous les changements importants.
En ce moment, je travaille sur un projet en mode de développement initial, qui est très différent d'un projet en mode de maintenance. Beaucoup d'outils les mêmes sont utilisés dans les deux environnements, mais les besoins diffèrent un peu. Par exemple, il existe souvent une tâche qui nécessite deux ingénieurs ou plus de travailler quelque peu de près pour construire quelque chose (dire un client et un serveur de quelque sorte).
Si j'écris le serveur, je pourrais rédiger le code de l'interface brouillon que le client utilisera et le vérifiera complètement non fonctionnel, de sorte que l'ingénieur écrivant le client puisse mettre à jour. En effet, nous avons la politique qui dit que le seul moyen d'envoyer du code d'un ingénieur à un autre se fait via le système de contrôle source.
Si la tâche va prendre suffisamment de temps, cela mériterait d'être créé une succursale peut-être pour nous deux de travailler (bien que cela soit contre la politique de mon organisation - les ingénieurs et les chefs d'équipe individuels ne disposent pas des autorisations nécessaires sur le serveur de contrôle source). En fin de compte, c'est la raison pour laquelle nous essayons de ne pas instituer trop de politiques "toujours" ou "jamais".
Je répondrais probablement à une politique générale de Code non commentée en disant que c'était un peu naïf. Bien intentionné, peut-être, mais il est finalement susceptible de réaliser son objectif.
Bien que vous voyiez que ce message va faire reviendrai sur le code que j'ai vérifié la semaine dernière et supprimez la partie commentée qui n'était jamais finale (bien que cela fonctionne) et que cela ne soit jamais souhaité à nouveau.
Je pense que l'enregistrement du code commenté dans un système de contrôle de code source doit être effectué avec une extrême prudence, en particulier si les balises de langue utilisées pour commenter le code sont écrites par des blocs, c'est-à-dire
/* My commented code start here
My commented code line 1
My commented code line 2
*/
Plutôt que sur une base de ligne individuelle, comme:
// My commented code start here
// My commented code line 1
// My commented code line 2
(vous avez eu l'idée)
La raison pour laquelle j'utiliserais une extrême prudence est que, selon la technologie, vous devez faire très attention à l'outil diff/fusion que vous utilisez. Avec certains systèmes de contrôle de code source et certaines langues, l'outil diff/fusion peut être facilement confondu. Le diff/fusion standard de ClearCase, par exemple, est notoirement mauvais pour la fusion de fichiers .xml.
S'il arrive que les lignes de commentaires des blocs ne se fusionnent pas correctement, PRESTO Votre code sera actif dans le système lorsque cela ne devrait pas être. Si le code est incomplet et enfreint la construction, c'est probablement le moins mauvais, comme vous le ferez immédiatement.
Mais si le code passe la construction, il peut devenir actif quand il ne devrait pas être présent et d'une perspective de cm pourrait être un scénario de cauchemar. QA testez généralement ce qui devrait être là, ils ne testent pas le code qui n'est pas censé être présent, votre code peut donc se retrouver dans la production avant de le savoir, et au moment où il serait réalisé que le code est là quand il Si le coût de la maintenance n'a pas multiplié de nombreux plis (comme le "bogue" sera découvert dans la production ou par le client, le pire lieu ou le temps).
Il y a clairement une tension entre 1) le contrôle au début du mois, et 2) en maintenant toujours le référentiel dans un état de fonctionnement. Si vous avez plus de quelques développeurs, ce dernier va avoir la priorité de plus en plus, parce que vous ne pouvez pas avoir un développeur crapping tout le monde sur les autres pour son propre flux de travail personnel. Cela dit, vous ne devriez pas sous-estimer la valeur de la première directive. Les développeurs utilisent tous les différents types de mental piquets de clôture, et les flux de travail personnalisés sont d'une façon que les grands développeurs presser sur les Xs supplémentaires. En tant que gestionnaire de votre travail de ne pas essayer de comprendre toutes ces nuances, qui vous échouerez à moins que vous êtes un génie et tous vos développeurs sont des idiots, mais permettent plutôt vos développeurs d'être le mieux qu'ils peuvent être par leur prise de décision.
Vous mentionnez dans le commentaire que vous n'utilisez des branches privées. Ma question est pourquoi pas? Bon, je ne sais rien à propos de TFS, alors peut-être il y a de bonnes raisons. Cependant après avoir utilisé git pendant un an, je dois dire que ai une bonne DVCS totalement cette tension diffuse. Il y a des cas où je trouve Décommenter code pour être utile que je construis un remplacement, mais je vais perdre le sommeil si je suis infliger aux autres. Être en mesure de branche signifie localement que je peux garder commits significatifs pour mon processus individuel sans avoir à se soucier (ou même en informer) les développeurs en aval des dégâts temporaires.
Fait écho au choeur. Décourager cela à tout prix. Il rend le code plus difficile à lire et à laisse les gens qui se demandent ce qui est bon/mauvais à propos de ce code qui ne fait même que partie de l'application à l'heure actuelle. Vous pouvez toujours trouver des changements en comparant les révisions. S'il y avait une chirurgie majeure et que le code a été commenté en Masse, le Dev aurait dû l'avoir noté dans les notes de révision sur CheckIn/Fusion.
le code incomplet/expérimental devrait être dans une branche à développer à l'achèvement. La tête/tronc doit être la ligne principale qui compile toujours et est ce qui est l'expédition. Une fois la branche expérimentale terminée/acceptée, elle devrait être fusionnée dans la tête/la ligne principale. Il existe même une norme IEEE (IEEE 1042) décrivant cela si vous avez besoin de documentation de support.
"- tissu cicatriciel " est ce que j'appelle le code commenté. Dans les jours précédant l'utilisation généralisée de systèmes de contrôle de la version, singes de code laisserait commenté le code dans le fichier au cas où ils devaient revenir à la fonctionnalité.
La seule fois qu'il est acceptable d'enregistrer "le tissu cicatriciel" est
- Si vous avez une succursale privée et
- Vous n'avez pas le temps de compiler le code sans erreurs et
- Vous allez sur une longue vacances et
- Vous ne faites pas confiance à votre VCS, comme si vous utilisez la source visuelle Safe [~ # ~ ~] ou [~ # ~] .
[ÉDITER] - Vous avez un bogue subtil qui pourrait être réintroduit si le code incorrect n'est pas laissé dans un rappel. (bon point d'autres réponses).
Il n'ya presque aucune excuse pour # 4 car il y a beaucoup de systèmes VCS librement disponibles et robustes autour, GIT étant le meilleur exemple .
Sinon, laissez simplement le VCS être votre archive et votre distributeur de code. Si un autre développeur veut regarder votre code, envoyez-lui un courriel et laissez-le appliquer les choses qu'il souhaite directement. En tout état de cause, la fusion ne se soucie pas de la raison et de la manière dont le codage de deux fichiers a divergé.
Parce que c'est du code, le tissu cicatriciel peut être plus distrayant, même qu'un commentaire bien écrit. De par sa nature même en tant que code, vous rendez le programmeur de maintenance dépensant des cycles de processeurs mentals à déterminer si le tissu cicatriciel a quelque chose à voir avec ses changements. Peu importe que la cicatrice soit de semaine âgée ou âgée de 10 ans, laissant des tissus cicatriciels dans le code impose une charge sur ceux qui doivent déconnecter le code après mots.
[Modifier] J'ajouterais qu'il y a deux scénarios principaux qui doivent être distingués:
- développement privé, codant un projet personnel ou enregistré dans une succursale privée
- Développement de la maintenance, où le code en cours d'enregistrement est destiné à être mis en production.
Il suffit de dire "non" au tissu cicatriciel!
Je préférerais voir éventuellement cassé un code accessible qui n'est pas encore utilisé dans le même code étant complètement indisponible. Étant donné que tous les logiciels de contrôle de version permettent une sorte de "copie de travail" distincte du coffre, c'est vraiment une bonne idée d'utiliser ces fonctionnalités à la place.
Un nouveau code non fonctionnel est bien dans le coffre, car il est nouveau. Cela ne brise probablement rien qui fonctionne déjà. S'il casse la casse du code de travail, il devrait simplement aller dans une branche, de sorte que d'autres développeurs puissent (s'ils doivent) vérifier cette succursale et voir ce qui est cassé.
Les référentiels sont sauvegardes du code. Si je travaille sur le code mais que cela n'est pas terminé, pourquoi ne pas le commenter et le vérifier à la fin de la journée. De cette façon si mon disque dur meurt pendant la nuit, je n'aura plus perdu de travail. Je peux vérifier le code dans la matinée du sport et continuer à continuer.
La seule raison pour laquelle je voudrais le commenter est parce que je ne voudrais pas casser la nuitée.
Je pense que l'enregistrement du code commenté doit être valide comme, simplement parce que les nouveaux changements ont passé des tests, il peut être plus utile de voir ce qui y était avant et de voir si le nouveau changement est vraiment une amélioration.
Si je dois revenir en arrière plusieurs versions pour voir un changement antérieur qui conduit maintenant à un succès de performances, ce serait très gênant.
Parfois, le code commenté est une bonne histoire, mais mettez des dates sur le moment où le code a été commenté. Plus tard, une personne qui travaille près de là peut simplement supprimer le code commenté comme il a été prouvé de ne pas être nécessaire.
Il serait également bon de savoir qui a commenté ce code afin que si une justification soit nécessaire, on peut demander.
Je préfère écrire de nouvelles fonctionnalités, assurez-vous que les tests d'unité passent, vérifiez-le, puis permettent aux autres de l'utiliser et de voir comment cela fonctionne.
Je ne sais pas - je remarque toujours les lignes original des lignes avant de faire des changements - cela aide-moi à les revenir si je change d'avis. Et oui je les vérifie.
Je dise cependant un ancien code commenté de l'enregistrement précédent.
Je sais que je pouvais regarder les journaux diff pour voir ce qui a changé, mais c'est une douleur - c'est agréable de voir les derniers changements là-bas dans le code.
En C++, j'utilise #if 0 Pour le code commenté et le trouver légitime. refactoring Les outils fonctionnent toujours dessus, donc techniquement, il est presque entretenu. Et, c'est nettement coloré par la sélection de la syntaxe.
Je pense que cette fonctionnalité serait utile pour tous:
- ce code n'est pas opérationnel
- il appartient toujours ici
- et cela doit être très visible à ce point même, car il est pertinent.
Supprimez toujours le code commenté s'il n'a pas -réel commentaire Expliquant ce qui est si spécial à propos de ce code et pourquoi est-ce si important, bien qu'il soit inopératoire.
Si le développeur a commenté un certain code, car il n'est pas encore complet, le moyen "contrôle source" correct de traiter cela serait pour ce développeur pour le maintenir dans une branche distincte de la sienne, jusqu'à ce que ce code est prêt à vérifier.
Avec un DVCS (comme Git, Bazar ou Mercurial), cela n'est pas mort, car il ne nécessite aucune modification du référentiel central. Sinon, vous pourriez peut-être parler de donner aux développeurs leurs propres branches sur le serveur s'ils travaillent sur des fonctionnalités spécifiques qui les prennent suffisamment de temps (c'est-à-dire jours).
Il n'y a rien de mal à vérifier le code commenté dans certaines situations, il s'agit simplement d'une situation où il peut y avoir une meilleure façon de le faire, le développeur peut donc suivre les modifications de sa source même si Il n'est pas prêt à être vérifié dans le référentiel principal.
Clairement, le développeur qui vérifie le code commenté doit fonctionner dans une branche distincte, la fusion de modifications de la branche du réseau en fonction de la néccessaire.
Il appartient au système VCS d'aider le développeur dans ce flux de travail (GIT est un excellent système VCS qui fonctionne très bien avec cela).
Un joli compromis consiste à écrire un petit outil qui décharge vos fichiers décédés/modifiés sur un lecteur de sauvegarde réseau. De cette façon, vous pouvez modifier le contenu de votre cœur et faire sauvegarder votre travail, mais vous ne devez jamais vérifier le code expérimental ou non fini.