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

Si vous êtes le nouveau, avancez.

Il est peu probable que cela soit bien regardé si vous commencez à agir en cow-boy et à refaire des choses un peu partout, surtout si cela n'a aucun lien avec ce sur quoi vous travaillez. Même si vous "savez" que cela améliorera la base de code, et que vous avez le sentiment de "prendre des initiatives", la première fois que vous ferez une erreur et introduirez un bug dans du code qui fonctionnait auparavant, cela vous sera très préjudiciable.

Je noterais toutes les choses que vous voyez qui ont besoin d'être refaites, et lorsque vous aurez bâti votre réputation et votre confiance au sein de l'entreprise, vous aurez beaucoup plus de marge de manœuvre pour revenir en arrière et améliorer les choses.

Answer 2

Mauvais Programmeurs :

Refactorisez-le, vérifiez-le et passez à autre chose sans dire un mot.

Bons Programmeurs :

"Hey Neil, je suis tombé sur cette méthode et je me demandais pourquoi elle était écrite de cette façon.. ce retour null ici semble redondant, est-ce que ça te dérange si je le supprime pour nettoyer un peu le code ? Ou y a-t-il une raison spécifique pour laquelle tu l'as écrit comme ça ?"

Answer 3

Si cela fonctionne, alors laissez-le tel quel, vous ne sauriez jamais ce qui pourrait arriver si vous modifiez des choses

Answer 4

Ne changez pas le code de travail sans bonne raison.

Si vous pensez qu'il y a quelque chose de mal avec un code, alors signalez-le à votre chef d'équipe, et laissez-le décider quoi en faire.

Raisons:

• Vous ne savez pas pourquoi le programmeur original a fait quelque chose. Cela pourrait être de l'idiotie, ou ils pourraient avoir une raison valable pour ce qu'ils ont fait. Il est tout à fait possible que vous soyez l'idiot et n'ayez pas saisi une 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 nécessite des re-tests, et pourrait potentiellement introduire de nouveaux bugs dans un code par ailleurs fonctionnel. Cela ne devrait pas nous empêcher de refondre pour améliorer la qualité du code, mais nous ne devrions pas tout changer uniquement parce que nous pensons que c'est faux sans y réfléchir attentivement.

• Si vous "corrigez" le code des autres, vous risquez fortement de générer du ressentiment et des "batailles" de codage avec vos coéquipiers.

• Votre chef d'équipe peut gérer cela de manière appropriée (prendre le programmeur original à partie, faire la leçon à l'équipe, ou le faire corriger discrètement, etc.) sans que personne ne sache que vous "avez pointé du doigt" sur eux. Et vous obtiendrez des points bonus avec votre patron pour avoir signalé le défaut... À moins que ce ne soit son code :-)

(Vous pouvez également consulter le contrôle de source pour voir qui a écrit le code)

Answer 5

Supprimez tout ce qui identifie votre entreprise (ou le codeur précédent) et envoyez-leur à The Daily WTF :)