Remaniement de code (refactoring)

Les bénéfices que cette pratique d'ingénierie logicielle vous apporte :

  • Améliore la conception du logiciel;
  • Facilite la compréhension du code;
  • Facilite la découverte de bogues;
  • Augmente la rapidité de programmation.
Sommaire
1. Remaniement de code (code refactoring)
    1.1 Définition
    1.2 Odeurs de code (code smells)
        1.2.1. Odeurs de poissons
        1.2.2. Odeurs de mauvaises utilisations de l'orienté objet
        1.2.3. Odeurs de futur enclave au développement de votre logiciel
        1.2.4. Odeurs de code non nécessaire
        1.2.5. Odeurs de fort couplage
        1.2.6. Odeurs de lisibilité du code
    1.3. Références sur le remaniement
        1.3.1. Livres
        1.3.2. Blogues et comptes Twitter
        1.3.3. Articles
2. Remaniement de base de données (database refactoring)
    2.1. Définition
    2.2. Références sur le remaniement de base de données
        2.2.1 Livres
        2.2.2 Articles

1. Remaniement de code (code refactoring)

1.1. Définition

 Comme Martin Fowler l'explique dans son livre ("Refactoring: Improving the Design of Existing Code"), le remaniement de code (refactoring) est un changement effectué à la structure interne du logiciel dans le but de rendre le code plus facile à comprendre et moins coûteux à modifier sans changer le comportement observable du logiciel.

1.2 Odeurs de code (code smells)

 Le besoin de remaniement se fait sentir quand des odeurs de code (code smells) apparaissent. Une odeur de code est un symptôme dans le code source qui indique possiblement un problème plus profond.

Dans leur trés bon livre (Refactoring: Improving the Design of Existing Code), Kent Beck et Martin Fowler ont listé les odeurs de code en 6 groupes (voir l'article de Mika Mäntylä).

1.2.1. Odeurs de poissons
 Les odeurs de poissons sont des odeurs fortes de code directement et facilement visible :

  1. Méthodes longues (long methods) : Les méthodes devraient être courtes.
  2. Grosses classes (large classes) : Les classes devraient être petites.
  3. Longue liste de paramètres (long parameter list) : Le nombre des paramètres devrait rester restreint.
  4. Les touffes de données (data clumps) : Vous voyez un jeu d'éléments de données ensemble à plusieurs endroits, cette odeur de code a pour conséquence d'avoir des méthodes trop grosses, et de longues listes de paramètres.
  5. L'obsession des primitives (primitive obsession) : Vous observez des concepts récurrents dans votre projet qui ne sont pas des objets mais simplement des primitives (currency, ID, dates). La logique métier liée à ces concepts est étalée à travers le code. utilisez le moins possible de primitive dans votre application.
1.2.2. Odeurs de mauvaises utilisations de l'orienté objet
  1. Instructions de commutation (switch statements) : La plupart du temps, une instruction de commutation (switch) devrait être remplacée par une conception polymorphique.
  2. Champ temporaire (temporary field) : De temps en temps, vous voyez un objet dans lequel la variable d'instance n'est affectée que dans certaines circonstances. Tenter de comprendre pourquoi la variable temporaire est présente quand elle ne semble pas être utilisée peut vous rendre fou.
  3. Affiliation refusée (refused bequest) : Les enfants de classes ne veulent, ni n'ont besoin de ce qui leur est donné par leurs classes parent. Ceci signifie que la hiérarchie n'est pas adaptée.
1.2.3. Odeurs de futures enclaves au développement de votre logiciel
  1. Changement divergeant (divergent change) : Des changements non corrélés se retrouvent à affecter la même partie du code. Voir le Single Responsibility Principle.
  2. La chirurgie avec fusil à pompe (shotgun surgery) : À chaque changement, il est nécessaire d'effectuer plein de petits changements dans différentes classes.
  3. Héritage parallèle (parallel inheritance) : Lors de la création d'une sous-classe, il est nécessaire de créer une autre sous-classe dans une autre hiérarchie d'héritage.
1.2.4. Odeurs de code non nécessaire
  1. Classes de données (data classes) : Ce sont des classes sans comportement avec seulement des données.
  2. Classe fainéante (lazy class) : Une classe qui n'en fait pas assez pour mériter d'exister. Elle devrait disparaître.
  3. Code dupliqué (duplicated code): Ne pas se répéter (principe DRY).
  4. Généralité spéculative (speculative generality) : 'Oh, je pense qu'on a besoin de la capacité de faire ce genre de choses un jour.' Le résultat est la création de fonctionnalités inutiles et de la suringénierie (over-engineering).
1.2.5. Odeurs de fort couplage
  1. La convoitise de fonctionnalité (feature envy) : Une méthode est plus intéressée par une autre classe que par elle-même.
  2. Chaînes de messages (message chains) : Longue ligne de méthodes getXX(), ou longue liste de variables temporaires.
  3. L'homme du milieu (middle man) : La moitié des méthodes délèguent à une autre classe. C'est le temps de supprimer l'homme du milieu et de parler directement aux objets concernés.
  4. Intimité inappropriée (inappropriate intimacy) : Les classes trop intimes doivent être divisées.
  5. Classes alternatives avec des interfaces différentes (alternative classes with different interfaces) : Utilisez la méthode renommée ou n'importe quelle méthode qui fait la même chose avec une signature différente.
1.2.6. Odeurs de lisibilité du code
  1. Commentaires (comments) : Le code devraient être autoexpressif rendant les commentaires inutiles.
  2. Mauvais noms (bad names) : Les noms de classe et de méthode devraient exprimer l'intention du code. Cette odeur de code peut avoir comme conséquence l'apparition de commentaires dans votre code.

1.3. Références sur le remaniement

1.3.1. Livres
1.3.2. Blogues et comptes Twitter
1.3.3. Articles

2. Remaniement de base de données (database refactoring)

2.1. Définition


Le remaniement de base de données est un simple changement à un schéma de base de données qui améliore la conception tout en conservant à la fois la sémantique comportementale et informationnelle. Un remaniement de base de données est conceptuellement plus difficile qu'un remaniement de code; les remaniements de code doivent simplement maintenir le comportement sémantique alors que le remaniement de base de donées doit surtout maintenir la sémantique informationnelle.

Le processus de remaniement de base données consiste à appliquer des remaniements de base de données pour faire évoluer des bases de données existantes. L'idée est de réusiner un schéma de base de données pour une des deux raisons suivantes :
  • développer le schéma d'une manière évolutionnaire en parallèle à la conception évolutionnaire du reste du système;
  • résoudre des problèmes de conception relatifs à un schéma de base de données patrimonial (legacy).

2.2. Références sur le remaniement de base de données
2.2.1 Livres

2.2.2 Articles



L'équipe de Pyxis