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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Comment obtenir un logiciel ingérable ?


Sujet :

Débats sur le développement - Le Best Of

  1. #41
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par noirbizarre Voir le message
    • 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.

    Citation Envoyé par Nicam Voir le message
    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.

  2. #42
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Jbx 2.0b Voir le message
    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

  3. #43
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 388
    Points
    2 388
    Par défaut
    Citation Envoyé par 4sStylZ Voir le message
    Alors... De mon coté :
    - Des BDD différentes selon les environnements.
    - Des SGBDR différents selon les environnements. (Sybase-Oracle... *sigh*)
    - Un seul et même environnement pour le développement, la recette (mais heureusement pas la prod).
    - Une appli vendue comme étant basée sur un framework mais qui ne l'utilise pas du tout.
    - Une appli optimisée pour IE avec la google chrome-frame...
    - Plusieurs bibliothèques logiciels inconnue sur la terre, et dont la doc est en Klingon ou un truc du genre.
    - Du code condensé en développement, si si.
    - Pas de norme, pas de commentaires, et je ne saurais parler d'architecture pour un bidonville pareil.

    Et pour finir, la perle :

    - Une série de programme censés être développés de la sorte :
    1) Programmation par un AGL qui compile un code source (lisible) qui lui même est 2) recompilé dans un langage propriétaire dont les sources sont 3) détruits sur la production.

    Normalement si on veut maintenir un tel programme, il est logique de tout maintenir à partir de l'AGL...

    - Ces sources, censés être maintenu l'AGL ont étés modifiés dans le langage de milieu niveau puis recompilés. Tout les source, que ce soient de l'AGL ou ceux du niveau moyen ont étés détruits. La seule solution pour maintenir le code c'est de tester le programme et de pratiquer une rétro ingénérie (Sur deux langage différents), mais là ou tout se corse, c'est que la dernière version du programme à maintenir est sur un OS propriétaire et sur la production uniquement. Il n'y a absolument accès à aucun binaires...

    On est donc obligé de faire des tests en production pour cette rétro ingénérie...
    Bon, je crois que tu as gagné. C'est insurpassable, à mon avis.

    Mais comment on peut perdre intégralement les sources d'un projet ? Je veux dire, même en l'absence d'outil de versioning et en l'absence de backup, s'il y a plusieurs personnes qui bossent sur le projet, chacun a les sources sur son PC. Ils ont tous passé leur disque dur à la friteuse au même moment ou quoi ?

  4. #44
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 642
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 642
    Points : 30 747
    Points
    30 747
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Bon, je crois que tu as gagné. C'est insurpassable, à mon avis.

    Mais comment on peut perdre intégralement les sources d'un projet ? Je veux dire, même en l'absence d'outil de versioning et en l'absence de backup, s'il y a plusieurs personnes qui bossent sur le projet, chacun a les sources sur son PC. Ils ont tous passé leur disque dur à la friteuse au même moment ou quoi ?
    j'ai déjà vu ça - sur des docs. Le code, lui, était correctement versionné. Mais chaque développeur du projet(nous étions 4) avait fait sa petite doc. Puis l'avait envoyé au chef. Seul moi l'avait gardée sauvegardée. Le disque dur du chef à grillé, et je suis resté tout seul en maintenance. 25 jours de boulot pour refaire la doc de mes 3 camarades partis - et ayant tous conscienscieusement nettoyé leur PC(heureusement, c'était un petit projet, sinon j'en aurais eu pour deux ans).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #45
    Membre éprouvé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    novembre 2011
    Messages
    311
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 311
    Points : 1 027
    Points
    1 027
    Par défaut
    Mais comment on peut perdre intégralement les sources d'un projet ? Je veux dire, même en l'absence d'outil de versioning et en l'absence de backup, s'il y a plusieurs personnes qui bossent sur le projet, chacun a les sources sur son PC. Ils ont tous passé leur disque dur à la friteuse au même moment ou quoi ?
    Sur l'agl en question, aucun code n'est fait en local, on développait du client-serveur et tout code était saisie via un éditeur faisant parti de l'agl et le code envoyé sur un serveur de source contenant absolument tout le projet.

    Il y'avait des backup mais l'appli a été développé de 92 à maintenant, et les cd de backup de ce programmes trop vieux ont étés égarés.

    ---

    Un vieil ami me racontait qu'il bossait dans une grande banque et à l'époque il était développeur sur certains projets et bossait en free lance.

    Il se pointe à la cafet' et un mec lui sort :

    - Tiens toi le programmateur! (j'en rajoute un peu mais bon on vous l'a déjà faite )...

    - J'ai un petit truc à te demander, voila, je suis là depuis 2 ans et on m'a demandé de changer les bandes magnétiques et de les stocker tout les matins, et j'ai toujours eu un drôle de message.

    Mon vieil amis vas voir l'IBM system 3X (qui en gros stocke des données bancaires vraiment, vraiment importantes...) et voit le message qui ressemblait approximativement à (pardonnez mon Anglais) :
    "Error : recorder failed: no archived data".

    Deux ans que le gus archivait des bandes vierges à la place des backup.

  6. #46
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 4
    Points : 15
    Points
    15
    Par défaut
    - Réutilisez vos variables ! Quand on n’a plus besoin de $adresse_ip, on peut bien y stocker un numéro de téléphone...

    - Faites le moins de fonctions possible. Une seule fonction à laquelle on donne en paramètre ce qu’elle doit faire, c’est tellement plus fun à relire... Et ça donne une fonction qui sait tout faire ! Trop bien, non ?

  7. #47
    Membre averti
    Profil pro
    Inscrit en
    juin 2006
    Messages
    179
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 179
    Points : 387
    Points
    387
    Par défaut
    Citation Envoyé par Xavtak Voir le message
    - Réutilisez vos variables ! Quand on n’a plus besoin de $adresse_ip, on peut bien y stocker un numéro de téléphone...

    - Faites le moins de fonctions possible. Une seule fonction à laquelle on donne en paramètre ce qu’elle doit faire, c’est tellement plus fun à relire... Et ça donne une fonction qui sait tout faire ! Trop bien, non ?
    Évidemment, si tout est au même endroit, quoi que tu cherches tu sais où le trouver !

  8. #48
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    mars 2007
    Messages
    579
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 579
    Points : 1 582
    Points
    1 582
    Par défaut
    Lorsqu'on voit ce genre de code, il y a des bouées pour rester zen :

    Working Effectively with Legacy Code et Clean Code: A Handbook of Agile Software Craftsmanship.

  9. #49
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juillet 2012
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2012
    Messages : 5
    Points : 8
    Points
    8
    Par défaut
    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.».

    On récupère du code non documenté et non testé, vu sur le net sur un site pas connu. Si l'auteur dit que ca marche alors c'est que ca marche

    Pas de commentaire dans le code, les commentaires c'est pour les nuls.

    Pas de schéma de l'architecture du produit, pareil c'est pour les nuls.

    Faut faire des docs, des specs, DAIs..... qu'il ne faudra surtout pas mettre à jour au fur et à mesure des évolutions. Comme ça on ne pourra pas nous dire qu'on n'a pas fait de doc.

    En C++ on fait pas tous les constructeurs nécessaires ni les destructeurs (par copie, et les autres). Ça prend du temps et ça sert à rien. Pour récupérer la mémoire (qui coûte rien), t'as qu'a rebooter le poste...

    Vendre un truc au client qui sert à rien, mais qui oblige à dupliquer beaucoup de code car c'était pas prévu et on n'a pas le temps de faire propre.

    Utiliser au maximum Ctrl C, Ctrl V, c'est plus simple et çà va plus vite que de réfléchir.

    Et "y'en" a d'autres.......

  10. #50
    Membre régulier

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2008
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 24
    Points : 113
    Points
    113
    Par défaut Le quotidien.
    C'est ce que je vois tous les jours sur un nombre incalculable de projets.
    Des architectures détruites par des interventions et des modifs réalisées par du personnel débutant ou incompétent.
    Une inconscience en ce qui concerne la robustesse ou la qualité du code, le règne du "je m'en foutisme".
    Le non respect des règles de base du développement logiciel.
    L'incompétence et la pratique du "parapluie" de la part des responsables projet et des clients.
    Le "tout, tout de suite et pour rien" pratiqué dans les entreprises.
    Le fait que le développement logiciel n'est plus un plaisir et une passion, mais seulement un gagne-pain.
    Croire qu'un informaticien à la connaissance et la compétence universelle, dans les métiers clients et dans le vaste domaine de la science informatique.
    Le manque de rigueur et la pratique du n'importe quoi.

  11. #51
    Membre régulier

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2008
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 24
    Points : 113
    Points
    113
    Par défaut
    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.».

    On récupère du code non documenté et non testé, vu sur le net sur un site pas connu. Si l'auteur dit que ca marche alors c'est que ca marche

    Pas de commentaire dans le code, les commentaires c'est pour les nuls.

    Pas de schéma de l'architecture du produit, pareil c'est pour les nuls.

    Faut faire des docs, des specs, DAIs..... qu'il ne faudra surtout pas mettre à jour au fur et à mesure des évolutions. Comme ça on ne pourra pas nous dire qu'on n'a pas fait de doc.

    En C++ on fait pas tous les constructeurs nécessaires ni les destructeurs (par copie, et les autres). Ça prend du temps et ça sert à rien. Pour récupérer la mémoire (qui coûte rien), t'as qu'a rebooter le poste...

    Vendre un truc au client qui sert à rien, mais qui oblige à dupliquer beaucoup de code car c'était pas prévu et on n'a pas le temps de faire propre.

    Utiliser au maximum Ctrl C, Ctrl V, c'est plus simple et çà va plus vite que de réfléchir.

    Et "y'en" a d'autres.......
    C'est exactement ce que j'ai pu constater dans beaucoup de projets dans des grands groupe et des banques.
    Mais là le code en C++ bourré de patchs datait de 1995 !!!!
    Ingérable.
    Mais là c'est de la faute aux développeur, jamais aux responsables projets et à la direction.

  12. #52
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 642
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 642
    Points : 30 747
    Points
    30 747
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  13. #53
    Membre expérimenté
    Avatar de Jarodd
    Profil pro
    Inscrit en
    août 2005
    Messages
    845
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 845
    Points : 1 683
    Points
    1 683
    Par défaut
    Je me suis bien marré sur ce billet (et sur les commentaires), ça a réveillé des souvenirs d'anciens projets

  14. #54
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 476
    Points : 4 746
    Points
    4 746
    Billets dans le blog
    6
    Par défaut
    moi mon problème c'est mon patron qui mélange tout le temps des données de test avec des données de prod et je passe des heures à trier

    quand au vieux code git est la pour me le ressortir
    je garde pas le vieux code dans mes fichiers plus de 2 itérations sinon j'ai trop de ligne à lire ^^
    Rien, je n'ai plus rien de pertinent à ajouter

  15. #55
    Membre régulier
    Homme Profil pro
    Ingénieur
    Inscrit en
    octobre 2006
    Messages
    48
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Transports

    Informations forums :
    Inscription : octobre 2006
    Messages : 48
    Points : 97
    Points
    97
    Par défaut
    - ajouter des commentaires inutiles comme la date du jour où vous modifiez chaque ligne de code
    - utiliser des variables globales au programme et écrire des fonctions sans paramètre ni retour pour gagner en performances
    - ne pas utiliser au maximum le standard mais systématiquement chercher à le réimplementer sur chaque projet afin de toujours s'adapter au plus près du besoin
    - mélanger vos "modifications personnelles", vos tests et le code spécifique à vos applications dans vos livraisons de code de composants réutilisables
    - ne jamais documenter vos api externes. Préférez documenter d'obscures api internes a base de doxygens incomplets

    ... et j'en passe

  16. #56
    Membre averti

    Inscrit en
    juin 2008
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 307
    Points : 364
    Points
    364
    Par défaut
    commenter le code qui n'est plus utilisé ou l'ancienne morceau de fonction qui vient d'être ré écrit. Résultat au bout de plusieurs années, on arrive a des fichiers de plusieurs milliers de lignes avec la moitiée qui sont des commentaires.

    La réponse qui m'a fait bien rire c'est que le développeur qui faisait ca le justifiait en indiquant que pour revenir en arrière en cas de problème/bug c'était plus simple.....

  17. #57
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2007
    Messages
    863
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2007
    Messages : 863
    Points : 1 485
    Points
    1 485
    Par défaut
    Petite pierre a l'edifice:

    Avoir un projet en vbnet en prod mais pas avec les options explicites et autres:
    => solution qui ne compile pas mais ou les pages s'executent
    => sources sur le repo qui ne sont pas celles en prod
    => deploiment 'Only the brave'


    Sinon special trick: avoir plein de services/executables partout qui pointent vers la prod mais qui s'executent depuis
    => la recette ( classique)
    => un serveur random (comment ca t'as pas lu le memo ? )
    => le pc de Francis (il ya toujours un Francis)
    => et en prime on a plus les sources de ces executable


    Bien sur tous cela est du vecu

Discussions similaires

  1. comment obtenir un polynome de regression
    Par evariste_galois dans le forum Mathématiques
    Réponses: 17
    Dernier message: 19/01/2007, 15h06
  2. Comment obtenir le nom d'un pc sur un réseau?
    Par Depteam1 dans le forum MFC
    Réponses: 2
    Dernier message: 19/02/2004, 10h17
  3. Réponses: 5
    Dernier message: 18/01/2004, 16h25
  4. Comment obtenir l'heure du serveur avec flash ?
    Par Michaël dans le forum Flash
    Réponses: 9
    Dernier message: 23/12/2003, 17h50
  5. Comment obtenir la liste des paramètres d'une SP ?
    Par Le Gritche dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 14/03/2003, 16h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo