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 ?
![Où est donc le problème ? Où est donc le problème ?](https://www.itpro.fr/wp-content/uploads/2014/08/9dd9d068ac26d4419fde428f5d20040a.jpg)
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 cette ressource
![Comment lutter contre le Phishing ?](https://www.itpro.fr/wp-content/uploads/2024/07/Special-Report-Eviden-Securite-Phishing-Juillet-2024.png)
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Stimuler l’innovation durable grâce à la transformation numérique et aux principes ESG
- Retour au bureau avec Copilot M365
- Les entreprises optent pour des solutions durables
- Le rôle clé du no-code/low-code dans la transformation numérique
- Le rôle de l’intelligence Artificielle dans le Cloud Computing
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)