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
Discussion :
Si ça arrive, j'ai déjà eu des cas ou l'on passe par exemple de 5 jours à 2 heures mais qui est passé à 3h30 quand il a fallu rajouter des controls juste pour rassurer et que le code soit lisible et surtout compréhensible par tous.Envoyé par Neckara
Malheureusement, bien souvent, on confond code illisible (lié à la subtilité du langage) et code crade.
Cordialement.
WOW ! WOW ! WOW !
C'est le MATIN, j'ai pas encore bu mon café et je dois me taper des MULTIPLICATIONS ???
Mais tu n'as aucune pitié ma parole !
Alors... heu... 5jours * 24 = 120. 120/2 = 60. Donc un facteur x60 si je ne dis pas de bêtises.
Et pour le rendre plus propre... 2h = 120 minutes, 3h30 = 180+30 = 210 minutes. 210/120... heu, je sors la calculette, 1.75.
Pfiou, heureusement que c'est la fin de la semaine là. Ne me refait plus jamais ça.
Ouais, un facteur x1.75 ça me semble tout à fait cohérent, surtout si tu rajoutes des vérifications à l'exécution du type "if", qui sont quand même relativement coûteux. Après, tu as essayé de compiler avec la prédiction d'exécution ? Ça peut te faire gagner pas mal de perfs.
Après, ce que certains peuvent faire aussi, c'est avoir un mode debogue/safe et un mode release/perf. Comme ça tu fais tes vérifications quand tu peux, et quand t'as vraiment besoin de performances, tu les fais sauter.
Je suis d'accord sur ce point. Il faut connaître le langage et son fonctionnement.
Après les grosses subtilités de langages ça rentre dans les trucs un peu tricky où je mettrais un commentaire.
C'est ce qui me fait dire que tu ne travailles pas sur de gros projets comme j'en parle...
Voici un peu de métrique pour illustrer :
Tests unitaires recouvrent environ 45% du code. Temps total d'exécution : 37h
Tests fonctionnels qui avec la dette technique recouvrent environ 85-90% des fonctionnalités. Temps total d'exécution : 8 jours
Tests de performances/endurance... Temps total d'exécution : 2 mois (autant vous dire qu'on ne déroule jamais tout à la fois mais par échantillon successif)
Tests en environnement simulés (climatique, ionosphérique, ect) : 2 semaines
Tests terrain avec des opérateurs physiques et le système complet : 2 semaines (qui ne permettent pas de tout valider bien évidemment)
Bref... Comment veux-tu dans un cadre comme cela couvrir ne serait-ce que 99% des fonctionnalités ?
On ne pourrait jamais livrer un seul client... (parce que bien sûr on ne fait pas qu'une version par an...)
Rien que le temps des tests unitaire fait pâlir n'importe quel développeur...
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Ouch... Après, je ne bosse pas dans ton entreprise, donc il m'est difficile de parler plus en détails, je ne peux faire que des suppositions.
N'est-il pas possible d'exécuter les tests unitaires en fonction des fichiers modifiés dans le commit ?
Je présumes que vous êtes plusieurs développeurs, donc que vous avez plusieurs ordinateurs, n'est-il pas possible de faire des planifications de tests unitaires distribués la nuit ou durant des WE par exemple ?
En découpant en modules avec des interfaces bien définis, ce n'est pas possible de diviser ce temps d'exécution en ne testant en somme que les modules modifiés ? Plus en distribuant les tests ?
Oui, là je veux bien.
Mais de ce que j'ai l'impression de comprendre, il n'y a pas que le code, mais aussi le hardware ou des capteurs j'ai l'impression.
Donc ça n'a pas l'air d'être que une question de gros projets, mais aussi du contexte spécial dans lequel vous vous trouvez.
Tu m'étonnes.
Je suis d'avis que le code doit avoir des fonctions courtes au nom explicite (tant pis si celui là est long), que les commentaires ne sont pas une source d'info fiable.
Dans ce cadre là, bien que je suis pas fan des motivations inclusives (donc non technologique), il faut avouer que la PR de rust augmente la lisibilité de certaines variables.
Je rajouterais même que les spec, c'est les tests.
Parce que les spec de référence et les commentaires ont tendances à pas être mis à jours. là où où des tests qui ratent le sont.
C'est tout l'intérêt de fonctionner en module. Tu lances les tests sur le le module sur lequel tu travailles.
Si les tests de l'api de ce module te montre un changement dans l'api ou si le but était de modifier l'api du module, tu testes/corriges aussi ceux qui dépendent directement de ce module.
Et tu continues récursivement.
De plus, tu peux paralléliser les tests quand tu as différents modules à tester. Donc au final, tu ne prends plus tant de temps que ça.
Pour ça, il faut un code bien découpé et assez fin. Après, je suis conscient que c'est dans un monde un parfait. Certaines boites ne te laisse pas faire ce découpage et dans d'autres, ils veulent le faire quand le projet est déjà monstrueux et qu'on ne maîtrise plus ce qui serait impacté par le changement d'une ligne de code.
Le premier gros défaut du projet dont je sors les chiffres c'est qu'il n'est pas si modulaire que cela.
Avec le temps la granularité s'est perdue. De ce fait il est risqué de ne lancer les tests unitaires que sur un module modifié.
Et si on tire l'arbre de dépendance d'un fichier modifié alors on se retrouve à devoir tester plusieurs modules au final.
Le gros problème aussi est que comme nous n'avons pas une couverture totale il faut forcément tester au plus haut niveau, ce qui prend plus de temps.
Alors pourquoi ne pas rédiger plus de tests unitaires me direz-vous ?
Parce que nous n'avons pas assez de puissance de calcul pour tout faire tourner en un temps raisonnable, que d'expérience sur un autre projet où ils en sont à 99% de couverture avec les mêmes contraintes de qualité que nous cela représente tout de même 5-7h de test par commit (honnêtement je prend le chiffre et je vous le donne car je ne suis pas allé voir, mais à priori ils testent bien uniquement le module modifié, mais avec aussi des tests de fuzzing ce qui va décupler le temps sans aucun doute), ce qui multiplié par le nombre de développeur est totalement aberrant...
Une batterie de test de 100% sur des gros projets j'attends de voir, car d'expérience il faudrait un data center pour faire tourner cela en une nuit.
Le second gros défaut est la nature du projet : la dépendance matérielle, les équipements connectés et les contraintes de sécurité et de temps réel.
Ce qui fait qu'on aura beau avoir des tests unitaires montrant 100% de OK qu'on peut avoir des tests fonctionnels avec 50% de KO...
Mais là j'admet que c'est bien spécifique à l'embarqué.
Après la parallélisation n'est possible que si on possède le matériel...
Avoir une station digne de ce nom pour faire tourner des tests unitaire c'est déjà bien.
Mais avoir le matériel cible en quantité pour lancer des tests fonctionnels, endurance et compagnie... Quelqu'un a des lingots dans un coffre ?
Bref, mon expérience me fait dire que les modules et les tests unitaires c'est plus pour se rassurer qu'assurer une qualité parfaite.
De tous les projets de la boite, seuls ceux qui se font pour PC et qui sont cloisonnés (pas de dépendance système ou autre) possèdent des tests unitaires complets.
Pour le reste c'est une perte de temps (on avait estimé à 8 mois de rédaction pour 2 personnes pour arriver à 90% de couverture de test unitaire sur notre projet) et d'investissement par rapport à des tests sur cible.
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Si tu veux je vous donne un accès à mon cluster de 4 raspberry pi.Une batterie de test de 100% sur des gros projets j'attends de voir, car d'expérience il faudrait un data center pour faire tourner cela en une nuit.
Ouais, donc tout de suite, c'est bien plus casse-c*****.
Pour le reste je compatis.
Merci de l'ironie.Si tu veux je vous donne un accès à mon cluster de 4 raspberry pi.
Mais non on va rester avec nos grosses stations Linux.
En plus on a pas les outils pour faire tourner nos tests sur ARM.
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Ce sont visiblement des usages très spécifiques qui requièrent ça et ce type de langage mais personnellement je ne pourrais pas travailler là-dedans, j'aurais toujours l'impression de faire du sale boulot purement utilitaire sans aucune satisfaction derrière.
Oui enfin en 2020, optimiser un code c'est pas juste régler quelques options de compilation... En plus des classiques complexité d'algo, validation numérique, accélérateurs de calculs et optimisations bas-niveau, on a fait très souvent de l'interopérabilité zero-cost entre plusieurs langages, de la gestion mémoire optimisée à base de GC, boxed values ou autres, des systèmes distribués hétérogènes, des compilateurs JIT, etc. Tout ça demande un vrai travail d'optimisation et pas seulement quelques bonnes pratiques de "code propre". Et le gain de performances peut tout à fait atteindre un ordre de grandeur.
L'informatique c'est justement plein d'usages très spécifiques qui ont tous autant le droit d'exister. Perso, je trouve plus satisfaisant d'optimiser des outils de simulation numérique qui peuvent servir dans le médical ou la climatologie, plutôt que de développer un n-ième site de e-commerce qui va servir à vendre des chaussures fabriqués par des enfants chinois pour finir 6 mois plus tard dans le continent de plastique. Mais bon, chacun ses goûts...
Ne soit pas malhonnête. J'ai déjà listé une liste non-exhaustive d'optimisations possibles dans ce sujet.
Là j'en donne quelques unes adaptées spécifiquement à l'optimisation sur des conditions/assertions vu qu'il était question du surcoût ajoutées par ces dernières.
Tu déformes complètement ma position.
Tu peux avoir en effet du code propre très mal optimisé, mais tu peux aussi avoir du code propre pas trop mal optimisé. Bien évidemment que tu pourrais obtenir des facteurs de x30, et bien plus en encore, si tu pars d'un code propre très mal optimisé, et bien évidemment que cela ne se résume pas à quelques "bonnes pratiques"...
Par exemple, pré-charger des fichiers en RAM comme je l'ai évoqué, ce n'est pas en soit une "bonne pratique". Cela va te permettre d'optimiser ton code, sans pour autant impacter sa propreté. Bon, bien évidemment, je n'ai pas dressé une liste exhaustive de tous les moyens d'optimisations.
Ma position était que la nécessité de rendre ton code sale pour une optimisation ne te fera pas gagner des facteurs énormes. Car il existe très souvent un code propre optimisé d'un facteur dont le logarithme est grossièrement similaire à celui de ton code sale.
Le compilateur JIT ne va pas changer la propreté de ton code. Ton interopérabilité entre différents langage n'a pas de raisons d'être sale. Ton GC n'a pas de raison d'avoir une API sale, etc.
Où a-t-il parlé d'un quelconque droit d’existence ?
Si tu le dis...
Hein ? C'est quoi le logarithme du facteur d'optimisation d'un algorithme ?
Ben... souvent si. Quand on a besoin de performances, on réimplémente les sections critiques pour gérer ce genre de chose plus efficacement et désolé mais le code résultant est souvent "plus sale". Après, faut arrêter de caricaturer : on fait pas du code sale exprès en espérant que ça ira vite parce que c'est sale. C'est même souvent un compromi entre le gain de performances de la réécriture et son impact sur la qualité du code.
Un exemple, puisque tu "connais" le C++ : prend un algo calculé à l'exécution et transforme-le en algo "compile-time" avec des constexpr et des templates. Je doute que tu obtiennes un code final aussi "propre"...
Ah ben justement je n'ai pas dit que ça n'avait pas le droit d'exister, il faut bien des gens pour faire le sale boulot, je préfère juste que ça ne soit pas moi
Si tu n'es pas foutu de comprendre la différence entre un code propre non optimisé, un code propre optimisé avec e.g. chargement d'un fichier en ram, et un code sale optimisé avec chargement d'un fichier en RAM PLUS d'autres optimisations qui font que le code devient sale... je suis désolé, mais je peux plus rien pour toi.
Ce n'est absolument pas ce que j'ai dit...
Un exemple à me proposer ?
Et en quoi est-ce du "sale boulot" ? Tu as une expérience particulière dans ce domaine pour dire ça ? Ou mieux, une étude de satisfaction des gens qui y travaillent ?Ah ben justement je n'ai pas dit que ça n'avait pas le droit d'exister, il faut bien des gens pour faire le sale boulot, je préfère juste que ça ne soit pas moi
Ok. Salut.
Si tu n'es pas foutu de comprendre la différence entre un code propre non optimisé,
Il y a des développeurs axés mathématiques et d'autres plutôt littéraires. Les uns sont bons pour faire des algorithmes, comprennent facilement des enchaînements d'opérations avec des signes pas forcément très clair. Le problème est que ce code est compréhensible principalement par eux-mêmes. D'autres sont meilleurs à un niveau organisationnel et langagier, ils se focalisent sur comment dire à la machine ce qu'elle doit faire avec un enchaînement de fonctions et variables bien nommées permettant de lire le programme comme un texte. Les deux aspects du métier sont nécessaires mais je vois les premiers comme des personnes à l'esprit purement logique qui sont moins intéressés notamment par l'expérience utilisateur d'un programme. Tant que ça marche et que c'est rapide ça leur va.
Il y a un langage qui est très critiqué car souvent difficile à lire (enfin, soi-disant) qui a été créé par un linguiste, ce langage est le perl...
A tous, faudrait peut-être définir le terme de code sale, non ?
Cordialement.
On voit surtout que le flot de conneries est alimenté par une minorité de personnes.
C'est un peu inquiétant que ces personnes soient au bon endroit pour filtrer, bloquer, censurer toute opinion divergente.
Ces personnes sont très bien organisées, se cooptent entre elles, se font la courte échelle. C'est comme ça que sur certains réseaux comme Reddit, on se retrouve avec une majorité de modos gauchistes extrémistes en plein pays de John Wayne.
Pour moi ce mode de recrutement ressemble à ce qui se pratique dans les sectes.
Le truc avec les anecdotes c'est que ça reste juste ça, des anecdotes.
Sinon il y a un paquet de catégories de code sale, ça va de l'amateurisme au manque de lisibilité. Le contenu d'une fonction peut être compliqué à lire (et encore ce n'est pas forcément nécessaire), mais il faut que ce qu'elle fait, prend et renvoie soit clair afin que justement, on n'ait à essayer de comprendre le détail de ce qu'elle fait que quand c'est réellement nécessaire.
J'avais justement posté sur un autre topic un exemple de code d'un ancien collègue. On sait que ça "finalise des ids", mais c'est quoi finaliser concrètement ? Ca prend des datas mais quelles datas ? Si c'était un objet on pourrait au moins la classe pour savoir ce qu'il est censé contenir. A l'intérieur des array_flips qui servent à optimiser mais le détail est imbitable. Le retour n'est pas typé, on peut supposer que ça renvoie un array d'ints en la lisant, et encore car il y a des trucs bizarres sur les index donc on n'est même pas sûr. Mais le mec qui a écrit ça ça lui paraissait totalement logique et limpide.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager