Discussion :

[Stéphane le calme]

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

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 ?

[JavaBean]

- 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é.

[SalutAVous]

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à ?

[noirbizarre]

• 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é

[wiztricks]

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

[Jbx 2.0b]

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.

[Bono_BX]

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.

[Dalini71]

[*]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.

[Zefling]

Ç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 ».

[kikotte]

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 !!

[mangobango]

- 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

[terence]

Serieusement traduire STAGING par mise en scene????

[yoday38]

Par rapport à un projet que j'ai récupéré récemment :
- avoir oublié de committer son projet avant de quitter le boîte
- avoir comme seuls commentaires des choses comme ça : "Lignes merdiques mais à mettre absolument"
- mettre des noms de méthodes n'ayant rien à voir avec ce qu'elles font.

[Washmid]

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.

[Jitou]

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 ...

[SylvainPV]

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 plutôt d'accord avec ça, si ces langages sont vraiment mieux adaptés. On ne va pas utiliser éternellement les mêmes technos sous prétexte qu'on doit pouvoir coller n'importe qui au projet plus tard, sinon plus aucune innovation n'est possible. Et parfois on rend même service au prochain développeur. Personnellement, j'ai déjà découvert de nouvelles bibliothèques en reprenant des projets existants, et je les réutilise maintenant dans d'autres projets.

[23JFK]

• Ne jamais faire simple quand il y a moyen de pondre un code tarabiscoté.

[kyrilkarlier]

Bonjour à tous,

cela fait maintenant 5 ans que je fais dans de la maintenance applicative... et chez nous le service informatique à 0 € de budget .... puis que ce sont les services qui décident de payer ou non pour un logiciel !!

Du coup, lorsqu'une évolution est demandée, nous disons attention cela a un fort impact... le service répond "c'est nous qui payons, nous le voulons..."

Nous le faisons faire par l'éditeur qui rechigne aussi à le faire car c'est une belle connerie !

Au final, une gescom qui devait rester 10 voir 15 ans ne fera que 5 ans et au final également le SI a un budget un droit de veto sur tous les développements... après plus de 2M d'€ de perdu en 5 ans !

[CHbox]

Résultat un code simplement incompréhensible pour le commun des mortels (en fait l'ensemble Univers moins le développeur originel).

Généralement ça devient également incompréhensible par le dev lui-même au bout de quelques mois sans y toucher, qui te répondra cordialement qu'il n'a pas le temps lorsque tu lui demanderas des explications.

Des histoires de ce genre j'en ai vécu et entendu, certains devs qui considèrent que si leur appli compile c'est qu'elle fonctionne, d'autres qui écrivent des méthodes hyper complexes pour faire quelque chose d'assez simple, mon pire souvenir sera une méthode C# qui faisait des tonnes de boucles pour générer une requête SQL de 100 000 caractères

[Bktero]

On peut aussi citer le non-transfert de compétences.

Exemple bête (mais vécu....): un développeur travaille un an sur un projet, il démissionne, on fait 2 jours de transfert de compétences vers le nouveau développeur (si possible la dernière semaine), on attend quelques jours que le client fasse une demande et bim ! Au premier bug un peu sérieux, ou la première modification plus conséquente que changer une virgule par un point dans la génération d'un rapport, ou encore si on doit rebuilder une partie du système qui ne devait soit disant plus bouger (et qui n'était donc au menu du "transfert de compétences"), c'est panique à bord.

Pour pimenter tout ça, on peut ne pas faire de spécifications techniques ni de cahier + rapport de tests. Ainsi, quand le client demande "cette fonctionnalité a t-elle été implémentée ?", on est bien embêté pour répondre.