Affichage des résultats du sondage: Quels sont les meilleurs conseils pour bien déboguer son code ?

Votants
54. Vous ne pouvez pas participer à ce sondage.
  • Beaucoup utiliser la fonction Print

    23 42,59%
  • Commencer avec un code qui fonctionne déjà

    13 24,07%
  • Exécuter votre code à chaque petit changement

    21 38,89%
  • Bien lire les messages d'erreur

    33 61,11%
  • Rechercher le message d'erreur sur Google

    16 29,63%
  • Deviner et vérfier

    7 12,96%
  • Déguiser votre code en commentaire

    8 14,81%
  • Effectuer une recherche dichotomique

    5 9,26%
  • Faire une pause et s'éloigner du clavier

    29 53,70%
  • Savoir comment demander de l’aide

    14 25,93%
  • Autres (à préciser dans les commentaires)

    12 22,22%
  • Pas d'avis

    1 1,85%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
  1. #61
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 402
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 402
    Points : 7 022
    Points
    7 022

    Par défaut

    Citation Envoyé par Songbird_ Voir le message
    Je rejoins marco46 concernant les tests unitaires, par contre un peu moins d'accord sur le fait que "pas de test unitaire => amateur".
    C'est le point de vue de Uncle Bob, et je suis assez d'accord avec lui.

    Si tu n'as pas d'automatisation de tes tests, ça veut dire que tu les fais à la main. Ton cycle de feedback (entre modification du code et vérification) est potentiellement très long, et tu n'as aucune garantie que la couverture soit suffisante. Effectuer ce test à la main c'est de l'amateurisme, c'est pour moi parfaitement indiscutable, c'est du même ordre que réinventer la roue en permanence (ne pas utiliser de librairies ou de frameworks), c'est même pire puisqu'on fait manuellement des opérations qui sont automatisables facilement. Bref c'est une perte de temps sèche et également une absence de qualité indigne d'un pro.

    Je sais bien que tout le monde n'est pas d'accord sur ça, il suffit de voir le ratio +1/-1 sur mon post initial pour s'en convaincre. Et c'est encore bien pire chez les décideurs qui ont une culture du développement logiciel très superficielle (pour rester poli).

    Citation Envoyé par Songbird_ Voir le message
    Y'a des contextes où on ne peut utiliser correctement des TU sous peine de faire pire que si il n'y en avait pas. (e.g. faire des tests unitaires sur la communication d'une BDD, c'est possible, mais sans Mock c'est pas tellement utile, même principe pour la communication avec une infra (API))
    Les TU remplissent un besoin précis : S'assurer que le code produit fait ce qu'il est censé faire, et avoir de la visibilité sur ce statut dans le temps. En exécutant une seule commande, on peut savoir si le code fait ce qu'il est censé faire ou pas. Cela permet donc le refactoring en limitant drastiquement les risques de régression. Évidemment cela suppose que les TU soient de bonne qualité.

    Maintenant faire communiquer un système avec un autre (se connecter à une BDD, se connecter à une autre application via un WS, etc ...) ça ne peut évidemment pas être couvert par un test unitaire puisque le propre du test unitaire c'est de mocker tout le contexte autour du bloc de code à tester.

    Pour ça on a les tests d'intégration qui ont pour rôle de tester que le cas passant entre 2 systèmes fonctionne. Bref, à besoin différent, solution différente
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 568
    Points : 18 689
    Points
    18 689

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    (.../...)Pour ça on a les tests d'intégration qui ont pour rôle de tester que le cas passant entre 2 systèmes fonctionne. (.../...)
    ...suivis des tests d'homologation, ou un robot simule un utilisateur crétin qui fait toutes les erreurs possibles avant de faire le bon mouvement. Je programme ce robot, et on ramasse pas mal de choses. Et quand on a des bugs en prescription de médicaments, si on les laisse passer, ça peut tuer des gens... J'ai trouvé un doublonnage de prescriptions, une fois. Pas glop.

    Dans un monde idéal, on aurait tout ça : des TU automatiques à chaque commit, suivis d'un test complet par le programmeur, suivis de tests d'intégration autant automatisés que possibles, avec un build et une exécution toutes les nuits, et enfin, repasser le robot à chaque version. Bon, partout ou je suis passé, les décideurs préfèrent le management par la panique, et c'est déjà bien d'avoir le robot pour détecter quand le programmeur n'a pas vérifié que son WPF s'ouvrai sans exploser à vide..... Quand il n'y avait pas le robot, ça partait chez le client et boum.

    Pour revenir aux TU, c'est aussi un problème de culture. Quand on a des utilisateurs qui demandent des macros excel(dans un cas ou c'est justifié, puisque 'il s'agit juste de toutouiller des données pour fournir un excel au client), mais qui refusent obstinément d'installer rubberduck, faire des TU, ça devient monstrueux. Et nettoyer l'excel de ses tests auto à chaque livraison demanderait trop de temps. Quand tu as un écosystème COBOL ou tu est le seul à faire des TU, à la fin, tu te fais tancer parce que tu livres des programmes non demandés, et qui ne tournent même pas en prod, donc qui ne servent à rien, donc tu as volé l'argent du client.

    Alors qu'en fait, non, tu a fait un système bien plus performant, et bien plus adaptatif. Quand je vois notre programmeur principal compta qui installe en direct des correctifs à chaud(chez le client, à l'hôpital) en oubliant à chaque fois de mettre à jour perforce, sans même avoir testé, et qui déjà trouve que Perforce est une insupportable atteinte à sa liberté, je crois que les TU automatisés, ce n'est pas pour demain, ici - pourtant, on a un vrai problème de qualité. Et je n'ai le droit de taper que sur l'interface, donc je le fais, c'est mieux que rien. Et on ramasse un tas de bugs - surtout à la compta.....
    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.

  3. #63
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 402
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 402
    Points : 7 022
    Points
    7 022

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    ...suivis des tests d'homologation, ou un robot simule un utilisateur crétin qui fait toutes les erreurs possibles avant de faire le bon mouvement. Je programme ce robot, et on ramasse pas mal de choses. Et quand on a des bugs en prescription de médicaments, si on les laisse passer, ça peut tuer des gens... J'ai trouvé un doublonnage de prescriptions, une fois. Pas glop.
    Pour moi c'est typiquement le genre de cas où si un mec meurt et qu'il y a procès le développeur qui a fait le con devrait se retrouver en taule exactement comme un médecin qui ne prend pas les mesures d'hygiène nécessaires ou un mécanicien qui déconne en remplaçant les freins d'un véhicule, ou encore l'industrie alimentaire qui met de la merde dans la bouffe.

    Ça s'appelle un homicide involontaire :

    Citation Envoyé par Code Pénal, Article 121-3
    [...]
    Il y a également délit, lorsque la loi le prévoit, en cas de faute d'imprudence, de négligence ou de manquement à une obligation de prudence ou de sécurité prévue par la loi ou le règlement, s'il est établi que l'auteur des faits n'a pas accompli les diligences normales compte tenu, le cas échéant, de la nature de ses missions ou de ses fonctions, de ses compétences ainsi que du pouvoir et des moyens dont il disposait.

    Dans le cas prévu par l'alinéa qui précède, les personnes physiques qui n'ont pas causé directement le dommage, mais qui ont créé ou contribué à créer la situation qui a permis la réalisation du dommage ou qui n'ont pas pris les mesures permettant de l'éviter, sont responsables pénalement s'il est établi qu'elles ont, soit violé de façon manifestement délibérée une obligation particulière de prudence ou de sécurité prévue par la loi ou le règlement, soit commis une faute caractérisée et qui exposait autrui à un risque d'une particulière gravité qu'elles ne pouvaient ignorer.
    Et vous verrez qu'on y viendra dès qu'un évènement lié à un bug informatique aura causé une catastrophe entrainant de nombreux morts, soit par une loi directe soit par jurisprudence.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  4. #64
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 402
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 402
    Points : 7 022
    Points
    7 022

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Dans un monde idéal, on aurait tout ça : des TU automatiques à chaque commit, suivis d'un test complet par le programmeur, suivis de tests d'intégration autant automatisés que possibles, avec un build et une exécution toutes les nuits, et enfin, repasser le robot à chaque version.
    Ca ça ne dépend que de nous. C'est à nous d'inclure tout ça dans nos estimations. Le donneur d'ordre demande une fonctionnalité, on lui fait une estimation. Point barre ...

    Citation Envoyé par el_slapper Voir le message
    Bon, partout ou je suis passé, les décideurs préfèrent le management par la panique
    ... et les décideurs n'ont pas à se méler de savoir comment on s'y prend parce que ce n'est pas leur métier. Ils ne pinent rien au génie logiciel, donc qu'ils ferment leur gueule sur ces sujets.

    A-t-on déjà vu le directeur d'un hôpital imposer au personnel de réutiliser les instruments de chirurgie d'une opération à l'autre par mesure d'économie ? C'est exactement du même ordre. Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  5. #65
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 101
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Et vous verrez qu'on y viendra dès qu'un évènement lié à un bug informatique aura causé une catastrophe entrainant de nombreux morts, soit par une loi directe soit par jurisprudence.
    Tu es le genre d'individu a qui je répondrais sérieusement sur un sondage traitent de l'importance de l'informatique à un stade personnel et de l'importance de l'informatique à un stade professionnel. Surement pas d'état, puisque sa n'existe pas de façons aussi organisé que les impôts.

  6. #66
    Expert éminent
    Avatar de GrandFather
    Inscrit en
    mai 2004
    Messages
    4 587
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : mai 2004
    Messages : 4 587
    Points : 7 037
    Points
    7 037

    Par défaut

    Citation Envoyé par MikeRowSoft Voir le message
    Tu es le genre d'individu a qui je répondrais sérieusement sur un sondage traitent de l'importance de l'informatique à un stade personnel et de l'importance de l'informatique à un stade professionnel. Surement pas d'état, puisque sa n'existe pas de façons aussi organisé que les impôts.
    Euh... Kamoulox ?
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  7. #67
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2013
    Messages : 1
    Points : 0
    Points
    0

    Par défaut

    Dans la catégorie de la recherche dichotomique pour chercher par exemple un commit ayant introduit une régression, une commande git qui peut être très utile : git bisect.

  8. #68
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    221
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 221
    Points : 749
    Points
    749

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    ou qui te retourne une BrolException
    J'ai un ami qui avait laissé traîner une PenisTooSmallException. Je vous laisse imaginer sa tête quand elle a été levée lors d'une défense de projet :p

  9. #69
    Rédacteur/Modérateur

    Avatar de Songbird_
    Homme Profil pro
    Bidouilleur
    Inscrit en
    juin 2015
    Messages
    307
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Bidouilleur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2015
    Messages : 307
    Points : 2 445
    Points
    2 445
    Billets dans le blog
    3

    Par défaut

    J'ai un ami qui avait laissé traîner une PenisTooSmallException.
    Ahah, ce collector.
    Avant de poster: FAQ Rust(WIP); FAQ Dart; FAQ Java; FAQ JavaFX.
    Vous souhaiteriez vous introduire au langage Rust ? C'est par ici ou ici !
    Une question à propos du langage ? N'hésitez pas à vous rendre sur le forum !

    N'hésitez pas à contribuer ou nous faire part de vos retours !
    Release Rust FAQ #7


    Ninja Gaiden meets Metal.

  10. #70
    Membre éprouvé
    Avatar de fenkys
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    356
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 356
    Points : 981
    Points
    981

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Pour moi c'est typiquement le genre de cas où si un mec meurt et qu'il y a procès le développeur qui a fait le con devrait se retrouver en taule exactement comme un médecin qui ne prend pas les mesures d'hygiène nécessaires ou un mécanicien qui déconne en remplaçant les freins d'un véhicule, ou encore l'industrie alimentaire qui met de la merde dans la bouffe.

    Ça s'appelle un homicide involontaire :



    Et vous verrez qu'on y viendra dès qu'un évènement lié à un bug informatique aura causé une catastrophe entrainant de nombreux morts, soit par une loi directe soit par jurisprudence.
    C'est déjà arrivé :

    Dans aucun des deux cas, les développeurs n'ont été inquiétés alors qu'un bug informatique est clairement la cause de ces accidents.

  11. #71
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 642
    Points : 2 286
    Points
    2 286

    Par défaut

    Citation Envoyé par fenkys Voir le message
    C'est déjà arrivé :

    Dans aucun des deux cas, les développeurs n'ont été inquiétés alors qu'un bug informatique est clairement la cause de ces accidents.
    En même temps, la justice pénale ne s'est saisie d'aucun de ces deux cas. Pour le Therac-25 il y a eu seulement une enquête non officielle en interne, et pour l'hôpital, juste un rapport de la commission régionale de conciliation et d'indemnisation.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 568
    Points : 18 689
    Points
    18 689

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Pour moi c'est typiquement le genre de cas où si un mec meurt et qu'il y a procès le développeur qui a fait le con devrait se retrouver en taule exactement comme un médecin qui ne prend pas les mesures d'hygiène nécessaires ou un mécanicien qui déconne en remplaçant les freins d'un véhicule, ou encore l'industrie alimentaire qui met de la merde dans la bouffe.

    Ça s'appelle un homicide involontaire
    Oui, mais va le prouver... Va prouver qu'il y a malveillance. D'ailleurs, les liens donnés par Fenkys montrent que c'est assez compliqué à démontrer.

    Citation Envoyé par Marco46 Voir le message
    Ca ça ne dépend que de nous. C'est à nous d'inclure tout ça dans nos estimations. Le donneur d'ordre demande une fonctionnalité, on lui fait une estimation. Point barre ...
    Allons, tu sais très bien que dans la vraie vie, ça ne se passe pas comme ça. J'ai eu à maintenir un projet, mes malheureux prédécesseurs avaient demandé 300, on leur avait donné 100.... Ca a couté bien plus que les 200 manquants en maintenance, évidemment. Mais ils sont passés quand même, et ça marchait. Impressionnant. Et malheureux, parcequ'au final, j'ai du tout refaire, ça coutait moins cher que de modifier l'appli pour prendre en compte une évolution majeure.

    Citation Envoyé par Marco46 Voir le message
    ... et les décideurs n'ont pas à se mêler de savoir comment on s'y prend parce que ce n'est pas leur métier. Ils ne pinent rien au génie logiciel, donc qu'ils ferment leur gueule sur ces sujets.
    Mais c'est leur pognon que nous consommons. D'ou les rapports de force généralement défavorables au dev, surtout dans les boites non informatiques. Maintenant que je suis en édition de logiciel, j'apprécie beaucoup quand un de mes collègues demande "Je veux bien passer à mi-temps sur ce projet, mais alors c'est une semaine sur deux, je refuse de jongler jour après jour, je ne serais pas productif", et la chef répond "c'est une bonne idée, qui d'autre veut faire pareil?" au lieu de lui hurler dessus jusqu'à ce qu'il cède.

    Et même dans ce contexte très favorable, la pression des clients(des Hôpitaux, je rappelle) fait que parfois on livre en urgence des composants qui ne sont pas encore passés par les fourches caudines de la qualité(i.e. moi ou ma collègue). Alors bon, je me souviens du milieu bancaire, ou c'était largement pire, ou on m'a tapé sur les doigts(20 minutes d'engueulade en me traitant de voleur) pour avoir fiabilisé les traitements, et je me dis que ta théorie, elle est jolie, mais elle ne colle pas au monde réel que je fréquente.

    Citation Envoyé par Marco46 Voir le message
    A-t-on déjà vu le directeur d'un hôpital imposer au personnel de réutiliser les instruments de chirurgie d'une opération à l'autre par mesure d'économie ? C'est exactement du même ordre. Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.
    Euh, comment dire..... J'ai passé une semaine dans un hôpital pourtant moins radin que les autres lors d'une installation, et j'ai vu des choses que je couvrirais du secret professionnel, mais bon, ça faisait très bricolage, pour rester poli. Pas au point que tu décris, mais pas joli-joli quand même.
    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. #73
    Expert éminent
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    mai 2013
    Messages
    1 929
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : mai 2013
    Messages : 1 929
    Points : 7 293
    Points
    7 293

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Ca ça ne dépend que de nous. C'est à nous d'inclure tout ça dans nos estimations. Le donneur d'ordre demande une fonctionnalité, on lui fait une estimation. Point barre ...

    ... et les décideurs n'ont pas à se méler de savoir comment on s'y prend parce que ce n'est pas leur métier. Ils ne pinent rien au génie logiciel, donc qu'ils ferment leur gueule sur ces sujets.

    Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.
    Encore faut-il que l'on te demande ton avis pour estimer le temps nécessaire, ce qui n'est pas le cas partout, tellement les tâches ont été fractionnées sur différents "métiers".

    Et si les "décideurs" s'appellent comme ça, c'est justement car ce sont eux qui "décident". Si c'était juste des mecs que l'on peut écouter parler sans tenir compte de ce qu'ils disent, cela ne serait pas des "décideurs". En général, il y a quand même un lien hiérarchique avec ces personnes, donc oui ,tu peux expliquer que, mais rien ne les oblige à tenir compte de ton avis, même si ce n'est pas leur métier et qu'ils n'y connaissent rien. Si ils ont décidé que tu devais le faire en X jours, car cela a été vendu comme ça au client par un mec qui n'y connait rien, et bien il faudra le faire en X jours, même si cela veut dire pas de TU.

    Tu as bien raison d'être aussi catégorique sur tes convictions, mais comme le dit el-slapper, ce n'est pas toujours aussi simple. ^^
    "The world is broken. We’re the last choking embers of a fire waiting to burn out.
    Long before our grandfathers and their fathers before them, we started pulling our planet apart in the name of progress and blind ambition.
    The greed of man has devoured this earth until there was nothing left. We watch as time eats us alive.
    A generation born to witness the end of the world..."

  14. #74
    Membre confirmé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

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

    Informations forums :
    Inscription : septembre 2016
    Messages : 132
    Points : 544
    Points
    544

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    A-t-on déjà vu le directeur d'un hôpital imposer au personnel de réutiliser les instruments de chirurgie d'une opération à l'autre par mesure d'économie ? C'est exactement du même ordre. Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.
    Le directeur d’hôpital ne va pas imposer cela car si il y a un procès par la suite, c'est pour sa pomme. Par contre, il va fournir des instruments de mauvaise qualité, avec du retard, etc. Bah oui, le personnel arrive quand même à travailler. Pas besoin de dépenser plus. Oh et puis, les chaises pour les infirmiers/ères, ça ne sert à rien de les remplacer. Ils/elles n'ont pas à s'assoir normalement. Et puis, n'achetons qu'un seul chariot par étages. Jusqu'à présent, on ne nous a rien dit. Eh oui, dans tous les milieux, l'argent, toujours l'argent. Si on veut développer quelque chose de sérieux, il faut le faire sur son temps personnel malheureusement.

    Les décideurs décident dans quelles conditions on travaille. Malheureusement pour le personnel qui n'a pas son mot à dire sauf si c'est dans la même vision que la tête de décision... Et ce n'est pas forcément qu'à cause de l'argent. Dans les associations de bénévoles humanitaires, on retrouve des fois ce même schéma. C'est juste humain.

    edit: que du true story au passage
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

  15. #75
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 101
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par GrandFather Voir le message
    Euh... Kamoulox ?
    Non, tu peux te laissé allé, aucune gravité n'est envisageable.

    Mon Lumia 550 n'a aucun bogue qui le fait planté, que des bogues de désagréments.

  16. #76
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 642
    Points : 2 286
    Points
    2 286

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    J'ai eu à maintenir un projet, mes malheureux prédécesseurs avaient demandé 300, on leur avait donné 100.... Ca a couté bien plus que les 200 manquants en maintenance, évidemment. Mais ils sont passés quand même, et ça marchait.
    C'est tout le noeud du problème.

    • Comment faire comprendre à un décideur qu'il est en train d'échanger une économie de 200 à court terme contre une perte de, disons 400 en maintenance à moyen terme + des préjudices non chiffrables dûs à des bugs ?

      Je suis d'accord que l'époque se fout royalement du moyen terme. L'approche de Marco46 (et de Uncle Bob) se heurte de plein fouet à la quête folle du profit immédiat et à la loi du financier qui règnent en ce moment. Mais pour autant, est-ce qu'on doit laisser tomber notre devoir de conseil en tant que professionnels ?


    • Par ailleurs, lorsqu'on on nous attribue 100 au lieu des 300 promis, est-on obligé de rogner sur la qualité ? Est-ce qu'on ne peut pas livrer moins de fonctionnalités ?

      Je rappelle que le point portait sur les tests unitaires, donc directement la validité du code et la détection de bugs. Que se passerait-il si par défaut les développeurs se mettaient dans un mode "qualité" au lieu de se mettre en mode "respect à tout prix des délais calculés par d'autres" ? Si on avertissait par écrit le demandeur que le délai est intenable et que rogner sur la qualité occasionnera des bugs ? A ce moment-là, l'ordre du supérieur de basculer dans l'autre mode, c'est à dire de faire sciemment de la m**** au niveau qualité, deviendra nécessairement officiel et explicite, et quelque part, le développeur se protège les miches au lieu d'être le complice tacite d'un produit plein de bugs.



    PS @el_slapper : je te pensais moins fataliste, pour le coup tu as une vision au vitriol de l'avenir de notre profession...

  17. #77
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 583
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 583
    Points : 8 454
    Points
    8 454
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par kilroyFR Voir le message
    non non je ne bave sur les debogueurs et je sais largement mieux m'en servir que les nouveaux arrivants qui ne savent coder qu'en C# sans vraiment rien maitriser dans la gestion memoire (fonctionnement GC etc).
    Je dis que c'est a utiliser en dernier recours en combinaison des logs bien sur
    Ah ben on est bien d'accord alors

    Citation Envoyé par kilroyFR Voir le message
    arf le coup du serveur de symbole et analyse du crash dump
    "en combinaison des logs bien sur"

    Citation Envoyé par kilroyFR Voir le message
    En pratique c'est artillerie lourde
    Là je suis pas d'accord. Avec Visual Studio en tous cas, c'est assez simple et rapide à mettre en place. Et quand il s'agit de trouver où se situe le déréférencement du pointeur null ou la levée d'exception, c'est très pratique. le log permet ensuite de comprendre pourquoi on en arrivé là - ça se complète.

    En embarqué, le dump ne peut parfois toujours être généré et stocké localement pour un futur export (avec les logs) quand le technicien passe. Dans ce cas les logs sont critiques non pas parce que c'est un outil plus puissant que le dump, mais parce que c'est le seul dont on dispose (nuance!).

    Citation Envoyé par kilroyFR Voir le message
    Ce que tu me racontes est ce qu'une equipe de mon taf ont mis en place (ceux la meme qui considerent que les traces sont inutiles et un soft passé par les TU il n'est nul besoin de traces quand un dump suffira).
    Je suis pas sûr de raconter la même chose, car pour moi une appli sans fichier de log, c'est de l'amateurisme, TU ou pas TU. Faut pas mettre la charrue avant les boeufs.

    Le côté "être pro", c'est vis à vis du support client. Pour l'avoir vécu, quand un soft te pète dans les pattes, et que 10 secondes plus tard, il t'informe que ton problème est corrigé et que c'est dispo à telle URL, ben moi j'ai trouvé ça très pro!

    Citation Envoyé par kilroyFR Voir le message
    Au passage j'ai pu recemment voir avoir la demonstration de la pietre efficacité du systeme... puisque meme l'outil lui meme d'analyse du dump etait foiré.
    Resultat, pour corriger un pb sur un logiciel tu te retrouves a devoir deboguer l'outil d'analyse lol !
    Si on va dans cette direction, je peux moi aussi te donner une exemple de piètre efficacité des fichiers de logs : des logs tellement volumineux (plusieurs Go) qu'il ne sont pas exploitables (ne serait-ce que les ouvrir dans un éditeur de texte) et qu'il faut coder des outils spécifiques (4 jours de dev...) pour extraire les lignes dignes d'intérêt... Et c'est tellement fréquent comme fonctionnement que y'a des produits spécialisés dans l'aggrégation et le filtrage de tout ce bruit (kibana...). Pour autant, j'en ai pas conclu (dans l'exemple précédent) que les logs étaient un mauvais outil, juste que c'était fait n'importe comment dans ce contexte.

    Ce que je contacte souvent, c'est que c'est plus facile de blâmer l'outil que de remettre en question la façon dont on l'utilise. C'est pour ça que j'ai toujours une petite alerte dans ma tête quand quelqu'un dit "ce truc là ça sert à rien c'est nul". Je ne me souviens pas d'un exemple où, après approfondissement, on ne s'est pas rendu compte que, en fait, la personne ne savait juste pas s'en servir correctement.

    Et oui, "l'etat de l'art du dev" est une façon parmi d'autres de déguiser son incompétence tout comme le terme "pragmatisme" peut servir (aussi) à cela (je ne te vise pas attention,j'ai aimé nos échanges).

  18. #78
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 583
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 583
    Points : 8 454
    Points
    8 454
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    J'ai aussi remarqué, en traitement par lots de masse(c'est certainement une mauvaise pratique en transactionnel, et aussi dans la plupart des autres contextes), qui mettre des compteurs complets, détaillés, à la fin de chaque exécution, était une pratique qui permettait de réduire fortement le temps de débug. du genre "3701 enregistrements lus, 3701 enregistrements validés, 523 clients pros ignorés, 3178 clients privés traités, 24 clients privés corrigés, 3154 clients privés inchangés, 3178 clients privés écrits". Parce-que si les chiffres ne collent pas, on sait tout de suite ou chercher. C'est un peu canulant à mettre en place, mais à la maintenance, ça fait gagner un temps fou.
    Merci pour ce partage sur comment créer des messages de logs utiles (c'est toujours pareil : c'est pas l'outil qui apporte quelque chose mais comment on le met en oeuvre).

    Et en plus, j'ai appris un nouveau mot : canulant

  19. #79
    Membre actif
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Drôme (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 179
    Points : 282
    Points
    282

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    ...
    Alors oui l'histoire des logs volumineux on a eu deja ca, voire meme a l'inverse, des gens qui te disent : je ne sais pas quoi mettre dans les logs... (alors ils logguent parce qu'on leur a dit de faire ... mais c'est completement inutile.
    Au final tu leur fait remarquer que leur logs ne servent a rien en l'etat ... et a eux de retorquer avec une mauvaise fois ... 'tu vois je t'avais dit que ca servait a rien...' ()

    => ben trace deja les erreurs fonctionnelles avec des vrais messages explicites et les exceptions ce qui evite de faire perdre du temps a l'analyse (ex: valeur lue x != valeur attendue y); bref des regles simples mais quand les gens n'ont pas le reflexe/habitude c'est difficile.
    Pour tout dire sur un composant qui nous posait pb recemment malgré de multiples relances inutiles, j'ai finalement recupére le code et fais l'analyse + ajout traces pertinentes ou il faut pour pallier aux pbs. Au final je les ai mis devant le fait accompli. Alors oui j'ai du prendre sur moi mais c'etait la seule façon (comme c'est un module que j'integre dans mes WS webapi je me suis donné le droit de regarder sur ce qui m'etait fourni).

    Et oui comme tu dis les logs en plus des TUs mais malheureusement dans ma boite j'en ai qui ont des principes et ne veulent pas en deroger meme si en pratique on voit qu'il y a des pbs (depassements budgets systematiques...).

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 568
    Points : 18 689
    Points
    18 689

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    Comment faire comprendre à un décideur qu'il est en train d'échanger une économie de 200 à court terme contre une perte de, disons 400 en maintenance à moyen terme + des préjudices non chiffrables dûs à des bugs ?
    Le concept de dette technique est bien utile, mais seulement face à des gens un minimum intelligents et ouverts. Quand on fait face à des gens qui prennent 100% de leurs décisions en fonction de leur intérêt immédiat, ça ne fonctionne pas.

    Citation Envoyé par Luckyluke34 Voir le message
    Je suis d'accord que l'époque se fout royalement du moyen terme. L'approche de Marco46 (et de Uncle Bob) se heurte de plein fouet à la quête folle du profit immédiat et à la loi du financier qui règnent en ce moment. Mais pour autant, est-ce qu'on doit laisser tomber notre devoir de conseil en tant que professionnels ?
    C'est pourquoi j'ai parfois joué au con, et quand même fait mon boulot presque comme il faut. "Livre en prod sans passer par la qualif et sans tester!!!! Désolé, chef, les livraisons urgentes, je sais pas faire, en plus les autorisations mettent deux plombes à arriver, ça ira plus vite si je fais comme d'hab(et je glisse un ou deux tests au passage, et je m'aperçois que j'avais fait une connerie que je corrige discrètement)"

    Citation Envoyé par Luckyluke34 Voir le message
    Par ailleurs, lorsqu'on on nous attribue 100 au lieu des 300 promis, est-on obligé de rogner sur la qualité ? Est-ce qu'on ne peut pas livrer moins de fonctionnalités ?
    Dans ce cas précis, non. C'était une chaine complète à monter avec une sortie bien définie, et ils n'ont pu rogner que sur les contrôles et traitement d'erreurs(j'ai un doute? Je crashe!). Le fait que quand il n'y avait pas d'erreur en entrée, tout se passait comme prévu prouve la grande qualité de l'équipe qui m'a précédé. Mais oui, dans d'autres cas, c'est la question à se poser.

    Citation Envoyé par Luckyluke34 Voir le message
    Je rappelle que le point portait sur les tests unitaires, donc directement la validité du code et la détection de bugs. Que se passerait-il si par défaut les développeurs se mettaient dans un mode "qualité" au lieu de se mettre en mode "respect à tout prix des délais calculés par d'autres" ? Si on avertissait par écrit le demandeur que le délai est intenable et que rogner sur la qualité occasionnera des bugs ? A ce moment-là, l'ordre du supérieur de basculer dans l'autre mode, c'est à dire de faire sciemment de la m**** au niveau qualité, deviendra nécessairement officiel et explicite, et quelque part, le développeur se protège les miches au lieu d'être le complice tacite d'un produit plein de bugs.
    Ben, souvent, on te montrera la porte. Mais, paradoxalement, j'ai eu quelques expériences ou on m'a demandé explicitement de faire du code sale, et ou j'ai été moins productif que si j'avais fait propre dès le départ. Je ne parle pas de TU, non, là le retour sur investissement est moins immédiat(même si réel et massif). Je parle juste de faire un code un peu organisé et pas monolithique. Eh bien dès le débogguage, faire propre est rentable. Avant même le premier passage en prod(qui dans ce cas a été la seule exécution).

    Le truc, c'est qu'on a à faire à des relations sociales. De pouvoir, en l'occurrence, mais ce qui compte, c'est que se sont des relations sociales. Les gens à l'aise avec les machines sont souvent moins à l'aise avec les humains, et se font généralement emmener là ou ils ne veulent pas aller. Par des gens dont c'est le métier que de manipuler les autres.

    Citation Envoyé par Luckyluke34 Voir le message
    PS @el_slapper : je te pensais moins fataliste, pour le coup tu as une vision au vitriol de l'avenir de notre profession...
    Bon, j'ai un peu forcé le trait. D'ailleurs, il ne s'agit pas de l'avenir, mais du passé et surtout du présent. Et il ne s'agit pas de que nos métiers, mais de tous les métiers. Je ne doute pas que l'actuaire, l'égoutier ou les publicitaire sont soumis aux mêmes tiraillements que nous, par des hiérarchies formées dans les mêmes écoles. Ou on apprend que "le management, c'est la science du contrôle"(je compte au moins 3 mensonges/contre vérités dans cette phrase courte, et j'en loupe probablement). Ma réponse à moi, c'est de résister tant que c'est possible et réaliste. Et la base de ma réponse était la suivante : les TU, c'est au-delà du possible. Même dans une bonne(mais pas parfaite, ni même excellente) boite comme la mienne.

    Je fais ce que je peux, je mets en fonctions les codes que mon collègue copie-colle partout, je documente mes crimes, j'automatise tout process qui peut l'être(et là dessus, par contre, mon collègue est très bien, même mieux que moi), je suis heureux d'ouvrir mon code à la critique et à la revue, etc..... Mais le TU, non, ça ne passera pas. Déjà, au bout de 4 ans, les tests automatiques d'interface commencent à peine à être acceptés comme autre chose que des lubies(je rappelle qu'ils ont déjà sauvé des vies), mais si je commence à mettre des TU automatisés sur les fonctions dont je me sers dans lesdits tests automatiques, j'ai 3 étages pour apprendre à voler.
    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.

Discussions similaires

  1. Comment bien déboguer son code ?
    Par D[r]eadLock dans le forum Débuter
    Réponses: 46
    Dernier message: 04/07/2013, 10h48
  2. Réponses: 145
    Dernier message: 15/02/2009, 11h51
  3. Comment bien commencer la Programmation
    Par Le_Faya dans le forum Débuter
    Réponses: 6
    Dernier message: 01/12/2006, 18h39
  4. Memory Managment dans vos programmes
    Par Clad3 dans le forum C++
    Réponses: 11
    Dernier message: 25/07/2006, 01h25

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