PandaLabs

La nécessité du Refactoring

23 avril 2017,   By ,   0 Comments

Quand je me suis lancé avec NodeJs il y a bientôt 2 ans… j’ai tout de suite bossé sur de l’existant : des projets avec une structure, des specs déjà lockées. Projet après projet, je me suis trimbalé ce background.

Une des choses les plus importantes est « la structure du projet ». J’avais eu comme idée d’attaquer le vif du sujet rapidement et de m’y mettre : l’impatience. Du coup, j’ai pas vraiment réfléchi : features oriented façon DDD, une structure un peu plus classique façon symfony ?

Sur le coup, j’me suis dit, je verrais plus tard… et j’ai vu plus tard… cette semaine quoi xD ! Ca fait quelques temps, je dirais une bonne année que je vois les langages côté server (php, nodejs…) comme des média de fournir de l’information à plusieurs clients. En gros, j’ai arrêté avec les Twig, les Smarty, les Volt et les templates contenus dans une grosse app php… Y a du pour et y a du contre, mais en gros, maintenant je ne fais plus que des API et j’y plug des clients frontaux.

Les pour de cette approche :

  • 100% de la logique métier est là où elle doit être
  • Si demain j’bosse avec un dev frontend, il a pas besoin de connaître le langage… Je pars du principe que le dev web frontend a de sérieuses bases en HTML/CSS/Javascript et qu’il sait faire un call XHR et traiter la réponse.
  • Changer le front du jour au lendemain n’impacte plus que le front lui-même. Repensez aux anciens projets où vous utilisez votre petit MVC classique et où vos controllers gèrent des petites exceptions par ci par là pour de l’affichage spécifique… une gestion de paramètres en session pour un background avant que vous connaissiez le localstorage ou le sessionstorage des navigateurs … eh beh là, y a plus.
  • Les tasks runners font ce que vous faisiez avant : « comment j’vais faire pour injecter mes libs selon la page demandée ? et autres considérations relous, gestion des builds, de la compression … »
  • Beaucoup plus simple à gérer les ressources de l’architecture : dupliquer les fronts ou l’API et pas l’ensemble du projet…

Les moins pour cette approche :

  • Plus de projets … avant vous aviez un github avec le projet et tout dedans… là, vous avez un projet front, un projet api, un projet backend …
  • Il y a plus d’appels réseaux : avant vous faisiez vos requêtes, construisiez la vue et crachiez le tout à la gueule du client, maintenant vous crachez une vue vide, vous chargez les données (si vous avez des problèmes de perfs, ça peut être lent, très lent…) et vous remplissez. Y a des notions de gestion de l’asynchrone, plus d’efforts côté UI pour faire patienter l’user…
  • Une sécurisation plus complexe

Bref… ça se discute, mais au moins, moi ça me convient. Ca colle au principe de « Separation of concerns ».

Et donc, quand j’ai commencé le projet… j’ai pas vu de suite que la partie publisher/subscriber allait se comporter comme… une sorte d’API. Et pourtant, c’est ni plus ni moins qu’une grosse API… Eh bah qu’à cela ne tienne, j’ai tout revu.

Ca m’a pris pas mal de longues heures… mais c’est gratifiant.

Pourquoi la refacto, c’est gratifiant en fait ?

Y a un moment, quand tu regardes la gueule de ton projet et que tu te dis « génial, ce fichier fait 5500 lignes, c’est la classe »… moi ça me fait l’effet inverse « Mais… merde, qu’est-ce que j’ai foutu ? » Ensuite, tu regardes ta structure et tu te dis « si un gosse de 10 ans comprend pas sa place en la lisant… alors personne ne peut comprendre ». Bon, OK, un gosse de 20 ans… J’ai lu pas mal de bouquins sur « les bonnes pratiques » et la première chose que tu apprends, c’est que chacun a ses petites conventions et que chacune a ses pour et ses contres. Pour ma part, j’utilise la guideline JS d’airbnb, j’évite les fonctions de plus de 10 lignes, j’évite plus de 20 méthodes par fichier, j’évite les fonctions avec plus de 3 arguments, je ne mets que des commentaires utiles et je ne raconte pas ce qui est « induit »… Si ma fonction s’appelle « getGameByUserId » … je vois pas l’intérêt d’écrire « get a game with the user id »…

On nous enlèvera pas que dans le domaine du développement, il y a une part de philosophie des mathématiques. Attention, j’dis pas « toi, tu dois comprendre les équations différentielles »… à vomir… mais dans les maths, y a une forme d’esthétisme  : « comment trouver une belle façon de résoudre un problème ».

Genre par exemple, additionner tous les nombres de 1 à 100 … ça peut vous apparaître chiant. Y a ceux qui vont y aller comme des porcs et dire « ça fait 5050 » après 15 minutes de pianotage intensif sur la calculatrice… y a ceux qui vont faire un truc sur leur TI Basic avec une boucle for… et y a ceux qui vont remarquer que chaque extrémité fait 101 (1+100 + 2+99 + 3+98 … 50+51) … et de se dire que finalement, ce n’est que 50×101 … et que ça, ça claque quand tu expliques comment tu as trouvé le résultat en environ 3 secondes.

Eh bah… la refacto, c’est pareil. Te dire que tout ce bordel, ce n’est ni plus ni rien que l’application d’un pattern connu, c’est quand même cool.

Bref… j’ai refacto 100% du code de la partie serveur de 7 wonder Online. A la place d’un fichier socket de plusieurs centaines de lignes, j’ai adopté une approche par feature, que j’ai géré les événements avec une grosse factory d’events et que ça devient lisible, compréhensible et bien plus simple à maintenir.

Voilà… c’est tout !

Un petit historique de quelques commits de ces dernières semaines…