> Tech > Où est donc le problème ?

Où est donc le problème ?

Tech - Par iTPro - Publié le 24 juin 2010
email

Ce modèle est simple à coder et simple à lire. C’est un bon exemple pour des programmeurs écrivant leur premier programme interactif, parce qu’il est facile à comprendre. Mais, dans la pratique, il n’est pas si parfait : simple à écrire mais difficile à maintenir. Mon entreprise a des centaines

Où est donc le problème ?

de programmes qui doivent lire et écrire des données client. Si je veux changer mon fichier client, chaque programme écrit de la sorte devra être analysé, modifié et retesté !

Que se passe-t-il quand je veux modifier des clients provenant d’un programme différent ? Peut-être que quand une commande est placée dans mon programme de saisie de commandes, elle devrait automatiquement afficher l’écran de modification afin que l’opérateur puisse vérifier (et, si nécessaire, changer) le nom et l’adresse du client. Maintenant, je dois modifier mon programme afin qu’il reçoive le numéro de client comme paramètre au lieu de le demander sur le second écran. Ou peut-être devrais-je écrire un programme « edit » entièrement nouveau séparé de celui-ci. Après quoi, j’aurai deux programmes à maintenir et deux endroits où modifier ma logique en cas de changements de stratégie.

Et si ma société décide d’accepter des commandes sur le Web? Dois-je écrire encore un autre module de modification de clients ?

Il est certain que d’autres applications, outre le programme de maintenance, extrairont aussi le nom et l’adresse d’un client. D’où l’idée de réutiliser ces parties de mon programme sans être obligé de les réécrire à chaque fois. Bien sûr, je pourrais copier et coller le code d’un programme dans un autre, ou même utiliser la directive de compilateur /COPY pour rassembler différents morceaux du programme, mais je me retrouve quand même avec un grand nombre d’objets programmes utilisant tous le même code. Si je modifie le code dans un endroit, je dois le modifier partout ailleurs pour que les règles de gestion s’appliquent de manière homogène. Dans le cas de /COPY, si je le change, je dois tout retester sous peine de voir un programme défaillir.

Quand tout changement exige beaucoup d’analyse et de nouveaux tests, il y a un problème. Votre système est trop rigide. Vous craignez tellement de perturber le code existant que vous répugnez à effectuer des changements pourtant bénéfiques. C’est le monde à l’envers : l’entreprise subordonne ses règles de gestion aux contraintes informatiques, plutôt que l’inverse.

Téléchargez gratuitement cette ressource

Guide de Services Cloud Managés

Guide de Services Cloud Managés

Accélérer votre transformation digitale, protéger et sécuriser vos environnements Cloud avec les offres de support, d'accompagnement et de services managés. Découvrez le TOP 3 des Services Managés pour accompagner la transformation de vos environnements Cloud, gagner en agilité et en sécurité dans un monde d'incertitudes.

Tech - Par iTPro - Publié le 24 juin 2010