Quel est le terme pour un commit de code source vraiment BIG? [fermé]


37

Parfois, lorsque nous vérifions l'historique des mises à jour d'un logiciel, nous pouvons constater qu'il y a quelques validations qui sont vraiment GRANDES - elles peuvent modifier 10 ou 20 fichiers avec des centaines de lignes de code source modifiées (delta). Je me souviens qu'il existe un terme couramment utilisé pour désigner un tel grand BIG mais je ne me souviens pas exactement de ce terme. Quelqu'un peut-il m'aider? Quel est le terme que les programmeurs utilisent habituellement pour faire référence à de tels BIGs et géants?

BTW, est-ce qu’il est bon d’engager beaucoup de changements?

MISE À JOUR: merci les gars pour la discussion inspirante! Mais je pense que "code bomb" est le terme que je recherche.


15
"Rompre commettre". :-)
Peter K.

3
Personnellement, j'appellerais un commit de cette taillecluster f...
Ramhound, le

1
Mon patron le fait tout le temps. Commentaire
concernant le

+1 pour la question parce que j'aime chaque réponse jusqu'à présent et que j'ai souffert d'avoir commis au moins un des péchés au moins une fois dans ma carrière et que je veux que les autres ne le fassent pas =)
Patrick Hughes

Je pourrais dire code avalanche!
Brian

Réponses:


50

(1) Ben Collins-Sussman : "..." code bombes ". Que faites-vous lorsque quelqu'un se présente à un projet open source avec une nouvelle fonctionnalité gigantesque qui a pris des mois à écrire? Qui a le temps de réviser des milliers de lignes de code? ... "

(2) Dan Fabulich : "La bombe de code, ou: Le débutant avec de grandes idées ... Une bombe de code est un patch qui est si grand que personne ne peut l'examiner."

(3) Google Summer of Code: instructions : "Engagez-vous tôt, engagez-vous souvent ... Ne travaillez pas toute la journée, puis insérez le tout dans une seule et même bombe de code . Au lieu de cela, chaque commit doit être autonome pour une tâche seulement. qui devrait être résumé dans le message du journal. "

(4) Jeff Atwood : "Code-bombes ... Règle n ° 30: Ne faites pas sombre . ...


lien 2 et 4 directement lien et citation lien 1. Rien ne cloche dans la diffusion du concept, mais il est un peu moins pertinent. J'aime le terme, mais il ne semble pas qu'il ait beaucoup rattrapé.
Hayem

1
Que se passe-t-il si le code validé est un nouveau code assez isolé du reste du projet? Dans ce cas, je pense qu’un seul grand commit de code (presque) fini et nettoyé est préférable à de nombreux petits commits qui obligent les utilisateurs à passer en revue (1) les corrections de bugs intermédiaires, (2) le refactoring comme le changement de nom de classe, etc. 3) le code préliminaire qui sera éventuellement supprimé. Juste mes 2 cents.
Giorgio

C'est un peu la raison pour laquelle je suis contre la réécriture / rebasage de l'histoire
dukeofgaming

@Giorgio - c'est à cela que servent les branches.
Brian

@ Brian: Oui, c'est une possibilité. Dans ce cas, vous avez un gros commit sur la branche principale lorsque vous fusionnez les fonctionnalités que vous avez développées sur la branche.
Giorgio

38

Nous appelons probablement cela un mauvais commit . :)

Mauvaise pratique

Et oui, cela serait généralement considéré comme une mauvaise pratique , car cela a les effets négatifs suivants:

  • rendant difficile la révision ,
  • il est difficile de saisir facilement et rapidement l'intention initiale du commit ,
  • il est difficile de voir en quoi l'impact sur le code est de corriger explicitement ou de résoudre un problème ,
  • il est donc difficile de savoir si la taille de la validation est due au bruit d'autres modifications éventuellement non liées (par exemple, petits nettoyages ou autres tâches).

Cas acceptables

Cependant, vous pouvez avoir des cas où des commits importants sont parfaitement acceptables . Par exemple:

  • lors de la fusion de branches ,
  • lors de l' ajout de nouvelles sources à partir d'une autre base de code non versionnée,
  • lorsque vous remplacez une fonction volumineuse sur place (vous devriez plutôt le faire dans une branche, avec des commits plus petits traitant différentes parties du changement, puis fusionner le tout pour que vous puissiez avoir une meilleure fenêtre sur le développement incrémental du fichier. les problèmes rencontrés en cours de route),
  • lors du refactoring d'une API impactant de nombreuses classes descendantes et consommateurs.

Dans la mesure du possible, préférez les types de commits «frappes chirurgicales» (et associez-les aux identifiants de tâches dans votre outil de suivi des problèmes!). Si vous avez une raison valable, allez-y.


En dehors de cela, en fait je ne sais pas et je ne pense pas avoir jamais entendu un nom spécial pour un grand commit. Un monstre-commit? Un gros-commit?

Mise à jour: La réponse de David Cary renvoie à des acteurs informatiques notables qui utilisent le terme "code-bomb" (le plus important est Collins-Sussman, créateur original de Subversion ). Comme ça (bien que jusqu'à présent je ne puisse pas dire que j'ai entendu si souvent).


11
Un engagement de Godzilla! Eeeeeeeek !!!
Péter Török le

@ PéterTörök: Je l'aime. Faisons-en une tendance. Autres options: commettre une baleine, un gargantuesque ou tout simplement un BigFatCommit.
haylem

1
Oui, "mauvais" ou "tardif". S'il n'y a pas de nom pour cela dans votre entreprise, nommez-le après le développeur en question. "Hey, nouveau mec, ne fais pas de Jerry! Engage-toi tôt et engage-toi souvent."
Chooban

Ne faites pas de Jerry, c'est une approche utile! Aussi, massive-commit peut s’approvisionner auprès de développeurs stressés qui ne croient pas ou ne comprennent pas l’utilisation du versioning. Vérifiez la connaissance!
Indépendante

Et si quelqu'un s'appelle Jerry?
Loïc Faure-Lacroix

12

BTW, est-ce qu’il est bon d’engager beaucoup de changements?

Eh bien, ce n’est pas une bonne pratique de conserver les modifications pendant longtemps et d’implémenter diverses fonctionnalités et corrections de bugs, puis de les valider, ce qui est l’un des moyens de générer un gros commit.

Cela pourrait également se produire si une refactorisation modifiait la signature d'une fonction largement utilisée et que toutes celles-ci devaient être modifiées. Ce n'est pas nécessairement mauvais et je ne voudrais pas que les développeurs s'abstiennent de nettoyer le code, de peur de franchir un certain seuil.

Donc, il ne suffit pas de regarder le nombre de fichiers impliqués dans un commit.


5
Cette. Ce qui compte vraiment, ce n'est pas le nombre de fichiers modifiés, ni le nombre de lignes modifiées, mais la portée des modifications. Si vous parvenez à décrire succinctement et avec précision l'ensemble des modifications dans un message de validation court sans omission, le nombre de modifications physiques est relativement peu important. Ce n’est pas sans importance, mais moi-même, je préférerais avoir un gros commit qui permette de construire le code plutôt qu’un ensemble de commits où seuls certains d’entre eux donnent lieu à une arborescence de code source qui sera construite (cf modification de la signature de la méthode).
un CVn

8

Le terme que j'ai entendu est "enregistrements volumineux" . Et je ne suis pas fan d'eux. J'aime les petits engagements qui garantissent que rien d'autre n'est cassé à une étape raisonnable d'un projet. Le gros engagement comporte généralement de nombreux problèmes qui se répercutent pendant un certain temps.


+1 car je ne m'en souvenais pas à l'époque (bien que je ne pense pas que ce soit un terme générique, ou que je ne le sache pas), mais j'ai entendu le mot "morceau" utilisé spécifiquement par mercurial en relation avec une extension permettant de soumettre de gros commits avec différents blocs de données, mais à part cela, je ne pense pas avoir jamais entendu ce terme pour les commits en général.
haylem

La société dans laquelle je me trouvais lorsque le développeur a utilisé ce terme utilisait SourceGear Vault.
Jesse C. Slicer

3

Je l'appelle "commettre SVN typique" ou "demain est le jour de publication"

Autant que j'aime SVN, je suis simplement choqué par le fait que je ne peux pas faire de commits locaux.

EDIT: ils ont généralement les mots "stuff" et "beer" dans le message commit.

EDIT ENCORE: engager beaucoup de changements, même s’il n’est pas forcément une mauvaise pratique, devrait être évité autant que possible. Je trouve plus facile de réviser une révision / validation qui est courte et concise. (associé à un message de validation bien écrit, voir mon édition précédente pour un mauvais exemple)



2
  • commit initial - le projet qui n'était pas sous contrôle de révision jeté dans SVN
  • refactoring - l'architecte a une idée brillante sur le changement de nom de classe de / vers la convention de nommage de Schtroumpf ou a changé la racine de la hiérarchie de paquets
  • format de code - l'architecte a décidé de modifier le retrait de code de 4 à 3 espaces ou de modifier les fins de ligne d'Unix à Windows (ou de rétablir)
  • Vendredi commit - Joe engage toujours toute sa semaine de travail le vendredi à 16h30.
  • uuups commit - Ted a, par erreur, supprimé le répertoire racine, l'a commis et maintenant, il transfère à nouveau toute la hiérarchie de fichiers dans SVN

0

Généralement, beaucoup de gens ont tendance à faire de gros commit en utilisant un VCS centralisé, en particulier le serveur impose une bonne politique de commit. C'est-à-dire que la validation doit réussir tous les tests et que ceux-ci durent plus longtemps (plus de quelques secondes). Les développeurs ne veulent donc pas attendre si longtemps avant de valider plusieurs fois et de décomposer les modifications en plusieurs petits commits.

Et les développeurs respectueux de l'environnement VCS peuvent oublier de décomposer les modifications en plusieurs petits commits. Ils se souviennent de ne s’engager que lorsqu’ils transmettent le programme à l’équipe d’AQ. Pire encore, pour éviter que les autres utilisateurs ne voient un code erroné, ils ne commettent pas avant d'avoir passé avec succès les tests QA. Enfin, ils ne se sont pas rendus compte qu'ils avaient des fichiers binaires de sortie validés, des fichiers temporaires et une sortie de l'éditeur de liens, ce qui produisait un "gros" commit.

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.