Nous avons tous été là. Vous avez écrit du code et des tests unitaires, les tests Tous réussissent et le code est décent (rien n'est parfait, non?). Ensuite, quelqu'un qui est sûr qu'ils savent mieux que vous ne venez et décide de changer votre code ou vos interfaces à votre code simplement parce qu'il / elle n'aime pas les noms de variable / classe que vous avez utilisés. Pas de refactorings «réels», aucune optimisation réelle, aucune amélioration réelle - juste des mots différents - pas nécessairement de meilleurs mots, juste différents.
Mon vrai problème avec c'est que (a) sa perte de temps et (b) il montre un manque de respect flagrant pour le développeur qui a écrit le code en premier lieu.
Ma réponse viscérale est de cailler, mais c'est contre-productif. Au lieu de cela, je risquez que je puisse voyager un paragraphe ou deux comme une sorte de "charte" ou "philosophie" qui est adopté pour le projet. Je me demande si quelqu'un d'autre a essayé cela, et si oui, était-ce réussi?
Après avoir examiné les premiers commentaires ci-dessous (qui sont appréciés), je pense que mon problème est principalement que ce changement a cassé la construction du code qui travaillait déjà. Donc, le temps nécessaire pour être dépensé pour résoudre le code de ce qui était (à mon avis) un changement non à valeur ajoutée.
- merci
11 Réponses :
Une chose qui pourrait aider dans ce type de situation est d'exiger des critiques de code pour tous les changements. Les gens sont moins susceptibles de faire des changements inutiles si quelqu'un d'autre doit l'examiner en premier. S'ils peuvent réellement convaincre un autre développeur que leur changement devrait aller alors peut-être que ce n'est pas aussi inutile après tout.
Il est également possible qu'un examen de code ait pu montrer que la nommage originale ou le code d'origine avait des problèmes ...
Je soupçonne que de payer plus d'attention aux revues de codes et à l'ouverture de ces discussions au groupe fera probablement le plus de bons - ThX.
Et le code d'origine de l'OP aurait dû être revu aussi bien ...
@Tim oui, définitivement. Quand j'ai dit "changements", je ne voulais pas simplement dire des modifications au code existant, mais plutôt tous commettre. (Retour quand j'ai écrit que j'ai utilisé beaucoup de perforce et quels appels git appels "commet" cela appelle "changements".)
Parfois, la modification des noms peut être justifiée. Cela peut être déroutant si la moitié du projet fait référence à la sexe d'une personne, puis vous enregistrez un nouveau code qui fait référence à sexe ou quelque chose. D'accord, cela pourrait être un mauvais exemple comme techniquement, ils sont deux choses différentes et leur signification est probablement toujours évidente. Mais si le code d'un projet utilise deux termes différents pour faire référence au même concept, cela peut être déroutant.
Habituellement, j'essaie de laisser le code des gens seuls, à moins que je n'ai qu'une justification de refactoring. Heureusement, la même chose semble aller pour mes collègues, donc non, je n'ai pas encore eu besoin d'écrire une telle charte.
... décide de changer votre code ou le interfaces à votre code juste parce que il / elle n'aime pas le noms variables / de classe que vous avez utilisés.
Mon vrai problème avec c'est que (a) c'est une perte de temps et (b) il montre un manque de respect flagrant pour le gars développeur qui a écrit le code dans le première place.
ma réponse viscérale est de caresser ...
Je vois des questions très concernant des choses dans ces déclarations.
- Naming est vraiment, vraiment important. Il vaut la peine de réécrire le code pour l'obtenir correct.
- Ce n'est pas votre code
- Comment est-ce irrespectueux?
Vous le prenez trop personnellement.
J'ai travaillé une fois avec quelqu'un qui a paniqué lorsque j'ai apporté des modifications à "son" code. Son code comme horrible; C'était buggy et immunitaire. Il restait toujours tard, combattre les incendies et briser des choses - essentiellement un contributeur négatif. J'ai réécrit tout son mauvais code pour un grand morceau de fonctionnalité pour un projet un week-end et lorsqu'il est revenu lundi, il y avait un ajustement Hissy. Je ne dis pas que vos affaires sont horribles, mais vous devez peut-être vous calmer et être plus objectif à ce sujet.
Ne le prenez pas si personnellement. Reculez-vous et réfléchissez-y - peut-être que "votre" code nécessaire nécessaire à la fixation
Nous pourrions être en mesure de donner de meilleures réponses si vous avez posté le code et les modifications, ou au moins une meilleure idée de la situation avec un exemple ou deux.
EDIT: Après avoir vu le changement de code et découvrir que la construction était cassée, je vais devoir changer le ton de cette réponse. Je comprends la frustration de Steve - et je suis d'accord - ce n'est pas un bon changement. Il rend un typdef spécifique plus général et pas très descriptif plus.
Pendant que je pense que certains de mes points sont valables, dans ce cas, on dirait que les modifications n'étaient pas appropriées.
La question du code "propriété" n'est pas pertinente. Si les changements de code sont inutiles, tout le monde de l'équipe ne devrait pas être heureux. S'ils sont de bons changements, tout le monde devrait être heureux à ce sujet. S'il y a une différence d'opinion, vous devez tous trouver un terrain d'entente.
Briser la construction n'est pas une bonne chose.
Steve, désolé si je suis descendu dur - on dirait dans ce cas, vous êtes justifié de votre frustration, mais pas parce que c'est "votre" code.
Euh, il est irrespectueux de changer de code d'erreur sans leur parler d'abord sur les changements et expliquant les problèmes avec leur code. En allant de l'avant et de déversement sur leur code est un moyen sûr de pisser quelqu'un à partir de ... comment d'autrien que quelqu'un est censé aller mieux?
Euh, enfin, j'ai vérifié, le code était mon employeur, pas le mien ou mes collègues. Je ne sais pas ce que signifie "déversement sur leur code". Cela aiderait si nous avons eu de réelles informations sur les changements, mais pour l'instant, c'est la spéculation. Mais je supporte mon affirmation que cela ne devrait pas être pris personnellement et certains des commentaires de l'OP me font peur. J'aurais un problème sérieux s'il se rapporte à moi ou dans mon groupe.
+1. Ce n'est pas votre code . C'est du travail pour la location. Si c'était votre code, personne d'autre ne serait capable d'y arriver.
D'accord, j'ai pris les changements personnellement. Je n'ai pas senti qu'ils ont ajouté une valeur et ils ont cassé la construction. Si la personne qui a fait les modifications avait été suivie et s'assurait qu'il avait corrigé tout le code et qu'il avait brisé (voir l'addition ci-dessus pour le changement) et réexécuter les tests, je ne pense pas que ce serait m'ont irrité presque autant.
Accepter avec Tim et Jon. Si le code pourrait être meilleur, il devrait être corrigé. Mais voici deux points: 1) Vous réparez quelqu'un d'autre, ce qui signifie qu'il se trompe. S'il accepte cela, donc pas de problème. Mais s'il pense que tout va bien, vous pouvez simplement réparer ce code sans discuter de votre correctif. En petites personnes n'aiment pas qu'ils sont réparées. 2) Votre correctif doit mieux rendre le code, ce qui signifie que vous devriez en parler au moins avec le code auteur.
Fabriquer une modification de non-fonction, le changement de code que renommé est une chose - il est impossible de dire sans précision, que ce soit une bonne ou une bonne chose. Faire un changement de nommer uniquement et ne pas déranger de voir s'ils ont cassé quoi que ce soit est un peu effrayant. Si vous êtes inquiet de la qualité du code, vous ne seriez-vous pas au moins exécuté les tests? BTW, je sens que le nom original était meilleur - il explique le but de la variable plutôt que du type.
@Steve, s'il cassait la construction qui n'est pas une bonne chose, mais c'est un problème différent de changer "votre" code. C'est non pertinent. Briser la construction est une autre affaire.
Je suis d'accord avec Laurence que les critiques de code peuvent aider. C'est un problème de la façon dont votre équipe devrait travailler ensemble. Ce qui pourrait aider est la notion de programmation Egoless - en un mot Code comme produit conjoint de l'équipe et tente de prendre des décisions pour le Code plutôt que de l'ego du programmeur. Votre coéquipier a violé le Quatrième commandement de la programmation d'Egoless - "Ne pas réécrire le code sans consultation." Peut-être que si votre équipe est informée de ces principes, les choses vont s'améliorer. Je voudrais essayer cela.
Dans toute équipe de développement de logiciels avec une taille> 1, la normalisation est la clé. Non seulement pour chaque développeur de comprendre le code de l'autre, mais de sorte que les personnes qui arrivent en 2 ans, 5 ans et 10 ans peuvent regarder n'importe quelle partie du code et voir un modèle clair et cohérent. Voulez-vous ... et le reste de l'équipe ... Sérieusement encore, travaillez-vous sur ce projet, des années au long de la ligne?
Si vous «avez simplement votre façon de faire des choses» et qu'il n'y a pas de norme officielle pour le projet / entreprise, je vous suggère de travailler avec l'équipe et / ou de votre patron pour suggérer une norme formelle être adoptée. De nombreuses normes sont déjà publiées pour les différents environnements que vous pouvez utiliser comme standard ou comme point de départ.
S'il existe une norme formelle, tout le monde de l'équipe est obligé de le suivre ... peu importe la quantité "meilleure" qu'ils pensent que leur chemin est.
tant pour les compétences difficiles.
Maintenant sur le côté des compétences douces ...
Vous et votre collègue doivent développer une relation saine ou décider de travailler à différents endroits. Tit-for-tats qui aboutissent à des personnes qui ont des sentiments qu'ils veulent cacher feront tout le monde malheureux, sans parler de manière gravement compromise le projet que tout le monde est payé pour compléter. Recherchez une personne que vous respectez à vous deux (peut-être de votre patron, peut-être un membre senior respecté et à la tête de niveau de l'équipe, peut-être que HR si vous avez un bon département des ressources humaines). Expliquez à cette personne quel est le problème et que cela vous fait sentir non évalué et ignoré. Demandez de l'aide pour parler de la situation avec votre collègue et d'accepter une meilleure façon de travailler ensemble.
Enfin, vous devez être ouvert à la possibilité que votre collègue puisse faire des changements sensiblement corrects, même si la manière dont il le fait en vous offense. Séparez le codage correct des interactions interpersonnelles correctes. Faire la bonne chose pour le projet.
Je suis d'accord avec tout ce que vous avez dit avec la réserve qu'elle s'applique aux équipes de taille = 1 aussi.
Bon point. Je stimule certainement mon propre travail individuel autant que possible et construit une bibliothèque de code réutilisable bien structurée, à la suite d'un modèle de conception constant. Alors oui, une bonne idée d'une équipe d'un aussi. Néanmoins, si ce n'est qu'un gars, il sait ce qu'il pensait (parfois), alors je suppose que vous peut réussir sans standardiser votre propre travail. Vous Certainement rendez-vous beaucoup plus facile sur vous-même si vous le faites.
heey,
gars! Nous devons tous Assieds-toi décider ensemble !
Ne vous laissez pas simplement à Stackoverflow ou à un forum et dites poser ce type de questions.
Le nouveau dev fait-il - il reçoit des réponses de la communauté probablement positive ( ouais, le code Bad doit être refactore ). et le résultat est: environnement contre-productif, destructeur et offensant pendant une longue période.
Qui le veut?
juste mettre vos arguments sur la table et c'est ça. Ceci devrait être travail collaboratif et ne pas énerver les uns des autres.
décider ensemble, parlez, comme l'équipe .
et ... mieux poser des questions comme "Comment va-t-il mieux refroidir cela?"
acclamations.
Le device actuel fait-il - il reçoit également des réponses de la communauté: " quel idiot pourrait faire un tel type de changements! " ""
Le nouveau dev a besoin d'une introduction aussi.
Old Dev doit aussi être répertorié.
+1: Plus succinctement - N'essayez pas d'utiliser Stackoverflow comme levier pour obtenir votre propre chemin dans le désaccord de projet!
Que diriez-vous d'utiliser un système de construction automatisé, de sorte que cette personne change le code et enfreint quelque chose que l'équipe obtiendra une alerte à ce sujet. Cela résout votre problème avec avoir à perdre votre temps à réparer quelque chose de brisé par une autre chose changeant à votre code. De cette façon, tout le monde saura cela et ainsi fait un changement et cassé la construction, et peut voir pour eux-mêmes. La règle est "ne casse pas la construction".
Et la prochaine fois que ce type vous attendra pour casser la construction et utiliser une "réponse à tous" sur le courrier électronique.
Un courriel de construction automatisé? Les courriels ne peuvent généralement pas être répondu à. Evenso vous brisez la construction à un moment futur et que leur réponse ne sont pas pertinentes. Votre préoccupation qu'il "répondrait à tous" montre que votre problème n'a rien à voir avec le code du tout - le code n'est qu'un champ de bataille sur lequel vous mangez une guerre.
Vous devriez discuter de cela avec la personne qui l'a fait, de manière non menaçante.
Eh bien, si ce gars va maintenir votre code, laissez-le faire ce qu'il veut. N'oubliez pas que ce n'est pas "ton" code. Le code appartient à la société pour laquelle vous travaillez. Vous avez écrit le code et vous avez été payé pour cela. Laissez la direction faire ce qu'ils veulent faire avec cela.
Ne prenez pas les choses personnellement, passez à autre chose.
Je crois que chaque développeur devrait prendre la responsabilité et, partant, posséder une partie du code, mais pas tout le code. Je comprends le code que j'ai écrit mieux (quel que soit le bien / mauvais c'est) que tout autre gars qui l'a jamais vu. Par conséquent, les modifications que je fais seront plus rapides et moins sujettes aux erreurs.
Cela ne me dérange pas de changer le code que j'ai écrit plus tard, mais j'ai quelques conditions:
Tous les développeurs ne devraient pas modifier tout le code, tout le temps. Seulement une partie du temps, dans le but d'apprendre à connaître le code (partage des connaissances).
Je n'ai jamais travaillé pour un employeur qui approuve un "Tout le monde peut changer quelque chose à tout moment". Les développeurs possèdent certaines parties du code et ils sont invités spécifiquement à apporter des modifications / refacteurs sur la base d'une démocratie en développement.
Vous touchez mon code et enfreignez quelque chose, (1) Vous feriez mieux d'avoir une bonne raison pour que tous les développeurs sont d'accord avec tous les développeurs et (2) que vous feriez mieux de ne pas laisser de choses cassées cassées ou de me demander d'aller faire le nettoyage pour vous sauf si vous êtes mon supérieur. Je soumets humblement si c'est le cas.
Peut-être pas complètement sur le sujet, mais ... Si vous avez des développeurs qui ont le temps de modifier le code simplement parce qu'ils n'aiment pas les noms de variable utilisés, peut-être que la conversation devrait peut-être s'agir de savoir si vous avez trop De nombreux développeurs et lesquels doivent être montrés à la porte ... ou comment vous allez justifier de la gestion du personnel gonflé que vous avez, en particulier dans la situation économique actuelle!
Je suppose que cette question sera fermée comme "subjective". Mais avez-vous essayé de parler à d'autres développeurs qui changent le code pour leur demander quelles avantages ont-ils apportés?
Questions connexes: Stackoverflow.com/questions/206286/... Stackoverflow.com/Questtions/1044590/... Stackoverflow.com/questions/369399/...
poster le code et les modifications. cela pourrait nous aider à avoir une meilleure idée
Une bonne citation sur ceci est - vous n'êtes pas votre code.