IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Comment obtenir un logiciel ingérable ?
Partagez votre expérience sur vos pires observations lors d'une maintenance logicielle

Le , par Stéphane le calme

36PARTAGES

10  1 
La maintenance logicielle est une tâche à laquelle les développeurs sont souvent confrontés, aussi bien dans le monde professionnel que dans le monde universitaire. Face à cet exercice qui s'avère parfois délicat, nombreux sont ceux qui recherchent des conseils sur les meilleures pratiques.

Greg Jorgensen, spécialiste en débogage, dépannage, maintien et extension des systèmes de logiciels existants, s'attaque au sujet en prenant le problème à l'envers : il a décidé de prodiguer des conseils … pour obtenir des logiciels ingérables. Son client-type est un possesseur de site web ou d'application interne, qui fait appel à lui quand son outil fonctionne plus ou moins bien et que le développeur original de l'application n'est pas disponible, les besoins de l'entreprise ont changé ou le logiciel n'a pas de suivi. « Voici quelques choses que vous pouvez faire à vos propres projets logiciels pour m'assurer du travail » dit-il avec une pointe d'amusement avant de commencer son listing.

  • N'utilisez pas de contrôle de version : quand vous ne l'utilisez pas, le prochain développeur qui passera par là devra déterminer quels fichiers font partie du système ainsi que ceux qui sont obsolètes ou font partie des sauvegardes.
  • Personnalisez votre environnement de développement à outrance : ne rendez pas la tâche facile à un autre programmeur qui viendra travailler sur le code. Exigez des versions spécifiques de langages et outils, et assurez-vous qu'elles entrent en conflit avec les versions fournies avec le système d'exploitation. Personnalisez votre Eclipse ou VisualStudio à outrance, puis écrivez des macros et des scripts qui ne fonctionnent qu'avec cette configuration.
  • Utilisez un tas de différents langages de programmation et restez à la pointe : essayez les derniers langages qui font le buzz. Tout programmeur qui se respecte peut apprendre un nouveau langage en peu de temps, alors si le prochain développeur qui viendra travailler sur votre code est novice ce n'est pas votre problème.
  • Ajoutez des dépendances à des versions spécifiques des bibliothèques et des ressources ... : mettez-y autant de code tiers partie que vous pouvez. J'ai vu le code dépendant de larges bibliothèques externes uniquement pour avoir accès à une fonction. Modifiez le code source des bibliothèques tierces afin qu'elles ne soient pas automatiquement mises à jour vers une nouvelle version, mais ne vous embêtez pas à garder vos versions modifiées sous contrôle du code source.
  • Mais ... ne protégez ou ne documentez pas ces dépendances : une mise à niveau apparemment anodine de WordPress, ou même une nouvelle version jQuery va déclencher une réaction en chaîne de défaillances. Ne faites pas que votre code recherche une version spécifique ou une copie modifiée de vos ressources externes ou des bibliothèques tiers. N'ajoutez même pas de commentaire pour vous en rappeler.
  • Ne mettez pas sur pied des plates-formes de test ou des mises en scène : ne vous embêtez pas avec un serveur de test / mise en scène. Mélangez les données de test avec des données réelles dans votre base de données.


Source : Typical Programmer

Et vous ?

Qu'en pensez-vous ? Avez-vous déjà rencontré les cas de figure qu'il décrit ?

Quelles sont les observations négatives les plus récurrentes que vous avez faites lorsque vous aviez la tâche d'une maintenance logicielle ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de pyros
Membre expérimenté https://www.developpez.com
Le 02/12/2013 à 9:54
  1. Faire développer le logiciel par des stagiaires (par tranche de 2 mois max, sinon il faut les payer)
  2. Vendre le truc à un client quelconque
  3. Embaucher un développeur avec les sous de la vente pour assurer la maintenance.
13  0 
Avatar de JavaBean
Membre habitué https://www.developpez.com
Le 30/11/2013 à 13:14
- N'utilisez jamais plus d'une lettre pour les noms de variables, ça gaspille de l'espace.
- Indentez le code de façon aléatoire, l'indentation est une perte de temps.
- Ne mettez pas de commentaires, les vrais programmeurs n'en ont pas besoin.
- Utilisez les fonctionnalités les plus absconses et obscures du langage (C++ est très bien pour ça) pour prouver votre supériorité.
10  0 
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 30/11/2013 à 13:49
Citation Envoyé par SalutAVous Voir le message
Il y a vraiment des personnes qui sont allés jusque là ?
A partir du moment ou:
  • on accepte un code qui fonctionne a peu près,
  • on souhaite être livre vite
  • payer le moins cher possible,

Tout devient possible...
Même de la viande de cheval dans ses macaronis.
- W
9  0 
Avatar de Jitou
Membre confirmé https://www.developpez.com
Le 30/11/2013 à 21:17
Pas mal toutes les recommandations déjà invoquées mais j'en rajouterai une, payez vos développeurs comme des employés administratifs et vous aurez du travail à la hauteur de vos espérances ...
10  1 
Avatar de grunk
Modérateur https://www.developpez.com
Le 02/12/2013 à 9:37
Citation Envoyé par Washmid Voir le message
J'ai commencé à parler récemment du concept de serveur de test à un de mes responsables, résultat on m'a bien fait comprendre que l'idée était stupide. Et le pire c'était que c'était lors d'une réunion où j'ai du me battre pour qu'on nous laisse déployer / compiler nos appli avec des scripts ant, car un de mes collègues y était farouchement opposé.

Alors oui, il y en a qui vont jusque là... Parce qu'ils ne savent même pas que ça existe.
Les tests sont vus généralement par les décideurs (non techniques) comme une perte sèche. Logiciel se lance donc sa marche , pourquoi je devrais dépenser une semaine de dév en plus alors que le logiciel est fini ?

On préférera dépenser 100K€ sur 2 ans en maintenance et correction de bug que 25 tout de suite et seulement 25 sur les 2 ans qui suivent ... Psychologiquement c'est comme acheter un téléphone nu à 700€ ou le payer 100€ chez ton opérateur et payer 800€ en plus après ...
9  0 
Avatar de lamaison
Membre du Club https://www.developpez.com
Le 02/12/2013 à 11:50
Le pire à mon avis :
Bien entourer son code avec une gestion des erreurs .. non gérée.
Le programme ne plantera plus jamais ( le développeur est vraiment très fort et va bénéficier d'une belle promo dans un autre service ).

Histoire vraie : quand je suis arrivé derrière, le programme était un champs de ruine entouré d'un joli papier cadeau, un vrai cauchemar.
8  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 02/12/2013 à 13:46
  • Quand j'entends le mot "retro-planning", je sors mon revolver. En gros, ça veut dire : on a déjà la date où le projet doit s'achever. Peux-tu nous faire un planning qui colle pile-poil avec cette date qu'on a décidé sans toi ?
  • Décider de délais impossible à tenir. Quand il est évident qu'il ne sera pas tenu, ajouter 2 semaines. Puis de nouveau 2 semaines. Et encore, jusqu'à ce que le projet soit fini. Résultat : les développeurs font tout à l'arrache parce qu'ils passent tout le projet (sauf les 2 dernières semaines) à penser qu'ils n'ont pas assez de temps, alors qu'au final, c'est pas plus rapide. C'est l'inverse, en fait.
  • Ne pas faire de specs. Ca, je l'ai vu souvent ces dernières années. Certaines personnes ont vraiment mal compris les principes de l'agilité et pensent que comme on a le droit de modifier les specs en cours de route, ce n'est pas la peine d'en faire. Les résultats sont invariablement catastrophiques. A rapprocher du modèle en avalanche. Certaines personnes ne se rendent pas compte que savoir ce qu'il faut faire, ça aide beaucoup, quand on doit le faire. Au pire, il faut au moins un périmètre de projet. Un projet sans specs est un projet sans fin.
  • Utiliser aujourd'hui les outils de hier parce que c'est "le standard" de l'entreprise. Quand on ne s'est pas retrouvé en 2013 en train de bosser sur un nouveau projet développé avec Struts 1, on ne peut pas comprendre...
7  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 06/12/2013 à 13:43
Citation Envoyé par cgoyeau Voir le message
Ne pas réécrire un produit qui a plus de 5 ans et qui ne correspond plus du tout aux besoins, «*ça va plus vite de le modifier que de le réécrire et puis si il existe du code qui ne sert pas, bah c'est pas grave, on ne passe pas dedans. On ne supprime pas de lignes, on sait jamais ça peut servir.».(.../...)
100% d'accord avec le reste.

Celui-ci, par contre, est un serpent de mer. Le "vieux code" a un tas d'inconvénients, mais aussi un avantage massif : il fonctionne. Et, de plus, il est généralement porteur d'innombrables corrections et ajustements qui l'ont rendu plus conforme.

Si on se contente de le jeter à la poubelle et de recommencer, alors on perd tout ce savoir-faire accumulé avec les années. Et on refera les mêmes erreurs que les anciens.

J'ai été amené à refaire au propre du code qui avait 36 ans d'âge(1972-2008). Je n'aurais jamais fait du bon travail si j'avais juste suivi les specs. J'ai ensuite fait un comparateur de résultats entre l'ancienne et la nouvelle chaine, qui m'a trouvé plus de 500 décalages. 2 étaient de vieux bugs de prods pas bien graves et jamais détectés. les 498 autres étaient des choses auxquelles personne n'avait pensé, mais que les anciens s'étaient mangé en pleine poire. Genre, pas de TIP pour les paiements à 1M€ ou plus, un type de courrier différent pour l'Alsace-Moselle, des conneries de ce genre, impossibles à prévoir tant que ça n'a pas planté. Ou qu'on a pas trouvé une différence entre le nouveau et l'ancien...

Quand on a pas les moyens de faire ce genre de vérifications(d'une manière ou d'une autre), garder l'ancien vieux et moche est généralement le bon choix.
6  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 30/11/2013 à 21:11
Citation Envoyé par SalutAVous Voir le message
Il y a vraiment des personnes qui sont allés jusque là ?
J'ai commencé à parler récemment du concept de serveur de test à un de mes responsables, résultat on m'a bien fait comprendre que l'idée était stupide. Et le pire c'était que c'était lors d'une réunion où j'ai du me battre pour qu'on nous laisse déployer / compiler nos appli avec des scripts ant, car un de mes collègues y était farouchement opposé.

Alors oui, il y en a qui vont jusque là... Parce qu'ils ne savent même pas que ça existe.
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 02/12/2013 à 9:47
Citation Envoyé par Dalini71 Voir le message
Je suis pas persuadé qu'utiliser une langage récent soit une mauvaise chose au contraire. Si ce dernier apporte vraiment quelque chose c'est tout benef'.
Faut juste faire gaffe que la personne recrutée derrière soit compétente sur ce langage.
ça dépend.

En fait, au début du projet, tu as raison. Commencer aujourd'hui un nouveau système en Scala, Ruby, ou je ne sais quel langage relativement récent(y'a sans doute encore plus récent, je ne suis plus très au jus), c'est parfaitement légitime.

Ce qui ne l'est pas, c'est de rajouter des couches et surcouches en un tas informe, et de rajouter chaque nouveau langage qui sort dès qu'il sort, au prétexte qu'il a une fonctionnalité top moumoute au poil. Au final, on perdra peut-être du temps à émuler cette fonctionnalité, mais pas autant que d'avoir à gérer plein de langages à la fois.

Y'a des applis en COBOL qui ont 40 ans d'âge et qui tournent très bien. On peut rajouter du JAVA, ou du Delphi, ou du .NET en transactionnel pour que ça soit plus beau, mais si on rajoute les 3 à la fois, on va se flinguer.
5  0