Quelles sont les bonnes pratiques avant de vérifier le code source? [fermé]

Mon équipe utilise Team Foundation Server pour le contrôle de code source et, aujourd’hui, j’ai corrigé quelques bogues et une application de test de la fumée avant de l’enregistrer, mais j’ai oublié de commenter du code. (Ce code a rendu l'interface utilisateur un peu étrange.)

Je veux savoir quelles sont les bonnes pratiques avant de vérifier le code - je ne veux plus commettre ce genre d'erreur.

Une chose que j’ai eu l’habitude de faire est de toujours regarder les diffs de chaque fichier que je suis sur le point d’enregistrer, juste avant que je les archive.

Vous ne devriez jamais enregistrer de code commenté. Si vous avez du code qui a besoin d'être commenté avant les enregistrements, vous le faites mal.

En ce qui concerne les règles:

1. Obtenir les dernières
2. Résoudre les conflits de fusion

3. Construire

   3.1 Corriger les erreurs de construction

4. Exécuter des tests

   4.1 Correction des tests cassés

5. Aller à 1 (jusqu'à ce qu'il n'y ait rien de nouveau à obtenir)

Ne vous enregistrez que lorsque toutes les étapes sont terminées.

Voir la danse d'enregistrement .

Autres bonnes pratiques:

• Passez en revue la liste des fichiers à archiver pour vous assurer qu'ils correspondent aux fichiers attendus.
• Examiner les modifications pour chaque fichier (suppressions / ajouts / diffs)

Je ne veux pas être trop d'un pantsweasel, mais l'hypothèse de cette question (et tout sauf une des réponses) concerne surtout les VCS centralisée, tels que TFS, SVN, Perforce, etc.
assez juste, il est ce que le PO utilise.

Cependant, lorsque vous utilisez DVCS (tels que Mercurial et Git), vous ne devriez généralement pas attendre pour enregistrer, et la plupart des choses mentionnées dans les réponses - telles que diff, obtenir les dernières nouvelles, fusionner, etc. - ne sont pas nécessaires. . Même des choses telles que des révisions de code et des tests sont préférables après l'enregistrement (bien que peut-être avant de pousser, cela dépend ...)
La seule exception que j'ai vue ici (jusqu'à présent) est l'association à un élément de travail. Bien sûr, commenter l'enregistrement est également bon ...

Trois choses que je n'ai pas vues dans d'autres réponses:

Inclure les nouveaux fichiers

• Rechercher les nouveaux fichiers qui ne font pas partie de votre liste de modifications
• Peut être spécifique à des GDS comme Perforce - vous devez lui dire tout ce qui est dans votre changement.

Rétablir les fichiers non modifiés

• Je déteste quand je regarde les changements d'autres personnes et qu'il y a une liste de modifications avec neuf fichiers mais seulement trois d'entre eux ont été modifiés.
• Je retourne également des fichiers avec des espaces ou des modifications sans signification.

Vérifiez votre commit soumis

• Assurez-vous que la construction reste verte après votre commit.
• J'avais une deuxième machine que je synchronisais, construisais et courais après mes commits; ainsi, en cas de problème, je pouvais facilement intervenir et le réparer.

Deux choses quand j'utilise Git:

Atomic commet:

• Définissez uniquement les modifications fonctionnelles individuelles pour la validation.
• Faites des commits aussi petit que possible. Rendez-les faciles à corriger, à rétablir et à comprendre.
• J'utilise git add --patchpour diviser mon changement en plusieurs parties si nécessaire.

Voir les diffs en résumant

• Je vérifie toujours avec git commit --verboseafin que je puisse voir un diff de mon changement pendant que je tape dans mon message de validation. (Ou j'utilise mon git-vim patché pour montrer le diff.)
• Cela rend beaucoup plus facile de passer en revue vos modifications et de décrire le commit complet. Parfois, je remarque des changements imprévus à ce stade. (Décrire votre changement vous aide à y penser.)

Quelques éléments de «bonne pratique» que je mets en application sur les serveurs de mon équipe sont assez simples. Tout d'abord, avant de vous enregistrer, vous devez toujours obtenir les dernières informations et exécuter une construction locale, afin de vous assurer que personne d'autre n'a vérifié quoi que ce soit dans lequel votre code se heurtera. En outre, prenez soin de tout conflit de code sur votre ordinateur local, pas sur le serveur. Une fois que votre code, avec le dernier code téléchargé, a été confirmé pour se construire et fonctionner correctement, vous êtes prêt pour l'étape suivante. Exécutez tous les tests automatisés, puis commencez votre enregistrement pour vous assurer qu'ils fonctionnent toujours correctement. Ensuite, juste pour être sûr, soyez à nouveau au courant.

En tant qu'administrateur TFS, il est possible d'appliquer des commentaires à tous les enregistrements. Je recommanderais de toujours mettre des commentaires d’enregistrement pour votre travail, que celui-ci soit appliqué ou non. Si vous avez la possibilité de le faire, appliquez-le. Assurez-vous que les commentaires sont, au moins, un résumé général de ce que vous avez changé depuis la dernière fois que vous avez archivé votre code. changé dans cet enregistrement. Cela facilite beaucoup le débogage d'une construction cassée.

En outre, si vous disposez des privilèges d’administrateur TFS, appliquez des générations évolutives aux archivages (pour vous assurer que tous les autres savent immédiatement si leur enregistrement casse quelque chose), et vous pouvez configurer le serveur pour effectuer un archivage sécurisé ( si le code coché interrompt la construction, le serveur la rejette) ou vous pouvez simplement lui demander de créer un bogue et de l’affecter à celui qui a cassé la construction.

Il y a quelques autres options que vous pouvez activer ou désactiver pour que tout soit en ordre ou suggérer à votre administrateur TFS de l'activer pour garder les choses propres et propres ... mais elles sont largement préférables.

Rechercher et remplacer les mots de malédiction ;-)

Si vous vous enregistrez à partir de Windows, vérifiez si votre code ne contient pas ces caractères ^ M invisibles - les éditeurs sous UNIX donnent souvent des erreurs / avertissements à cause de cela.

Essayez également de remplacer les onglets - différents utilisateurs finiront par voir les arrêts de tabulation différemment, certains avec 4 espaces, certains 8 et ne seront pas bons pour la lisibilité du code.

La meilleure approche à mon humble avis consiste à faire en sorte qu'un script prédéfini vérifie votre code par rapport aux instructions de codage de votre organisation. Les charges des systèmes de contrôle de source ont cette fonctionnalité.

Dans mon entreprise, nous utilisons des avis d’enregistrement. Celles-ci n'ont pas besoin d'être détaillées, mais montrer à quelqu'un les différences de votre liste de modifications et en tenir compte mettra parfois en évidence la mauvaise frappe que vous avez manquée lors des tests.

Notre serveur de contrôle de code source ne vous autorisera pas à enregistrer sauf si vous notez le nom du réviseur dans les commentaires (sous la forme! Initiales, par exemple! BW si Bruce Wayne a fait votre commentaire). L'examinateur reçoit un courrier électronique indiquant qu'il a contribué à la révision. Ceci est ouvert à une exploitation évidente mais semble fonctionner assez bien.

Dans la mesure du possible, j'aime associer un enregistrement à un élément de travail. Cela vous donne des informations contextuelles sur POURQUOI cela a été changé, pas seulement sur QUOI a été changé. TFS a un système de suivi des éléments de travail assez décent, il est donc relativement facile de le faire au moment de l’enregistrement.

(ceci s'ajoute à l'examen des diffs de mes modifications)

Une petite chose que je fais est de ne pas archiver les fichiers qui n’ont pas vraiment changé. Ces fichiers peuvent avoir été modifiés par inadvertance ou avoir été impliqués dans des refactorisations annulées ou rendues sans objet.

De cette façon, votre ensemble de modifications (associé à un élément de travail) contient exactement les fichiers nécessaires pour satisfaire l'élément de travail.

Pour combiner toutes les réponses ici et donner une liste de contrôle complète

1. [check in / check out] vous ne devriez pas vous enregistrer directement dans le flux de travail des autres utilisateurs. Vous devriez avoir une stratégie de flux: par exemple, un flux dans lequel vous pouvez archiver et extraire les sorties de manière indépendante sans déranger les autres: votre travail soyez en sécurité, mais dans votre propre flux de développement, donc [uniquement dans votre propre flux de développement]. À chaque enregistrement, vous l'associez à un enregistrement de modification pour que vos modifications soient identiques à celles-ci (l'ensemble de modifications) (vous pouvez ainsi distribuer les bogues / bogues, etc. de rfc individuels, sans avoir à fournir «tout»).

2. [puis rebasez avec votre flux d'équipe] cela signifie que vous obtenez les modifications des autres dans votre propre flux. Au cours de cette opération, vous pouvez voir dans le dialogue de fusion tous les "diffs" et les parcourir ou ... s'il y en a des milliers et / ou si vous utilisez non pas du code, mais aussi, par exemple, des modèles de données / projets siebel, etc. les fusions manuelles non triviales, les fusions manuelles triviales-automatiques et triviales, la dernière catégorie contient les plus difficiles. Rappelez-vous que vous travaillez toujours dans votre propre flux.

3. [refonte complète] Si tout va bien, enregistrez toutes les modifications que vous venez de recevoir du flux d'équipe: votre propre flux est maintenant à jour.

4. [Livrer] maintenant livrer votre travail au flux d'équipe. SI vous ne voulez pas tout livrer, vous pouvez également sélectionner, par exemple, 1 RFC spécifique avec des versions de fichiers spécifiques ou un ensemble de RFC / défauts résolus.

5. [test deliver] ça devrait aller, mais comme il y a une chance que quelqu'un apporte entre-temps des modifications: vous pouvez tester si votre travail fonctionne avec les dernières modifications du flux d'équipe. Avec les mêmes boîtes de dialogue de fusion montrant des différences.

6. [complete deliver] terminez votre livraison et votre travail est maintenant dans le flux d'équipe.

Pour compliquer les choses: comme il est toujours possible que le travail que vous avez livré = ok MAIS vous travaillez déjà sur une version ultérieure, vous devez toujours baseline toujours après livrer et indiquer la base de référence sur laquelle elle est préférée par les autres utilisateurs. . Cela garantit que les autres développeurs obtiennent une version recommandée et non la dernière version du flux (si vous travaillez dans ce scénario). Il s’agit également d’une triple vérification. Même si les dernières versions du flux d’équipe sont "mauvaises", elles ne sont toujours pas celles sur lesquelles les autres se basent ou se regardent et votre gestionnaire de configuration peut fusionner la version précédente vers la version suivante pour annuler. votre livraison.

• la réponse de histumness arrive 2 fois: aux étapes 2 et 6
• la réponse de Oded lors de l'enregistrement: idem, mais une couche supplémentaire de restitutions et de restitutions lors de l'enregistrement / du départ pour vous assurer que vous travaillez isolé et que les erreurs peuvent toujours être résolues facilement, même à un stade ultérieur
• la réponse de guildsbounty répond: get last est la deuxième étape. Pour la construction: cela dépend vraiment si vous AVEZ une construction ... dans mon monde, vous avez des entrées de modèles de données, de documents Word, de feuilles de configuration, de données de configuration d’informatica, siebel, etc. etc .., et oui aussi le code java, le code .net etc ... que tous devraient se mélanger. Donc, il n’ya pas vraiment de "construction" ici, mais plutôt une intégration plus élevée selon que cette construction, par exemple à partir de votre "code", s’intègre à tout le reste, car vous ne pouvez pas savoir avec certitude s’il s’agit d’intégration et si Dans leurs environnements de test, il peut s’agir de trucs compilés ou, lors de livraisons plus importantes, d’une autre version, car ils ont besoin de quelque chose d’une autre équipe.
• la réponse de guildsbounty sur les commentaires et requis: Je pense que tous les environnements dans lesquels vous n’avez pas l’intégration des VERSIONS et des modifications dans les ensembles de modifications (et le type: défauts, RFC, hotfi) n’est pas mature. Je pense que son chaos si vous ne pouvez pas par exemple automatiser les notes de publication avec la quantité de bogues et de rfcs soumis qui sont cliquables sur les versions exactes qui sont touchées (par exemple, les versions 1 et 3 de hello.c pourraient très bien être livrées, mais la version 2 n’aurait pas dû être livré, car cela contiendrait une partie d’une version ultérieure, mais certains noob l’auraient déjà insérée) (c’est donc une décision manuelle SI VOUS souhaitez également supprimer la version 3 de hello. c MAIS retirer la version 3 signifie que vous devez également supprimer toutes les autres versions touchées par ce RFC / défaut, vous devez donc pouvoir utiliser facilement et rapidement un outil pour supprimer tout ce qui se passe) (même si plusieurs développeurs ont travaillé sur des parties de ce même RFC) mais au moins vous avez besoin de trucs autour pour en décider, etc ...). Une documentation supplémentaire est toujours utile, mais en associant des ensembles de modifications, vous obtenez le cercle complet: une version <- un ensemble de modifications <- des éléments de travail <- un ticket / rfc / defect <- est indispensable. Signification: vous savez quelles exigences sont entièrement ou complètement fournies: une exigence comporte plusieurs RFC, bogues ou autres. La RFC comporte plusieurs éléments de travail pour plusieurs personnes. cet élément de travail correspond à un ensemble de modifications existant dans un ensemble de versions (par exemple, les versions 1 et 3 de hello.c sur le flux d'intégration qui ne sont bien sûr PAS les versions 1,
• le commentaire de luis.espinal: ne cassez pas la construction est revérifié et restez stable ... il y a des livraisons plus hautes pour les "gestionnaires de version et les constructeurs" qui devraient voir les ensembles de modifications et les lignes de base comme informations. "Ne travaillez jamais directement sur la branche principale". Oui, la structure du flux peut être volumineuse ou simple, mais essentiellement: les développeurs ont leur propre flux, ils livrent à un flux d'équipe qui livrent à un flux de version. -> afin que les livraisons de toutes les équipes (p. ex. équipe de documentation, équipe des exigences, équipes de développement,

Dans votre exemple, vous indiquez que vous avez oublié de commenter du code. Des erreurs se produisent. Le système de gestion de la configuration autour de lui devrait s'en charger. Par exemple, il se peut que des milliers de modifications interviennent et que les "constructions" et les "intégrations" se déroulent dans une hiérarchie de flux sur différents serveurs chaînés et traités à temps. Ainsi, même si, au bout de 5 mois, votre code commenté est testé sur un serveur d'intégration, car votre code doit être intégré à d'autres codes et systèmes, il devrait toujours être possible de supprimer votre ensemble de modifications de manière atomique et de continuer. La meilleure pratique est donc plus ou moins à un niveau supérieur. La conception globale des flux de gestion de la configuration devrait en prendre soin. Pour les développeurs individuels, la meilleure pratique consiste bien entendu à valider / tester l’unité. Mais de la grande image à "

Certains des éléments suivants s'appliquent plus que d'autres (ou sous différentes formes) en fonction de votre SCM, alors les voici:

1. Ne cassez pas la construction, cochez uniquement le code compilé.
2. Commentez vos entrées (et éventuellement vos sorties si votre SCM vous en donne la possibilité).
3. Ne laissez pas de matériel non contrôlé pendant de longues périodes.
4. Enregistrement souvent (plusieurs fois par jour si possible.)
5. Étiquetez de manière significative.
6. Étiqueter régulièrement.
7. Ne travaillez jamais directement sur la branche principale.
8. Chaque mise en production doit avoir son propre label (et si possible une branche en lecture seule de la branche principale). Si possible, faites de même pour les versions de test UAT / Integration / Pre-Production.
9. Vous devriez être capable de construire exactement ce qui est en production à partir de ce qui se trouve dans votre SCM et d'un label.

REMARQUE : certains des éléments ci-dessus semblent plutôt évidents, mais vous ne pouvez pas croire combien de personnes travaillent réellement sur la branche principale ou apportent des modifications en production en premier , puis créent manuellement des deltas pour passer au contrôle de version ... directement sur la branche principale. .. et avec des étiquettes. Douce comme de la bile fermentée mélangée à du jus d'aisselle non lavé ... ouais, comme ça.

Avoir une liste de contrôle personnelle. Commencez vide quand vous vous trompez, à une entrée. Quand il devient une seconde nature, retirez-le de la liste.

Exécutez les tests. Si elles réussissent, inscrivez-la. Si vous vous trompez et que quelque chose dépasse les tests, écrivez un test.

Nous faisons ce qui suit ...

1. Test - Nous voulons nous assurer que cela fonctionne. À tout le moins, nous voulons savoir que cela ne casse rien.

2. Révision du code, ou du moins vérification par un ami - C’est un excellent moyen de s’assurer que les connaissances sont diffusées et que les personnes sont mises à jour. Cela aide aussi à attraper les bugs avant d’enregistrer les choses.

3. Envoyer un préavis - Un préavis est envoyé au groupe avant l'enregistrement. Le but n'est pas seulement de laisser savoir aux fichiers quels fichiers ou zones changent, mais cela leur donne un avertissement (au cas où ils choisiraient de prendre note) au cas où ces changements sont susceptibles de les affecter.

4. Quelques heures après l'envoi de la notification préalable, l'enregistrement est effectué et le groupe est informé par courrier électronique. Tout le monde dans le groupe peut savoir quand le travail sur un bogue ou une fonctionnalité est terminé.

5. Une copie de l’avis d’enregistrement est collée dans l’enregistrement de correctif associé au bogue ou à la fonction. Lors de la recherche dans les enregistrements, nous trouvons qu’il est très pratique d’avoir une idée de ce que le correctif / la fonctionnalité impliquait.

Exécutez vos tests unitaires sur lesquels vous avez travaillé avec tant de diligence. Le vert c'est bien.

Assurez-vous que votre code est correctement formaté (par exemple pour Java: sélectionnez votre code et appuyez sur Ctrl-Maj-F dans Eclipse). Mais faites attention à faire la même chose pour tout un document.

Toujours, toujours, toujours , vérifiez que les changements que vous avez apportés ne brisent pas la construction. Surtout des changements mineurs qui peuvent sembler triviaux.

Une fois que j’ai fait un changement très mineur qui, à mon avis, ne poserait aucun problème juste avant de quitter le travail pour le week-end. Effectivement, ce petit changement a brisé la construction et aucun test nocturne n'a été exécuté pour notre projet. Le chef des questions-réponses n'était pas très content de cela, et à juste titre.

Recherchez des parties de vos modifications pouvant constituer des unités autonomes.

Souvent, lorsque j'ai une solution de travail ou une amélioration au code, plusieurs modifications ont été apportées. Certaines d'entre elles sont spécifiques au changement de comportement que je vais obtenir; d'autres sont des refactorings que j'ai faits pour rendre ce changement plus propre.

Je préfère enregistrer chaque refactoring séparément, avec sa propre description de changement, comme ceci:

REFACTORING: Renommez X en Y

X avait un sens avant parce que ... mais maintenant, ce devrait être Y. Ceci est lié au travail pour le numéro 9.

Ensuite, une fois que chaque refactoring correct est enregistré, le changement de comportement final est souvent anodin.

De plus, certaines modifications affectent de nombreuses lignes de code mais ne sont pas très intéressantes, tandis que d'autres sont très localisées mais ont un impact important. Si ces modifications sont enregistrées ensemble, il peut être difficile de lire les diffs. Donc, je les garde séparés.

Plus tard, lorsque quelqu'un lit l'historique des changements, il est évident que la situation actuelle en est devenue la raison et pourquoi. Il est également trivial d’annuler mon changement de comportement car il n’est pas mêlé à d’autres modifications.

Faites ce que vous feriez en retournant quelque chose que vous avez emprunté à quelqu'un. Assurez-vous qu'il est propre et en bon état. Si vous avez causé des dégâts, assurez-vous de nettoyer avant de renvoyer le code à son propriétaire (dans la plupart des cas, votre employeur).

Je garde un dépôt HG local pour mon travail.

• Chaque fois que je vérifie quelque chose, je regarde le diff et m'assure que tous les changements sont acceptables.
• J'essaie de noter la fonctionnalité clé de l'enregistrement.
• J'essaie de garder chaque taille de commit sur une fonctionnalité clé.

Je ne prétends pas que ce sont les meilleurs, mais ils fonctionnent pour moi.

Lorsque j'écris du code dont je sais qu'il n'est pas censé être archivé, j'ajoute une ligne avant celle-ci contenant "// TEMP:" et après celle-ci avec "// END TEMP.". Ceci, associé au fait que diff soit vérifié avant l'enregistrement, m'annonce que je ne vais pas enregistrer ce code par erreur.

Testez minutieusement tout ce que vous avez ajouté ou modifié. Essayez tous les cas possibles auxquels vous pouvez penser. Ne laissez pas les tests à l'assurance qualité. Si je mangeais un sandwich à chaque fois que je faisais quelques changements mineurs, puis que j'essayais quelques essais, par souci de sécurité, et que je voyais immédiatement des problèmes, j'aurais beaucoup de sandwichs. Je me dis d'habitude à voix haute: "Je suis vraiment content d'avoir essayé ça ..."

Vous dites que l'interface utilisateur est devenue étrange après votre changement. Si vous aviez seulement exécuté le programme et consulté l'interface utilisateur avant de vous enregistrer, auriez-vous remarqué le problème?