Directives détaillées sur la façon de refactoriser le code de votre site web

Avez-vous déjà secoué la tête en signe de désapprobation en lisant du code lorsque vous travailliez sur un projet ? Vous êtes-vous déjà au moins une fois dit : "Ce code n'est pas optimal - il est possible de l'écrire mieux et plus efficacement" ? L'ajout ou la modification d'une fonctionnalité théoriquement mineure sur votre page cause-t-il d'innombrables problèmes et nécessite-t-il d'introduire des modifications dans de nombreux autres domaines ? Si la réponse à au moins l'une de ces questions est "oui", il est peut-être temps de planifier un refactoring du code.

Qu'est-ce que cela signifie de refactoriser du code ?

Refactoriser du code signifie lutter contre la dette technique. C'est un processus de transformation de code chaotique non conforme aux normes et bonnes pratiques en code propre, dont la structure est simple, compréhensible et extensible.

Qu'est-ce que le code propre ?

Le code est considéré comme propre si tout le monde dans l'équipe est capable de le comprendre facilement. La fonctionnalité fournie par un code propre peut être facilement étendue par tous les développeurs de l'équipe, et pas seulement par le développeur du code.

Le code propre se caractérise par :

• simplicité,
• compréhension par d'autres programmeurs,
• absence de duplications,
• minimalisme,
• complètement testé,
• entretien facile et peu coûteux.

Étape 1 : Apprendre à connaître une application ou un site web

Au début d'un processus de refactorisation de code, vous devez effectuer une analyse approfondie de l'application et mettre en évidence les éléments difficiles à développer et à maintenir. Une méthode utile à ce stade (et en même temps – l'une des méthodes de refactorisation) est le Refactoring Exploratoire. De quoi s'agit-il ? Réglez une minuterie pour 25-30 minutes et refactorisez la fonctionnalité que vous souhaitez comprendre pendant ce temps. À ce point, il importe peu que les changements que vous introduisez ne soient pas optimaux ou que le code cesse de fonctionner comme il le devrait. Le but de l'introduction des changements à ce stade est de comprendre en profondeur la fonctionnalité et de comprendre le code ancien que vous venez refactoriser. Cette approche réduit le temps nécessaire à l'analyse - la lecture statique du code ne vous donnera presque jamais une vue d'ensemble de la situation.

Étape 2 : Écrire les choses qui peuvent être un problème

Hey, j'ai choisi de travailler sur la classe "AplicationManager". Elle n'a pas du tout été testée. Elle a de nombreuses responsabilités. Elle est aussi très fragile et a une faute de frappe dans le nom. Cette méthode de 250 lignes, qui a sept paramètres et deux indicateurs, pourrait être décomposée non pas en quelques méthodes mais en trois classes. J'en suis arrivé à ces conclusions lors d'un Refactoring Exploratoire, et j'ai aussi découvert que nous devrions…

Ceci est un exemple du résultat de l'utilisation de la méthode de Refactoring Exploratoire. Pendant l'analyse, notez les problèmes que vous avez rencontrés et les solutions possibles à ces problèmes. Cette liste sera nécessaire pour le processus correct et optimal de conception de l'application actualisée. Ne vous concentrez pas sur les détails à ce stade, ne tentez pas de définir des solutions exactes - il y aura du temps pour cela.

Quels éléments peuvent poser problème ? Dans de nombreux cas, nous pourrions sentir qu'il y a quelque chose qui ne va pas dans le code. Cela affecte tant de personnes qu'une telle intuition a même reçu un nom - odeurs de code. Les odeurs de code peuvent être regroupées et utilisées pour une refactorisation itérative.

Encombrement du code

Je sais que cette classe a déjà 648 lignes et de nombreuses dépendances et responsabilités, mais j'ai rapidement ajouté une méthode parce que j'en avais besoin pour ma tâche. Cette classe me semblait appropriée. Quoi? Pourquoi l'ai-je déjà fait six fois dans six tâches différentes et non liées ? Comme je vous le dis - c'est juste un correctif rapide.

Le code est encombré lorsqu'il est si volumineux qu'il prend beaucoup de temps à comprendre, à maintenir, à modifier ou à étendre. Ce type de code est coûteux et difficile à tester. Il se caractérise par :

• des méthodes longues,
• des classes longues,
• une longue liste de paramètres,
• la duplication de variables dans plusieurs classes,
• l'utilisation de champs primitifs au lieu de classes simples.

Utilisation partielle ou inappropriée de la programmation orientée objet

Le code recueille tous les abus et les mauvaises utilisations de la programmation orientée objet – il enfreint les règles, perd sa lisibilité. Les modifications, la maintenance et les tests deviennent plus coûteux.

La liste des odeurs de code dans ce cas inclut :

• la duplication des fonctionnalités,
• des commutateurs complets qui peuvent être éliminés par le polymorphisme,
• des variables temporaires dans la méthode.

Bloqueurs de changements

Modifier la classe entraîne la nécessité de réécrire des méthodes théoriquement non liées. Cela allonge le temps nécessaire pour apporter des améliorations ou des extensions au code.

Éléments redondants du code

- Lors de la revue de code, je suis tombé sur la variable $fooMaganer, que vous avez commentée comme "Variable Foo Manager, utilisée pour gérer le Foo". Pensez-vous que c'est un commentaire approprié ?

- Je ne sais pas, mais nos normes indiquent que chaque variable doit être commentée, pas que le commentaire doit apporter quelque chose. Alors, comment ça sera ? Allez-vous approuver ?

Les éléments redondants incluent tout ce qui n'apporte rien au code ou qui n'est pas utilisé. Parmi eux se trouvent :

• un code excessivement rempli de commentaires inutiles,
• des duplications de code,
• du code non utilisé,
• des classes non utilisées,
• des méthodes non utilisées.

Connecteurs

Salut, Adam, Anna a besoin d'une liste des dix premiers nombres de la séquence de Fibonacci. S'il te plaît, donne-la-moi, et je la transmettrai en ton nom. Merci !