Quand faut-il commettre du code?


59

Lorsqu’on travaille sur un projet, le code peut être développé assez rapidement en une seule journée ou petit à petit pour une période prolongée de quelques semaines / mois / années. Comme les commits de code commencent à être considérés comme une mesure du développement de projet, cela ne signifie pas vraiment qu'il a écrit plus de code qu'un projet comportant moins de commits.

La question est donc de savoir quand faire un commit dans le référentiel afin que le commit soit justifiable.

En complément: est-ce une pratique correcte de mesurer le développement d'un projet sur la base de ses engagements?


9
La plupart des choses qui sont facilement quantifiables sont de mauvaises mesures car elles sont trop simplifiées ou peuvent facilement être interprétées comme performantes par rapport à la mesure spécifique.
Unholysampler

Merci à tous pour les contributions. Il y a de nombreuses raisons valables de faire un commit qui est réparti sur les réponses, et je ne peux pas accepter plusieurs réponses, j'accepte la réponse avec le plus grand nombre de voix jusqu'à présent. Mais je prends toutes vos réponses.

Réponses:


79

Vous vous engagez lorsque vous avez atteint un état de base de code que vous souhaitez mémoriser. Il y a beaucoup de raisons pour lesquelles vous pourriez vouloir vous souvenir d'un état de base de code particulier, de sorte qu'il ne peut y avoir de règles strictes sur le moment de la validation. Cependant, le nombre de commits n'est en aucun cas une mesure de la qualité ou des progrès.


10
Je suis d'accord avec l'addenda que le coffre est une histoire différente. Pour pouvoir vérifier dans le coffre de mon équipe, par exemple, il faut a) construire correctement et b) compléter quelque chose. Tout membre de l'équipe est libre de créer une branche et il peut être dans l'état de son choix.
Edward Strange

34

J'aime penser à coder comme de l'escalade dans ce contexte. Vous montez un peu, puis vous mettez une ancre dans le rocher. Si jamais vous tombez, la dernière ancre que vous avez plantée est le point qui vous assure, vous ne tomberez donc jamais à plus de quelques mètres. Idem avec le contrôle de source; vous codez un peu et lorsque vous atteignez une position relativement stable, vous validez une révision. Si vous échouez horriblement, vous pouvez toujours revenir à la dernière révision et vous savez que celle-ci est stable.

Cela dit, si vous travaillez en équipe, il est de coutume de vous assurer que tout ce que vous commettez est complet, logique, construit proprement et ne casse pas le travail de quelqu'un d'autre. Si vous devez apporter des modifications plus importantes susceptibles d'interférer avec le travail des autres, créez une branche pour pouvoir commettre sans déranger personne.

Cela dépend également du système SCM que vous utilisez. Les systèmes distribués permettent généralement de fusionner et de forger sans douleur et rapidement, et vous pouvez vous engager localement; cela signifie que vous devez vous engager beaucoup et pousser / fusionner lorsque vous avez effectué un travail considérable. Avec les systèmes centralisés tels que svn ou cvs, s’engager coûte plus cher et affecte tout le monde. Le branchement résout partiellement ce problème, mais comme cela se produit sur le serveur, il peut être extrêmement lent et la fusion peut s'avérer fastidieuse. Ainsi, avec la gestion de la chaîne d'approvisionnement centralisée, il existe souvent une culture plus prudente dans laquelle vous ne vous engagez qu'une fois que vous avez effectué un travail considérable.

En ce qui concerne l'add-on: s'il vous plaît, s'il vous plaît ne faites pas cela. Les lignes de code, le nombre de commits, le nombre de bugs trouvés / résolus, etc., sont tous de très mauvaises mesures de qualité ou même de quantité.


Je suppose que la même chose s’applique aux nouvelles branches, où tous les nouveaux développements sont validés dans votre propre branche, que vous pousserez ensuite lorsque la fonctionnalité sera prête? C'est à dire. vous pourriez même envoyer beaucoup de code incomplet dans votre propre branche privée.
Juha Untinen

Oui, mais dans une moindre mesure, car (voir la réponse initiale), vous ne dérangerez personne directement. En fonction du SCM en question, il est généralement considéré comme une bonne pratique de nettoyer votre historique de validation avant la fusion en amont (par exemple git rebase -i).
tdammers

13

Si vous utilisez DVCS comme Mercurial ou Git, vous devez vous engager dans votre référentiel local chaque fois que vous avez effectué une quantité importante de travail. Cependant, transférez-le uniquement vers le référentiel partagé uniquement après avoir fonctionné, un changement autonome testé.

Pour les VCS non distribués (comme par exemple SVN), la même logique s'applique. Au lieu du référentiel local, utilisez une branche privée, au lieu d'une fusion avec une branche principale.


+1 Étonné cela n'a pas été voté plus. Ce fut ma première pensée - dvcs or vcs
Michael Durrant

9

Vous devriez vous engager tôt et souvent.

Je connais des gens qui s'engagent aussi souvent que toutes les 90 secondes. Sérieusement. Cela semble fonctionner pour eux. J'ai essayé de valider chaque fois que je sauvegardais un fichier, ce qui prend probablement plus de 90 secondes. Aujourd'hui, je m'engage probablement toutes les 15 minutes environ. Un VCS qui vous permet de réduire plusieurs commits en un seul et qui autorise les commits locaux (comme git) facilite beaucoup cela.

À quelle fréquence devriez-vous vous engager? Difficile à dire, mais probablement plus souvent que vous ne l’êtes maintenant. Continuez à vous engager de plus en plus souvent, trouvez un point qui vous semble absurde trop souvent, puis reculez un peu. Les chances sont que vous finirez avec quelque chose de raisonnable.

Vous mesurez le développement d'un produit en fonction de la valeur fournie à ses utilisateurs. Il n'y a pas d'autre mesure précise.


1
+1 Lorsque vous combinez BDD-As-You-Si-Mean-It, Refactor Envolez vous, codage atomique, et un langage très expressif, 90 secondes peut être longue le temps d'aller sans commettras.
Jörg W Mittag Le

8

Les validations sont les éléments constitutifs de tout code / donnée contrôlé par la version. Chaque commit doit faire exactement l'une des choses suivantes:

  • Ajouter une nouvelle donnée ou fonction
  • Corrige un ou plusieurs bugs (un commit pour chaque correctif si possible), correctif possible:
    • Amélioration des performances
    • Corriger le mauvais comportement du code
    • Supprimer les erreurs typographiques
  • Refactoriser le code ou les données sans changer la sémantique. Ceci comprend:
    • Code de réécriture qui se comporte identique à l'original
    • Modification de la représentation des données dans un format différent
    • Mettre en forme le code ou les données pour respecter les directives de mise en forme du projet
  • Fusionner les modifications d'une autre branche (en amont / en aval)

De même, lorsque vous travaillez dans des branches, les commits doivent aller dans une branche plus apte. Deux commits ne doivent pas avoir le même message de validation (impliquant des modifications similaires), mais dans des branches différentes car cela déroute les collaborateurs. Un meilleur moyen est de s’engager dans la branche principale et de fusionner avec la branche.

Si les auteurs suivent la règle ci-dessus, il devient trivial de:

  • Annuler un changement particulier sans effets secondaires
  • Identifier le comportement modifiant le changement de code à partir des changements de formatage de code
  • Fusionnez entre différentes branches en évitant la plupart des conflits
  • Collaborez avec d'autres développeurs qui peuvent facilement tirer votre changement

En ce qui concerne la mesure de la progression du projet sur la base des validations, il est possible que les validations du refactoring et des corrections de bogues ne soient pas prises en compte.


Je pense que cette réponse doit être la réponse acceptée, mais le questionneur cherchait probablement une explication plus simple :)
Behnam Rasooli

7

N'engagez que lorsque vous avez testé avec succès la fonction / le module / la fonctionnalité donnée et que vous êtes raisonnablement assuré qu'il est prêt pour l'intégration ou le test du système.

Et pour répondre à vos questions complémentaires - NON !! la mesure de l'endroit où le projet est ne devrait jamais être déterminée par le nombre de commits ... qui sait ce qui a réellement été commis? A-t-il été testé avec succès sur le système ou même sur l'unité? Ce n’est pas parce que c’est engagé que la production est prête.


5
Ce serait vrai si vous vous engagiez dans le coffre, mais si vous vous engagiez dans une branche de fonctionnalité ou dans une branche privée, il n'était pas nécessaire qu'elle soit prête pour l'intégration.
Neil Butterworth

1
@Neil Butterworth: ... sauf si d'autres développeurs travaillent sur la même branche avec certaines dépendances de votre code.
FrustratedWithFormsDesigner

@Frustrated Dans ce cas, il devrait certainement être compilable, mais je ne pense pas qu'il devrait être prêt pour l'intégration et les tests du système.
Neil Butterworth

1
Dichotomie intéressante ici entre les vcs distribués et centralisés. Avec les vcs distribués, cela ne sera jamais un problème, car vous pouvez vous engager à mettre en place des branches en local et éviter tout autre développement.
George Mauer

2
@ George - Ceci est une fausse dichotomie. La vraie dichotomie réside entre l’utilisation de branches privées (par développeur) ou publiques (partage entre plusieurs développeurs). Ceci est orthogonal si vous utilisez un VCS centralisé ou distribué (toutefois, les DVCS encouragent les branches privées, car les branches démarrent en tant que privées jusqu'à ce que vous les publiiez).
Stephen C. Steel

6

En complément: est-ce une pratique correcte de mesurer le développement d'un projet sur la base de ses engagements?

Non, il y avait un quotidien WTF sur pourquoi c'est une idée horrible.

Ma règle générale sur la validation du code est de vérifier lorsque j'ai terminé une partie du code et qu'il est compilé. Chunk n'est pas vraiment défini. Si c'est une petite tâche, il est possible que je ne m'enregistre pas avant de l'avoir terminée. Si elle est plus grande, je pourrais vérifier après chaque partie logique est terminée.

Mais ne vérifiez jamais si cela ne compile pas. Je sais que cela semble stupide de dire à voix haute, mais je devais l'expliquer aux gens auparavant.


1
+1 pour l'avertissement de compilation. Nous avions une tirelire au bureau où tout le monde devait verser des frais chaque fois qu’il / elle commettait un acte faisant échouer une construction. Malheureusement, nous avons eu pas mal d'argent de cette façon, au moins dans un premier temps :)
Ray

@Ray - À ma dernière place, l'amende a été versée au fonds de loto. Hélas, nous n'avons jamais été riches de cette mauvaise habitude. : P
Tyanna

1

Faites un commit lorsque le code est prêt à être partagé avec d'autres utilisateurs du code - lorsqu'il est relativement stable, sûr et correctement testé.

Et non, je ne pense pas que les commits constituent un bon indicateur du développement d'un projet, car je connais des développeurs qui vont valider toutes les modifications mineures et mineures, et d'autres qui ne valideront que d'énormes changements majeurs en termes de fonctionnalité. Comment mesurez-vous quantitativement la valeur d'un engagement par rapport à un autre?


N'oubliez pas qu'avec les systèmes distribués, commit! = Share. Vous devriez pousser quand vous avez quelque chose de prêt à être partagé.
Rein Henrichs

@ Rein Henrichs: C'est un bon point, même si le contrôle de source ici au travail n'a pas cette fonctionnalité (du moins autant que je sache). Lorsque quelque chose est engagé, tous les autres membres du projet peuvent le voir et le resynchroniser (et le font généralement, parfois à l’aveuglette).
FrustratedWithFormsDesigner

Ce qui pourrait indiquer que vous pourriez bénéficier de meilleurs outils. Tout ce qui empêche les commits fréquents est un obstacle inutile.
Rein Henrichs

@ Rein Henrichs: Je ne discuterai pas de ça !!
FrustratedWithFormsDesigner

1

Dès que la tâche correspondante est terminée . Une tâche fait partie d'une histoire d'utilisateur .

Une tâche est terminée lorsque:

  • les tests unitaires correspondants ont passé,
  • le code est correctement documenté et
  • le code est engagé.

Vous pouvez avoir une définition différente de done .

Je ne vois pas l'intérêt de mesurer le nombre de commits. Cependant, si vous voyez quelqu'un travailler pendant longtemps sur la même histoire d'utilisateur (ou pire encore, d'histoires), c'est une odeur.


1

Commettez tous les changements importants qui, à votre avis, ne vont pas dans un sens. La seule chose que vous ne devriez pas commettre sont les changements de style, car ils n'incarnent pas de changement logique. Mais sinon, moins vous apporterez de changements, mieux ce sera.

Plus les commits sont petits, plus vous pouvez documenter le processus de pensée de manière détaillée, ce qui constitue l'un des aspects d'un bon journal de validation. Une bonne révision de code ne doit pas uniquement porter sur le résultat du code, mais également sur le processus de réflexion.

De plus, avoir de nombreux petits commits facilite la division en bissect, une fonctionnalité du contrôle de version trop peu utilisée, qui m'a évité de nombreuses heures de recherche de punaises des aiguilles dans les bases de code de la botte de foin.

Bisecting en bref; Découvrez un problème dans la base de code actuelle. Ensuite, choisissez un commit dans le changelog où vous êtes sûr que le problème spécifique n’existait pas. Commencez par vérifier le commit en plein milieu entre la version "bonne" et la version "mauvaise". Testez pour voir si le problème est toujours présent. Si c'est le cas, vous devez regarder plus en arrière, au milieu du «bon» et du commit précédemment testé. Si le problème a disparu, il a été introduit après cette modification spécifique. Vous devez donc vérifier le milieu entre le "mauvais" et le commit précédemment testé. Répéter. Finalement, vous vous retrouverez avec le commit qui a introduit le problème. Mais seulement si vous avez de petits commits, sinon vous saurez simplement dans quel grand tas de changements le problème a commencé à exister.

Voici comment cela fonctionne avec Git mais le principe s'applique à tout contrôle de version.


cela ne semble rien offrir de substantiel par rapport aux points soulevés et expliqués dans 10 réponses précédentes. En outre, le dernier paragraphe semble faire référence à une fonctionnalité spécifique à git alors que la question ne semble pas être relative à git
gnat

La bissection n'est pas spécifique à Git. Cela peut être fait avec n'importe quel type de contrôle de version, ce n'était qu'un exemple, car je sais que Git l'a intégré.
Jasper Kennis

-1

Quand:

  • ça construit (TOUJOURS)
  • tests unitaires réussis
  • cela fonctionne (sauf s'il est clairement indiqué comme "travail en cours")
  • les avantages liés à la sauvegarde de l'état du code sont plus lourds que ceux liés à l'exécution des tests, à la formulation d'un message de validation correct et à la résolution de tout conflit de fusion au cours du processus de validation

upvoted pour cela est notre meilleure pratique.
Jersoft
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.