 les derniers articles |
 Index & Sommaire |
 DÉCOLLAGE ! |
 |
 Présentation du site WEB AILES |
Développeur : |
Pour vous, jeune programmeur, la phase d'intégration est avant tout une phase qui va générer les fameux "RA" (Rapport d'Anomalie) ou "FT" (Fait Technique) ou ... bref les p... de Bug, quoi! Et on vous demandera gentiment de les corriger fissa. Devinez ce qui peut alors poser d'insurmontables problèmes (entre autres) ? Le couplage entre classes, encore lui et encore gagné! (cf. également une "illustration" avec le "projet-cauchemar" : Waterfall) |
 Lisez-moi et réagissez ! |
 Écrivez à AILES ! |
 Bugs : multiples sens (Laurent Bossavit) |
 page précédente : Coder |
 Article suivant : MOE & MOA |
| Test Dans la réalité vraie, il est rare d'avoir le temps de tester unitairement chacun de vos composant, car : - vous n'avez pas l'temps! - le couplage fort entre classe vous imposerait d'écrire des centaines de "bouchons" (qui représentent les classes liées à celle que vous souhaitez tester, mais qui sont des squelettes vides de tout code, afin de les simuler). Cela est d'ailleurs dénoncé par un ancien! Résultat : il n'est pas rare de tester sa classe en l'intégrant directement avec toutes celles déjà développées (dans l'espace publique géré par une gestion de configuration, quand vous avez la chance d'en avoir une!!!) Pour les gros projets, vous avez même une équipe chargée de prendre votre code "parfait" (« un code qui ne plante pas est un code qui va planter! ») afin de l'intégrer (intégration : « rassembler tous les morceaux, appuyer sur le gros bouton rouge, regarder le programme exploser et ramasser les débris :) »). Corrections de Bugs Certaines corrections impliquent plusieurs classes développées par des personnes différentes. Plusieurs programmeurs peuvent également se retrouver à corriger une même classe un peu trop importante (c'est souvent le cas pour des classes complexes d'IHM, par exemple). Enfin, le dernier cas *sans* gestion de configuration vous permet de développer de sérieux dons de communication (« Quoi! Tu as modifié cette classe!? Mais cela fait 3 jours que je la corrige!!! Et puis tout a changé de toutes façons. Tu aurais pu me prévenir... »etc). |
Couplage again... Évidemment, on vous demande d'agir vite et bien. Vite, car ces actions correctives ne doivent pas faire exploser les prévisions initiales en terme de délais. Bien, parce qu'il s'agit de ne pas remettre en cause la modélisation conçue avant le codage. Et c'est là que réside le principal danger : Si, pour corriger, il serait si facile que C (la classe de l'article précédent et du schéma) connaisse la classe A alors que la conception a tout fait pour que les C ignore A, vous *devez* trouver une autre solution. Et ce, même si cela devient plus long à corriger (si c'est vraiment trop long, alors on peut parler d'une erreur de conception à la base!). Pourtant, c'est tellement tentant (et rapide) d'aller chercher le service dont vous avez besoin (pour la classe C) chez la classe A... En introduisant un couplage de C vers A, surtout à ce moment du projet, c'est une véritable bombe à retardement que vous créez. De même, si vous ne faites qu'apporter une évolution (via un service supplémentaire), vous devez respecter la conception initiale. Vous expérimenterez, au cours de ces évolutions, les fameux "effets de bords" : plus il y a de classes en jeu, plus une évolution (ou correction) a de chance de tout casser! Vous ferez alors vôtre, vous aussi, la devise de tout ingénieur informaticien qui se respecte, à savoir : « Mais... j'vous *juuure*, y'a pas 10 minutes, ça marchait encore! ». |
Décollage ! | Présentation du site web "AILES" |
Infos générales | articles "Informatique"