Quand faut-il commettre du code?

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?

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.

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é.

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.

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.

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.

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.

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.

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?

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.

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.

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