Journal Optimisez votre code !

Posté par . Licence CC by-sa
66
7
déc.
2017

Cher journal,
Je voudrais te raconter une histoire, qui n'est peut-être pas encore finie d'ailleurs, qu'on pourrait résumer en 1 mot : OPTIMISATION !

Tout commence en tout début d'année : je suis embauché chez Chacun cherche son Film, une toute petite (5, moi inclus) boite qui développe un site Web faisant la promotion du cinéma indépendant. Cette boite a fait le (très mauvais, comme on va le voir) choix de faire développer son site par une boite de prestation parisienne, qui a mis des mois à livrer son travail et qui, en plus, était bâclé !
Ils devaient notamment gérer l'import hebdomadaire des horaires de séances : tous les mardis soirs, nous recevons un fichier XML (35Mo, 400.000 lignes) contenant les 3.300 cinémas de France métropolitaine, les centaines de films projetés dans la semaine (du blockbuster au vieux film projeté 1 fois par un petit cinéma Art & Essai, dans le cadre d'une rétrospective d'un réalisateur), les 15.000 événements (1 événement = toutes les infos concernant la projection de 1 film dans 1 cinéma : VF/VO, 3D ou pas, projection 35mm/numérique/…) et les 100.000-150.000 horaires de séances.
Leur import reposait sur le système de Queue de Drupal (avec lequel ils avaient développé le site Web). Mais il était tellement mal optimisé que cela prenait jusqu'à 18 heures (!) pour tout traiter ! De plus, leur script plantait souvent en cours de traitement, nécessitant de le relancer manuellement (et quand il plante dans la nuit de mardi à mercredi, il faut donc attendre que quelqu'un s'en rende compte le matin, et relance).
Bref, les horaires de cinéma pour la semaine, qui commence le mercredi, n'étaient parfois pas totalement disponibles avant… le jeudi dans la journée !

Une de mes premières missions fut donc de corriger et d'optimiser tout ça.
Première optimisation : ne pas traiter les cinémas ou les films dont la date de dernière modification (incluses dans les attributs XML de chacun) est plus ancienne que le flux hebdomadaire précédent. Si rien n'a changé, y a rien à traiter !
Deuxième, et principale, optimisation : réécrire les 2 requêtes XPath (servant à chercher des infos sur les cinémas et films auxquels se rattache chaque horaire). Leurs requêtes XPath cherchaient dans TOUT le fichier XML, au ;lieu de ne chercher que dans les blocs des cinémas/des films.
Résultat : de 18h, on arrive à 3h.

Quelques :ois plus tard, le choix fut fait de recoder totalement le site. Les bugs étaient trop nombreux, et la boite de presta n'avait pas l'air de s'en sortir pour déboguer tout ça. Je recode donc tout en PHP (framework Laravel, mais ça n'a pas d'importance ici). Il me faut donc aussi réécrire le script d'import. Je décide alors de le faire en Python.
Résultat : de 3h, on passe à 1h30.

On a donc les horaires de séances de la nouvelle semaine disponibles dès le mardi vers 19h. Parfait ! Je décide alors d'en rester là, et de me concentrer sur d'autres priorités.

Le temps passe, les autres priorités sont traitées, et me revoilà à repenser à ce script. Ne pourrait-on pas l'améliorer encore ? Après tout, ces 15.000 événements et ces 100.000-150.000 horaires qu'on insère en autant de requêtes, c'est vraiment pas top, quand même. Ça donnerait quoi, si je faisais des INSERT multi-lignes ? Disons… 2 INSERT par cinéma, 1 pour tous les événements, l'autre pour tous les horaires.
Résultat : de 1h30, on passe à… 10 minutes !

Bref, on ne le dira jamais assez : OPTIMISEZ VOTRE CODE ! Ce n'est pas parce que ça tourne sur un serveur avec 8 cœurs que ça dépotera. Surtout quand votre script n'est absolument pas parallélisé !
Et même si je suis très fier de ce gain (d'un rapport de plus de 100 pour 1, au final), je ne peux que me désespérer de voir des codes absolument pas optimisés parce que "bof, de toute façon, le processeur en a sous la pédale !".

PS : ma modification du script n'ayant consisté qu'à stocker dans un tableau les données à insérer, et à passer ce tableau d'un coup à la requête d'insertion, la seule autre cause possible de gains de temps que je vois est l'écriture des logs (à raison d'une ligne par INSERT), qui a diminué dans les mêmes proportions que le nombre de requêtes SQL.

  • # Chacun cherche son film

    Posté par (page perso) . Évalué à 4 (+3/-0).

    Bon exemple d'optimisation simple et efficace.

    Dans le même genre : juste ajouter un "LIMIT 1" à la fin de toutes les requêtes ne concernant qu'une seule ligne. Ou 2 si c'est 2, etc…

    Quelques questions sur ton site :
    - Quel est le modèle économique ?
    - Le fichier XML des séances, c'est de l'Open Data ?

    • [^] # Re: Chacun cherche son film

      Posté par . Évalué à 5 (+3/-0).

      _ Modèle économique : aucune publicité sur le site, c'est la règle !
      Notre financement vient donc (une fois passée les subventions obtenues auprès de plusieurs organismes, au départ) uniquement des distributeurs de films. Ils nous payent pour mettre plus en avant leurs films (même si tous sont visibles, vu qu'on a tous les films qui sortent en salle).

      _ Fichier XML des séances : je doute qu'il soit en Open Data, étant donné que le fournisseur de ce fichier (Plurimedia) le fait payer (20.000€/an, de mémoire). Mis à part nous, leurs autres clients sont au moins Première et Télérama, mais pas Allociné.

      • [^] # Re: Chacun cherche son film

        Posté par . Évalué à 2 (+0/-0).

        _ Fichier XML des séances : je doute qu'il soit en Open Data, étant donné que le fournisseur de ce fichier (Plurimedia) le fait payer (20.000€/an, de mémoire). Mis à part nous, leurs autres clients sont au moins Première et Télérama, mais pas Allociné.

        Si ce sont les fichiers SMPTE, j'ai un peu travaille sur un script qui les recupere sur des milliers de cinema en Europe pour Ymagis :-)

        Je n'avais pas remarque qu'il y avait foule sur les projecteurs pour les recuperer. Ces donnees pourraient donc assez bien venir d'Ymagis.

    • [^] # Re: Chacun cherche son film

      Posté par . Évalué à 3 (+2/-0).

      Dans le même genre : juste ajouter un "LIMIT 1" à la fin de toutes les requêtes ne concernant qu'une seule ligne. Ou 2 si c'est 2, etc…

      Dans le fond, tu as raison, mais comme ça me rappelle un mauvais souvenir, je précise : en ayant mis des contraintes d'unicité là où il faut !

      • [^] # Re: Chacun cherche son film

        Posté par . Évalué à 5 (+3/-0).

        … et en rappelant également que LIMIT ne fait pas partie de la norme ! ;)

        • [^] # Re: Chacun cherche son film

          Posté par . Évalué à 6 (+4/-0).

          Se restreindre à la norme quand on code du SQL, c'est garantir que le code ne sera pas optimisé.

          C'est pour ces raisons que les ORMs implémentent la notion de dialecte, permettant un certain niveau de généricité avec des performances honorables. Et encore, l'ajustement des paramètres du serveur est parfois plus efficace que la réécriture du code…

          • [^] # Re: Chacun cherche son film

            Posté par . Évalué à 7 (+5/-0).

            Il ne s'agit pas de se « restreindre », mais bien d'agir en connaissance de cause, surtout que LIMIT est aussi utile que répandu, mais que si l'on en croit ce tableau, cette fonctionnalité serait prise en charge sur un grand nombre de SGBD mais à l'exception notable de poids lourds comme Oracle ou MS SQL.

            Du coup, si ça nous a toujours paru naturel de l'utiliser et qu'on a appris le SQL avec, on va vers certaines déconvenues.

            À l'inverse, on n'est plus obligé non plus de s'en tenir à SQL92. On peut aujourd'hui choisir de reconnaître SQL 2003 (même s'il y a eu 2008, 2011 et 2016 depuis) et profiter des fenêtres WINDOW, et même des requêtes récursives qui sont définies depuis 1999 et avec lesquelles j'ai implémenté le forum du site de mon quartier.

            • [^] # Re: Chacun cherche son film

              Posté par . Évalué à 4 (+2/-0).

              D'une part, et comme indiqué par wismerhill, ce n'est pas le standard, (je rajoute que Sybase ne le prend pas en compte non plus et il est encore très répandu le bougre, surtout dans la finance).

              D'autre part, dans la plupart des cas, un LIMIT 1 ne va pas être très efficace ; un index unique avec des statistiques à jour sera déjà suffisant pour ne pas continuer à lire la table "pour rien".

        • [^] # Re: Chacun cherche son film

          Posté par . Évalué à 2 (+0/-0).

          En effet, mais si j'en crois PostgreSQL (https://www.postgresql.org/docs/current/static/sql-select.html, j'ai la flemme d'aller vérifier dans le standard même) SQL 2008 a introduit la clause OFFSET pour remplir la même fonction.

  • # Optimisez la clarté de votre code !

    Posté par . Évalué à 10 (+23/-5).

    L'optimisation de la vitesse du traitement, c'est bien, mais la base de l'optimisation, c'est de ne jamais commencer par l'optimisation. Déjà, faire du code clair et modulaire, ça permet en moyenne de s'assurer que l'optimisation sera moins complexe car plus localisée.
    Ensuite, on ne doit optimiser que ce dont on peut mesurer la performance. Si vous n'arrivez pas à prouver quel bout de code, SQL ou quoi que ce soit est lent, faut pas se lancer dans l'optimisation. D'abord il faut ajouter des mesures de performance, puis si on se rend compte que la granularité des mesures est insuffisante, en mettre encore plus et enfin seulement optimiser.
    Enfin, l'optimisation, ça n'est pas juste un travail de développeur, c'est aussi un travail d'administrateur système, d'administrateur réseau et de DBA. Le code n'est pas la seule source de lenteur ou de performances non déterministes.

    • [^] # Re: Optimisez la clarté de votre code !

      Posté par (page perso) . Évalué à 5 (+4/-0).

      Oh que je suis d'accord.

      Je ne suis pas un vrai dev (mais un académique qui pond des scripts horribles) mais combien de temps ai-je perdu à optimiser des trucs inutiles. Rendre la maintenance plus difficile et introduire des bugs pour gagner quelques millisecondes, ça ne vaut pas le coup.

      Bon en vrai j'ai du mal à m'en empêcher parce qu'on est toujours content quand son code va super vite… Mais c'est con !

    • [^] # Re: Optimisez la clarté de votre code !

      Posté par (page perso) . Évalué à 8 (+8/-0).

      C'est absolument vrai, il faut toujours éviter les "premature optimization" - cependant, la performance commence toujours par une architecture logicielle claire et pensée en premier lieu pour les performances. Quand on importe toutes les semaines de centaines de milliers de lignes de gros fichiers XML, la mécanique a sérieusement intérêt à avoir été pensée pour dès le départ.

      Par exemple, l'auteur parle de Drupal, et je sais de quoi je parle j'en fais depuis presque 10 ans, et je suis certain que les gens ayant commencé le site ont utilisé les API de Drupal pour injecter le contenu. Cependant, ça devient très vite très compliqué (ça aurait été pareil avec une application Symfony ou Django basée sur un ORM) - où est la barrière que je peux franchir ou pas pour respecter les performances ? Est-ce que j'accepte de contourner les API du logiciel et potentiellement avoir des données obsolète dès leur import (évènements non lancés, listeners non reveillés) où est-ce que j'accepte que ce soit juste lent mais m'assure que tout le monde ai bien sa chance d'intervenir logiciellement au moment de l'injection des donnée ?

      La réponse que j'aurais apporté à ce genre de problématique c'est que bien souvent l'outil de base est mal choisi, et dès ce moment, avant même qu'une seule ligne du logiciel existe, ce choix aurait pu permettre d'éviter d'avoir se poser ces questions là.

      Puis, pour revenir au XML, utiliser du XPath, sérieusement ? Pour des très gros imports, si tu sais ce que tu fais et que tu connais le schéma, il faut mieux utiliser un lecteur séquentiel, comme l'API XMLReader, qui va juste être incroyablement plus rapide et ne pas consommer de mémoire, là où les implémentations basées sur la libxml2 (c'est à dire toutes en PHP, sauf l'API XML(Reader|Writer)) nécessitent de charger le fichier XML intégralement en mémoire, et en profitent pour passer une phase d'autocorrection du contenu (si si, ça le fait, et même plutôt bien).

      Bref, les performances ça se prépare en amont:

      • éviter les optimisations prématurées permet d'éviter de créer des goulots au niveau des caches, et de rendre illisible une API qui aurait pu l'être,
      • penser le design logiciel dès le départ pour être taillé pour notre métier, quitte à rendre plus compliqué et plus lent les tâches annexes moins importantes,
      • bien choisir l'outil de départ,
      • éviter de tomber dans les pièges classiques/cas d'école.
  • # Problème

    Posté par (page perso) . Évalué à 10 (+7/-0). Dernière modification le 07/12/17 à 13:39.

    Pas trop de rapport avec l'optimisation de ton script mais quand je vais sur http://chacuncherchesonfilm.fr et que je cherche la chaîne "La défense" ça me retourne 4 films et un cinéma.
    Si je clique sur le cinéma j'ai une erreur de type : "Whoops, looks like something went wrong."

    Edit : Ah en fait ça le fait sur tous les cinémas :-(

    • [^] # Re: Problème

      Posté par . Évalué à 10 (+13/-0).

      Oupsss !
      C'est corrigé.

      (note à moi-même pour plus tard : ne pas faire de nouvelle mise en prod' avant de parler de son site)

      • [^] # Re: Problème

        Posté par (page perso) . Évalué à 10 (+11/-0). Dernière modification le 07/12/17 à 16:41.

        C'est la blague effectivement.

        Le nombre de fois ou je veux faire une démo d'une nouvelle fonctionnalité dans Lollypop ou Eolie en postant une vidéo sur Google+ et que je découvre 1 ou 2 ou 3 bugs pendant l'enregistrement, que je corrige les bugs, et qu'au final cette vidéo m'a pris 3 heures de mon temps. Alors que j'utilise la fonctionnalité en question depuis une semaine sans rien voir.

        Moralité, faisez des vidéos!

  • # Yet another movie database?

    Posté par (page perso) . Évalué à 6 (+5/-1).

    Même si tu résous les problèmes techniques, ce site risque d'avoir du mal à vivre s'il ne se différencie pas des allocine/imdb/…

    http://devnewton.bci.im

    • [^] # Re: Yet another movie database?

      Posté par . Évalué à 10 (+12/-0).

      On ne se contente pas d'être une base de données : notre créneau, c'est la promotion du cinéma indépendant.
      Critiques de films (on assistes à quasiment toutes les projections presse des films indépendants qui vont sortir en France), interviews de réalisateurs/acteurs, débats filmés lors de projections dans des cinémas Art & Essai, …

      Les horaires, c'est le truc qui nous met à égalité, si je puis dire, avec d'autre sites.

    • [^] # Re: Yet another movie database?

      Posté par . Évalué à 3 (+1/-0).

      En tout cas le site est agréable.
      Il est plus rapide de allociné.
      Et je partage l'adage de google : speed is a feature.

  • # INSERT et transaction

    Posté par (page perso) . Évalué à 7 (+7/-1).

    Pour le multi INSERT, l'autre solution est, si ce n'est pas déjà fait, d'utiliser des transactions. Je l'ai fait sur un Prestashop et c'est magique ;)

    • [^] # Re: INSERT et transaction

      Posté par . Évalué à 10 (+8/-0). Dernière modification le 07/12/17 à 15:14.

      En effet, la suppression d'un grand nombre de COMMIT (à chaque requête SQL), au profit d'un seul COMMIT pour chaque cinéma (avec ses événements et horaires) traité a là encore permis de gagner de précieuses minutes (de 10 minutes, je viens de tomber à moins de 3).

      • [^] # Re: INSERT et transaction

        Posté par . Évalué à 4 (+4/-1).

        Diviser le temps d'exécution par 360 au minimum c'est classe.

        La boite de presta a filé ça à des lycéens stagiaires, c'est pas possible d'accumuler autant de lacunes sur la base de la programmation.

        Après cette lecture fort intéressante, je pense qu'une entreprise devrait avoir au moins une personne capable de vérifier la production externalisée quand elle est aussi critique.

        • [^] # Re: INSERT et transaction

          Posté par . Évalué à 4 (+3/-0).

          Que le travail ai pu être confié à des stagiaires c’est pas tellement le problème, c’est qu’il n’y a eu aucun contrôle derrière et que, si c’est le cas, nos pauvres stagiaires sont ressortis sans aucune connaissance supplémentaire… enfin bon c’est un tout autre sujet.

          • [^] # Re: INSERT et transaction

            Posté par . Évalué à 7 (+5/-0). Dernière modification le 08/12/17 à 20:45.

            Que le travail ai pu être confié à des stagiaires c’est pas tellement le problème, c’est qu’il n’y a eu aucun contrôle derrière et que, si c’est le cas, nos pauvres stagiaires sont ressortis sans aucune connaissance supplémentaire… enfin bon c’est un tout autre sujet.

            Tout a fait. Si tu fais de la relecture de code pour le stagiaire pour chaque pull request, le resultat ne devrait pas etre trop mauvais.

            • [^] # Re: INSERT et transaction

              Posté par . Évalué à 6 (+5/-0).

              Je suis complètement d'accord avec ces remarques. Je me suis mal exprimé. Je ne blâme pas l’exécutant mais bien le manque d'encadrement.

              Je pense simplement que c'est le genre d'entreprise qui confond stage et CDD voire qui ne tourne qu'avec ce genre de contrats à bas coûts et qui ne fait qu'empocher sans superviser, parce que dès les premiers choix, avant même de coder, le projet était très mal pensé, tellement mal que j'en viens à croire que la ou les personnes qui ont travaillé dessus soient de jeunes néophytes livrés à eux-mêmes.

              Je suis totalement un amateur autodidacte en informatique pourtant j'ai constaté que dans tous les corps de métier (et même par extension dans le travail domestique non rémunéré) il y a toujours une part d'organisation préalable qui correspond à une bonne partie du travail et qui détermine l'exécution et l'efficacité (qualité, temps, énergie, coûts, etc). Une formation pro commence souvent par le savoir théorique, l'apprentissage d'une méthodologie et la description des outils manipulés.

              • [^] # Re: INSERT et transaction

                Posté par . Évalué à 9 (+8/-1).

                Je pense simplement que c'est le genre d'entreprise qui confond stage et CDD

                Pourquoi supposer que ce sont des stagiaires ou CDD qui ont fait ça ? Il y a une masse significative de gens parfaitement incompétents parmi les gens en CDI, qu'ils aient 1 mois ou 10 ans d'expérience d'ailleurs. Après il y en a moins, ils ont été déplacé middle manager / product owner, ou jouent au consultant mais ne produisent plus rien.

                Le fait qu'on parle d'optimisation pour ce genre d'évolution montre où on en est !

                • [^] # Re: INSERT et transaction

                  Posté par . Évalué à 2 (+1/-0). Dernière modification le 09/12/17 à 12:35.

                  Je n'ai pas supposé que c'était des gens en CDD, tu as mal lu cette phrase qui évoque une pratique détournée du stage en entreprise.

                  Je doute fortement que les bases méthodologiques se désapprennent. À ce niveau de méconnaissance c'est pour moi de l'amateursime d'où l'emploi du terme "lycéens stagiaires" (au pluriel car dans le détournement de stage c'est commun qu'on refile un projet en cours de stagiaires en stagiaires). Dans tous les cas c'est bien un problème de supervision et de vérification, surtout quand tu sais que l'employé assigné n'est pas à la hauteur de la tâche ou qu'il doit faire ses preuves (la période d'essai sert à ça).

                  La problématique sur l'emploi du terme "optimisation" est déjà discutée plus haut dans les commentaires, ce n'était pas mon propos.

              • [^] # Re: INSERT et transaction

                Posté par . Évalué à 1 (+1/-1).

                C'est aussi le problème de la prestation. Comment veux-tu motiver tes développeurs à se donner à fond et à faire de la qualité pour quelque chose qu'ils te toucheront plus une fois livré ? Surtout s'ils n'ont pas à gérer les problèmes d'exploitation derrière

                • [^] # Re: INSERT et transaction

                  Posté par . Évalué à 2 (+1/-1). Dernière modification le 11/12/17 à 10:05.

                  C'est aussi le problème de la prestation. Comment veux-tu motiver tes développeurs à se donner à fond et à faire de la qualité pour quelque chose qu'ils te toucheront plus une fois livré ? Surtout s'ils n'ont pas à gérer les problèmes d'exploitation derrière

                  Parce que la recherche du travail bien fait est la seule motivation qui leur reste puisque comme tu le dis ils ne peuvent pas suivre la vie du projet et son impact. Mais ca peut etre une motivation puissante. C'est un peu la motivation de l'artiste et de la recherche du chef d'oeuvre. C'est ce type de motivation que je privilegie personnellement.

                  Je pense que cet extrait de Simone Weil peut aider a comprendre cet etat d'esprit:

                  Un poète, dans l'arrangement des mots et le choix de chaque mot, doit tenir compte simultanément de cinq ou six plans de composition au moins. Les règles de la versification – nombre de syllabes et rimes – dans la forme de poème qu'il a adoptée ; la coordination grammaticale des mots ; leur coordination logique à l'égard du développement de la pensée ; la suite purement musicale des sons contenus dans les syllabes ; le rythme pour ainsi dire matériel constitué par les coupes, les arrêts, la durée de chaque syllabe et de chaque groupe de syllabes ; l'atmosphère que mettent autour de chaque mot les possibilités de suggestion qu'il enferme, et le passage d'une atmosphère à une autre à mesure que les mots se succèdent ; le rythme psychologique constitué par la durée des mots correspondant à telle atmosphère ou à tel mouvement de la pensée ; les effets de la répétition et de la nouveauté; sans doute d'autres choses encore ; et une intuition unique de beauté donnant une unité à tout cela.

                  L'inspiration est une tension des facultés de l'âme qui rend possible le degré d'attention indispensable à la composition sur plans multiples.

                  Celui qui n'est pas capable d'une telle attention en recevra un jour la capacité, s'il s'obstine avec humilité, persévérance et patience, et s'il est poussé par un désir inaltérable et violent.
                  S'il n'est pas la proie d'un tel désir, il n'est pas indispensable qu'il fasse des vers.
                  […]
                  Celui qui compose des vers avec le désir d'en réussir d'aussi beaux que ceux de Racine ne fera jamais un beau vers. Encore bien moins s'il n'a même pas cette espérance.

                  Pour produire des vers où réside quelque beauté, il faut avoir désiré égaler par l'arrangement des mots la beauté pure et divine dont Platon dit qu'elle habite de l'autre côté du ciel.

                  Une des vérités fondamentales du christianisme, c'est qu'un progrès vers une moindre imperfection n'est pas produit par le désir d'une moindre imperfection. Seul le désir de la perfection a la vertu de détruire dans l'âme une partie du mal qui la souille. De là le commandement du Christ : « Soyez parfaits comme votre Père céleste est parfait. »

                  Sachant que Simone Weil a suivis les debuts du collectif de mathematiciens Bourbaki avec son frere Andre Weil, je me demande si cet etat d'esprit n'a pas un peu participe au succes du projet.

                  • [^] # Re: INSERT et transaction

                    Posté par . Évalué à 5 (+4/-0).

                    Faut-il encore avoir le temps de faire les choses bien en prestation. J’ai quitté ce mode pour cette raison… je n’ai pas eu l’occasion d’avoir des clients désireux de travail bien fait jusqu’au bout. Il fallait que ça soit fait pour rentrer dans le budget quitte à avoir des bouts de scotch pourris à certains endroits.

                    Ce n’est que mon expérience, j’espère que ce n’est pas le cas pour tout le monde.

                    • [^] # Re: INSERT et transaction

                      Posté par . Évalué à 3 (+2/-0).

                      J'en ai aussi posé du scotch cache-misère plutôt que de reboucher proprement des trous.
                      Ce qui m'a fait quitté l’événementiel c'est à la fois le manque d'intéressement proposé et de considération des employeurs, et à la fois le manque de peaufinement et le rush permanent parce qu'on veut pas dépenser dans le budget alloué à la construction et au montage.
                      Quant en plus certains exposants ne sont pas joignables et se permettent de demander de gros changements lorsqu'ils débarquent les derniers jours avant l'ouverture au public, t'as vraiment ni le temps ni la motivation de faire du bon travail et tu n'en retires aucune satisfaction, uniquement le soulagement d'en avoir terminé.

                • [^] # Re: INSERT et transaction

                  Posté par . Évalué à 6 (+5/-1).

                  Comment veux-tu motiver tes développeurs les fleuristes à se donner à fond et à faire de la qualité pour quelque chose qu'ils te toucheront plus une fois livré ? Surtout s'ils n'ont pas à gérer les problèmes d'exploitation derrière

                  Si les fleuristes (et ça marche avec plein de métiers) y arrivent, pourquoi pas les développeurs ?
                  D'ailleurs, plein de développeurs se sont déchirés pour faire du super code qu'ils n'ont plus jamais touché ensuite (par exemple des légions de développeurs de jeux vidéo qui ont fait cracher leurs tripes aux micros et consoles des années 80 et 90).

                  BeOS le faisait il y a 15 ans !

  • # Bémol

    Posté par (page perso) . Évalué à -1 (+16/-19).

    OPTIMISEZ VOTRE CODE

    Zut, je retrouve plus l'histoire, alors vite fait :
    C'est l'histoire d'un responsable d'équipe qui présente à sa hiérarchie le travail depuis 6 mois de son équipe pour optimiser la RAM, car ça touchait les limites des machines (et il y en avait, "quand même".
    Le mec était fier, ça évitait d'acheter de nouvelles machines ou d'upgrader.
    Et la intervient le stagiaire : "je ne connais pas tous les prix, mais de ce que vous donnez comme info, ajouter de la RAM aux machines me semble moins cher, pouvez-vous m'en dire plus?"
    La fin ne s'est pas bien passé pour le responsable d'équipe.


    Bref, attention aux généralités, ici tu as oublié de comparer le prix que ça a coûté à faire ces modifs (ton temps passé dessus) et le prix d'achat d'une machine plus puissante : peu information à ce sujet, donc impossible de savoir si ce que tu as fait a été intelligent (ça va dépendre du nombre d'heures passées et de ton salaire, par rapport au prix d'une machine 10x plus puissante disons, 2 heures ou 10 minutes pour le traitement, faut voir si ça a une rentabilité pour vous entre l'un et l'autre). La, il semble que tu as pensé geek (1h30, tu aimes pas, mais combien ça te rapporte de passer à 10 minutes? aucune info) et pas "gestionnaire d'entreprise" (est-ce que ça vaut le coût de dépenser de l'argent à passer en dessous de 1h30? tu ne le dis pas, mais il semble bien que tu l'as fait sur le temps de l'entreprise et non pas sur ton temps perso, donc c'est important)
    Alors certes un gain de 100 sur plusieurs heures ça semble plié, mais de manière générale on dit aussi le contraire : arrêtez de vouloir optimiser quand le coût de développement est supérieur au gain prévu.

    Moralité : penser à optimisez ou surtout arrêtez de vouloir optimiser, ça dépend des cas, en faire une généralité dans un sens ou dans l'autre en conclusion, sans avertissement, est un mauvais conseil.

    • [^] # Re: Bémol

      Posté par (page perso) . Évalué à 10 (+9/-0).

      Sauf que d'après ce qu'il décrit, il y a ait peu de chance qu'une machine plus puissante fasse beaucoup mieux. Typiquement, le genre d'opération qu'il décrit, ça demande du tuning db pour tirer correctement parti d'une machine plus puissante (augmenter les valeurs de consommation mémoire, déplacer certaines opération en mémoire…).

      Pour la partie utilisation RAM, il faut faire aussi attention, un processeur Intel Xeon ne peut avoir que 750Gb de RAM (1,5To pour certaines version). Passer cette limite, tu vas avoir ta mémoire déplacer sur plusieurs processeurs, ce qui va ralentir les traitement vu qu'il faudra lire la mémoire en passant par un autre CPU. Et je parle du cas limite. Si tu as 500 Gb de RAM dans un machine, tu as (dans les configurations classiques) 250Gb par CPU, si tu rajoute 500Gb, tu n'auras que 250Gb en plus par CPU.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Bémol

      Posté par . Évalué à 10 (+14/-0).

      Comme je l'explique dans le journal, je me suis "contenté" d'un traitement durant 1h30 pendant des mois (de mars à cette semaine), parce que, comme tu le soulignes, le gain de temps que j'aurais pu avoir n'aurait pas apporté grand chose, si ce n'est une fierté personnelle.
      C'est quand j'ai eu du temps "libre" (pris sur mon temps de travail, toutefois) que je me suis remis à optimiser ce script. Tout compris (donc en incluant le temps mis ce matin pour écrire ce journal), j'estime mon temps passé dessus à 1 journée, max.

      • [^] # Re: Bémol

        Posté par (page perso) . Évalué à 10 (+16/-0).

        et la prochaine fois que tu travailleras sur un problème similaire, tu n'y passeras que quelques minutes

        Envoyé depuis mon Archlinux

      • [^] # Re: Bémol

        Posté par . Évalué à 9 (+8/-0). Dernière modification le 08/12/17 à 15:04.

        Une journée pour optimiser vs. le temps passé à être en retard je crois que ça en vaut le coup.

        Et puis bon, c’est bien aussi d’arrêter de faire flamber les centrales nucléaires ^^'

    • [^] # Re: Bémol

      Posté par . Évalué à 10 (+28/-2).

      Ouais faut arrêter un peu la. c'est pas de l'optimization ce qu'il a fait, c'est corriger des bugs monstrueux.

      Ya aucune raison pour qu'un import hebdomadaire de petite taille (on parle de 200k insert la quand meme, on est loin du big data…) prenne 18 heures.
      Si ca veut dire que les horaires du mercredi ne sont pas dispo avant jeudi matin, ben c'est un peu ballot quand meme, non?
      ya aucune raison que ca prenne plus de 5 minutes. L'équipe qui a écrit ca avait pas la moindre idée de ce qu'ils faisaient (ou en avaient rien a carrer).

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Bémol

      Posté par (page perso) . Évalué à 9 (+8/-1).

      Dans mon industrie, on cours après les % de performance qui peuvent impacter le coût d'un projet d'une manière non significative (le coût du calcul est souvent supérieure à la masse salariale de nos projets). Ceci impact directement notre façon de programmer. On passe du temps à optimiser pour 5%, on est pret a transformer un code générique de 3 lignes en 2000 lignes d'une soupe infâme pleine de cas particuliers.

      Après de nombreuses années dans cette industrie, je ne sais toujours pas quel est la stratégie gagnante. Si on est 10% plus lent que la concurrence, on perd des clients, mais si on prend 6 mois a mettre en place un nouvel algorithme parce que le code est trop complexe, on perd des clients aussi.

      Et sinon, pour la blague sur la RAM, on s'amuse à quantifier des float sur moins de bits (en fonction du contexte), parce que 1 ou 2 bits à droite ou à gauche, au final cela fait quelques Giga de RAM en plus ;)

      • [^] # Re: Bémol

        Posté par . Évalué à 6 (+4/-0).

        Dans mon industrie, c’est l’inverse on court après les certitudes…

        On a besoin d’être sûr que la boucle principale s’exécute bien en moins de 10ms (proc pas véloce) tout le temps.
        Pour moi, l’optimisation doit être mesurable : gain, temps de dev et de maintenance… car la soupe infâme, quand il y a un bug, c’est encore plus infâme.

        Au niveau de l’approche que j’adopte :
        - Quelles sont mes contraintes temporelles ?
        - Quels sont les traitements qui risque de déborder ?

        En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.

        Ma question pour l’auteur, c’est : entre le moment d’obtention des données et la limite de mise en ligne acceptable, tu as combien de temps pour combien de donnée ?

        À partir de là, tu peux voir si tu tiens ou non. S’il faut optimiser ou pas. Parce que souvent, c’est rigolo d’optimiser, mais on oublie souvent que ça a un coût non négligeable. Dans certains métier comme le tien c’est vital, dans d’autre non. Par contre, si la maintenance à long terme est vitale, il vaut mieux pas faire trop d’optimisation (micro optimisation locale), et privilégier les bons algo structure de donnée.

        • [^] # Re: Bémol

          Posté par . Évalué à 2 (+0/-0).

          En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.

          Parcourir une liste, c'est pas franchement O(1)..

          • [^] # Re: Bémol

            Posté par . Évalué à 3 (+2/-0).

            Si les tailles des listes sont bornées, si :-)

            C'est comme ça que je l'ai compris.

        • [^] # Re: Bémol

          Posté par . Évalué à 5 (+3/-0).

          pendant un stage chez THALES, un formateur a expliqué :

          il faut mesurer pour décider.

          J'ai bien aimé, après c'est pas une excuse pour pondre des fichiers excel degeulasse pour mesurer des latences sous MS SQL

        • [^] # Re: Bémol

          Posté par . Évalué à 5 (+3/-0).

          En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.

          Il doit y avoir une incompréhension entre toi et nous, parce qu'arrêter de chercher une liste quand on a trouvé, ça reste en O(1). O(1) veut dire "plus petit qu'une constante", donc faire moins de calculs préserve toujours la propriété d'être O(1).

          Il y a des domaines où on veut non seulement faire du O(1), mais en plus que le calcul consomme toujours les mêmes ressources (temps, mémoire, énergie) : c'est quand on veut éviter les attaques par canaux auxiliaires dans un protocole cryptographique. Mais tu parlais plutôt de systèmes temps-réel dur dans ton message.

          • [^] # Re: Bémol

            Posté par . Évalué à 2 (+2/-2).

            A moins que je me méprenne, les deux sont du o(n), à moins que tous ses tableaux aient une taille fixe (ce qui est certes pas courant, mais pas forcément jamais vu), mais même dans ce cas, c’est une utilisation douteuse de la notation O.

            La différence entre les 2 approches c’est que la sienne va donner des temps d’executions plus constant sur des données différentes, à savoir que les cas pathologiques (valeur à la fin du tableau) s’exécutent aussi lentement que les meilleurs cas. C’est assez particulier comme approche, j’avoue, mais il a potentiellement des contraintes qui justifient ça.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Bémol

              Posté par (page perso) . Évalué à -5 (+1/-8).

              La différence entre les 2 approches c’est que la sienne va donner des temps d’executions plus constant sur des données différentes, à savoir que les cas pathologiques (valeur à la fin du tableau) s’exécutent aussi lentement que les meilleurs cas. C’est assez particulier comme approche, j’avoue, mais il a potentiellement des contraintes qui justifient ça.

              Oui c'est précisément le commentaire de gasche, c'est gentil de lui expliquer qu'il a raison sur l'air d'il a tort.

              • [^] # Re: Bémol

                Posté par (page perso) . Évalué à -6 (+1/-9).

                Visiblement les lecteurs de DLFP sont toujours aussi cons et illettrés.

                • [^] # Re: Bémol

                  Posté par . Évalué à 3 (+2/-1).

                  Et les commentateurs aussi pedants et attaches a leur sacro saint karma.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Bémol

      Posté par . Évalué à 10 (+10/-0). Dernière modification le 08/12/17 à 14:43.

      Tu n'as pas totalement tord, mais dans la cas présenté tu oublies aussi les faits suivants :
      - sur les 18h il y avait des erreurs, et il fallait parfois relancer manuellement (donc on a aléatoirement des pertes et un gros problème de fiabilité),
      - le script doit tourner au moins 1 fois par semaine, ce qui à 18h d'exécution est ENORME à l'année,
      - la machine consomme sans doute bien plus d'électricité, ce n'est ni économique ni écologique,
      - difficile à quantifier financièrement, mais avoir cherché à optimiser lui a fait gagner en compétence ce qui sera toujours bénéfique,
      - si le fichier reçu est de plus en plus volumineux, ça devrait avoir très peu d'impact.

      Le gain n'est pas que financier. Et de manière générale, ne penser qu'en terme financier est un mauvais calcul, il y a tellement d'autres paramètres…(ah mais oui, ce n'est pas aussi facile à quantifier, donc les gens du dessus n'aiment pas…).

      Edit : j'oubliais, le partage d'expérience derrière tout ça (qui n'aurait au eu lieu en gonflant la machine) ! Gain qui sort du simple cadre de ton entreprise, et rapporte à tous.

      • [^] # Re: Bémol

        Posté par (page perso) . Évalué à 3 (+10/-9).

        En fait, l'idée de mon bémol était moins sur cet exemple précis (qui forcément est assez "évident"), mais sur le fait de passer d'une exemple "pour moi, sur ce cas, ça a été utile d'optimiser" à une conclusion "optimisez" très générale, qui est le meilleur moyen pour se planter à terme.
        Après, si on a envie de me moinsser pour faire une remarque sur une erreur des plus classiques de passer d'un exemple à une généralité, que les moinsseurs s'amusent à se complaire dans cette façon de faire… (mais je parie qu'ils ne mettent pas la conclusion en application, car les jours ne faisant que 24 heures et les finances étant non infinies il faut bien faire des choix de ce qu'on cherche à optimiser et non pas suivre la généralité à laquelle on "refuse" le bémol)

        PS : et zut, je m'étais dit de ne faire qu'un commentaire, bon essayons de se limiter à 2 vu que de toute façons c'est "inutile"…

    • [^] # Re: Bémol

      Posté par . Évalué à 6 (+5/-1).

      Passer de 18h à 10m en groupant des inserts.
      Faut que tu expliques comment tu fais ça en ajoutant de la RAM et sans code…

  • # -fomgoptimization !

    Posté par (page perso) . Évalué à 7 (+5/-0).

    -O5 et ça roule !

  • # Et au final ?

    Posté par . Évalué à 8 (+7/-0).

    Vous leur avez fait quoi à ces consultants incompétents ? Vous avez demandé un retour de votre argent ? Un procès pour violation du contrat ? …

    • [^] # Re: Et au final ?

      Posté par . Évalué à 7 (+6/-1).

      Ils leur ont offert Windows 10.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Et au final ?

      Posté par (page perso) . Évalué à 6 (+4/-0).

      C'est une bonne question, et moi qui n'ai pas une grande expérience de ce type de contrats, je me demande quelles genre de clauses on trouve pour se protéger de consultants complètements incompétents. (Le plus simple est peut-être d'essayer de parler à leurs anciens clients?)

      • [^] # Re: Et au final ?

        Posté par . Évalué à 5 (+3/-0).

        De manière générale, le mode forfait et le développement agile te permet de limiter les dégâts.
        En ajoutant de partir d'un COTS, si possible opensource (pour la pérennité, et la gestion simplifie des licences) pour un premier proto fonctionnel.
        Tu paies deux trois sprints. Si les résultats sont pas là, tu changes de presta.
        Sans vouloir être méchant, quand un client s’aperçoit un an après le lancement de projet, que le logiciel qu'on lui livre n'est pas de la qualité attendue, c'est plus le client qui est à blâmer que le presta.

    • [^] # Re: Et au final ?

      Posté par . Évalué à 9 (+7/-0).

      Une procédure est en cours…

  • # Vécu

    Posté par . Évalué à 7 (+5/-0).

    Malheureusement, la prestation de code, ça ne marche que très rarement surtout qu'à moins d'être vraiment une toute petite structure, il y a toujours un geek quelque part qui est capable d'écrire ce genre de script dans le cadre de ses heures et qui est beaucoup plus au fait des nécessités de sa boîte (surtout que ce sont généralement les siennes aussi).

    J'ai connu l'affaire aussi au début des années 2000. Je travaillais dans un centre de recherche semi-indépendant et qui avait besoin d'un LIMS depuis longtemps (une vraie arlésienne) et le patron avait confié la chose à une boîte canadienne pour le développer.

    Moralité, un soft toujours pas sorti des années plus tard et une facture tenue confidentielle mais qu'un collègue avait réussi à estimer en millions de dollars. Au point ou on en était, on ne disposait que d'une interface (client Windows natif) qui permettait de nourrir une base de données… sans pouvoir la lire en retour. Celle-ci était formée d'une boîte de dialogue de taille fixe truffée de champs de saisie et de boîtes déroulantes. Entre autres tares, j'ai suggéré à un collège de faire [TAB]… [TAB]… [TAB]… pour voir comment on passait d'un champ à l'autre au clavier, sachant que cette interface devait être utilisée intensivement dans les laboratoires pour entrer les résultats de recherche. Et sans surprise, on voyait le focus partir dans tous les sens. L'interface proprement dite avait là encore dû être confiée à un stagiaire débutant (j'ai connu plusieurs stagiaires qui étaient plus compétents que les titulaires qu'ils épaulaient), qui avait dû utiliser l'interface de composition de Visual Basic et décorer bien gentiment son panneau avec ses contrôles, sans même être conscient de l'existence de la propriété « index ».

    Toujours au même endroit, quelques années plus tard, un type qui faisait de la bioinfo devait reverse-complémenter une séquence de paires de bases génétiques (remplacer un A par T, un C par un G, et vice-versa, puis retourner la séquence en la lisant de droite à gauche) enregistrée en ASCII dans un fichier de 3Mo.

    Le gars avait fini par me demander de l'aide parce que son programme n'avait toujours pas fini après… 2 heures de calcul ! Il avait écrit un script en Perl (encore à la mode à l'époque), il chargeait son fichier dans une grande chaîne de caractères et utilisait chomp pour grignoter le dernier caractère, le complémenter et l'ajouter à la chaîne de sortie.

    Pour le fun, étant donné que la tâche à réaliser était excessivement simple, je me suis amusé à l'optimiser à outrance également, en y consacrant une petite heure. J'avais utilisé mmap() pour projeter son fichier en mémoire en laissant toute latitude au système pour charger tout cela de la façon la plus efficace possible et j'avais écrit le cœur de la boucle en utilisant xlat sur x86 (c'était surtout un prétexte pour le faire. En plus, je n'avais pas envie de me faire suer à savoir si et dans quelles conditions le compilateur aurait pu faire mieux).

    On est passé de plus de 2 heures à… 2 dixièmes de secondes ! :-)

    Certes, ce n'était pas très difficile, mais je pense que c'est le plus grand gain que j'obtiendrai jamais.

    • [^] # Re: Vécu

      Posté par . Évalué à 6 (+4/-0).

      Le contrat à l'extérieur ne marche pas forcément, mais tout internaliser a aussi ses propres problèmes, au moins quand la taille du projet est trop petite (ou ses finances) pour avoir plus d'un seul développeur. Avec un prestataire extérieur, si tu as la chance de trouver des gens compétents (oui, ça existe), tu peux espérer avoir plusieurs personnes qui travaillent sur le projet à temps partiel, ou au moins un seul développeur qui a beaucoup d'expérience de travail en équipe.

      (Bien) travailler à plusieurs et (bien) travailler tout seul c'est très différent, le premier est un peu moins efficace sur le court terme (coûts de communication, conventions à adopter, mécompréhensions etc.), mais il incite beaucoup plus à avoir de la documentation écrite, des processus de développement/bugfix/release/etc. explicités, et se prête donc plus naturellement à un passage de bâton (partiel ou total) à d'autres développeurs ensuite.

      Quand on travaille tout seul (même quand on est compétent et qu'on fait attention), c'est facile de s'enfermer sans s'en rendre compte dans un projet où on a tout en tête mais peu de choses écrites pour d'autres, dans des choix d'architectures non-standards qui rendent le projet plus difficile à comprendre pour d'autres, et au final avec quelque chose qui, si on doit se faire remplacer pour une raison quelconque, est beaucoup plus difficile à prendre en main pour les suivants.

      Idéalement je pense que si j'étais demandeur d'une prestation informatique, j'essaierais de trouver un compromis entre "la boîte de prestation opaque" et "le développeur tout seul en interne". Soit une petite boîte avec un petit nombre de personnes en local avec qui j'ai de bons rapports, soit essayer de gérer les responsabilités en interne pour avoir plus d'une personne sur le backend (par exemple, au lieu d'avoir un développeur et un webmaster, chercher deux personnes polyvalentes qui se partagent les tâches sur les deux fronts).

  • # Beaucoup de dev ne savent pas faire du SQL

    Posté par (page perso) . Évalué à 5 (+5/-1).

    Salut,

    En plus des problèmes XML, ceci démontre bien ce à quoi j'ai déjà été confronté, il y a … 20 ans (putaing, je suis vieux) : la plupart des développeurs ne sont pas intéressés par le SQL et la base de données.

    Gérer les problématiques d'insertion (INSERT multi-ligne, et transactions pour diminuer les logs) : cela fait partie de ce que doit savoir un développeur qui travaille avec une base de données mais qui est très souvent ignorée. De plus dans le cas d'insertion de plusieurs parties corrélées, la gestion de transaction permet de s'assurer que la base de données reste dans un état stable en cas d'arrêt du chargement (suite à une erreur) et donc de pouvoir recommencer simplement.

    J'ai déjà constaté très souvent, que beaucoup de développeurs ne voient la base de données que comme "le truc dans lequel on enregistre et lit les données" sans se préoccuper de comment ça marche et surtout comment l'utiliser efficacement. Par exemple, faire des requêtes efficaces, lire les query plan, ajouter des index si besoin, en supprimer s'ils sont inutiles, utilier BCP (ou équivalent selon le moteur) pour charger des données etc.

    Bravo pour les modifications apportées.

    Et bonne continuation pour Chacun cherche son Film, que j'ai découvert grâce à ce journal.

    • [^] # Re: Beaucoup de dev ne savent pas faire du SQL

      Posté par . Évalué à 3 (+2/-1).

      Gérer les problématiques d'insertion (INSERT multi-ligne, et transactions pour diminuer les logs) : cela fait partie de ce que doit savoir un développeur qui travaille avec une base de données mais qui est très souvent ignorée. De plus dans le cas d'insertion de plusieurs parties corrélées, la gestion de transaction permet de s'assurer que la base de données reste dans un état stable en cas d'arrêt du chargement (suite à une erreur) et donc de pouvoir recommencer simplement.

      Qu'est-ce que tu conclus avec cette remarque de ce que dois savoir ou ne pas savoir un developpeur sur les DB? Si c'est d'aider avec bienveillance le developpeur en question a s'approprier ces techniques des que tu te rend compte de ce type de lacune, ca me va. Mais c'est valable pour tout truc necessaire a un moment donne, que ca soit plus ou moins pointu. Donc pourquoi ca en particulier?

      En plus je sens bien le truc venir de la liste des choses indispensables a connaitre, et que c'est une humilitation d'un ignorer une. Eviter la honte est plutot une mauvaise motivation d'apprentissage.

      • [^] # Re: Beaucoup de dev ne savent pas faire du SQL

        Posté par . Évalué à 3 (+1/-0).

        Donc pourquoi ca en particulier?

        En plus je sens bien le truc venir de la liste des choses indispensables a connaitre…

        Rien de tout cela, à mon avis.

        Je suis assez d'accord avec lui quand il dit qu'au départ, les bases de données sont un sujet qui a l'air rébarbatif aux jeunes programmeurs. C'est même un problème quand ça dure dans le temps, au point d'avoir un chef qui se sent obligé d'expliquer leur métier à tous les développeurs mais qui met un point d'honneur à dire que les bases de données ne sont pas dans son périmètre, justifiant ainsi ses soi-disant domaines d'expertise (en fait, ses centres d'intérêts, qui sont bien souvent les mêmes que tout le monde. Et, oui, tout le monde aura compris que c'est là encore un exemple vécu.)

        L'ennui avec les DB, c'est qu'on les enseigne bien souvent avec le traditionnel annuaire ou la base de données clients (nom, prénom, adresse, numéro de client, liste des produits achetés, etc.). Déjà rien de folichon en soi mais, en général, on doit aussi construire et surtout remplir la base soi-même. Donc, des heures de insert à recommencer sans arrêt pour se retrouver au final avec une base de cinq clients et trois commandes. :-\ Il est beaucoup plus intéressant, à mon avis, de se faire les dents sur une base déjà faite et bien remplie, avec un schéma visuel et bien explicite, surtout que cela ne pose aucune difficulté technique : il est tout-à-fait possible d'accorder des droits en lecture seule sur la base à un profil donné et de lui conférer en plus la possibilité de créer les siennes dans un tablespace bien défini, avec bien sûr les contraintes d'intégrité qui s'imposent. Personnellement, j'ai totalement pris goût au SQL lorsque j'ai commencé à travailler sur la base de gènes qui m'a occupé pendant six ans. Donc en faisant des requêtes dans une base avec beaucoup de tables, énormément de données (des millions d'enregistrements par table sur une base Sybase de l'époque).

        et que c'est une humilitation d'un ignorer une. Eviter la honte est plutot une mauvaise motivation d'apprentissage.

        Non plus. C'est plutôt que ces notions sont intimement liées aux SGBDR et en fait, c'est même pour elles qu'ils ont été conçus ! Sinon, ils n'apportent pas grand chose de plus que de simples fichiers. Au passage, on rappelle qu'initialement, un « fichier », c'est une boîte à fiches. Et c'est bien pour faire ce genre de traitement qu'ils ont été inventés sur les ordinateurs. Comme depuis le départ, un fichier est implémenté comme une suite continue de données, on les utilise majoritairement cette fin : sauvegarder une séquence d'octets continue quelle qu'elle soit, et c'est très bien comme ça. Mais ça explique pourquoi les appels comme fread() permettent de préciser la longueur d'un enregistrement ET le nombre d'enregistrements à lire, et pourquoi un certain nombre de langages définissent les champs destinés aux fichiers comme étant de taille fixe et comblés par des espaces.

        En plus, ce n'est pas forcément difficile. C'est plutôt une bonne habitude à prendre depuis le départ. Et très vite, dresser un schéma bien léché devient un plaisir de fin gourmet.

        Alors naturellement, il ne s'agit pas de faire de tout un chacun un expert base de données mais en revanche, la façon dont tu poses la question laisse penser qu'en effet, pour un certain nombre de personnes, une base MySQL serait un peu l'équivalent d'une base de registre Windows. Si c'est le cas, et qu'en plus c'est en toute bonne foi, alors c'est peut-être, en effet, quelque chose à surveiller puisque l'on tenait cela pour acquis depuis longtemps.

        En plus, c'est réellement important qu'il est extrêmement difficile de gérer « à la main » les contraintes d'intégrité dès lors qu'on dépasse deux ou trois tables. Il n'y a qu'à comptabiliser le nombre de fois que l'on s'est vu opposer une erreur par le SGBD au départ pour se rendre compte que chacune d'elle était en fait une catastrophe potentielle évitée. C'est un peu comme les segfaults quand on fait du langage C ou autre langage compilé en langage machine. Il faut se souvenir que même sur PC, on a attendu le 286 et surtout le 386 pour avoir un mode protégé et que même avec eux, le DOS n'a réellement pris sa retraite qu'avec les années 2000. Cela veut aussi dire qu'en fin de compte, ça ne fait qu'une petite quinzaine d'années que l'informatique grand public est proprement sécurisée de ce côté. :)

        • [^] # Re: Beaucoup de dev ne savent pas faire du SQL

          Posté par . Évalué à 4 (+2/-0).

          Je suis d'accord que les base de donnees peuvent etre un probleme interessant. Mais je ne repondais pas sur ce point mais plutot sur declarer ce que les autres doivent savoir. Ce genre de preoccupation est le premier pas pour developper des relations pourries tout autour de soit.

          Apres si on est enseignant ou qu'on doit payer un salaire c'est sans doute une question a se poser.

          • [^] # Re: Beaucoup de dev ne savent pas faire du SQL

            Posté par (page perso) . Évalué à 7 (+5/-0).

            mais plutot sur declarer ce que les autres doivent savoir.

            Bah disons que quand c'est le point (la méconnaissance des SGBDR) qui fait passer de 10s à 18h d'exécution, non ce n'est plus "un savoir parmi d'autres" mais "le problème n°1".

            Je ne peux qu'abonder dans le sens de l'auteur du journal et du commentaire initial. Venant d'un monde JEE, j'ai vu mon lot de développeurs d'applis de gestion qui ne comprennent rien aux SGBDR / à SQL (voire refusent de) et les horreurs que ça provoque. Alors que dans le même temps, dans chaque test de recrutement on leur demandera la différence entre une TreeMap et une LinkedHashMap (donc ils la connaissent, éventuellement par cœur sans la comprendre). Différence dont on se bat les gonades dans le contexte de la majorité des applis JEE car elles contiendront maximum 100 éléments et auront la durée de vie d'une requête HTTP, alors qu'un pauvre index sur la table utilisée ferait passer le temps de chargement de cet écran de 10s à 10ms (et je parle même pas de mieux modéliser les données).

            Je ne sais pas pourquoi mais c'est comme ça. Enfin si j'ai une vague idée, liée au fantasme des abstractions comme Hibernate et équivalents ailleurs (quand j'ai fait de très modestes contribs à des projets non-Java, même des avec pignon sur rue, j'ai vu de ces trucs qui m'ont bien décomplexé de mon passé Javaiste, comme quoi c'est pas une question de langage utilisé…), qui promettent d'abstraire totalement le stockage concret des données. Note que j'aime bien Hibernate pour ce qu'il apporte réellement, mais je reste lucide. Mais malheureusement on a formé des générations de développeurs qui pensent que "le stockage des données ça juste marche et c'est pas un problème".

            Donc je n'ai pas de preuve parfaitement scientifique, mais j'ai l'impression que oui, le problème des développeurs qui font des horreurs avec leur modélisation / stockage des données, est bien plus grave que "là tu aurais pu dérouler ta boucle et gagner 10 cycles de processeur".

            • [^] # Re: Beaucoup de dev ne savent pas faire du SQL

              Posté par . Évalué à 6 (+5/-1).

              Bah disons que quand c'est le point (la méconnaissance des SGBDR) qui fait passer de 10s à 18h d'exécution, non ce n'est plus "un savoir parmi d'autres" mais "le problème n°1".

              Ce que j'essaie de dire c'est que ca ne me derangerait pas forcement de travailler avec quelqu'un qui ferait ce genre d'erreur. Il se pourrait meme que je m'en fout totalement.

              Un processus qui fait des insertion dans une table, qui prend 18 heures a tourner, une des premieres choses que je demanderais a la personne qui a fait ca, c'est est-ce que tu fais des bulk insert. Si il ne sait pas ce que c'est on va un peu parler, je lui montre peut-etre un exemple en SQL et voila. C'est gere sans aucune consideration de ce que les autres doivent savoir ou pas.

              Et j'essaie surtout de pas lui faire sentir qu'il aurait du le savoir! Meme si c'est difficile de se sortir ce genre de betise de la tete quand on est immerge dans cette societe pourrie qui est la notre.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.