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

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

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

[Invité]

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 ?

Les "bons vieux champs de bits" rendent bien des services, j'ai eu un code une fois qui gérait plus de dix variables avec chacune entre 5 et 10 cas enregistrées en bases en type INTEGER avec comme valeur 0 ou 1 et pour noms truc1, truc2, ... trucN (N de 5 à 10)

Bon, je reconnais que le dev qui m'a remplacé ne connaissait pas les champs de bits, malgré 20 ans dans l'informatique et du C

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

[grunk]

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

[sevyc64]

Les tests sont vus généralement par les décideurs (non techniques) comme une perte sèche. Pour le logiciel se lance donc sa marche , pourquoi je devrait 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 ...

Et il y a aussi quand même un bon nombre de décideurs qui considèrent encore que les personnes les mieux placées pour faire du test approfondi sont les utilisateurs en situation réelle.
En effet, quel est l'intéret de passer 3 jours à "rustiner" (même pas corriger) un gros sale bug que l'utilisateur ne verra jamais en 10 ans d'utilisation "normale" ?

[Traroth2]

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

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

[Invité]

• Ne pas livrer régulièrement (ah, les big MEPs au risque maximal)

Ah lâchez un dev pendant 3 ou 6 mois en roue libre, même avec un minimum ( réunions, git, connaissance du framework ) et on est sûr d'aller dans le mur.

2 - En maintenance, bien souvent au fil du temps, on modifie le code, mais pas les commentaires. Au final, le nouveau dev qui débarque est induit en erreur. L'effet obtenue est bien souvent pire que l'absence de code en lui même.

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

[el_slapper]

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.

[pyros]

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.

[Cincinnatus]

- présentation/traitement/appel de base mélangés,
- noms de variables non descriptifs,
- appels de la base avec les fonctions PHP spécifiques mysql_*,
- fonctions de plusieurs centaines de lignes avec de nombreuses responsabilités,
- un fichier de plusieurs milliers de lignes regroupant des dizaines de fonctions appelées de n'importe où dans l'appli