• [^] # Re: chi va piano va sano

    Posté par (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.

    Les tests sont un pré-requis pour refactoriser en toute sereinité. Mais parfois tu refactorises sans tests (tu te fais quelques sueurs, mais bon, ça fait partie du métier;)

    Du code ready-to-refactor, pour moi c'est :

    • du code propre et correctement conçu là où les algorithmes sont clairs et ne sont pas destinés a priori à être refactorisés
    • du code plus ou moins propre là où tu as identifié des pistes d'amélioration mais que tu ne les implémentes pas car pas dans l'objectif et générant plus de travail. Ce code sera avantageusement commenté avec des TODO, des HACK ou des FIXME citant auteur, date, et refactoring imaginés.
    • tu n'as jamais une couverture de test exhaustive de tous les cas possibles et imaginables ; les parties de code identifiées comme "ready-to-refactor" seront mieux testées pour qu'au moment du refactoring on ne se pose pas de question sur le comportement attendu.
    • le code "ready-to-refactor" sera idéalement encapsulé dans des fonctions ou des méthodes statiques. Ceci permet de localiser le refactoring et de définir un périmètre de test clair.
    • tu ne fais pas de méta-programmation sur ce code car c'est plus compliqué à comprendre et vu que c'est destiné à être refactorisé...
    • tu ne fais pas d'optimisation quelle qu'elle soit. (si tu as besoin d'améliorer les perfs, soit tu fais ton refactoring à ce moment-là, soit tu mets un gros cache moche par dessus "en attendant"... mais tu l'identifies comme tel)

    Exemples de cas compliqués à refactoriser :

    • si le code que tu veux/dois refactoriser est disséminé un peu partout dans tes sources, ça devient difficile à refactoriser car tu risques d'oublier des endroits ou des cas de figure.
    • si ce que tu veux refactoriser ce sont des classes complètes, le problème c'est qu'une classe embarque un état + un comportement, c'est donc plus compliqué qu'une "simple fonction" qui n'embarque qu'un comportement (sous réserve que tu n'utilises pas des variables globales, statiques ou assimilés)

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo