Un collègue a renommé toutes mes requêtes [fermé]

Je ne sais pas si je devrais être très irrité ou quoi. À lui seul, j'ai construit plus de 300 requêtes pour une base de données volumineuse et développé une convention de nommage afin de pouvoir les retrouver plus tard. Personne dans mon bureau ne sait même comment créer une requête, mais je suis arrivé hier pour constater que toutes avaient été renommées. J'ai maintenant beaucoup de mal à trouver des choses et j'essaie de savoir quoi faire.

J'ai parlé avec la personne responsable, et elle a tout minimisé. Elle a dit qu'elle les a renommés afin qu'elle puisse les trouver plus facilement. Malheureusement, je suis la seule à savoir comment la construire, la modifier et la maintenir, et la seule raison pour laquelle elle avait besoin de les trouver était de tester les requêtes. La nouvelle convention de nommage n’a aucun sens, et j’ai le sentiment que nous avons fait un pas en arrière dans le processus de développement.

Ce que j'essaie de comprendre c'est:

1) Est-ce que je réagis de manière excessive?

2) Quelle est la meilleure façon de gérer cela? Je n'aime pas en parler à mon patron, mais après avoir parlé avec ma collègue hier, je peux déjà dire qu'elle a l'impression qu'elle n'a rien fait de mal.

1. Pas vraiment - c'est une chose incroyablement irrespectueuse à faire.

2. Vous lui avez parlé et nous ne l'avons pas encore fait, mais il semble que vous ayez le droit de restaurer les conventions de dénomination précédentes à partir d'une sauvegarde ou de les rétablir si elles se trouvent dans un contrôle de source. FAITES-EN AVALER votre patron et votre collègue si vous le faites et donnez votre raison (vous ne pouvez pas maintenir votre propre travail).

La dernière chose que vous souhaitiez, c'est d'entrer dans un va-et-vient à ce sujet, alors gérez-la à mesure que la situation semble régner, mais vous devriez au moins la documenter au cas où cela ferait partie d'un modèle de manque de respect.

Pourquoi ne pas simplement le traiter comme des adultes: asseyez-vous, sans confrontation, et dressez une liste de pour et de contre pour un schéma de nommage, acceptez-le et rendez-le officiel en rédigeant un court document le décrivant. Suscitez un intérêt sincère pour sa contribution afin qu'elle se sente (et soit) impliquée

Si c'est principalement une question de goût et si elle est le genre de personne qui doit absolument faire les choses à sa manière, alors soyez heureux que vous soyez la personne la plus grosse et laissez tomber. La vie est trop courte pour avoir un concours de noms énervant.

Le problème est-il le schéma de nommage ou celui que vous estimez ne pas être respecté? Si oui, vous pouvez peut-être travailler sur votre relation de travail. Si vous pensez que cela n'en vaut pas la peine, pourquoi vous souciez-vous de ce qu'elle pense de toute façon? :) Une autre option pourrait être qu’elle ne pense pas vraiment que c’est un gros problème et si vous expliquez gentiment que vous avez du mal à trouver des choses, vous pourrez peut-être les modifier.

1. La conception de la base de données comprend des autorisations (GRANT et REVOKE).
2. Le test comprend les autorisations de test.
3. Relativement peu de personnes devraient être autorisées à renommer des objets de base de données.
4. Votre collègue n'est pas l'un des rares.

"La nouvelle convention d'appellation n'a pas de sens du tout" sonne comme cela pourrait être le cas:

1. Elle leur a appliqué une norme de la compagnie. Celles-ci sont souvent utilisées pour s'assurer que le code est au moins cohérent et, dans le meilleur des cas, peuvent aider des périphériques, comme de petits scripts personnalisés, à trouver facilement du code. Dans ce cas, vous devez comprendre la norme et pourquoi elle "n’a pas de sens" dans votre situation. Si vous pensez toujours qu'il est préférable que tous les développeurs la laissent telle quelle, expliquez-leur pourquoi votre méthode est supérieure et demandez-lui si vous pouvez changer la norme (probablement d'accord s'ils sont d'accord sur cette supériorité) ou renoncez à votre cas. (peu probable et désordonné à long terme).
2. Elle a inventé sa propre norme sur place et l'a appliquée. C'est plus probable si elle est nouvelle et elle devrait expliquer sa raison. Vous pourriez apprendre quelque chose et / ou elle pourrait apprendre quelque chose si vous expliquez ensuite votre raisonnement.

Un point important est que ce n'est pas votre code (singulier), s'il appartient à quelque chose et sera modifié par tout le groupe. Aucune critique sur le code ne devrait jamais être centrée sur qui l'a écrit.

J'ai parlé avec la personne responsable, et elle a tout minimisé.

Ensuite, je vais vous dire, sans vergogne:

Annulez les modifications.

Salaire cette guerre. Votre responsable doit vous soutenir et renforcer votre autorité.

1) Non, vous ne réagissez pas trop. Quelqu'un a modifié votre travail sans vous en informer et l'a effacé lorsque vous leur avez demandé pourquoi. C'est extrêmement irrespectueux et grossier à mon humble avis.

2) Êtes-vous le DBA officiel, ou au moins la personne qui a été nommée gardien de la DB? Si tel est le cas, modifiez les noms et rédigez un document sur les conventions décrivant la procédure. En outre, rédigez un document de style "Guide de l'utilisateur" afin que, si quelqu'un doit accéder à la base de données et trouver quelque chose qu'il peut.

J'enverrais ceci au groupe, sans pointer du doigt, avec une note utile disant que vous seriez heureux de vous asseoir et de guider les gens à travers certaines des nuances de la structure.

Sinon, organisez des conventions en équipe et suivez-les en équipe.

Sur une note de côté, pour quelqu'un qui a dû tester quelque chose pour changer les noms de plus de 300 requêtes semble assez enfantin. Combien de temps a-t-elle perdu à faire cela, et seulement pour pouvoir trouver des choses? Au lieu d'aller simplement demander de l'aide à quelqu'un, elle a perdu son temps, votre temps et celui de l'entreprise. Sans parler du code probablement cassé quand elle l'a fait, perdant ainsi du temps à un autre membre de l'équipe.

Si j'étais vous, j'attendrais que vous vous calmiez un peu, essayez de lui parler à nouveau. Si cela ne fonctionne pas, prenez-le avec le patron. Ce genre de mentalité de cow-boy mettra éventuellement toute l'équipe dans une situation difficile.

Si vous renommez au hasard dans la base de données, un environnement de production risque de s’effondrer. Si ces procédures étaient référencées quelque part dans le code, cela pourrait avoir des conséquences graves. Vous pouvez effectuer des restaurations, mais si un testeur comme celui-ci ne sait vraiment pas ce qu'il fait, il n’est pas si difficile de voir le testeur apporter des modifications à la production. Cela pourrait signifier une perte d'activité. C'est pourquoi vous devez essayer d'implémenter des rôles d'utilisateur distincts pour les développeurs et les testeurs. Nous le faisons avec nos testeurs et cela fonctionne très bien. Les testeurs l’apprécient souvent, car ils n’ont pas à vivre dans la crainte de foirer des données en direct.

Cela ne semble pas être abordé ailleurs, mais toute source (par exemple, une requête) placée dans un lieu public devrait se trouver sous un système de contrôle de version.

Ensuite, si un collègue modifie votre schéma de dénomination, vous pouvez facilement revenir à votre schéma de travail (et voir leurs modifications; et éventuellement revenir si nécessaire). Vous associez également les modifications à des utilisateurs spécifiques afin de voir qui a tout gâché.

Ne regardez pas un cheval de cadeau dans la bouche.

Premièrement, la propriété collective du code - ils ne devraient pas être "à vous".

Deuxièmement, s’ils les ont renommés, demandez le raisonnement autour du nouveau schéma de nommage. Soit ils utilisent les requêtes - dans ce cas, c'est en quelque sorte leur appel; ou bien c'est une première étape pour qu'ils commencent à vous aider à les maintenir.

Si tout le monde pense qu'ils sont 'à vous', vous ne les éliminerez jamais et vous passerez à quelque chose de nouveau.a

Je ne sais pas si cela a été demandé, mais quelle convention de nommage est la version officielle? Si votre version est officielle, je dirai alors que vous devez aborder la question du point de vue. Ainsi, au lieu de dire "La personne X a annulé toutes mes modifications", dites simplement "La personne X a apporté des modifications contraires aux conventions de dénomination officielles". S'il n'y a pas de convention officielle, je lui suggère de lui faire savoir que vous n'apprécierez pas les changements apportés sans vous consulter au préalable.

Dans les deux cas, je pense que mener une "guerre" n'est pas la solution. Même si vous gagnez, vous perdez.

C'est un comportement épouvantable. On dirait qu'elle ne regrette rien, alors parlez-en à votre patron et demandez à ce que son accès soit révoqué jusqu'à ce qu'elle puisse être convaincue de ne pas perdre son temps.

Si votre patron n'est pas technique, expliquez-le dans des termes qu'il comprendra. Imaginez que vous commenciez à travailler dans une salle de courrier, où le courrier est trié dans des casiers prêts à être livrés. Vous décidez unilatéralement de trier les casiers par étage puis par nom de famille au lieu du système actuel de département puis par étage. Cela pourrait vous rendre la vie plus facile à court terme, mais vous seriez assassiné par les autres membres du personnel des postes.

C'est plus impoli. Je serais furieux.

Outre la définition d'autorisations pour empêcher les personnes aléatoires de les modifier, vous devez également expliquer, car son travail consiste à tester les fonctionnalités. Vous ne pouvez en aucun cas garantir la fiabilité si des personnes aléatoires apportent des modifications au code.

Comme tout le monde l’a dit, elle n’aurait pas dû le faire, ne serait-ce que par respect pour vous, puisque vous êtes la créatrice responsable de ces requêtes.

Cela dit, je ne vois personne dire que si elle a renommé vos requêtes en premier lieu, c'est parce qu'elle ne pouvait pas donner de sens à votre convention d'appellation.
Ainsi, le problème pourrait facilement être résolu en documentant votre convention de nommage et en veillant à ce que vos collègues aient accès au document et puissent trouver ce dont ils ont besoin.

Vous devez également faire attention et prendre en compte la manière dont les autres personnes trouveront et utiliseront vos requêtes: si votre convention de nommage ne leur permet pas de faire leur travail efficacement, vous devrez probablement conserver une liste plus complète de vos requêtes, en utilisant peut-être balises et mots-clés convenus pour que les autres puissent trouver ce qu'ils recherchent.

Je pense que la clé ici est que personne ne travaille isolément et que le meilleur moyen d'éviter de se marcher sur les pieds est de communiquer et de s'entendre sur des règles de base communes.

Je répondrais de la même manière - minimisant votre décision de tout revenir en arrière. Annulez simplement ses modifications et envoyez un e-mail très court à vos collègues:

"Révéler le changement rXXXX pour l'instant, parce que je ne comprenais pas que c'était la convention de nommage. Merci d'avoir essayé. :)"

Oui, vous réagissez de manière excessive.

Il y a quelque chose appelé contrôle de version qui, entre autres choses, est utilisé pour ne pas avoir à battre les collègues sur vos collègues. Revenez simplement à la version précédente et verrouillez le fichier, lui permettant ainsi de gérer sa colère. Cela vous donnera l’opportunité d’expliquer que modifier radicalement un code qui repose sur le contenu de quelqu'un d’autre sans motif valable et sans demander d’abord n’est pas simplement faux, extrêmement irréalisable et pratiquement un péché.

Bien entendu, cela suppose que votre convention de nommage soit meilleure que la sienne et que vous pouvez réellement sauvegarder cette décision avec des arguments objectifs solides. Si ce n’est pas le cas, il est plus sage de commencer à modifier votre code dès que vous pouvez gérer les modifications et. essayez de trouver une meilleure convention d'appellation la prochaine fois.

Ne le prenez pas pour votre patron, la façon mûre de le résoudre est directement avec votre collègue, vous devrez travailler avec elle après cela, donc il est stupide de nuire à la relation pour une querelle facilement résolvable.