Refactoring : Qu'est-ce que c'est, et quand est-il préférable de le faire ?

Maintenir le code existant est un processus très important qui ne doit pas être sous-estimé. Malheureusement, plus de temps et de ressources sont souvent consacrés à la mise en œuvre de nouvelles fonctionnalités au détriment de la maintenance du code actuel. Bien sûr, nous pouvons tous parfois nous demander : pourquoi réparer quelque chose qui fonctionne déjà ? Quels avantages cela peut-il apporter ?

Qu'est-ce que le refactoring ?

Selon Wikipédia, c'est un processus consistant à introduire des changements dans un projet ou un programme, à la suite duquel la fonctionnalité ne change pas substantiellement. Ainsi, le refactoring vise à ne pas créer de nouvelles fonctionnalités mais à maintenir une organisation appropriée et de haute qualité du système.

Essayons maintenant de traduire cette définition pour que tout le monde puisse la comprendre. À cette fin, j'utiliserai la phrase suivante comme exemple : Le conducteur d'un véhicule à moteur qui, tout en se déplaçant sur la route, est dépassé par un autre véhicule à moteur, ne devrait pas accélérer jusqu'à la fin de la manœuvre de dépassement.

La phrase est longue et compliquée, mais nous parvenons à comprendre son message après un moment. D'un autre côté, la phrase Nous ne devrions pas accélérer si un autre véhicule nous dépasse est beaucoup plus courte, plus facile à comprendre, tout en nous fournissant des informations importantes.

Par conséquent, nous pouvons transmettre la même information de nombreuses manières différentes, dont certaines seront meilleures tandis que d'autres seront moins bonnes. Il en va de même pour la programmation. Le fonctionnement d'une fonctionnalité donnée peut être écrit sous la forme d'un code de manière meilleure ou pire, mais le résultat restera inchangé. Et ici, nous revenons au refactoring de code, qui n'est rien d'autre que le changement de contenu de code sans affecter le résultat final. Alors pourquoi changer quelque chose qui fonctionne, et quels effets cela apporte-t-il ?

Quand devrions-nous effectuer le refactoring ?

Avant d'expliquer pourquoi nous devrions changer quelque chose qui est fonctionnel et les résultats qu'un tel changement apporte, examinons d'abord les symptômes qu'une application nécessitant un refactoring peut donner.

Absence de support ou fin imminente de support pour le CMS sur lequel l'application est basée

La date de fin de support pour le CMS ou le framework sur lequel l'application est basée n'est rien d'autre que sa date de péremption. Après cette date, l'application ne devrait plus être utilisée. C'est très important – non pas tant en termes de performance de l'application, mais plutôt de sa sécurité. Regardons la table ci-dessous, avec les dates de fin de support pour le framework Laravel.

Source: Laravel.com

La chose la plus intéressante dans cette table est la colonne Corrections de sécurité jusqu'à. Son titre signifie qu'aucun correctif de sécurité ne sera implémenté une fois la date spécifiée dépassée, même si une vulnérabilité est découverte et signalée. C'est l'opportunité parfaite pour un attaquant car s'il a affaire à un système déjà non pris en charge, il saura exactement où et quel type de vulnérabilités se trouvent, ce qui rendra l'attaque beaucoup plus facile.

Le temps et le travail que vous devrez consacrer à la mise à jour de l'application dépendent de nombreux facteurs. Par exemple, migrer de Drupal 7 à Drupal 8 signifie en réalité une réécriture complète de l'application. Cela s'applique également à certaines versions de Laravel.

Lenteur de l'application

C'est un phénomène très courant qui peut mettre plusieurs années à développer des symptômes. Pourquoi cela se produit-il ? Les objectifs initiaux de la phase de conception de l'application peuvent ne pas prendre en compte les performances de l'application en cas de pics de trafic sur le site web ou en cas de travail avec de plus grandes quantités de données. Ces données stockent des informations, par exemple, sur les utilisateurs enregistrés, les publications, les commentaires, les paramètres de l'application, etc. Avec le temps, il y en aura de plus en plus, et elles causeront de plus en plus de problèmes.

Cependant, vous devez garder à l'esprit que la lenteur d'une application ne signifie pas toujours la nécessité de refactoring. Parfois, pour accélérer son fonctionnement, par exemple, des changements dans son infrastructure seront nécessaires. Pour cette raison, la décision de refactoriser le code doit être précédée d'une analyse approfondie.

Temps de développement long

Une application bien écrite devrait permettre la mise en œuvre relativement facile de nouvelles fonctionnalités et de changements. Pour que cela soit possible, chaque développeur doit suivre certaines règles lors de l'écriture du code, telles que DRY ou SOLID. Malheureusement, cela est loin de la réalité, et les programmeurs doivent souvent développer un code qui a été initialement créé par des personnes peu familières avec ces règles. Pour cette raison, l'ajout de la fonctionnalité la plus simple peut parfois prendre un temps absurdement long.

Dans une telle situation, vous devez également analyser en profondeur le code et envisager si un refactoring total sera plus rentable que le développement du code actuel. Si vous décidez de refactoriser, cela doit être traité comme un investissement. Votre temps et vos ressources ne donneront pas de résultats immédiats, mais ils permettront d'économiser des ressources à l'avenir.

Erreurs courantes qui nécessitent souvent d'être corrigées

Cet aspect est quelque peu lié au précédent. Bien sûr, des erreurs arrivent à tout le monde, et parfois, malgré les meilleures intentions, de nombreux tests, et l'équipe QA, elles peuvent quand même se produire. Cependant, si elles deviennent de plus en plus fréquentes, ou si la majorité du temps de travail des programmeurs est consacrée à la correction de bogues plutôt qu'à l'optimisation et au développement de l'application, cela peut signifier qu'il y a un besoin de refactoring.

Comment se déroule le processus de refactoring ?

Comme nous l'avons déjà mentionné, la décision de refactoriser doit être précédée d'une analyse approfondie. Comment cela se présente-t-il alors, en quoi cela consiste-t-il, et quelles sont les étapes du processus de refactoring du code ?

1. Connaître l'application, les fonctionnalités et la logique métier. Au début, nous devons apprendre le fonctionnement exact des processus de l'application, ainsi que la tâche qu'elle accomplit.
2. Vérifier les technologies, les frameworks ou les CMS utilisés en termes de mises à jour et de la période de support. Les applications Internet se composent très souvent de nombreux composants, modules et paquets fournis par des tiers. Vous devez vérifier s'ils sont toujours pris en charge ou s'ils doivent être mis à jour.
3. Analyser le code en termes de sa qualité, des meilleures pratiques et des performances. À cette étape, nous évaluons si le code actuel est utilisable et si son développement ultérieur ne sera pas problématique.
4. Identifier les causes qui ont un impact négatif sur le fonctionnement de l'application. Sur la base des informations précédemment collectées, nous analysons les processus se déroulant dans l'application et identifions les maillons faibles qui affectent les performances.
5. Identifier les solutions qui amélioreront le fonctionnement de l'application et déterminer la méthode de leur mise en œuvre. Connaissant les problèmes dont souffre l'application, nous recherchons les solutions qui fonctionneront dans un cas donné. Chaque problème peut être résolu de plusieurs manières, nous pesons donc soigneusement tous les avantages et inconvénients.
6. Estimer les coûts, le temps de travail et les tâches à effectuer. Nous écrivons le plan d'action dans les moindres détails, divisons les tâches en étapes, et estimons la quantité de travail nécessaire pour les compléter.
7. Préparer des tests automatiques. Grâce à eux, à chaque étape du travail, nous nous assurerons que l'application fonctionnera de manière stable tout au long du processus et qu'il n'y aura pas de pannes imprévues ou d'autres problèmes.
8. Refactoring du code – mise en œuvre des changements planifiés précédemment.

Il est impossible de définir clairement comment se déroulera le refactoring du code lui-même. C'est une question très complexe et, selon la situation, l'ensemble du processus sera différent. Cependant, la chose la plus importante est de ne pas interférer avec le fonctionnement de l'application pendant tout le processus de refactoring, afin que les utilisateurs ne rencontrent aucun problème.

Traiter le refactoring comme un investissement

Parfois il est très difficile d'expliquer l'intérêt du refactoring. Ce n'est pas non plus facile de convaincre quelqu'un de dépenser de l'argent, parfois une somme non négligeable, pour un processus qui ne produira aucun changement dans l'application visible à l'œil nu. Cependant, gardez à l'esprit que le refactoring doit être traité comme un investissement. L'argent dépensé maintenant ne rapportera pas immédiatement, mais il nous permettra d'économiser des ressources à l'avenir. En outre, notre application sera plus stable, plus résistante aux attaques, et la mise en œuvre de nouvelles fonctionnalités ou d'autres changements sera beaucoup plus rapide.

Avez-vous une application ou un site web basé sur PHP ou l'un de ses frameworks (Drupal, Laravel, ou Symfony) ? En tant que spécialistes du développement PHP, nous pouvons analyser son code et – si nécessaire – effectuer le refactoring.