Contexte
Au fil des mois, le code évolue. De nouvelles fonctionnalités sont ajoutées. Des anomalies sont corrigées. Les personnes qui font ces modifications ne sont, généralement, pas celles qui ont créé le logiciel.De peur d'introduire des erreurs, il arrive souvent que, pour une correction, on neutralise des portions de code, on ajoute de nouvelles variables redondantes avec des variables existantes. Des fichiers entiers deviennent inutilisés. Dans les cas extrêmes, on arrive à une situation où - on maintient du code qui n'est plus utilisé
- on maintient plusieurs copies d'un même code sans le savoir
- on ne sait pas récupérer des parties réutilisables dans un code existant car tout est lié
Il est possible d'éviter une telle situation ou de la corriger par quelques actions correctives. Suppression du code inutiliséLa localisation, puis la suppression de tout ce qui est inutile dans un logiciel permet de le simplifier et de faciliter, par la suite, sa maintenance. Ce code peut être : - des fichiers qui ne sont plus utilisés
- du code inaccessible
- des fichiers inclus alors qu'ils ne contiennent aucune information utile
- des sous-programmes inutilisés
- des variables inutilisées
- des paramètres de sous-programmes inutiles.
Cliquez ici pour en savoir plus.Réorganisation des informations Les développeurs ont souvent l'habitude, en phase de maintenance, de mettre les corrections dans un minimum de fichiers pour limiter l'impact des changements. De ce fait, des données se trouvent déclarées dans des fichiers où elles ne devraient pas être ; du code de sous-programmes se retrouve également dans des environnements où il ne devrait pas être. On arrive ainsi à des applications où tous les fichiers sont liés aux autres. Elles deviennent de plus en plus difficile à maintenir. Il est possible de localiser des informations qui ne sont pas à leur place et, par un simple changement de localisation de déclarations, de rendre un code beaucoup plus modulaire. Cliquez ici pour en savoir plus. Recherche des souches communes aux applications
Si une application est une variante d'une autre et que son code a été réalisé en copiant le code de la première puis en l'adaptant, on finit par obtenir deux applications dont on ne connait plus la partie commune. Des défauts sont corrigées dans l'une sans être corrigés dans l'autre. Quand une troisième variante doit être réalisée, on ne sait pas de quelle souche partir. Il est possible d'identifier toutes les parties communes à deux variantes d'une application. Ces parties communes sont - des fichiers de même nom avec des contenus strictement identiques (aux commentaires et à la présentation près)
- des fichiers de même nom avec des contenus très proches
- des fichiers de noms différents mais avec des contenus proches
On peut reconstituer ainsi une souche commune qui va simplifier la maintenance et la création de nouvelles variantes. Cliquez ici pour en savoir plus.
| 
