Quand vous êtes le nouveau gars et vous continuez à voir des choses stupides - les refactorisez-vous?

Question

Est-ce que vous refactorisez quand vous voyez des choses comme ça? Ou vous suffit de vous boucher le nez et de passer à autre chose?

public Collection<DataValidationRuleBase> GetFieldValidationRules(String key) 
    { 
     Collection<DataValidationRuleBase> found = null; 
     try 
     { 
      this.mRules.TryGetValue(key, out found); 
     } 
     catch (ArgumentException ex) 
     { 
      //log the error 
      Log.Error(ExceptionHandling.BuildExceptionMessage(ex)); 
      return null; 
     } 
     return found; 
    } 

Answer 1

Si vous êtes le nouveau gars, vous continuez.

Il est peu probable que vous soyez regardé favorablement si vous commencez à être un cowboy et à refactoriser partout, surtout si c'est sans rapport avec ce que vous travaillez. Même si vous "connaissez" cela améliorera la base de code, et vous pourriez penser que vous "prenez l'initiative", la première fois que vous le ferez et introduisez un bug dans le code qui fonctionnait avant, cela vous semblera très mauvais. Je prendrais note de toutes les choses que vous voyez qui ont besoin de refactoring, et quand vous aurez construit votre réputation et votre confiance dans l'entreprise, vous aurez beaucoup plus de latitude pour revenir en arrière et améliorer les choses.

Answer 2

si elle travaille ensuite le laisser comme ça, on ne pouvait jamais savoir ce qui pourrait arriver si vous allez changer des choses

Answer 3

Strip quoi que ce soit qui identifie votre entreprise (ou le codeur précédent) et les envoyer à The Daily WTF :)

Answer 4

ya, si votre nouveau gars, alors vous ne refactoriser pas des choses, vous faites exactement ce que le chef d'équipe vous dit

Answer 5

qu'est-ce TryGetValue faire?

avez-vous besoin de toujours suivre les erreurs? (La chose forestière)

il y a beaucoup de chose qui pourrait être valable avec cette chose

Answer 6

Lorsque vous êtes nouveau, attention qui vous parlez de code « merde ». Il est hautement possible qu'ils l'aient écrit, ou qu'ils écrivent du code de la même manière. C'est un bon moyen de partir du mauvais pied avec un nouvel emploi.

Answer 7

Sauf si vous travaillez dans Dilbert-world, vous avez une conversation avec votre manager. "Hey, je pense que j'ai trouvé un problème et c'est comme ça que je voudrais le réparer." La discussion s'ensuit. Vous pourriez passer à parler au développeur d'origine et un contact humain aura lieu.

Comment est-ce un problème compliqué?

Answer 8

Ne modifiez pas le code de travail sans raison valable.

Si vous pensez qu'il y a un problème avec un code, signalez-le à votre chef d'équipe et laissez-le décider de ce qu'il doit en faire.

Raisons:

• Vous ne savez pas pourquoi le programmeur d'origine a fait quelque chose. Ce pourrait être idiot, ou ils pourraient avoir une bonne raison de ce qu'ils ont fait. Il est possible que vous soyez l'idiot et que vous n'ayez pas saisi la subtilité du code (bien que l'autre programmeur aurait dû le commenter clairement si c'est le cas!)

• Toute modification du code est quelque chose qui a besoin test, et potentiellement pourrait introduire de nouveaux bogues dans le code qui fonctionne autrement. Cela ne devrait pas nous empêcher de refactoriser pour améliorer la qualité du code, mais nous ne devrions pas simplement changer tout ce que nous pensons être faux sans le considérer attentivement.Si vous «corrigez» le code d'un autre peuple, vous avez de fortes chances de générer du ressentiment et de coder des «batailles» avec vos coéquipiers. Votre chef d'équipe peut s'en occuper de manière appropriee (remettre le programmeur d'origine a l'épreuve, donner des conférences a l'équipe, ou le faire calmement, etc.) sans que personne ne sache que vous lui avez "montré du doigt". Et vous obtenez des points brownie avec votre patron pour pointer la faille ... À moins qu'il est son code :-)

(Vous pouvez également vérifier dans la source de contrôle pour voir qui a écrit le code)

Answer 9

Vous êtes un peu vague sur votre définition de l'idiotie dans le code.

Si c'est parce que TryGetValue ne jette pas un ArgumentException mais jette plutôt un ArgumentNullException, vous devriez être en sécurité dans le fixer.

MSDN Dictionary.TryGetValue Method

Answer 10

Règle générale: Si ce n'est pas cassé, ne le répare pas!

Si vous êtes un nouveau type, et que vous rencontrez un code malodorant, je ne recommanderais pas de changer le code à moins que cela ne fasse partie de l'amélioration que vous êtes en train de faire. Si cela semble être un problème majeur, une alternative plus acceptable serait d'essayer d'écrire un test unitaire pour le cas qui échoue, puis, selon la façon dont votre entreprise traite normalement de ces problèmes, soit revenir en arrière et réparez-le, ou laissez les testeurs le rencontrer et attribuez-le au développeur approprié.

Cette approche est susceptible de vous rapporter quelques points, car elle montre que vous faites attention et que vous êtes proactif, sans introduire d'effets secondaires potentiels dans le code.

Answer 11

J'écrirais habituellement des tests unitaires (j'espère que ce n'est pas une idée étrangère dans votre entreprise) en fonction de mes hypothèses et je m'en tiendrai là.

Il y a parfois des raisons (valides?) Pour lesquelles le code est étrangement écrit, ce qui peut seulement être vu à partir d'un test unitaire échoué ou lorsqu'un changement est effectué par un nouvel employé. Plus tard, quand je ne suis pas le nouveau type et que j'ai une meilleure compréhension de la base de code, j'effectuerais le refactoring.

Cela a aussi l'avantage d'apprendre comment le code fonctionne sans être un cow-boy -Pas Peu importe la façon dont il peut être tentant :)

Answer 12

(presque) Chaque entreprise qui a un plus petit effectif que ses bons de souscription de la charge de travail aura dette technique ou code désordonné. Malheureusement, (presque) toutes les entreprises sont comme ça.

À moins que vous ne soyez dans une organisation agile ou dans un projet qui a débuté avec une faible dette technique et que vous l'ayez maintenu ainsi, la lutte est presque désespérée. Sous la pression du temps, nous écrivons tous du code comme ça. En fait, même oncle Bob écrit un code moche avant d'avoir le temps d'en refactoriser le bejesus avant de l'afficher dans un livre. Si vous commencez à refactoriser des choses, vous courez le risque de casser quelque chose.Si votre organisation n'a pas de tests unitaires complets, ce n'est pas un risque que vous devriez prendre.

Le nettoyage de la dette technique est une décision à l'échelle de l'organisation ou, du moins, du côté des projets. Ça ne commence pas avec le nouveau gars, malheureusement.

Answer 13

Bad programmeurs:

Refactor, vérifiez dans et passer à autre chose sans dire un mot.

bons programmeurs:

« Hey Neil, je suis tombé sur cette méthode et je me demandais pourquoi il a été écrit de cette façon .. ce return null semble ici redondant, l'esprit si je laisse tomber pour nettoyer le code un peu? Ou y a-t-il une raison spécifique pour laquelle tu l'as écrit comme ça?