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, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de JavaBean 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é.
Avatar de SalutAVous SalutAVous - Membre du Club https://www.developpez.com
le 30/11/2013 à 13:20
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.



Il y a vraiment des personnes qui sont allés jusque là ?
Avatar de noirbizarre noirbizarre - Membre régulier https://www.developpez.com
le 30/11/2013 à 13:46
  • Ne pas tester
  • Ne pas savoir dire non et expliquer pourquoi aux décideurs (marketing, investisseurs,...) sur certaines fonctionnalités
  • Ne pas nommer ses variables correctement, de façon explicite
  • Ne pas avoir de guide de style
  • Ne pas partager la connaissance avec son équipe
  • Ne pas écouter les avis divergeant de son équipe
  • Voir le développement comme un sous métier et chercher à recruter le moins cher possibles
  • Ne pas utiliser de gestionnaire de sources adapté, ne pas tagger...
  • Ne pas livrer régulièrement (ah, les big MEPs au risque maximal)
  • Avoir 10000 équipes pour un même logiciel
  • Passer plus de temps dans les processes que dans la production et le test (Cycle en V, offshore...)
  • ...


La liste est longue, il serait même plus simple de demander "Comment garder le contrôle sur un logiciel ?"

J'ai envie de simplifier ma réponse:
  • Ne pas être agile
  • Ne pas tenir compte de la qualité
Avatar de wiztricks wiztricks - Modérateur 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
Avatar de Jbx 2.0b Jbx 2.0b - Membre expérimenté https://www.developpez.com
le 30/11/2013 à 14:26
On rigole mais j'ai déjà rencontré des développeurs qui faisait consciencieusement ce genre d'erreurs pour s'assurer de devenir indispensables.
Un exemple : pourquoi s'emmerder avec des enum ou des tableaux associatifs pour gérer des états, quand des bons vieux champs de bits et des masques peuvent faire le même boulot ?
Résultat un code simplement incompréhensible pour le commun des mortels (en fait l'ensemble Univers moins le développeur originel).
Ensuite pour tout soucis ou évolution la société à deux choix :
- recoder l'intégralité du logiciel (c'est ce qu'il s'est passé chez nous).
- rappeler celui qui a codé ce bousin. Qui dans le cas d'un indé peut alors fixer son prix.
Avatar de Bono_BX Bono_BX - Membre confirmé https://www.developpez.com
le 30/11/2013 à 14:59
Il y a vraiment des personnes qui sont allés jusque là ?

Oui oui, j'ai eu ça dans mon ancienne boîte.

N'utilisez pas de contrôle de version

Ou bien modifiez les tags (pour SVN), ça marche très bien aussi ("Il faut faire une correction urgente ? ha zut, je ne retrouve pas les sources de la version en prod ...").

Et je rajouterai le détournement de logiciel / API pour exploiter une faille ou leur faire faire des choses non prévues par leurs concepteurs.
Avatar de Dalini71 Dalini71 - Membre averti https://www.developpez.com
le 30/11/2013 à 15:38
Citation Envoyé par Stéphane le calme  Voir le message
[*]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 peu 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.

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.
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
le 30/11/2013 à 18:43
Ça me rappelle un projet PHP. J'avais récupéré le code d'une autre boîte, et franchement tout y est :
- utiliser des variables mal nommées
- utiliser un import avec des variables et du code qui fait qu'on ne peut pas le modifier sans tout péter
- ne pas commenter
- ne pas se servir du framework sur lequel on se base

Résultat, j'ai mis 1 mois pour comprendre qu'au final, je ne pouvais strictement rien récupérer. Et si seulement j'avais vu ça que sur un seul projet. Le problème c'est pour certains, c'est des débutants (miam... les macros Excel fait par des gens qui ne savent pas coder), et ils font ça sans vraiment s'en rendre compte. Mais ça reste quand même pire quand ça vient d'un soi-disant « expert ».
Avatar de kikotte kikotte - Nouveau Candidat au Club https://www.developpez.com
le 30/11/2013 à 18:45
Pour ma part, là où je travaille :
- on met tous les JAR de l'appli Java EE dans le dossier /lib/ de Tomcat ("Tom 4" comme dirait mon chef), comme ça, on évite se prendre la tête avec Maven ou Ant.
- on créé du coup les WAR à déployer dans Eclipse, comme ça, on a pas besoin de configurer Nexus et Jenkins.
- le tests (unitaires, non régression, etc.), c'est une perte de temps.
- le serveur de test sert de serveur de développement, et on teste en prod, c'est plus simple.
- encourager les utilisateurs à utiliser Internet Explorer en mode dégradé (W3C, c'est bien la coupe du monde de jeux vidéo, non?).

Powered by Norme ISO-1664 from La Rache !!
Avatar de mangobango mangobango - Membre actif https://www.developpez.com
le 30/11/2013 à 18:47
- mélanger les dépendances aux licences incompatibles
- autoriser plusieurs dépendances recouvrant la même fonctionnalité
- intégré dans un projet multi-plateforme des dépendances non-portables...
- importer tous les symboles localement sans discernement, comme ça on ne sait pas d'où vient qui.
- monkeypatcher à outrance
Offres d'emploi IT
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil