Quand est-il temps de remanier le code ?

Question

Sur place :
1. Vous n'avez jamais le temps de le faire.
2. Le "changement de contexte" est mentalement coûteux (il est difficile de quitter ce que l'on est en train de faire au milieu de celui-ci).
3. Ce n'est généralement pas une tâche facile.
4. Il y a toujours la peur de casser quelque chose qui fonctionne maintenant.

De l'autre :
1. L'utilisation de ce code est source d'erreurs.
2. Au fil du temps, vous pourriez vous rendre compte que si vous aviez remanié le code dès la première fois, vous auriez gagné du temps sur le long terme.

Ma question est donc la suivante : en pratique, quand décidez-vous qu'il est temps de remanier votre code ?

Gracias.

Answer 1

Quelques observations :

Sur place : 1. Tu n'as jamais eu le temps de le faire.

Si vous traitez le remaniement comme quelque chose de distinct du codage (au lieu d'une partie intrinsèque du codage correct), et si vous ne pouvez pas gérer le temps, alors oui, vous n'aurez jamais le temps pour cela.

1. Le "changement de contexte" est mentalement coûteux (il est difficile de quitter ce que l'on est en train de faire au milieu de celui-ci).

Voir le point précédent ci-dessus. Le remaniement est une composante active des bonnes pratiques de codage. Si vous séparez les deux comme s'il s'agissait de deux tâches différentes, alors 1) vos pratiques de codage ont besoin d'être améliorées/maturées, et 2) vous vous engagerez dans un changement de contexte sévère si votre code a grand besoin d'être refactoré (encore une fois, la qualité du code).

1. Ce n'est généralement pas une tâche facile.

Seulement si le code que vous produisez ne se prête pas à une refactorisation. En d'autres termes, le code qui est difficile à remanier présente un ou plusieurs des éléments suivants (la liste n'est pas exhaustive) :

1. Complexité cyclomatique élevée ,
2. Pas de responsabilité unique par classe (ou procédure),
3. Couplage élevé et/ou faible cohésion (c'est à dire faible) Métriques LCOM ),
4. mauvaise structure
5. Ne pas suivre le Principes SOLIDES .
6. Aucune adhésion à la Loi de Déméter le cas échéant.
7. Une adhésion excessive à la Loi de Déméter quand c'est inapproprié.
8. Programmer en fonction des implémentations plutôt que des interfaces.

1. Il y a toujours la peur de casser quelque chose qui fonctionne maintenant.

Les tests ? Vérification ? Analyse ? Tout cela avant d'être enregistré dans le contrôle de la source (et certainement avant d'être livré aux utilisateurs) ?

De l'autre : 1. L'utilisation de ce code est source d'erreurs.

Seulement s'il n'a jamais été testé/vérifié et/ou s'il n'y a pas de compréhension claire des conditions et des modèles d'utilisation dans lesquels le code potentiellement sujet aux erreurs fonctionne de manière acceptable.

1. Au fil du temps, vous pouvez vous rendre compte que si vous aviez remanié le code de la manière suivante première fois que vous l'avez vu - Cela vous aurait fait gagner du temps sur le long terme.

Cette prise de conscience ne doit pas se faire au fil du temps. Une bonne ingénierie et une bonne éthique de travail exigent que cette prise de conscience ait lieu lorsque l'artefact (matériel ou logiciel) est en cours de réalisation.

Ma question est donc la suivante : en pratique, quand décidez-vous qu'il est temps de remanier votre code ?

Pratiquement Lorsque je suis en train de coder, je détecte un domaine qui doit être amélioré (ou quelque chose qui doit être corrigé après une modification des exigences ou des attentes) et j'ai l'occasion de l'améliorer sans sacrifier un délai. Si je ne peux pas remanier à ce moment-là, je documente simplement le défaut perçu et je crée un plan réalisable et réaliste pour revisiter l'artefact afin de le remanier.

Dans la vie réelle, il y aura des moments où nous coderons un affreux bidule juste pour que les choses fonctionnent, ou parce que nous sommes épuisés et fatigués ou autre. C'est la réalité. Notre travail consiste à faire en sorte que ces incidents ne s'accumulent pas et ne restent pas sans réponse. Et la clé pour cela est de refactorer au fur et à mesure que vous codez, de garder le code simple et avec une bonne structure, simple et élégante. Et par "élégant", je ne veux pas dire "malin" ou ésotérique, mais qui affiche ce qui est typiquement considéré comme des attributs lisibles, simples, composables (et des attributs mathématiques lorsqu'ils s'appliquent pratiquement.)

Un bon code se prête au remaniement ; il affiche de bonnes métriques ; sa structure ressemble à la fois à celle d'un code de base et à celle d'un code de base. composition de la fonction informatique y composition de fonctions mathématiques il a une responsabilité claire ; il rend ses invariants, ses pré et post-conditions évidents ; et ainsi de suite.

J'espère que cela vous aidera.

Answer 2

1. Quand ça sent je refactorise. Je ne peux pas le rendre parfait maintenant, mais je peux au moins faire un petit pas vers un meilleur état. Et ces petits changements s'additionnent avec le temps...
2. Si je suis au milieu de quelque chose lorsque je remarque l'odeur, et que la réparation n'est pas triviale (ou que je suis juste avant de me libérer), je peux prendre note (mentalement ou sur papier) de revenir à cette tâche une fois que j'en aurai terminé avec la tâche principale.
3. La pratique rend meilleur :-) Mais si je ne vois pas de solution à un problème, je le mets de côté et je le laisse infuser un moment, j'en discute avec des collègues, ou même je le poste sur SO ;-)
4. Si je n'ai pas de tests unitaires et que la correction n'est pas triviale, je commence par les tests. Si les tests ne sont pas non plus triviaux, j'applique le point 2.

Answer 3

L'une des erreurs les plus courantes que je vois est que les gens associent le mot "Refactor" à "Big Change".

Le remaniement du code ne doit pas toujours être lourd. Même les petits changements, comme la modification d'un bool en un enum approprié, ou renommer une méthode pour être plus proche de la fonction réelle que l'intention est de refactorer votre code. À l'exception de la fin d'une étape importante, j'essaie d'effectuer au moins un petit remaniement chaque fois que je vérifie. Et vous seriez étonné de voir à quelle vitesse cela fait une différence visible dans le code.

Les changements plus importants nécessitent une plus grande planification. J'essaie de prévoir environ une demi-journée toutes les deux semaines pendant un cycle de développement normal pour m'attaquer à un changement de refactoring plus important. Ce temps est suffisant pour apporter une amélioration substantielle à la base de code. Si le remaniement échoue, une demi-journée n'est pas une grande perte. Et c'est rarement une perte totale car même le remaniement raté vous apprendra quelque chose sur votre code.

Answer 4

Je commence à refactorer dès que je constate que je me répète. Les principes DRY ftw.

De même, si les méthodes/fonctions deviennent trop longues, au point de paraître lourdes, ou si leur objectif est obscurci par la longueur de la fonction, je la décompose en sous-fonctions privées qui expliquent ce qui se passe réellement.

Enfin, si tout est opérationnel et que le code est très lent, je commence à envisager de le remanier pour améliorer les performances.

Answer 5

Refactorisez le code lorsqu'il doit l'être. Quelques symptômes que je recherche :

• dupliquer le code dans des objets similaires.
• dupliquer le code dans les méthodes d'un même objet.
• chaque fois que les exigences ont changé deux fois ou plus.
• à chaque fois que quelqu'un dit "on nettoiera ça plus tard".
• à chaque fois que je lis du code et que je secoue la tête en pensant "quel crétin a fait ça" (même si le crétin en question, c'est moi).

En général, moins de conception et/ou des exigences moins claires signifient plus d'opportunités pour le remaniement.