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

Affichage des résultats du sondage: Quel parcours préconisez-vous pour être un développeur professionnel ?

Votants
102. Vous ne pouvez pas participer à ce sondage.
  • Parcours classique (DUT, Fac, école d'ingénieur)

    93 91,18%
  • MOOC (formation en ligne ouverte à tous)

    19 18,63%
  • bootcamp (formations courtes privées)

    11 10,78%
  • Autres à préciser en commentaire

    19 18,63%
Sondage à choix multiple
  1. #161
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 369
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    Citation Envoyé par wolinn Voir le message
    J'ai longtemps utilisé un déboggeur, mais depuis quelques années, j'ai quasiment abandonné cet outil. Maintenant, je tends à considérer que c'est un outil utilisé abusivement par des débutants et programmeurs peu rigoureux, et que le recours fréquent à un déboggeur signale un problème dans le processus de développement. Cet outil a bien sa place dans l'environnement de développement, mais y recourir devrait être exceptionnel.
    Pour ce qui est de l'IDE, je sais bien ce qu'il y a en dessous, et j'ai écrit mes premiers programmes à la fin des années 70, avant que ça existe.
    Là, par contre, dans mon contexte, il ne me viendrait pas à l'idée de m'en passer, étant donné le gain de productivité apporté.
    pour ce qui est du déboggueur, je dirais que plus la pénalité pour relancer un traitement est long, et plus il est utile. Pour déplomber un batch qui dure quelques dixièmes de secondes, il peut être en effet néfaste. Pour déplomber un script de test automatique qui dure 8 heures(vécu, il y a fort longtemps), c'est juste indispensable(voire même, corriger le code à la volée, et relancer là ou ça s'est planté, pour aller voir la suite).
    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.

  2. #162
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    En fait, un débogueur, c'est pratique pour analyser un problème que l'on ne peut diagnostiquer facilement en lisant le fichier de log. Mais, si les problèmes sont trop souvent difficiles à diagnostiquer simplement à partir du fichier de log, c'est qu'il y a un problème dans le programme. Cela ne veut pas dire que les derniers développeurs qui ont récupéré le projet sont peu rigoureux. Par contre, cela veut dire qu'il y a un problème avec le programme existant.

    Quand un programme rencontre une erreur comme un chemin de dossier non accessible ou un fichier en entrée qui n'est pas au bon format, il doit signaler l'erreur de manière claire.

    Les situations inhabituelles qui ne sont pas des erreurs devraient aussi être loguées, typiquement sous la forme d'avertissements.

    Si on fait de la programmation par contrat et que l'on contrôle à l'exécution les non-respects des contrats (préconditions, postconditions et invariants), alors on facilite le diagnostic de certaines erreurs de programmation.

  3. #163
    Membre éclairé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 241
    Points : 877
    Points
    877

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    pour ce qui est du déboggueur, je dirais que plus la pénalité pour relancer un traitement est long, et plus il est utile. Pour déplomber un batch qui dure quelques dixièmes de secondes, il peut être en effet néfaste. Pour déplomber un script de test automatique qui dure 8 heures(vécu, il y a fort longtemps), c'est juste indispensable(voire même, corriger le code à la volée, et relancer là ou ça s'est planté, pour aller voir la suite).
    Mais justement, ça ne te trouble pas de considérer cela comme indispensable ?
    Parce qu'avoir besoin d'un debugger est quand même bien une indication d'une défaillance dans le développement, analyse incomplète ou simples erreurs de codage. Donc d'un échec.
    Avant d'être virtuose du debugger, ne vaudrait-il mieux pas reconsidérer le problème en amont, et réévaluer les pratiques qui ont permis l'écriture d'un programme incorrect ?

  4. #164
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 698
    Points : 6 316
    Points
    6 316

    Par défaut

    Citation Envoyé par wolinn Voir le message
    Mais justement, ça ne te trouble pas de considérer cela comme indispensable ?
    Parce qu'avoir besoin d'un debugger est quand même bien une indication d'une défaillance dans le développement, analyse incomplète ou simples erreurs de codage. Donc d'un échec.
    Avant d'être virtuose du debugger, ne vaudrait-il mieux pas reconsidérer le problème en amont, et réévaluer les pratiques qui ont permis l'écriture d'un programme incorrect ?
    C'est un peu extrémiste Un débogueur peut aussi servir à avoir "une photographie de ton programme".

    Des fois cela m'est arrivé d'utiliser un débogueur pour une raison X et de m'apercevoir qu'une variable avait des données erronées pour certains cas mais que cela ne portait pas préjudice.
    L'obsession du détail

  5. #165
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 836
    Points
    13 836

    Par défaut

    Citation Envoyé par wolinn Voir le message
    Avant d'être virtuose du debugger, ne vaudrait-il mieux pas reconsidérer le problème en amont, et réévaluer les pratiques qui ont permis l'écriture d'un programme incorrect ?
    c'est ce que j' ai essayer d'expliquer précedemment.
    Reconsidérer les problèmes en amont c'est indispensable et il faut se placer sur la phase conceptuelle du programme informatique
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  6. #166
    Membre chevronné Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 922
    Points : 2 000
    Points
    2 000

    Par défaut

    Citation Envoyé par zecreator Voir le message
    OK, je vais prendre mon exemple : J'ai appris en 3 mois Java et la POO dans le cadre d'une formation DIF à l'Université de Jussieu Pierre et Marie Curie (Paris). Il y avait un projet à rendre en fin de formation, validé par des pros du secteur. Et bien croyez-le ou pas, j'ai obtenu mon DUT et 6 mois après, j'étais embauché dans une équipe J2EE et j'ai très bien fait le job.
    Cela ne m'étonne pas du tout, Pierre et Marie Curie est une des meilleures universités de France (j'entend déjà les dents grincer, les hurlements à la discrimination ne sont pas loin). Et donc bravo.

    Citation Envoyé par Mickael_Istria Voir le message
    Pas vraiment. Je pense juste qu'on a ete touches par le manque de rigueur de la phrase qui semblait trop absolue dans un monde tres relatif. Tu aurais dis "De nombreux linuxiens utilisent encore principalement Vim et Nano pour faire du dev C ou C++", on aurait pas reagi. Mais juste ignorer 1 a 2 millions de developpeurs qui font du C++ sous Linux avec un IDE, c'est pas vraiment acceptable dans un debat. Donc on vient porter cette voix de 1 a 2 millions de developpeurs.
    Balivernes, d'ailleurs pourquoi parler des usagers de XCode ou CLion puisqu'ils n'étaient pas concernés par la démonstration. Le contexte était exactement le suivant et nulle part n'est utilisé le terme uniquement ou un quelconque sens exclusif:

    Citation Envoyé par ddoumeche Voir le message
    on utilisait déjà des IDE il y a 30 ans (plus exactement 20 ans): Visual Basic, Visual FoxPro, Turbo Pascal, VisualAge et j'en passe. Et des frameworks, que cela soit ATL ou MFC.
    Aujourd'hui les linuxiens utilisent encore des vim et nano pour leurs code C et C++. Et automake.
    Mais ce sont les lois immuables des forums de discussion, il y aura toujours quelqu'un pour voir rouge alors que tu as écris bordeaux, et qui interviendra sous un ton outré pour te faire part de faire part de sa divergence d'opinion (si possible en ne respectant pas la netiquette). Ce à quoi tu répondras brièvement parce que tu n'es pas d'humeur, vu le manquement à la netiquette. En lui conseillant poliment de mettre de l'eau dans son vin.

    Citation Envoyé par Mickael_Istria Voir le message
    Voila un gros biais de vision du marche.
    Le monde est infiniment plus grand qu'un individu, qu'une equipe ou qu'une entreprise. On ne peut en rien inferer de la popularite ou des tendances a partir d'une equipe. Faire ca c'est clairement s'exposer a de mauvaises conclusions. Des nombres et des stats fiables (ie pas base sur des sondages qui ne touchent qu'une infime partie de l'ecosysteme) sont la seule source sure; sans ca, il vaut mieux ne meme pas chercher a tirer la moindre idee generale.
    Nul biais là dedans, hormis celui de l'observation participante.

    Nom : Market_share_of_the_most_used_C_C_IDEs_in_2018_stats_and_estimates_Chromium.png
Affichages : 152
Taille : 51,6 Ko

  7. #167
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 836
    Points
    13 836

    Par défaut

    Citation Envoyé par foetus Voir le message
    Des fois cela m'est arrivé d'utiliser un débogueur pour une raison X et de m'apercevoir qu'une variable avait des données erronées pour certains cas mais que cela ne portait pas préjudice.
    L'obsession du détail
    remarque pertinente mais juste une remarque: avec un théorème mathématique par exemple le théorème de Pythagore les valeurs numériques en entrée doivent vérifier le dit théorème pour avoir le bon résultat en sortie.
    Qu'en est-il de lignes de code informatique ?
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  8. #168
    Nouveau membre du Club Avatar de Brütal
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2018
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : juin 2018
    Messages : 14
    Points : 31
    Points
    31

    Par défaut

    Citation Envoyé par ddoumeche Voir le message
    Nul biais là dedans, hormis celui de l'observation participante.

    Nom : Market_share_of_the_most_used_C_C_IDEs_in_2018_stats_and_estimates_Chromium.png
Affichages : 152
Taille : 51,6 Ko
    Bordel, Vim est à 16% XD
    Comme quoi je suis pas le seul à l'utiliser en fait

    Citation Envoyé par Mat.M Voir le message
    remarque pertinente mais juste une remarque: avec un théorème mathématique par exemple le théorème de Pythagore les valeurs numériques en entrée doivent vérifier le dit théorème pour avoir le bon résultat en sortie.
    Qu'en est-il de lignes de code informatique ?
    Alors le problème majeur pour l'informatique, c'est que les mathématiques sont exactes, alors que l'informatique (même si elle tente d'effacer ce comportement) ne peut qu'avoir une représentation discrète des nombres. Ce qui peut-être problématique pour tout ce qui est utilisation des floatants, exemple

    Ce qui fait que la plupart des théorèmes géométriques ne fonctionnent pas à 100% lorsqu'on tente de les reproduire dans un programme.
    En plus, cela peut varier en fonction d'un tas de paramètres. J'ai déjà eu un cas où un programme de rendu d'image via des lancer de rayons, rigoureusement identique sous GNU/Linux et Windows, renvoyait une image avec des trous sur certaines formes géométriques sous windows, à cause de l'approximation des floats.

  9. #169
    Membre émérite
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 249
    Points : 2 693
    Points
    2 693

    Par défaut

    Citation Envoyé par ddoumeche Voir le message
    vu le manquement à la netiquette.
    Comment ils disent les anglishs ? you made my day !

    Ca faisait longtemps que je n'avais pas vu ce terme, des débuts de "l'ère internet"... Merci donc Courtoisie et respect


    Brutal, j'ai souvenir des tracés de cercles et disques sur les ordinateurs des années 80, avec des choses qui ressemblaient plus à des intersections de rectangles qu'à des disques au sens propre. En réalité c'est toujours la même chose quasi 40 ans après, même si les matrices sont beaucoup plus fines.

    1 fil et un crayon font mieux, et sont disponibles depuis des millénaires.

  10. #170
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 369
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    Citation Envoyé par wolinn Voir le message
    Mais justement, ça ne te trouble pas de considérer cela comme indispensable ?
    Non. Question de circonstances.

    Citation Envoyé par wolinn Voir le message
    Parce qu'avoir besoin d'un debugger est quand même bien une indication d'une défaillance dans le développement, analyse incomplète ou simples erreurs de codage. Donc d'un échec.
    Ah, quand un programme n'est pas bon du premier coup, c'est un échec? Tu pisses ton programme bon d'un claquement de doigts, sans erreurs, juste parceque tu as tout bien conçu avant? Non, je demande, parceque la phase de mise au point m'a toujours paru indispensable. J'ai d'aiilleurs fait beaucoup de COBOL dans des environnements ou les débuggueurs, sont, euh, comment dire, j'ai évité, pour rester poli. Mais moi je ne crois pas que mon petit cerveau(avec un QI d'à peine plus que 140) aie la capacité pour mettre un programme informatique entier dedans. Je prépare au mieux, puis ensuite je fais la mise au point, et il y a des erreurs. Toujours. Donc je débuggue, avec ou sans outil spécialisé suivant les circonstances.

    Après, si tu me considères comme un échec, ben, comment dire..... Non, moi je considères que nous sommes des humains, avec des failles, et qu'il est normal qu'on trouve des trous dans les specs et dans le codage. Une bonne préparation permet de limiter leur nombre, pas de les éradiquer. Non, un bug au premier jet de programmation n'est pas un échec à mon sens. ça fait partie de la vie. Savoir le gérer correctement est justement ce qui permet de limiter les échecs. Et j'ai un taux de succès des projets sur lesquels je suis passé qui me permet de prétendre que ma manière de travailler fonctionne bien. Je ne dis pas que c'est la meilleure. Je dis juste qu'elle marche bien.

    Citation Envoyé par wolinn Voir le message
    Avant d'être virtuose du debugger, ne vaudrait-il mieux pas reconsidérer le problème en amont, et réévaluer les pratiques qui ont permis l'écriture d'un programme incorrect ?
    Mais c'est du blablabla, ça!!! personne n'écrit un programme de production non trivial bon du premier coup! Personne n'a le cerveau assez balèze pour faire bon du premier coup! Si tu veux dire qu'il faut se préparer avant d'attaquer, oui, bien sur. Mais il y a des limites à ce que la préparation permet de faire.

    Un exemple que je cite souvent. Un grand assureur veut refaire ses avis d'échéances parce-qu'ils sont moches. Problème, la chaine - de 36 ans d'âge - qui les génère mélange allègrement le formatage des données avec les données elles-mêmes, et est devenue inmaintenable au fil des années. Le chef de projet obtient enfin ce qu'il réclamait à cor et à cris depuis des années : le budget pour une refonte totale de la chaine. Qui est confié à el_slapper, seul prestataire assez fou pour ne pas avoir fui en courant lors de l'entretien(véridique). Difficulté additionnelle : la chaine actuelle marche du feu de Dieu, sans bugs(en fait un seul, que personne n'avait jamais détecte, et qu'on trouvera complètement par hasard), personne ne comprend comment, et surtout personne ne sait ce qu'elle fait exactement. Et la documentation a disparu avant même ma naissance(j'avais 32 ans). On sait juste que fonctionnellement, il faut faire exactement pareil, mais sans savoir ce que ce "pareil" représente.

    L'idée de base, et qu'on a fait partiellement, c'était de faire un reverse engineering complet. Mais on est vite tombé sur un os - le code était tellement spaghetti qu'il était à peu près impossible de l'analyser. Il s'st avéré bien plus rapide de repartir sur des bases saines, et de faire tourner les nouveaux algorithmes en comparant les résultats aux anciens (sur des volumétries d'un mois complet de prod, à 300 000 enregs, on couvrait absolument tout). Et en essayant de comprendre les différences. Il est certes décevant intellectuellement de se dire que 2 des algos, je ne les ai jamais pigés. Je les ai recopiés, refactorisés, rendus lisibles avec des noms de variables plus parlants que "II" "YY", genre "POSITION-CONTRAT-CLIENT" ou "MONTANT-TAXE-ASSURANCE-AUTOMOBILE", mais je ne les ai pas pigés pour autant. Tous les autres, on les a compris en les refaisant. Sur certains, j'avais passé des jours à analyser le code sans rien piger. Les réécrire et les refactoriser a pris quelques heures, et, après exécution, on les a compris et documentés proprement.

    Et ça tourne toujours comme du papier à musique, dix ans plus tard.

    Ce que je veux dire par là, c'est que chercher à faire un code parfait du premier coup, c'est souvent illusoire. Et plus le projet est complexe et difficile, et plus c'est impossible. Les outils de débugguage, que ce soit un debugger ou une simple log(mon préféré quand ça suffit, c'est à dire 90% du temps) sont là pour permettre une mise au point après avoir pondu une première version. Pour acquérir une meilleure compréhension du sujet.

    Après, ça dépend certainement des domaines. Au plus on va vers des algorithmes compliqués, et au plus une analyse préliminaire(et documentée) est indispensable. Sur du complexe, en revanche, avec des centaines de règles imbriquées, pas compliquées en elles-mêmes, mais dont l'empilement est d'une grande complexité, non, initialement écrire un programme faux n'est pas un problème. C'est un point de départ pour mise à jour ultérieure. Ca ne dispense pas d'une réflexion préalable : quelle architecture, quelle données en entrée et en sortie, quelle organisation pour ranger les algos, etc... Mais chercher à faire parfait du premier coup est contre-productif, à mon sens. Cognitivement parlant, voir un algorithme tourner est un outil puissant de compréhension.
    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.

  11. #171
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    447
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 447
    Points : 1 825
    Points
    1 825

    Par défaut

    Citation Envoyé par fredoche Voir le message
    En réalité c'est toujours la même chose quasi 40 ans après, même si les matrices sont beaucoup plus fines.

    1 fil et un crayon font mieux, et sont disponibles depuis des millénaires.
    C'est clair c'était mieux avant. D'ailleurs je vais revendre mon quad-core 3-Ghz et ressortir mon zx80. Mais demain, parce que là il y a mon cheval qui m'attend pour aller chercher de l'eau au puits communal.

  12. #172
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Sur du complexe, en revanche, avec des centaines de règles imbriquées, pas compliquées en elles-mêmes, mais dont l'empilement est d'une grande complexité, non, initialement écrire un programme faux n'est pas un problème. C'est un point de départ pour mise à jour ultérieure. Ca ne dispense pas d'une réflexion préalable : quelle architecture, quelle données en entrée et en sortie, quelle organisation pour ranger les algos, etc... Mais chercher à faire parfait du premier coup est contre-productif, à mon sens. Cognitivement parlant, voir un algorithme tourner est un outil puissant de compréhension.
    Des centaines de règles imbriquées ?! Dont l'empilement est si complexe qu'il faut voir l'algorithme tourner pour essayer de le comprendre ?!
    Ces imbrications, ont-elles été explicitement voulues ou bien viennent-elles d'un travail bâclé ?

    Il y a plein de bonnes raisons pour lesquelles il est normal qu'un algorithme soit bien plus complexe que les visions que les utilisateurs en ont. Par exemple, un utilisateur utilise une fonctionnalité X, mais pas la fonctionnalité Y. Un autre utilisateur utilise Y, mais pas X. Mais X et Y interagissent si on les utilise en même temps. Donc le développeur doit gérer cette interaction qui est une complexité qui échappe à la vision des deux utilisateurs de l'exemple.

    Mais il y a aussi des cas où la complexité algorithmique n'a pas de bonne justification. Par exemple, certains développeurs complexifient un algorithme sans le comprendre, ce qui rend l'algorithme encore moins compréhensible. On entre alors parfois dans un cercle vicieux où l'algorithme a de moins en moins de sens et devient de plus en plus impossible à maintenir. Les clients remontent alors des anomalies et l'algorithme, incompris, est modifié à l'arrache pour corriger les anomalies, mais cela en crée d'autres, tout en complexifiant l'algorithme. Petit à petit, on approche vers un état d'équilibre dans lequel l'algorithme n'a absolument aucun sens, mais « marche » dans la majorité des cas d'utilisation des clients.

  13. #173
    Membre chevronné

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 970
    Points : 2 172
    Points
    2 172

    Par défaut

    Citation Envoyé par SimonDecoline Voir le message
    C'est clair c'était mieux avant. D'ailleurs je vais revendre mon quad-core 3-Ghz et ressortir mon zx80. Mais demain, parce que là il y a mon cheval qui m'attend pour aller chercher de l'eau au puits communal.
    Attention, il ne faut pas confondre progrès et évolution. Avoir lâché le cheval pour la voiture est une évolution du moyen de se déplacer. En terme de progrès, cela n'a pas apporter grand chose de positif. C'est même plutôt nocif, ne serait-ce pour l'environnement.

    Pareil, je ne serait pas étonné que l'eau puisée dans un puit en 1800, est moins de composants nocifs que l'eau qui sort de nos robinets.

    En ce qui concerne le ZX80, je t'invite à t'y remettre, pour te remettre dans le bain du "vrai" développement, ou tu avais tout le boulot à faire, ne serait-ce pour afficher un caractère à l'écran. revenir aux sources est vraiment très bon.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  14. #174
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    447
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 447
    Points : 1 825
    Points
    1 825

    Par défaut

    Citation Envoyé par zecreator Voir le message
    Attention, il ne faut pas confondre progrès et évolution. Avoir lâché le cheval pour la voiture est une évolution du moyen de se déplacer. En terme de progrès, cela n'a pas apporter grand chose de positif. C'est même plutôt nocif, ne serait-ce pour l'environnement.

    Pareil, je ne serait pas étonné que l'eau puisée dans un puit en 1800, est moins de composants nocifs que l'eau qui sort de nos robinets.

    En ce qui concerne le ZX80, je t'invite à t'y remettre, pour te remettre dans le bain du "vrai" développement, ou tu avais tout le boulot à faire, ne serait-ce pour afficher un caractère à l'écran. revenir aux sources est vraiment très bon.
    Oui, et je t'invite à souder toi-même tes transistors pour calculer une addition, voire à construire tes lampes électroniques que tu brancheras sur ta dynamo. Revenir aux sources est vraiment très bon.

    Sinon je suis d'accord que la modernité n'implique pas forcément le progrès, mais parler du tracé de disque en confondant géométrie et géométrie discrète, ça n'a pas vraiment de sens...

  15. #175
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 369
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Des centaines de règles imbriquées ?! Dont l'empilement est si complexe qu'il faut voir l'algorithme tourner pour essayer de le comprendre ?!
    Ces imbrications, ont-elles été explicitement voulues ou bien viennent-elles d'un travail bâclé ?
    Cet empilement est souvent issu du travail législatif, auquel s'ajoutent des spécificités de la boite. Il y a des exceptions partout, dans un calcul de taxes d'assurances.

    Plus généralement, un projet informatique, c'est surtout de la maintenance sur de l'existant. On fait une version en 1972, puis on l'améliore (ou on l'adapte aux nouvelles exigences législatives), petit à petit, ça devient de plus en plus complexe, les équipes tournent, les nouveaux ont peur de casser ce qui existe, alors le refactoring devient de plus en plus rare, les modifications de plus en plus ressemblent à des verrues, les développeurs réclament un budget pour refondre le truc et le rendre à nouveau gérable, sauf que la direction ne voit pas les couts cachés(la dette technique est une analogie encore mal comprise chez nos décideurs), et on arrive en 2008 à un monstre ingérable. Et, enfin, pour des raisons extérieures, le budget pour refaire au propre.

    Mais la complexité fonctionelle reste là. La complexité de codage a été notablement diminuée. J'ai divisé par deux le nombre de lignes de codes alors même que je faisais plus long pour être plus lisible, juste en éliminant tous les doublons. Mais les innombrables règles planquées à droite à gauche, rajoutées au fil des années en fonction du besoin, sont restées. Parce-qu'elles devaient rester. La verrue qui changeait le code routage quand l'adresse client était en Alsace-Moselle? Conservée(ben oui, c'est toujours un prestataire différent pour distribuer là-bas). dédoublonnée(j'ai du la lire plus de 30 fois, non seulement c'était répété à chaque produit, mais en plus c'était répété partout le long de la chaine. Pour certains produits automobiles, ce même code était copié et exécute à 5 endroits successifs.....). Le complexe algorithme de choix du type de destinataire, conservé(même si complétement refait pour lisibilité et documenté de partout). L'algorithme fort complexe de calcul des dates pour les paiements trimestriels, conservé(et même rendu encore plus complexe pour corriger le seul et unique bug que nous avons trouvé sur l'existant, les dates au 31 Juin et 31 Septembre). L'algo à la noix de calcul de taxe, conservé. L'algo de découpage des frais sur un contrat automobile, conservé(ses trois versions ont été unifiées). Etc.....

    On est dans une logique métier. Le métier prime sur la pureté de l'algorithme. L'informatique n'est qu'un support. Le métier n'a pas à se simplifier juste pour faire plaisir à l'informaticien. Tous ces morceaux(et bien d'autres que j'ai oublié, c'était il y a 10 ans) sont exigés par un métier complexe, soumis à des règles drastiques, avec ses propres tribunaux. Et on y ajoute des choix métier délibérés(comme certains produits ou on trouve en dur dans le programme le taux d'augmentations annuelle. usqu'à 4.5% sur certains produits - décision du client. Ne pas oublier de résilier son contrat de temps en temps et de repartir à zéro, parfois, mieux vaut perdre son ancienneté.....)

    Évidemment, ce que je dis là est vrai pour une certaine palette de métiers. Mon cousin, qui travaille dans un secteur ou on lui a notamment demandé de coder un calcul de l'influence de Jupiter sur les trajectoires des satellites, lui, fait face à un problème immuable. Il peut se permettre une conception totale avant de passer à la phase de code. Les lois de la physique, auxquelles sont soumis les sats, sont immuables. Les lois du code de l'assurance, elles..... On ne peut pas se permettre de tout repenser à chaque fois, il faut trouver un juste milieu entre "je refais tout pour un changement mineur parceque sinon ça devient illisible" et "je ne change que l'absolu nécéssaire, et j'évite de casser ce qui marche".

    Citation Envoyé par Pyramidev Voir le message
    Il y a plein de bonnes raisons pour lesquelles il est normal qu'un algorithme soit bien plus complexe que les visions que les utilisateurs en ont. Par exemple, un utilisateur utilise une fonctionnalité X, mais pas la fonctionnalité Y. Un autre utilisateur utilise Y, mais pas X. Mais X et Y interagissent si on les utilise en même temps. Donc le développeur doit gérer cette interaction qui est une complexité qui échappe à la vision des deux utilisateurs de l'exemple.
    ça, je ne peux que plussoyer. C'est mon quotidien depuis que je suis entré dans le métier.

    Citation Envoyé par Pyramidev Voir le message
    Mais il y a aussi des cas où la complexité algorithmique n'a pas de bonne justification. Par exemple, certains développeurs complexifient un algorithme sans le comprendre, ce qui rend l'algorithme encore moins compréhensible. On entre alors parfois dans un cercle vicieux où l'algorithme a de moins en moins de sens et devient de plus en plus impossible à maintenir. Les clients remontent alors des anomalies et l'algorithme, incompris, est modifié à l'arrache pour corriger les anomalies, mais cela en crée d'autres, tout en complexifiant l'algorithme. Petit à petit, on approche vers un état d'équilibre dans lequel l'algorithme n'a absolument aucun sens, mais « marche » dans la majorité des cas d'utilisation des clients.
    Vrai aussi, mais il faut bien voir les contraintes économiques. Je travaille aujourd'hui dans un domaine ou parfois, les lois sont applicables rétroactivement. Spécialement en comptabilité hospitalière, il arrive plusieurs fois par an que sorte un texte applicable plusieurs mois plus tôt, et les clients se jettent sur nous(et nos concurrents) pour avoir la modification pour hier sans faute. Donc oui, on en arrive parfois à des horreurs. Mon métier aujourd'hui, en tant que qualiticien, c'est de m'assurer que la bouillie faite par les développeurs marche dans "tous" les cas d'utilisation. Pas juste dans la majorité des cas. Après, si ils font de la bouillie, c'est parce qu'ils n'ont pas souvent le temps de faire bien(et on ne peut pas dire que les clients payent bien cher).

    L'idéal serait d'avoir les textes de loi bien en amont, et de faire une préparation optimale pour limiter ce genre d'effets. Le contexte nous l'interdit.
    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.

  16. #176
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    Merci pour les précisions.

    Citation Envoyé par el_slapper Voir le message
    Vrai aussi, mais il faut bien voir les contraintes économiques. Je travaille aujourd'hui dans un domaine ou parfois, les lois sont applicables rétroactivement. Spécialement en comptabilité hospitalière, il arrive plusieurs fois par an que sorte un texte applicable plusieurs mois plus tôt, et les clients se jettent sur nous(et nos concurrents) pour avoir la modification pour hier sans faute. Donc oui, on en arrive parfois à des horreurs. Mon métier aujourd'hui, en tant que qualiticien, c'est de m'assurer que la bouillie faite par les développeurs marche dans "tous" les cas d'utilisation. Pas juste dans la majorité des cas. Après, si ils font de la bouillie, c'est parce qu'ils n'ont pas souvent le temps de faire bien(et on ne peut pas dire que les clients payent bien cher).

    L'idéal serait d'avoir les textes de loi bien en amont, et de faire une préparation optimale pour limiter ce genre d'effets. Le contexte nous l'interdit.
    À mon avis, le problème numéro 1 ne vient pas des contraintes économiques, mais de la gestion des projets de développement logiciel :
    Citation Envoyé par el_slapper Voir le message
    sauf que la direction ne voit pas les couts cachés(la dette technique est une analogie encore mal comprise chez nos décideurs)
    En effet, si un code n'a pas de dette technique alors, pour un changement urgent de fonctionnalité, on peut faire :
    • Étape 1 : modifier le code en vitesse pour que le changement soit disponible le plus tôt possible.
    • Étape 2 : rembourser tout de suite la dette technique qui s'est ajoutée à l'étape 1. Comme le code est bien couvert par les tests unitaires, on peut se permettre de faire du réusinage de code sans avoir peur de casser ce qui marche.

  17. #177
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 836
    Points
    13 836

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    On est dans une logique métier. Le métier prime sur la pureté de l'algorithme.
    ehh c'est le métier qui génére des algorithmes non ?
    Citation Envoyé par el_slapper Voir le message
    Le métier n'a pas à se simplifier juste pour faire plaisir à l'informaticien.
    stricto sensu on est tous d'accord.
    Cependant les "décideurs" et ceux qui dirigent les entreprises, les projets informatiques voudraient l'inverse.
    Un nombre élevé d'individus s'imaginent que le numérique et l'informatique bref des lignes de code c'est la panacée et la solution à tous les problèmes
    Mais la remarque est fort pertinente
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  18. #178
    Membre émérite
    Profil pro
    Inscrit en
    décembre 2003
    Messages
    1 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 249
    Points : 2 693
    Points
    2 693

    Par défaut

    Citation Envoyé par SimonDecoline Voir le message
    C'est clair c'était mieux avant. D'ailleurs je vais revendre mon quad-core 3-Ghz et ressortir mon zx80. Mais demain, parce que là il y a mon cheval qui m'attend pour aller chercher de l'eau au puits communal.
    Citation Envoyé par SimonDecoline Voir le message
    Oui, et je t'invite à souder toi-même tes transistors pour calculer une addition, voire à construire tes lampes électroniques que tu brancheras sur ta dynamo. Revenir aux sources est vraiment très bon.

    Sinon je suis d'accord que la modernité n'implique pas forcément le progrès, mais parler du tracé de disque en confondant géométrie et géométrie discrète, ça n'a pas vraiment de sens...
    Derrière ces sarcasmes il me semble distinguer une volonté farouche de te payer ma tronche.
    Alors évidemment la perche est tendue, mais quelque part tu la saisis de manière assez grossière :
    Hélas pour toi je ne confonds pas, je note que c'est justement une différence fondamentale que je peux illustrer de la même façon aujourd'hui que 40 ans en arrière. D'autant mieux que je connais cette époque lointaine et que je pratique toujours dans ce milieu aujourd'hui. professionnellement... Il y a 40 ans j'étais un gamin, un vrai morveux.

    Pour le reste tu débats avec toi-même, aucune volonté de revenir en arrière pour ma part, je vis avec mon temps, et bien même.
    Mais je sais que toujours aujourd'hui ton quad core 3 Ghz comme le ZX80 avec son zilog ne savent pas en aucune façon tracer, représenter, modéliser, imprimer, etc un simple cercle avec le niveau de perfection que je peux obtenir avec le compas de ma gamine, encore moins avec mon Staedler à vis, des outils d'aujourd'hui, que tu le veuilles ou non. Comme la ficelle et le crayon cela étant, qui sont aussi des outils d'aujourd'hui : je pourrais te citer des anecdotes à ce propos, mais tu n'en vaux certainement pas la peine.

    Visiblement tu illustres encore à merveille cet article cité dans un sujet sur le Javascript et Microsoft : sais-tu faire voler un papillon sur une page web Simondecoline ? Ne serais-tu pas un hater ? De ceux qui ne cherchent qu'à blesser d'autres programmeurs ?
    Souvenir ému : https://www.developpez.net/forums/d1.../#post10309224
    Me semblait bien que ton pseudo me disait quelque chose

    Pour le reste connaitre les sources est vraiment très bon, ça apprend l'humilité, dont tu sembles assez dépourvu, et ça permet de comprendre. Les sources, les bases, les origines, tous ces éléments indispensables pour pouvoir évoluer vers ce statut de "pro" sujet de la discussion présente... en principe.

  19. #179
    Membre chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    447
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 447
    Points : 1 825
    Points
    1 825

    Par défaut

    Citation Envoyé par fredoche Voir le message
    Derrière ces sarcasmes il me semble distinguer une volonté farouche de te payer ma tronche.
    Alors évidemment la perche est tendue, mais quelque part tu la saisis de manière assez grossière :
    Hélas pour toi je ne confonds pas, je note que c'est justement une différence fondamentale que je peux illustrer de la même façon aujourd'hui que 40 ans en arrière. D'autant mieux que je connais cette époque lointaine et que je pratique toujours dans ce milieu aujourd'hui. professionnellement... Il y a 40 ans j'étais un gamin, un vrai morveux.

    Pour le reste tu débats avec toi-même, aucune volonté de revenir en arrière pour ma part, je vis avec mon temps, et bien même.
    Mais je sais que toujours aujourd'hui ton quad core 3 Ghz comme le ZX80 avec son zilog ne savent pas en aucune façon tracer, représenter, modéliser, imprimer, etc un simple cercle avec le niveau de perfection que je peux obtenir avec le compas de ma gamine, encore moins avec mon Staedler à vis, des outils d'aujourd'hui, que tu le veuilles ou non. Comme la ficelle et le crayon cela étant, qui sont aussi des outils d'aujourd'hui : je pourrais te citer des anecdotes à ce propos, mais tu n'en vaux certainement pas la peine.

    Visiblement tu illustres encore à merveille cet article cité dans un sujet sur le Javascript et Microsoft : sais-tu faire voler un papillon sur une page web Simondecoline ? Ne serais-tu pas un hater ? De ceux qui ne cherchent qu'à blesser d'autres programmeurs ?
    Souvenir ému : https://www.developpez.net/forums/d1.../#post10309224
    Me semblait bien que ton pseudo me disait quelque chose

    Pour le reste connaitre les sources est vraiment très bon, ça apprend l'humilité, dont tu sembles assez dépourvu, et ça permet de comprendre. Les sources, les bases, les origines, tous ces éléments indispensables pour pouvoir évoluer vers ce statut de "pro" sujet de la discussion présente... en principe.
    Mince alors, tu m'as percé à jour : oui je suis un vilain hater en série. Merci de me l'avoir rappeler avec tes gentils propos insultants.

    Toutes mes excuses d'avoir pollué la discussion sur la formation des développeurs en osant critiquer ton post sur la technique de tracé de disques des jardiniers.

    Et pour en revenir à la discussion sur JS, pourquoi tu ne cites pas aussi le fil que j'ai créé ensuite, où je résume 3 jours de boulot sur le sujet en question : https://www.developpez.net/forums/d1...facage-js-cpp/ ?

  20. #180
    Membre chevronné

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 970
    Points : 2 172
    Points
    2 172

    Par défaut

    Citation Envoyé par SimonDecoline Voir le message
    Oui, et je t'invite à souder toi-même tes transistors pour calculer une addition, voire à construire tes lampes électroniques que tu brancheras sur ta dynamo. Revenir aux sources est vraiment très bon.

    Sinon je suis d'accord que la modernité n'implique pas forcément le progrès, mais parler du tracé de disque en confondant géométrie et géométrie discrète, ça n'a pas vraiment de sens...
    Toi tu ne manipules pas de Raspberry pi ? Tous les développeurs devraient avoir l'obligation de faire un projet avec un RPI, juste pour prouver qu'ils savent faire autre chose que utiliser des Api toutes faites.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

Discussions similaires

  1. Réponses: 2
    Dernier message: 11/03/2013, 14h35
  2. Réponses: 158
    Dernier message: 29/08/2011, 20h18
  3. Les meilleurs programmeurs sont-ils ceux qui disent connaître C ++ ? Pas si sûr !
    Par Katleen Erna dans le forum Langages de programmation
    Réponses: 61
    Dernier message: 26/05/2010, 12h30
  4. Réponses: 0
    Dernier message: 01/04/2010, 23h57

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