Dois-je enregistrer des correctifs triviaux?


28

Je suis dans une boutique de code à deux. Et même si je comprends qu'un outil de suivi des bogues est utile lorsque le nombre de programmeurs est supérieur ou égal à un, je ne suis pas convaincu que la journalisation des bogues, des modifications et des correctifs vaille la peine lorsqu'ils sont triviaux. Quand je trouve un bogue simple, je le comprends, le corrige et le lance à travers quelques tests. Et PUIS j'ai réalisé que je devais aller le connecter.

Je sais en théorie que la journalisation des bogues doit se faire quelque part entre la recherche du bogue et la correction du bogue, mais si le corriger est plus rapide que de le journaliser, cela semble être un frein. Dans les grands magasins de codes, le patron fait attention à qui fait quoi et c'est bien de savoir où les autres se moquent.

Je me retrouve à décrire des choses que j'ai déjà corrigées puis à les fermer instantanément. J'ai des doutes que quiconque reverra jamais ce bug fermé. Est-il temps de couper le gras du processus?


6
Lorsque vous trouvez un bug, notez-le sur papier. Lorsque vous corrigez le bogue, notez quels fichiers ont été modifiés. Avant de soumettre le correctif, enregistrez le bogue, puis soumettez les modifications. Si vous faites cela à chaque fois que vous aurez une habitude, vous avez actuellement une mauvaise habitude, la journalisation des bogues n'est pas une perte de temps.
Ramhound

5
Comment pouvez-vous être certain que ces bogues sont triviaux?

2
@ashansky, avez-vous même lu la deuxième phrase de ma question?
Philip

1
Ne pas enregistrer votre propre travail est un moyen sûr a) de ne pas obtenir de crédit pour cela et b) de se demander 'pourquoi X n'est pas fait et pourquoi travaillez-vous sur Y?'
Michael Durrant

1
Vous ne pouvez pas tout enregistrer, ce n'est tout simplement pas pratique. Pourquoi certaines personnes sautent-elles de haut en bas en pensant que certains comment ne pas enregistrer quelques petites choses ÉQUIVALENT de ne pas se connecter du tout ???
Darknight

Réponses:


36

Vous devez enregistrer chaque modification apportée à votre système. Il n'y a rien de mal à le consigner après l'événement - tant que vous liez le rapport de bogue au numéro de modification.

Ensuite, si quelque chose se passe mal, vous pouvez retrouver le bug et découvrir pourquoi vous avez effectué le changement que vous avez fait.

Dans la grande majorité des cas, vous avez raison et personne ne les examinera plus jamais, mais dans 1 cas sur 100, lorsque quelque chose ne va pas, ces informations seront inestimables - surtout si le problème n'apparaît que 6 mois plus tard.

MISE À JOUR

De toute évidence, si vous développez toujours une nouvelle fonctionnalité et découvrez un bogue dans une partie de la fonctionnalité que vous pensiez avoir terminée, il n'est pas nécessaire de l'enregistrer en tant que modification distincte. Dans ces cas, je le connecte à l'élément demandant la fonctionnalité principale.

Une fois le système avec la fonction a été transmise à l' assurance qualité ou le client, alors il est nécessaire de faire ce que je décrit plus haut.


Au cours de la première phase de développement, avant de publier une première version hors de l'équipe d'ingénierie, il n'est pas nécessaire de consigner les modifications dans le suivi des bogues. Les modifications seront cependant notées dans les journaux de contrôle de version pour chaque soumission.
uɐɪ

@Ian C'est vrai, mais généralement au cours du développement précoce (en supposant que vous voulez réellement développer et non pas un prototypage exploratoire ou quelque chose du genre), vous travaillerez généralement contre un ensemble de fonctionnalités d'une certaine sorte. Dans ce cas, chaque modification doit être liée aux fonctionnalités qu'elle prend en charge. Des corrections de bugs mineurs sur la ligne vers une fonctionnalité "terminée" pourraient toujours être liées pour indiquer la prise en charge de cet élément. Attention, cela dépend de la façon dont vous suivez les fonctionnalités et les spécifications.
CodexArcanum

1
@Darknight - ce n'est pas facile! Cela est aidé par le fait que nous utilisons TFS et que nous l'avons configuré pour ne pas autoriser les connexions qui n'ont pas d'élément de travail associé. Oui, vous pouvez outrepasser la règle, mais elle s'arrête et vous fait réfléchir à ce que vous faites.
ChrisF

1
@Darknight Désolé, mais ces chiffres ne veulent rien dire. Le dire ne le rend pas vrai; même si vous pouviez valider tout cela, alors quoi? La seule conclusion que je peux tirer de votre présentation de ces chiffres est d'essayer de vous positionner d'une manière ou d'une autre au-dessus des autres d'une manière qui, très franchement, semble futile, inutile et à la limite grossière / offensive.
casperOne

3
@Tous S'il vous plaît, prenez cette discussion pour discuter.
maple_shaft

14

Si vous utilisez un outil de contrôle de source, vous pouvez décrire le bogue que vous avez corrigé dans la description de la validation et qui est généralement une documentation suffisante pour des corrections de bogues super-petites et triviales.

De plus, si vous utilisez un outil de suivi des bogues / fonctionnalités entièrement intégré à votre contrôle de source et à vos référentiels, comme FogBugz et Kiln , vous pourrez utiliser l'outil de recherche globale pour trouver ces corrections de bogues et voir quelles modifications de code vous avez apportées facilement.

De plus, vous pouvez attribuer une révision de code à votre partenaire de programmation afin qu'il puisse revoir la correction insignifiante que vous avez apportée, mais je m'éloigne du sujet ...


1
Ouais, je fais ça. Bien que parfois je me retrouve à réparer des choses dans une branche et à les regrouper dans d'autres commits.
Philip


@matthieu Attendez, Jira s'intègre à SVN? Mon Dieu, pourquoi ne faisons-nous pas cela? On dirait qu'il y a quelques plug-ins.
Philip

5

D'un point de vue métrique, cela peut tout de même être utile.

Ces informations pourraient être utilisées pour montrer au patron un certain nombre de choses:

  • nous avons besoin de plus de développeurs
  • quelque chose d'autre dans le processus est cassé (pourquoi tant de bogues? l'autre type génère-t-il la plupart des bogues), montrant peut-être que vous avez trop de bogues. Peut-être qu'il y a quelque chose qui cause ça? sortez-vous trop tôt? fait-on suffisamment de tests?
  • une bonne liste de ce que vous avez travaillé sur l'heure du bonus.

Cela étant dit, cela dépend de la taille d'un bug dont vous parlez. Par exemple, un des doublons que vous avez détecté lors de l'ajout de nouveau code serait probablement inutile.


2

J'essaie de consigner chaque modification que j'effectue, quelle que soit sa taille. Vous ne savez jamais quand vous, ou quelqu'un d'autre (futur ou présent), devrez revenir en arrière et voir si ce changement est la cause possible d'autre chose.


1

Le suivi est important, mais envisagez également un autre scénario: le moment venu pour votre examen. Cela se produira formellement en personne ou de manière informelle sans que vous y soyez via votre patron qui récupère les rapports du traqueur de bogues.

Considérez-les comme des «gadgets» qui finissent par augmenter vos chiffres. Après tout, ce sont des bogues que vous avez corrigés, et vous devriez être reconnu pour les corriger, même si ce sont des correctifs triviaux.

Enregistrez-les.


Oui, dans les grands magasins de code, le patron a des "métriques" basées sur cela, donc c'est un bon conseil général. Cela conduit également les gens à abuser du bug-tracker et à jeter ces métriques dans un enfer sans signification. Mais ici, c'est juste moi et l'autre gars. Le patron n'utilise pas le traqueur de bogues.
Philip

1

Pour répondre à cela, cela dépend vraiment où vous en êtes dans le processus.

Ceux-ci peuvent s'appliquer à un nouveau projet ou à un nouvel ensemble de fonctionnalités en cours de conception.

Conception initiale Si vous trouvez des bogues sur le code que nous avons créé lors de la conception initiale, la création d'une piste de bogues ne serait pas nécessaire. Je suggérerais un commit séparé pour le changement afin que vous puissiez facilement le dérouler si vous trouvez un problème plus tard.

Essai

Le code est généralement considéré comme imature pendant les tests unitaires, donc à moins qu'il ne soit effectué par un groupe différent, je dirais non. Si les tests unitaires sont effectués par un groupe différent d'un traqueur de bogues, c'est un bon moyen de formaliser la procédure de test.

Les tests CSCI dépendent. Est-ce fait par un autre groupe? Si oui, alors oui (voir ci-dessus). Est-ce la dernière étape des tests avant la sortie? Alors oui, car à ce stade, votre logiciel doit être considéré comme mature. Si vous êtes intéressé par les mesures, il serait également bon de commencer à suivre les bogues à ce stade.

Pour tout niveau de test supérieur, vous devez utiliser le suivi des bogues. À ce stade, votre logiciel doit être considéré comme mature et le suivi des bogues est important.

Libération

Vous devez toujours suivre les bogues sur le code publié. C'est important pour la reddition de comptes.

La rationalisation d'un processus pour répondre à vos besoins est également importante. Avez-vous vraiment besoin d'un énorme système de suivi des bogues? Tous les domaines sont-ils vraiment importants pour une équipe de 2 personnes?


1

Est-il possible que quelqu'un d'autre puisse rencontrer le bogue, peut-être dans une ancienne version du logiciel qui a été publiée dans le monde extérieur? Si c'est le cas, la journalisation du bogue et du correctif peut être utile.

D'autres ont suggéré que s'il fallait plus de temps pour enregistrer le bogue que pour le corriger, cela ne valait pas la peine d'être enregistré. Je suggère que l'intervalle de temps pertinent ne se situe pas entre la recherche du bogue et sa correction, c'est entre le moment où le bogue a été introduit et le moment où le correctif est publié.

Si l'historique des modifications et des versions indique que le bogue n'a jamais vu le jour, la consignation du correctif lorsque vous le vérifiez dans le contrôle de code source devrait suffire.

C'est assez proche de cette question , mais je ne suis pas sûr que ce soit un doublon, car celui-ci se concentre sur des correctifs triviaux .


1

Pourquoi vous ne devriez pas suivre les bogues, par Jon Arid Torresdal - corrigez -les à la place.

  1. Pendant le développement: vous rencontrez un bogue pour une fonctionnalité; vous ajoutez un scénario de test qui rompt la construction , puis archivez le correctif par rapport à la fonctionnalité.

  2. Après la sortie: documentez le comportement . Si vous prévoyez de publier une mise à jour, passez à 1. Si vous n'êtes pas en charge de cette version, gardez le test + correctif caché dans une branche privée.

Une fois le code publié, il peut y avoir d'autres priorités, et bien que la correction du bogue puisse être triviale, la distribution du correctif peut ne pas être économique en soi, sauf si vous effectuez un déploiement continu.


-6

Cela dépend de la banalité, j'utilise cette mesure:

S'il faut plus de temps pour l'enregistrer que pour le réparer , cela ne vaut pas la peine de l' enregistrer.


3
Ce n'est pas parce que la journalisation prend plus de temps que la réparation que cela suffit. Ha! celui-ci avait une explication :)
uɐɪ

2
Je n'ai pas dévalorisé cela, mais si je devais deviner pourquoi quelqu'un l'a fait, c'est parce qu'ils croient en la consignation de toutes les corrections de bogues, ou qu'ils pensent que votre réponse n'était pas très utile / perspicace.
CFL_Jeff

3
Je ne vais pas voter contre, mais je ne suis pas d'accord avec cela en règle générale (bien que dans la plupart des cas, je peux voir que cela a du sens!). Et si vous aviez une erreur "off by one" qui avait été expédiée, mais que vous avez glissé à travers le réseau d'assurance qualité? Il faut plus de temps pour se connecter que pour réparer ....
PhillC

2
S'il n'est pas connecté, il ne peut pas être vérifié comme fixé par QA
17 du 26

3
-1 C'est juste l'arrogance du programmeur (' Je ne fais pas d'erreurs') et l'ignorance (je n'ai rien vu de mal arriver avec des corrections mineures). Un crash et une gravure vraiment très bons à partir d'une correction `` mineure '' aident généralement à cela (également connu sous le nom d'expérience).
Michael Durrant
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.