Affichage des résultats du sondage: Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ?

Votants
59. Vous ne pouvez pas participer à ce sondage.
  • vouloir réinventer la roue tout le temps

    21 35,59%
  • être un développeur orienté copier/coller

    26 44,07%
  • être focalisé sur le codage

    15 25,42%
  • utiliser des noms ne donnant aucune information sur ce que fait le code

    44 74,58%
  • vouloir à tout prix minimiser le nombre de lignes de son code

    19 32,20%
  • ignorer les messages d’erreur

    24 40,68%
  • s’entêter à vouloir résoudre des problèmes sans demander de l’aide

    17 28,81%
  • toujours reporter la correction des bogues

    21 35,59%
  • vouloir traiter tous les problèmes avec un seul outil

    7 11,86%
  • ignorer les forces et limites des outils que vous utilisez

    14 23,73%
  • ne pas documenter ou commenter son code

    29 49,15%
  • ignorer les pratiques de développement éprouvées

    22 37,29%
  • ne pas explorer quelques pistes avant de demander de l’aide

    10 16,95%
  • ignorer les tests unitaires ou les considérer comme une tâche secondaire

    17 28,81%
  • ne pas aimer la lecture (documentation, aide en ligne, etc.)

    17 28,81%
  • vouloir optimiser le code dès le début

    12 20,34%
  • ne pas maîtriser ses outils et langages de développement

    24 40,68%
  • considérer les codes simples comme des codes d’amateur

    20 33,90%
  • Autre (à préciser)

    3 5,08%
  • Pas d'avis

    1 1,69%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 575
    Points : 45 383
    Points
    45 383
    Billets dans le blog
    2

    Par défaut Quelles sont les habitudes qui peuvent vous amener à écrire un code de mauvaise qualité ?

    Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ?
    Partagez votre expérience

    Beaucoup de développeurs passionnés aiment dire que coder est un art. Et si c’est le cas, c’est surement parce qu’il ne suffit pas d’écrire un code qui marche. Il y a un certain nombre de règles et bonnes pratiques – qui se développent parfois avec l’expérience – qui permettent de le faire de manière optimale. Celles-ci aident à écrire un code propre, maintenable, évolutif, et surtout en tenant compte des délais fixés. Déroger à ces règles, que ça soit par méconnaissance ou volontairement, peut donc conduire à un code de mauvaise qualité qui pourrait vous classer dans le groupe des mauvais développeurs.

    Au lieu de s’interroger sur les bonnes pratiques de programmation, comme nous l’avons fait plusieurs fois ici, on peut aujourd’hui aborder le problème sous un autre angle. Quelles sont les habitudes qui caractérisent un mauvais développeur ou qui vous amèneront à écrire un code de mauvaise qualité ? la liste est certainement longue, mais on peut citer les habitudes suivantes comme point de départ :

    • vouloir réinventer la roue tout le temps. Avec 99 % de chance, votre problème a déjà été résolu quelque part. Pourquoi donc ne pas googler quand le problème vous semble complexe ?

    • être un développeur orienté copier/coller. Il ne faut pas copier/coller aveuglément. Il est nécessaire d’essayer de comprendre le code d’abord, car il est possible qu’il ne fasse pas exactement ce qu’il prétend faire ;

    • être focalisé sur le codage. Le codage proprement dit n’est pas la chose sur laquelle les développeurs passent le plus de temps. Il faut donc prendre du temps sur la manière de résoudre les problèmes avant de se jeter sur son clavier ;

    • utiliser des noms ne donnant aucune information sur ce que fait le code. Un nom de fonction par exemple est censé donner une idée de ce que fait le bout de code. Dans le cas contraire, ça devient difficile de le relire, parce qu'il faut aller dans les détails pour savoir ce qu’il fait ;

    • vouloir à tout prix minimiser le nombre de lignes de son code. Être obsédé par le fait d'avoir des codes courts peut vous amener à sacrifier la lisibilité de votre code ;

    • ignorer les messages d’erreur. La plupart du temps, les messages d’erreur vous donnent suffisamment d’informations pour avoir une idée de ce qui ne va pas avec votre code. Il ne faut donc pas supposer quand vous avez une erreur dans votre code que vous savez ce qui ne va pas sans lire d’abord attentivement le message d’erreur. Sinon, vous risquez de perdre plus de temps ;

    • s’entêter à vouloir résoudre des problèmes sans demander de l’aide ;

    • toujours reporter la correction des bogues ;

    • vouloir traiter tous les problèmes avec un seul outil. Il n'existe pas de véritable couteau suisse en programmation. Il faut donc avoir plusieurs cordes à son arc et ne pas se figer à un seul outil, un seul langage ou une seule technologie. Quand on a qu’un marteau comme outil, on a en effet tendance à voir tous les problèmes comme des clous ;

    • ignorer les forces et limites des outils que vous utilisez ;

    • ne pas documenter ou commenter son code ;

    • ignorer les tests unitaires ou les considérer comme une tâche secondaire ;

    • ignorer les pratiques de développement éprouvées : revue de code, test-driven development (TDD), assurance qualité (QA), etc. ;

    • ne pas aimer la lecture (documentation, aide en ligne, etc.) ;

    • vouloir optimiser le code dès le début. Il n’est pas nécessaire de chercher à optimiser son code dès le début pour faire face à toute sorte de scénarios possibles. Ce travail devrait être gardé pour la fin. Le plus souvent les exigences telles que définies au début peuvent changer. Vous aurez donc perdu du temps à vouloir optimiser votre code dès le début, et adapter le code optimisé aux nouvelles exigences peut générer plus d’erreurs ;

    • ne pas maitriser ses outils et langages de développement. Si les outils et langages que vous utilisez régulièrement sont encore assez mystérieux pour vous, c’est un signe que vous les utilisez probablement mal. Que doit-on donc espérer du résultat ?

    • considérer les codes simples comme des codes d’amateur. Écrire un code simple et être à l’affût de simplification dans son code n’est pas forcément un signe d’amateurisme. Au contraire, cela peut-être la meilleure manière d’écrire un code propre et maintenable ;

    • ne pas explorer quelques pistes avant de demander de l’aide. Avant de solliciter de l’aide sur un problème, il faudrait essayer de le résoudre d’abord et explorer plusieurs pistes qui n’ont pas marché. Cela vous permet de mieux apprécier la solution qui vous est fournie et l’améliorer si nécessaire.


    Et vous ?

    Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ? Partagez votre expérience
    Lesquelles rencontrez-vous souvent ?
    Quels sont les éléments qui manquent selon vous ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre habitué
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    mai 2006
    Messages
    43
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mai 2006
    Messages : 43
    Points : 136
    Points
    136

    Par défaut

    J'ajouterai le critère selon moi le plus important:

    Ne coder que le cas nominal et planifier le codage des cas particulier et la gestion des erreurs à la fin du codage.


    Autre critère: ne pas factoriser le code.

  3. #3
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 262
    Points : 6 119
    Points
    6 119

    Par défaut

    Citation Envoyé par tp1024 Voir le message
    Autre critère: ne pas factoriser le code.
    Correction :
    Autre critère: ne pas factoriser le code tout de suite mais à la fin.

    Parce que sinon c'est une habitude à écrire un code de mauvaise qualité et difficilement maintenable.
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  4. #4
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    29
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2017
    Messages : 29
    Points : 242
    Points
    242

    Par défaut

    Je dirais le syndrome de la décharge (ou du carreau cassé) : s'autoriser un petit écart, une verrue qui va rester, qui va grossir avec le temps et les évolutions apportées. Au final, si le bout de code est mauvais, chacun viendra rajouter ses déchets dans l'esprit de l'existant.
    Moralité, c'est une mauvaise habitude de laisser le code de mauvaise qualité vivre.

  5. #5
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 604
    Points : 1 056
    Points
    1 056

    Par défaut

    Citation Envoyé par Michael Guilloux Voir le message
    [*]vouloir optimiser le code dès le début. Il n’est pas nécessaire de chercher à optimiser son code dès le début pour faire face à toute sorte de scénarios possibles. Ce travail devrait être gardé pour la fin. Le plus souvent les exigences telles que définies au début peuvent changer. Vous aurez donc perdu du temps à vouloir optimiser votre code dès le début, et adapter le code optimisé aux nouvelles exigences peut générer plus d’erreurs ;
    Suis pas tout à fait d'accord sur ce point, moi. Autant le principe est correct, autant dans la réalité du métier, ce n'est pas viable.

    Le plus souvent, on vous donne une mission à remplir, ainsi qu'un délai pour le faire. Si le code produit à l'échéance de ce délai n'est pas optimisé, l'employeur ou le client décidera généralement de zapper cette phase d'optimisation, après tout, ça tourne déjà, voire ça rapporte déjà, cela représente donc, pour lui, une dépense inutile ou juste annoncée comme du "on verra plus tard" qui n'arrive jamais.

    Perso, sur base de plus de 10 ans à aider du monde qui n'a pas le temps de faire du propre, je pars du principe que si un code n'est pas bien écrit dès le départ, il ne le sera jamais.

    C'est juste le meilleur moyen d'avoir une usine à gaz avec plein de conventions de codage différentes & Co.

    Alors, oui, avoir des process qui changent, ça arrive souvent mais ce qui génère davantage d'erreurs, c'est généralement que les développeurs font des rustines sur des trucs déjà pas trop bien pensés à l'origine ou pour lesquels on a pas donné assez de temps pour avoir du travail de qualité.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  6. #6
    Expert éminent
    Avatar de Michel Rotta
    Homme Profil pro
    Responsable d'exploitation informatique
    Inscrit en
    septembre 2005
    Messages
    4 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Responsable d'exploitation informatique
    Secteur : Distribution

    Informations forums :
    Inscription : septembre 2005
    Messages : 4 930
    Points : 8 318
    Points
    8 318

    Par défaut

    Considérer qu'il n'y a jamais d'erreurs possibles et donc ne jamais vérifier les données en entrée ou les échanges avec d'autres outils (méthode dite du Bisounours).
    Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).

    • Pensez à valoriser les réponses pertinantes, cliquez sur le bouton vert +1 pour indiquer votre accord avec la solution proposée.
    • Pensez à utiliser la balise [code] pour afficher du code, elle est cachée sous le bouton [#] dans l'éditeur.
    • Une discussion est terminée ? Alors le bouton est votre ami !

  7. #7
    Membre expérimenté Avatar de Jbx 2.0b
    Homme Profil pro
    Développeur Qt/3D
    Inscrit en
    septembre 2002
    Messages
    446
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Qt/3D
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : septembre 2002
    Messages : 446
    Points : 1 671
    Points
    1 671

    Par défaut

    - Ne pas respecter les règles de codage (syntaxe, nommage) formalisées par l'équipe. Pire: ne pas en avoir soit même, et jongler avec la casse, les indentations, la ponctuations, au petit bonheur la chance.
    - Ne pas prendre le temps pour donner des noms explicites qui décrivent clairement ce que fait l'objet ou la méthode.
    - Utiliser des abréviations.
    - Ne pas connaitre et mettre en oeuvre les design patterns les plus courants.
    - Violer le pattern MVC, en général en exposant la vue au modèle (y a des projets énormes dans des grandes boîtes basé sur ce péché originel).
    - Etre trop feignant pour refactoriser immédiatement un code lorsque l'on détecte une des erreurs sus mentionnées.
    - Procrastiner les bugs, la gestion d'erreur, les tests...

  8. #8
    Nouveau membre du Club
    Inscrit en
    août 2008
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 22
    Points : 26
    Points
    26

    Par défaut Contexte

    Meme si les grandes lignes des pires habitudes du sondage sont pertinentes, je trouve que tout est une affaire de contexte. Parfois vous devez faire du code "quick&dirty". Parfois il faut avoir un vrai framework robuste.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 699
    Points : 19 630
    Points
    19 630

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Correction :
    Autre critère: ne pas factoriser le code tout de suite mais à la fin.

    Parce que sinon c'est une habitude à écrire un code de mauvaise qualité et difficilement maintenable.
    Ca, c'est mon collègue, qui trouve que je me complique toujours la vie avec mes fonctions, là ou un simple posé de code copié-collé-adapté suffit à ses yeux..... Le pire, c'est que son code marche, mais le jour ou on a une modif majeure, on pleure.
    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.

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    juillet 2008
    Messages
    123
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2008
    Messages : 123
    Points : 303
    Points
    303

    Par défaut Factoriser

    Développeur ce n'est pas mon métier, mais j'écris pas mal de scripts en bash. C'est pratique pour les tests unitaires : il y a la console. Factoriser tout de suite, c'est une bonne habitude à prendre. En cas de modification, ça évite d'avoir à modifier plusieurs fois dans le code la même chose.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 699
    Points : 19 630
    Points
    19 630

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    Le plus souvent, on vous donne une mission à remplir, ainsi qu'un délai pour le faire. Si le code produit à l'échéance de ce délai n'est pas optimisé, l'employeur ou le client décidera généralement de zapper cette phase d'optimisation, après tout, ça tourne déjà, voire ça rapporte déjà, cela représente donc, pour lui, une dépense inutile ou juste annoncée comme du "on verra plus tard" qui n'arrive jamais.
    A mon sens, ça dépend de ce qu'on appelle "optimiser". Si c'est juste rajouter un tri préliminaire et un bête buffer pour limiter les I/O sur un traitement de masse, oui, c'est mieux de le faire au début. Si c'est penser son système pour ne pas avoir de redondances d'exécutions, oui c'est mieux d'y penser dès le début. Si c'est aller chercher des méthodes de sioux via des pointeurs pour forcer le compilateur à une manip nettement plus compliquée, là, il vaut mieux le faire vers la fin, et uniquement là ou on a identifié des fortes consommations.
    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.

  12. #12
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 351
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 351
    Points : 3 030
    Points
    3 030

    Par défaut

    Citation Envoyé par Michael Guilloux Voir le message
    [*]vouloir réinventer la roue tout le temps. Avec 99 % de chance, votre problème a déjà été résolu quelque part. Pourquoi donc ne pas googler quand le problème vous semble complexe ?
    A moitié vrai.
    La multiplication des solutions fait qu'on passe de plus en plus de temps à chercher quelquechose, à éplucher les documentations, voir les avis et a tester si ca fonctionne dans notre cas...
    Bref c'est de plus en plus chiant de "développer" parcequ'on devient de plus en plus des "assembleurs", et surtout en terme de maintenance je crois qu'on y perd.
    En effet lorsqu'on se retrouve a récupérer un projet qui fait reference à x librairie dont on a jamais entendu parler et qu'il y a un soucis, ou une demande d'evolution, il faut non seulement comprendre notre code mais egalement s'assurer que la librairie est "bien" utilisée. Dans le pire des cas on se rend meme compte que cette librairie possède un bug, et que la librairie est abandonnée.

  13. #13
    Membre régulier
    Homme Profil pro
    Développeur, graphiste et rédacteur web
    Inscrit en
    août 2011
    Messages
    34
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur, graphiste et rédacteur web
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 34
    Points : 105
    Points
    105

    Par défaut

    Vouloir réinventer la roue tout le temps

    Pas d'accord sur ce point précisément.
    Si on prend effectivement dans un cadre très précis de programmation et de contexte d'entreprise (avec délais de livraison très courts, contraintes à n'en plus finir, besoin sans cesse de gain de productivité), en effet, savoir utiliser l'existant permet de gagner de précieuses minutes et de fournir le travail dans les temps.

    Mais en prenant le codage d'un point de vue globale, dans un ensemble, c'est ô combien important de ré-inventer la roue. Je rappelle que ce sont des gens qui un jour se sont dit "moi, je peux refaire ce système, mais en mieux" qui sont à l'origine des innovations de notre temps. Et c'est parce que nombre de développeurs ont ré-inventé la roue que nous avons autant de choix de logiciels, systèmes, de jeux vidéo, et j'en passe.

    Il suffit de voir par exemple le cas des blogs WordPress. Si tout le monde installe exactement le même type de blog, les mêmes plugins, le même thème....on finira avec des clones, des projets sans aucune différence et une réelle perte d'identité pour ces derniers. À un moment donné, il faut bien ré-inventer quelque chose...ou partir d'une base que l'on améliore (mais cette amélioration, dans 99% des cas, existe sûrement déjà aussi).

    Étant formateur en informatique sur internet, c'est un point que j'aborde très souvent auprès de mon audience. Si vous travaillez dans des conditions précises et imposées, vous n'avez pas le temps de ré-inventer. Faîtes avec ce qui existe déjà et le client sera content. Mais pour celui qui code dans son coin, par véritable passion, ou est libre de travailler dans le temps qu'il lui convient, c'est souvent un réel gain d'expérience et de plaisir que de ré-inventer ce qui se fait déjà =).

    PS : je rajouterai que, de nos jours, les développeurs dans les entreprises (pas toutes heureusement) ne sont plus vraiment des développeurs ou programmeurs, mais des personnes qui apprennent à prendre en main des logiciels et des traitements automatisés, pour assembler tout ça et espérer que ça fonctionne. J'ose espérer que dans 10 ans, il existera encore des gens qui se poseront la question de s'il est possible de ré-inventer un système de tri qui sera plus performant que les actuels, ou d'autres algorithmes du genre qui sont toujours améliorables ou re-faisables.

  14. #14
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 1 700
    Points : 6 733
    Points
    6 733

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    Le plus souvent, on vous donne une mission à remplir, ainsi qu'un délai pour le faire. Si le code produit à l'échéance de ce délai n'est pas optimisé, l'employeur ou le client décidera généralement de zapper cette phase d'optimisation, après tout, ça tourne déjà, voire ça rapporte déjà, cela représente donc, pour lui, une dépense inutile ou juste annoncée comme du "on verra plus tard" qui n'arrive jamais.
    Tout dépend quel est l'utilisation du code en question.
    Parfois, le besoin est juste d'avoir une fonctionnalité qui effectue le service demandé.
    Pas besoin que ça soit beau ou optimisé ou même évolutif.
    Le quick and dirty peut parfaitement correspondre.
    Ce n'est pas pour rien qu'Excel est si utilisé en entreprise.
    L'idée peut être simplement d'aller vite et pas cher.
    Je sais que ça peut paraître irritant aux oreilles de développeurs chevronnés et passionnés mais cela est parfaitement sensé du côté client.


    Dans d'autres cas, les perf. du programmes sont au moins aussi importantes que ses fonctions.
    Et là, je peux dire que les clients payent sans rechigner pour optimiser le code.
    Je pense notamment à des programmes très fortement sollicités et souvent en appel direct par les clients réels de l'entreprise.
    Par contre, dans ces cas là, le besoin en perf est clairement spécifié dans le CDC et la conception en tient compte dès le départ.
    Les optimisation viennent suite aux observations effectués lors de tirs de charge et autres stress tests.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 699
    Points : 19 630
    Points
    19 630

    Par défaut

    Sur la réutilisation : la classique réponse de Joel Spolsky :

    If it’s a core business function — do it yourself, no matter what.
    En d'autres termes, si vous êtes un hopital, réutilisez un logiciel pour le café. Mais si vous êtes Starbucks, faites-le vous-même.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  16. #16
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    450
    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 : 450
    Points : 1 960
    Points
    1 960

    Par défaut

    Citation Envoyé par Michael Guilloux Voir le message
    être un développeur orienté copier/coller. Il ne faut pas copier/coller aveuglément. Il est nécessaire d’essayer de comprendre le code d’abord, car il est possible qu’il ne fasse pas exactement ce qu’il prétend faire
    Ce commentaire s'applique à ceux qui pompent du code sur internet. Mais, les pires développeurs orientés copier-coller, ce sont ceux qui copient-collent en masse de gros morceaux de code de leur propre programme au lieu de factoriser. Le pire exemple que j'ai vu était un copié-collé d'une fonction de plus de 1000 lignes.

    Citation Envoyé par tp1024 Voir le message
    Ne coder que le cas nominal et planifier le codage des cas particulier et la gestion des erreurs à la fin du codage.
    Pire : ne coder que le cas nominal, se barrer dans une autre boîte et laisser souffrir ceux qui reprendront le code. Déjà vu.

    Citation Envoyé par Lcf.vs Voir le message
    Le plus souvent, on vous donne une mission à remplir, ainsi qu'un délai pour le faire. Si le code produit à l'échéance de ce délai n'est pas optimisé, l'employeur ou le client décidera généralement de zapper cette phase d'optimisation, après tout, ça tourne déjà, voire ça rapporte déjà, cela représente donc, pour lui, une dépense inutile ou juste annoncée comme du "on verra plus tard" qui n'arrive jamais.
    Ce n'est pas forcément un problème. Si on se met à la place de l'utilisateur, il est parfois plus important qu'une certaine fonctionnalité soit disponible tôt plutôt que le programme soit optimisé.
    Ce qui est important, c'est que le code soit correctement architecturé pour qu'il soit facile d'optimiser plus tard, si le client en a vraiment besoin, par exemple si un traitement devient trop lent ou échoue car consomme trop de mémoire.

    Citation Envoyé par Jbx 2.0b Voir le message
    - Utiliser des abréviations.
    Abuser des abréviations est une mauvaise pratique, mais en utiliser est parfois justifié.
    Par exemple, pour éviter des collisions de noms, une bonne manière est d'utiliser un préfixe spécifique au projet.
    Comme ce préfixe doit être unique mais préférentiellement court, utiliser une abréviation peut être une bonne idée.
    Remarque : Dans les langages qui supportent les espaces de nom, c'est l'espace de nom qui joue le rôle du préfixe.

    Citation Envoyé par Michael Guilloux Voir le message
    Quels sont les éléments qui manquent selon vous ?
    Les deux points suivants relèvent plus de la conception que du codage, mais les voici quand même :

    Être trop permissif dans les données en entrée et les accepter sans signaler d'erreur ou, au moins, d'avertissement.
    Exemples :
    • Un fichier en entrée n'est pas au bon format. Pas grave : on ajoute plein de conditions dans le code pour réussir à le lire quand même dans un maximum de cas possibles.
    • Une configuration indique qu'un certain dossier a une certaine adresse, mais le programme constate que ce dossier ne contient pas certains fichiers qu'il aurait dû contenir si la configuration était cohérente avec l'installation. Pas grave : on va chercher les fichiers, successivement, dans plein d'autres dossiers différents. On finira peut-être par les trouver.

    Du coup, l'analyse des problèmes devient laborieuse et le code devient plus complexe, ce qui ralentit l'ajout de nouvelles fonctionnalités et augmente la fréquence d'apparition de nouveaux bogues.

    Utiliser des données utilisateurs comme des clefs primaires dans les bases de données.
    Exemple intéressant : https://www.developpez.net/forums/d8...s/#post5745847

  17. #17
    Membre averti Avatar de Aizen64
    Profil pro
    Inscrit en
    mai 2007
    Messages
    487
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2007
    Messages : 487
    Points : 374
    Points
    374

    Par défaut

    Sachant que je prend rarement le chemin le plus court ni le plus efficace, je dirais :
    - aller à l'essentiel
    - toujours vérifier les saisies utilisateur, exemple d'un formulaire web, si les valeurs autorisés sont A, B ou C, aucune autre valeur ne doit être acceptée,
    - toujours séparer le traitement de l'affichage,
    - ne pas réinventer la roue.
    Exprimer une différence d'opinion vaut mieux que :

  18. #18
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2013
    Messages : 13
    Points : 59
    Points
    59

    Par défaut

    Etant le seul développeur, j'ai personne pour vérifier mon code et pour me taper sur les doigts
    Au contraire, je suis très attaché à la qualité et être seul nécessite beaucoup plus de rigueur (pas toujours évident quand il y a une deadline serrée, et là c'est de la doc qui passe à la trappe ou l'optimisation de certaines fonctions).

    J'ai voté pour ces propositions :
    • être un développeur orienté copier/coller
    • utiliser des noms ne donnant aucune information sur ce que fait le code
    • s’entêter à vouloir résoudre des problèmes sans demander de l’aide
    • ne pas documenter ou commenter son code


    Critères que je rencontre parfois avec des stagiaires (que je met forcément sur le compte de l'expérience).

    Ou même de l'ancien développeur : du style à faire 1 fichier de 1900 lignes de fonctions et ne mettre qu'un seul commentaire en haut de page totalement inutile « Regroupe toutes les fonctions de l'application » OK MERCI

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

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

    Informations forums :
    Inscription : août 2014
    Messages : 277
    Points : 469
    Points
    469

    Par défaut

    optimiser du code dans une architecture logicielle pensée optimisation des perfs des la conception est essentielle et largement plus utile que coder en moins de lignes de codes possibles.
    Pour ca qu'en 2017 je ne comprends pas pourquoi M$ par exemple continuer a inventer des syntaxes dans les nouvelles versions C# pour passer de 3 lignes de code a 2. Ca ne fait absolument rien gagner, ca ne simplifie pas la maintenance -car tout le monde n'est pas forcement interessé de connaitre la derniere petite syntaxe inutile.
    Je vois trop souvent dans ma boite des gens qui pissent litteralement du code puis repasse par des etapes de refactoring. Souvent passer plus de temps en amont dans la conception est plus efficace que defaire/refaire apres. Enfin le refactoring est a la mode c'est donc que les dev ne concoivent pas mais se jettent sur le clavier et refont quand c'est au pied du mur avec un soft mal concu.
    je viens de l'assembleur/c/c++ donc j'ai toujours appris a penser optimiser logiciel en premier (a une epoque (1989), on desassemblait meme le C 68000 pour le modifier afin d'arriver a un code machine le plus simple). Maintenant on ne se fait plus chier, new() a tour de bras, il y aura bien quelqu'un (GC) qui fera le boulot (le dev est devenu faineant et faire un delete() est trop compliqué).
    Ca me fait rire quand je vois les sujets de discussion type 'optimisation du code : foreach ou for' ? A une epoque ou dans les langages on fait des new() a tour de bras. C'est le genre de discussion totalement inutile (qui meme si elle etait vraie ne ferait rien gagner quasiment alors qu'un logiciel un peu mieux concu suffirait a optimiser les perfs - independamment de la facon d'ecrire du code).
    Le langage est un support pas une fin en soi. Alors se faire plaisir pour faire du code "beau"...
    Seulement entre temps on a perdu le 'comment ca marche' et des qu'il y a pb de perfs ou bugs c'est la paanique car la mecanique de base n'est pas maitrisée (inspiration du code piqué sur internet le plus souvent). En 2017 la regle du devp moderne c'est copier/coller et stackoverflow.

    J'ai vu des soi disants tres bons programmeurs (code illisible en WPF par exemple). Par contre un logiciel qui est une merde en maintenance.
    La maintenabilité du code par quiconque est pour moi la 2eme chose essentielle (sans pour autant que celui qui passe derriere n'ai a connaitre les dernieres syntaxes a la mode - qui ne feront pas executer le code plus vite pour autant). Finie l'epoque du basic ou on enlevait les commentaires pour gagner en vitesse d'execution.

    Pour ce qui est revu de code (ou validation des pulls requests), je ne passe pas derriere mes collegues car j'estime qu'en etant ingenieurs ils doivent s'appliquer un minimum d'exigences. Ce n'est pas a moi d'aller verifier qu'ils ont mis les bons noms de variables, coder correctement le fonctionnel etc.
    ils ont une tache, elle doit etre remplie parfaitement. point barre.
    Un gars qui fait du code de merde ca se voit vite sur une prod donc generalement ca se termine en 'tu corriges tes merdes quittes a venir bosser le samedi, car maintenant c'est ton probleme' sinon tu n'as pas ta place ici. J'estime qu'un gars payé a un certain niveau de salaire est redevable d'une certaine qualité dans le travail rendu et ce n'est pas a l'equipe d'essuyer les platres a sa place.
    Ca fonctionne, les devps s'imposent un travail de verification/relecture qui paie.

  20. #20
    Membre averti Avatar de Aizen64
    Profil pro
    Inscrit en
    mai 2007
    Messages
    487
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2007
    Messages : 487
    Points : 374
    Points
    374

    Par défaut

    Citation Envoyé par kilroyFR Voir le message
    optimiser du code dans une architecture logicielle pensée optimisation des perfs des la conception est essentielle et largement plus utile que coder en moins de lignes de codes possibles.
    Oui c'est vrai, au passage, les perfs dépendent du projet en question.

    A moins de faire de gros calculs pointus, de l'IA, 3D et j'en passe, la plupart des projets plus "classiques" seront sensibles à une chose : faire un minimum d'appels BDD puisque une requête SQL (même simple) ou un appel WebService c'est 500ms à plus d'une seconde de perdue sur un environnement de production.

    Je ne dis pas de coder avec les pieds, cela étant, passer par des variables intermédiaires, ou déclarer 2, 3 variables pas très utiles ont pas forcément un impact capital sur les perfs.

    2 points sur le développement web
    - toujours séparer traitement et présentation, les appels BDD ne doivent pas être disséminés partout dans le code,
    - ne jamais mélanger du code client avec un langage serveur.

    Ne pas respecter ces règles c'est dire au revoir à des tests unitaires.
    Exprimer une différence d'opinion vaut mieux que :

Discussions similaires

  1. Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 69
    Dernier message: 20/09/2017, 19h55
  2. Réponses: 1
    Dernier message: 07/08/2008, 10h36
  3. quelles sont les SSII qui font du forfait
    Par coax81 dans le forum SSII
    Réponses: 11
    Dernier message: 12/10/2007, 14h49
  4. Réponses: 6
    Dernier message: 03/07/2007, 10h34

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