Bonne pratique : réviser et refactorer son projet final

Pourquoi un code qui 'fonctionne' n'est pas toujours un 'bon' code ?

Félicitations pour avoir construit une application fonctionnelle ! C'est une étape majeure. Cependant, dans le monde professionnel, un code qui "fonctionne" n'est que le point de départ. La qualité à long terme d'un logiciel dépend de sa lisibilité, de sa facilité de modification et de sa maintenabilité.

Imaginez une maison qui vient d'être construite. Elle est fonctionnelle : elle a un toit et des murs. Mais si la plomberie est un enchevêtrement de tuyaux et le câblage électrique un chaos de fils, toute réparation ou extension future sera un cauchemar. C'est ce qu'on appelle la dette technique. Un code qui fonctionne mais qui est mal organisé accumule cette dette, rendant chaque future modification plus lente, plus coûteuse et plus risquée.

La révision et le refactoring sont les pratiques qui permettent de rembourser cette dette. C'est l'acte de nettoyer et d'organiser la structure interne de votre code sans en changer le comportement externe. C'est ce qui transforme un simple script fonctionnel en une base de code professionnelle et durable.

Qu'est-ce que le refactoring et quand le pratiquer ?

Le refactoring est le processus de restructuration du code existant pour en améliorer la clarté, la simplicité et la maintenabilité, sans changer ce qu'il fait. L'objectif n'est pas d'ajouter de nouvelles fonctionnalités, ni de corriger des bugs (bien que cela puisse les révéler), mais purement d'améliorer la qualité de la conception interne.

Alors, quand faut-il refactorer ? La réponse est : presque tout le temps, mais par petites touches. Une pratique courante est la "Règle du Boy Scout" : toujours laisser le code un peu plus propre que vous ne l'avez trouvé. Plus concrètement :

• Avant d'ajouter une nouvelle fonctionnalité : Nettoyer la zone de code que vous allez modifier la rendra plus facile à étendre.
• Après avoir corrigé un bug : Une fois le bug corrigé, prenez un moment pour voir si vous pouvez réorganiser le code pour que ce type de bug ne puisse plus se produire.
• Lors d'une revue de code : En relisant votre propre code (ou celui d'un collègue), vous identifierez souvent des opportunités d'amélioration.

Pensez-y comme au rangement de votre cuisine après avoir préparé un plat. Vous ne changez pas la recette, mais vous nettoyez les plans de travail et rangez les ustensiles pour que la prochaine session de cuisine soit plus simple et plus agréable.

Exemples concrets de refactoring dans notre projet météo

Appliquons ces idées à notre projet météo. Même s'il est petit, il y a déjà des axes d'amélioration. Voici deux exemples de refactoring que nous pourrions appliquer.

1. Extraire la logique d'affichage dans une méthode dédiée :
Dans notre script meteo.rb, la partie qui affiche les résultats est mélangée avec la logique principale. On peut l'extraire pour séparer les responsabilités.

Avant :

# ... (dans meteo.rb)
if weather_data
  temp = weather_data['main']['temp']
  description = weather_data['weather'].first['description']
  
  puts "-" * 30
  # ... etc
else
  # ...
end

Après :

# ... (dans meteo.rb)
def display_weather(city, data)
  temp = data['main']['temp']
  description = data['weather'].first['description']
  
  puts "-" * 30
  puts "Météo actuelle pour #{city.capitalize}:"
  puts "Température: #{temp}°C"
  puts "Description: #{description.capitalize}"
  puts "-" * 30
end

if weather_data
  display_weather(city, weather_data)
else
  # ...
end

Le script principal est maintenant plus lisible. Il se concentre sur l'orchestration (récupérer les arguments, appeler l'API, afficher) et délègue le détail de l'affichage à une méthode spécialisée.

2. Externaliser la configuration :
Conseil de pro : Dans une application réelle, une clé API ne devrait jamais être écrite en dur dans le code. C'est une information sensible. Un refactoring avancé consisterait à utiliser une gem comme dotenv pour charger la clé API depuis un fichier .env (ignoré par Git), séparant ainsi la configuration du code.

Comment s'assurer que le refactoring ne casse rien ?

Vous vous demandez peut-être : "Si je modifie la structure de mon code, comment puis-je être certain de ne pas avoir introduit de nouveaux bugs ?" C'est une excellente question, et elle a une réponse claire : les tests automatisés.

Vous vous souvenez de notre chapitre sur RSpec ? C'est ici qu'il prend toute sa valeur. Le filet de sécurité du refactoring est une bonne suite de tests. Le cycle de travail idéal est le suivant :

1. Vérifier : Lancez votre suite de tests sur le code existant. Assurez-vous que tout est au vert.
2. Refactorer : Apportez vos améliorations au code, par petites étapes.
3. Vérifier à nouveau : Relancez les tests. S'ils passent toujours, votre refactoring a réussi : vous avez amélioré la structure sans altérer le comportement. S'ils échouent, vous savez immédiatement que votre dernière petite modification a cassé quelque chose et vous pouvez la corriger facilement.

Sans tests, le refactoring est une activité risquée. Avec des tests, il devient une pratique sûre et puissante pour maintenir la qualité du code sur le long terme. C'est un pilier du développement logiciel professionnel.