Un programmeur doit-il réparer la construction échouée de quelqu'un d'autre? [fermé]


45

Un programmeur a confié du travail au référentiel SVN, puis est rentré chez lui. Après son départ, la construction automatique de Hudson a échoué. Un autre programmeur a vu cela et, après avoir examiné les modifications du code, a détecté que le problème était l'absence d'une bibliothèque. Il a ajouté cette bibliothèque à SVN et la prochaine construction s'est terminée avec succès.

Le second programmeur a-t-il agi correctement ou aurait-il dû simplement attendre que le premier programmeur résolve le problème?


31
Question: Un membre programmeur a posé une question. Un autre membre a lu la question et a constaté des erreurs syntaxiques et grammaticales. Il a donc décidé de modifier la question et de la corriger, afin de la rendre un peu plus lisible. Est-ce que l'éditeur a bien fait ou aurait-il dû attendre que l'affiche corrige les erreurs?
Yannis

2
Quelles sont les règles de votre équipe pour cette situation?

4
@ nahab Oh, ne vous inquiétez pas, je ne dis pas que c'est un problème :). Simplement dans une communauté, comme dans une équipe, les membres qui s'entraident devraient être encouragés. De plus, je ne pense pas qu'un développeur qui casse une version soit peu professionnel, même si pour un bug mineur, ces choses arrivent au meilleur de nous.
Yannis

11
L’idée d’ avoir Hudson en premier lieu vient du fait que les humains sont des humains et qu’ils briseront la structure de temps en temps. Vous voulez juste l'attraper tôt. On pourrait faire valoir que le programmeur en question aurait dû vérifier que la construction avait été construite avant de rentrer à la maison.

14
C’est beaucoup plus facile à comprendre si vous considérez le contraire: si la construction est cassée, l’ensemble de l’équipe est ralentie (même à domicile, après les heures de travail) et vous pouvez le réparer, mais faites un choix délibéré pour des raisons de procédure. , devriez-vous être autorisé à garder votre travail?
Bill K

Réponses:


87

Cela dépend dans une certaine mesure du fonctionnement habituel de votre équipe, mais je dirais que ça va. Faire en sorte que la construction fonctionne épargne le temps aux autres.

Il est poli que le deuxième programmeur laisse tomber le premier courrier électronique pour expliquer ce qu'il a fait, juste au cas où une version spécifique de la bibliothèque serait nécessaire ou en cas de complication supplémentaire. C'est aussi une façon un peu plus subtile de faire remarquer qu'ils ont cassé la construction.


101
Il est également poli pour le premier développeur qui achète des beignets pour compenser la perte de la compilation
jk.

17
Je voudrais de la bière plutôt que des beignets.
Martin York

2
Les beignets pourraient être choquants pour les personnes intolérantes au gluten. Des cartes-cadeaux de 5 $ à Best Buy, par contre ...
Christopher Mahan Le

1
@ChristopherMahan provoquerait soit une bagarre entre tous les membres de l'équipe pour savoir qui l'obtiendrait; ou bien si un membre de l’équipe comme la distribution implicite d’une boîte à beignets dans la salle de pause est une proposition beaucoup plus coûteuse. Et dans tous les cas, une carte-cadeau Best Buy pourrait être offensante pour quiconque travaillait pour Circuit City ou CompUSA. :)
Dan Neely

1
Que pouvez-vous obtenir chez Best Buy pour moins de 5 $?
Kevin Cline

12

Ça dépend.

  • Le bogue est-il si évident que l'ajout d'une bibliothèque est le moyen de le réparer? Parfois, la solution consiste à trouver une solution de contournement pour ne pas avoir besoin de cette bibliothèque.

  • Le projet est-il dans une phase où tous les changements doivent être liés à un ticket existant? Si oui, avez-vous déposé une contravention? Ce billet vous a-t-il été attribué?

Quoi qu'il en soit, concentrez-vous sur la correction du bogue, pas sur le blâme du responsable.


9
"... pas à blâmer le responsable." Sauf si c'est une occurrence régulière.
Shawn D.

11

Oui c'est d'accord. Cependant, il est peu professionnel pour le programmeur d'origine de rentrer chez lui avant de tester si la compilation compilerait.

Votre réputation est à 100% dans votre contrôle. Ce genre de choses ternit votre réputation et il est très difficile d’en améliorer la réputation.


2
+1 pour que le premier développeur ait la responsabilité de tester la construction. Le deuxième paragraphe n'est vraiment ni vrai ni pertinent. D'autres personnes peuvent nuire à votre réputation, intentionnellement ou non, même lorsque votre comportement est totalement superficiel.
Caleb

6
Il est tout à fait possible que le programmeur d'origine ait la bibliothèque sur sa machine, mais pas la machine effectuant la construction automatique. Oui, la bibliothèque devrait être en SVN, mais cela peut être un problème très subtil à ne pas remarquer.
Mpdonadio

7

Communiquer

Il n'y a pas de règles strictes (à part les règles de votre propre équipe) pour ces scénarios.

Dev2 devrait pouvoir dire à dev1 qu'il peut réparer son erreur, aucun d'entre eux ne devrait craindre quoi que ce soit résultant de cet échange, ils font partie d'une équipe.


5

Pourquoi pas? Si votre produit est plus important que de réparer les fautes, tout va bien. Bien qu'une version échouant à cause d'un changement de bibliothèque soit assez boiteuse, vous devez réprimander le développeur pour ne pas l'avoir testée.


3

Les échecs de construction se produisent. S'il est important qu'une génération quotidienne se produise, je la corrigerais, puis demanderais au développeur qui a enregistré le code erroné de réviser le correctif le lendemain et de m'assurer que le code est maintenant tel qu'il devrait être.

Comme il a été dit, le gars qui l'a corrigé devrait probablement envoyer un courrier électronique à celui qui l'a cassé et lui expliquer en détail la solution.


2

Ma devise est de ne pas s’engager sur SVN après 15h. Ainsi, vous pourrez toujours réparer vos propres échecs de construction.

Si vous ne corrigez pas son échec de génération, la construction de tous les autres échouera également. Je le corrigerais pour gagner du temps à long terme, mais assurez-vous qu'ils sont conscients que vous deviez le réparer.

Avoir une sorte de script 'pointez le doigt du blâme' est un bon moyen de faire cela, ou faites que la personne qui casse la construction achète des beignets !!


2
Notre outil de CI dispose en fait d'une option pour envoyer un courrier électronique au développeur qui a cassé la construction (en plus du reste de l'équipe).
TMN

2

Quelqu'un a besoin de le réparer et le premier programmeur n'aurait pas dû rentrer chez lui sans d'abord s'assurer qu'il n'avait pas cassé la construction. Cependant, pour un problème aussi facile à résoudre, le rappeler pour le résoudre lui-même serait extrême.

Je suis d'accord avec la suggestion de Luke Graham d'envoyer un courrier électronique explicatif, même si je dirais que c'est plus que poli - c'est une communication de base.


Les générations d'intégration prenant parfois plus d'une heure, voire plus, en fonction de la complexité de votre système, il vous faudrait mettre en place un "seuil de validation" tous les jours pour vous assurer que la dernière version de la journée se déroulera pendant que tout le monde est toujours là. Même à ce moment-là, les gens ont des rendez-vous chez le médecin, des séances de football pour enfants, etc. Agile dit que le travail devrait être à un rythme soutenu et ne pas peser lourdement sur les travailleurs. Les garder jusqu’à 8h00 pour assister au succès d’une construction est contraire à cela.
KeithS

Kiths: Vrai. Mais j’ai trouvé que, quel que soit le moment où je pars, le moment le plus probable pour moi de casser la construction est lorsque je suis pressé: juste avant le déjeuner, juste avant une réunion, juste avant la fin de la journée. Donc, je pense que c'est une "meilleure pratique personnelle" de ne rien commettre quand il n'y a pas assez de temps pour regarder et réparer la construction après.
Daniel Pryden

2

Oui oui oui! Cela favorise la propriété collective du code et crée une sorte de pression saine des pairs dans l'équipe pour maintenir un niveau élevé de qualité et ne pas laisser un scénario de fenêtre brisée se développer. Un peu de communication pour informer l'autre développeur est une bonne idée.


2

Je pense que c'est correct de corriger des problèmes évidents - c'est-à-dire que si vous êtes à 100% sûr que le type dont vous corrigez le code corrigera de la même manière ou sensiblement la même chose. Si le correctif est plus complexe, il est généralement poli de parler à la personne dont vous corrigez le code - il se peut que vous ayez mal compris l'intention ou que le motif de la rupture ne soit pas ce que vous pensiez, ou peut-être avait-il l'intention d'un autre correctif mais pour une raison quelconque, je ne pouvais pas le commettre pour l'instant (la vie arrive, vous savez :).

En règle générale, la règle est la suivante: vous cassez la construction - vous corrigez la construction, mais il existe des exceptions, en particulier si la correction est évidente et / ou si la personne responsable est inaccessible.

Bien sûr, si vous avez le cas d'un disjoncteur de construction en série - en particulier avec le modèle "enregistré, rentré, construit pendant des jours" - la personne responsable doit s'expliquer sur les raisons pour lesquelles les systèmes et les tests de CI existent et comment vérifiez avant de vous enregistrer :)


1

Des choses arrivent. L'échec de l'ajout d'un nouveau fichier de code (qu'il soit source ou compilé) à Subversion est probablement la cause la plus courante de générations cassées, en supposant que cela fonctionne sur l'ordinateur du développeur. Lors de mon dernier emploi dans un environnement d’informatique, même les gars les plus âgés ont parfois oublié.

Je pense que si une autre personne a été capable de réparer le build et donc de laisser l'équipe fredonner, tout va bien. Je pense vraiment que le programmeur qui est rentré chez lui a besoin au moins d'un e-mail amical pour l'informer de ce qui s'est passé et pour lui rappeler de s'assurer que le nouveau code est ajouté avant la validation. Si cela arrive souvent, faites-en une infraction mineure punissable par la "danse de la honte", pour aider à réduire le nombre d'occurrences (et à alléger l'humeur).


1

Cela dépend de la dynamique de l'équipe, mais dans un monde idéal, tous les membres de l'équipe «posséderaient» l'ensemble du projet, tout le code et, par conséquent, tous les bogues conjointement. Donc, si vous trouvez un problème, vous corrigez le problème et ne communiquez avec l'auteur du bogue que si le code apporte une valeur ajoutée spécifique.


0

C'est correct de réparer à moins qu'il ne s'agisse d'un événement régulier, auquel cas je demanderais au chef de l'appeler pour le faire revenir et le réparer lui-même.


0

Ça dépend, ça dépend ...

En tant que programmeurs, notre travail consiste à faire fonctionner les choses et non à juger les gens. Je dirais donc que la meilleure chose à faire est de résoudre le problème ou, si ce n’est pas évident, annulez simplement les modifications et informez le premier programmeur afin qu’il puisse le réparer plus tard.

Quoi qu'il en soit, avoir le dernier gars qui a cassé la construction pour porter un chapeau étrange est suffisant pour payer plus d'attention la prochaine fois ^ _ ^


0

Dans certains environnements, c'est très impoli et pour de bonnes raisons. Dans d'autres environnements, c'est prévu et pour de bonnes raisons.

Dans d'autres environnements encore, c'est très grossier ou attendu pour de très mauvaises raisons.

Cela dépend en grande partie de la gravité d'une construction endommagée par rapport à une construction vérifiée correcte. Et dans une certaine mesure, cela dépend de l’évidence que le correctif était le correct correct et le seul nécessaire.


0

Premièrement, «rentrer chez moi» est un anachronisme. Les programmeurs ne vont plus chez eux - ils sont simplement en ligne ou hors ligne. Vous pouvez cingler et attendre.

Plus sérieusement, la question comporte en réalité deux parties. 'regarder à travers les changements de code' c'est bien; le repos peut ne pas être la bonne chose à faire. Et si son jugement d'une bibliothèque manquante était erroné?

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.