Comment améliorer son code ?<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> min read</span>

Comment améliorer son code ?9 min read

Votre code n’es pas terrible ? Vous avez envie de vous frapper quand vous le lisez ? Croyez moi, tout les développeurs ont connu ça…

Dans cet article, je vais vous apprendre à améliorer votre code. En anglais, on dis “refractoring”.

Voici donc quelques principes à suivre afin d’avoir un code plus lisible, de meilleur qualité et qui ne vous donnera pas envie de vous taper la tête contre les murs.

Je vais vous donner rapidement une définition de la réécriture du code que j’aime bien :

Améliorer un code signifie restructurer le contenu de votre code, c’est à dire altérer sa structure et son fonctionnement interne sans changer son fonctionnement externe.

Martin Fowler

Bon, j’ai traduis de manière approximative, mais l’idée est là. Vous devez réécrire des bouts de code sans changer le fonctionnement global.

Typiquement, une fonction va agir différemment mais son résultat de sortie sera le même, juste en plus optimisé.

C’est quoi un code mauvais ?

Pour pouvoir réécrire son code dans l’objectif de le rendre meilleur, il faut déjà comprendre ce qui le rends mauvais et donc par extension perfectible.

Un code mauvais ne possède pas de bugs direct, c’est plutôt un code qui pose des soucis et qui peux potentiellement créer de gros problèmes. Par exemple, une fonction qui va utiliser une boucle au lieu d’une solution plus simple peut créer des gros problèmes de performances si elle est trop utilisée.

Le mauvais code est souvent présent dans les gros projets. On dois faire fonctionner plusieurs parties d’une application ensemble, les liens crées sont donc souvent fragiles et pas vraiment optimisé.

Des exemples pratiques de mauvais code

Regardons maintenant des exemples concrets de mauvais code sur lesquels vous pouvez agir maintenant !

Du code dupliqué / répétitif

Si vous observez du code qui se répète dans un projet, vous devez changer la situation. Réécrire plusieurs fois les mêmes lignes de code, c’est inutile.

Avoir du code dupliqué, ça complexifie le test et la maintenance du code. Vous allez écrire des centaines de lignes de code en plus pour rien.

Une bonne façon de régler le soucis, c’est d’écrire une fonction qui va effectuer les actions que vos blocs de code répétés font. Vous pouvez bien sûr utiliser des arguments pour personnaliser le bloc de code.

Globalement, remplacez le code dupliqué par l’appel de votre fonction ou éventuellement, d’une méthode de classe et vous allez gagner énormément de lignes de code.

Je vous conseille vraiment d’écrire le fonctionnement fondamental de vos applications dans des fonctions / classes et de les appeler dans votre programme.

Des fonctions et des classes à rallonge

Si vous avez des fonctions ou des méthodes de classes faisant plusieurs dizaines de lignes de code, c’est bien souvent un signe de code non optimisé.

Plus votre fonction est longue, plus elle est difficile à maintenir et à tester.

Gardez un principe en tête, une fonction fait généralement une seule action. Si vous avez une fonction qui gère un processus en entier, créez en plusieurs et appelez les dans une fonction qui va servir de wrapper (une fonction qui va s’occuper du lancement des processus)

J’essaie généralement de garder des fonctions courtes et assignés à une seule tâche. Ensuite je les combine pour créer des programmes.

Des commentaires qui expliquent le code

Je sais que cette section semble contradictoire. On arrête pas de vous répéter qu’il est essentiel de commenter votre code, et je suis d’accord avec ça.

Néanmoins, vos commentaires ne doivent pas expliquer comment vos fonctions marchent. Ils doivent expliquer ce qu’elles font.

Un bon code doit se comprendre simplement en le lisant. Par exemple, vous allez écrire comme commentaire :

Envoi une requête pour créer un utilisateur

Ici, on explique ce que la fonction fait, pas comment elle fonctionne. Un mauvais commentaire ferait ça :

On envoi une requêtes AJAX asynchrone, on résouds la promesse, on stocke dans un objet et on retourne dans la réponse

Si votre code est bien écrit, pas besoin de détailler tout ça, on doit le comprendre juste en lisant votre code.

Les commentaires sont donc un bon moyen de diagnostiquer du mauvais code. Si vous en avez besoin pour expliquer le fonctionnement, alors quelque chose ne va pas.

Des blocs if else enchaînés

Bien souvent, les développeurs débutants ont tendance à enchaîner les if else dans un seul bloc de code.

C’est une erreur, vous devez séparer votre logique dans différentes fonctions. Donc par extension, vos if else.

C’est plutôt simple, vous pouvez mettre des conditions dans vos fonctions et les faire retourner des résultats différents selon les conditions. A partir de ce principe, vous pouvez retirer vos enchaînement de conditions et vous pouvez les combiner ensemble grâce à des fonctions.

Du code qui ne sers plus

C’est un grand classique des développeurs. Quand on code ne sers plus à rien, on le laisse là ou au mieux, on le commente et on le laisse dans le fichier.

Sérieusement, ne faites pas ça. Vous allez finir avec des fichiers de 3000 lignes pour seulement 1000 lignes de code actif.

Supprimez simplement le code qui est mort, vous allez gagner du temps.

Pourquoi réécrire son code ?

Maintenant que vous connaissez les techniques de base qui vous permettent de reconnaître du mauvais code, et surtout de le réécrire, Nous allons voir les raisons qui devraient vous pousser à réécrire votre code au plus vite.

Vous devez vous demander : Est-ce que je risque de casser mes programmes en réécrivant mon code ?

Et bien, oui. Si vous ne faites pas attention, ça va arriver. Pour palier à ce problème, vous devez réécrire votre code fonctionnalité par fonctionnalité pour éviter de changer la logique globale. Vous voulez modifier le fonctionnement interne sans toucher au fonctionnement externe, n’oubliez jamais ça !

La maintenabilité

Après avoir réécris une bonne partie de votre code, vous allez vous rendre compte que votre programme est beaucoup plus simple à maintenir. Si vous le réécrivez en suivant les principes énoncés ci-dessus, votre code sera découpé en plusieurs petites parties, les bugs sont donc plus facilement trouvables et réglables.

Globalement, vous passerez beaucoup moins de temps à maintenir votre code sur le long terme.

L’extensibilité

Lorsque vous passez du temps à réécrire votre code, vous aurez l’occasion d’ajouter de nouvelles fonctionnalités en même temps. Il est beaucoup simple d’ajouter de nouvelles fonctions ou classes au moment ou vous réorganisez la logique interne de votre code.

Je vous conseille donc de nettoyer votre code avant d’ajouter de nouvelles fonctionnalités. Ainsi, vous gagnerez énormément de temps et vous limiterez les bugs.

La testabilité

Réécrire son code dans des fonctions ou des classes plus petites rendent le test de code beaucoup plus simple. Si vous avez des centaines de lignes de code dans une seule fonction, vous allez passer des heures à écrire un simple test.

Si chacune de vos fonction font quelques lignes de code, les tests seront plus simple à écrire. Vous allez gagner beaucoup de temps.

Quand réécrire son code ?

On arrive à la grande question de ce guide, quand réécrire son code ? Beaucoup de développeurs vous diront que ça viens naturellement et qu’il ne faut pas trop y penser.

Et bien, je pense qu’il y a des moments propices, en voici quelques uns :

Après avoir sorti une version

Alors oui, ça peut sembler stupide, pourquoi améliorer son code après avoir sorti une version ?

Et bien, après avoir sorti une version, il est possible de réécrire son code sans être embêté par les impératifs de temps. Vous avez une fenêtre de temps pour optimiser votre code sans être sous la pression de la date de sortie.

Une fois la nouvelle version en ligne, vous passez à autre chose. C’est donc beaucoup plus simple de faire sa réécriture à ce moment là.

Créez des tests avant de réécrire votre code

On va rentrer dans un concept assez complexe à appréhender. Toute à l’heure je vous ai dit qu’il était possible de casser votre code si vous réécrivez votre programme de la mauvaise façon.

Encore une fois, on cherche à changer la logique interne sans toucher à la logique externe. Et bien, réécrire son code après avoir écrit ses tests est une excellente solution.

C’est simple, vos tests doivent encore fonctionner après la réécriture, ce qui vous assure que la logique externe n’as pas changée.

Une fois vos tests unitaire faits, réécrivez votre code et basez vous sur vos tests pour être sûr que vous n’avez rien cassé.

Réécrivez votre code relativement tôt, et souvent

Réécrire du code est une opération plutôt simple et marrante si vous vous y prenez bien. Plus vous le faites souvent et tôt, plus l’opération sera simple et légère.

Je vous recommande donc de réécrire votre code tôt et relativement souvent.

En conclusion

Réécrire du code demande beaucoup de temps. C’est une activité qui demande beaucoup de sérieux pour éviter de casser tout votre code.

Dans cet article, nous avons vu ce que la réécriture de code impliquait, pourquoi vous devez le faire et enfin, quand le faire.

J’espère que vous avez aimé cet article, si c’est le cas, n’hésitez pas à vous abonner à ma newsletter. Vous recevrez en prime un livre gratuit pour bien débuter la programmation !

Vous abonner à notre newsletter

* champ requis

Laisser un commentaire

Fermer le menu
×
×

Panier