Quand vous êtes le nouvel arrivant et que vous continuez à voir des choses bêtes - les retravaillez-vous ?

Question

Refactorez-vous lorsque vous voyez des choses comme ça? Ou vous vous contentez de boucher votre nez et de passer à autre chose?

    public Collection GetFieldValidationRules(String key)
    {
        Collection 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

Oui, si vous êtes le petit nouveau, alors vous ne refactorez pas les choses, vous faites simplement ce que le chef d'équipe vous dit

Answer 2

Lorsque vous êtes nouveau, faites attention à qui vous parlez du code "pourri". Il est très probable qu'ils l'aient écrit, ou qu'ils écrivent du code de la même façon. C'est un bon moyen de mal commencer un nouveau travail.

Answer 3

Règle générale : s'il n'est pas cassé, ne le réparez pas !

Si vous êtes le petit nouveau, et que vous tombez par hasard sur du code qui sent mauvais, je ne recommanderais pas de le changer à moins que cela ne fasse partie de l'amélioration sur laquelle vous travaillez actuellement.

S'il semble s'agir d'un problème majeur, une alternative plus acceptable serait d'essayer d'écrire un test unitaire pour le cas qui échoue, puis, en fonction de la manière dont votre entreprise traite habituellement ces problèmes, soit revenir en arrière et le corriger, soit laisser les testeurs tomber dessus et le confier au développeur approprié.

Cette approche est susceptible de vous faire gagner des points, car elle montre que vous êtes attentif et proactif, sans introduire d'effets secondaires potentiels dans le code.

Answer 4

Sauf si vous travaillez dans le monde de Dilbert, vous avez une conversation avec votre manager. "Hey, je pense avoir trouvé un problème et voici comment je voudrais le résoudre." Une discussion s'ensuit. Vous pourriez passer à parler au développeur original et un contact humain aura lieu.

Comment cela peut-il être un problème compliqué?

Answer 5

Je rédige habituellement des tests unitaires (j'espère que ce n'est pas une idée étrangère dans votre entreprise) basés sur mes hypothèses et je m'en tiens là.

Parfois, il y a des raisons (valables?) pour lesquelles le code est étrangement écrit qui ne peuvent être identifiées que lorsqu'un test unitaire échoue ou lorsqu'un nouveau employé apporte des modifications.

Plus tard, lorsque je ne suis plus le petit nouveau et que j'ai une meilleure compréhension de la base de code, je ferais la refonte.

Cela offre également l'avantage supplémentaire d'apprendre comment fonctionne le code sans être un "cowboy" - Peu importe à quel point cela peut être tentant :)