IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

Que signifie le terme « meilleures pratiques » dans le développement logiciel ?


Sujet :

ALM

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 287
    Points
    12 287
    Par défaut Que signifie le terme « meilleures pratiques » dans le développement logiciel ?
    Que signifie le terme « meilleures pratiques » dans le développement logiciel ?
    Un sénior déclare qu'il est dénué de sens et utilisé à tort

    Un article publié par Erik Dietrich, blogueur et auteur de deux livres sur le développement, a fait le buzz récemment sur DeadTech. L’article concerne l’utilisation « abusive » du terme « meilleures pratiques » dans les articles et les tutoriels traitant du développement logiciel qu’on peut trouver sur internet.

    Selon Erik Dietrich, l’expression « meilleures pratiques » est vague et subjective. En effet, il commence par donner la signification officielle du terme, qu’il décrit comme étant : « la pratique dont la preuve empirique démontre qu’elle est supérieure aux autres pratiques ». Il s’agit là de la définition « idéale » selon Dietrich. La deuxième signification, dite « réelle », la décrit comme étant « une convention sur la manière de faire quelque chose, souvent établie par des organismes de standardisation tels qu’ISO par exemple ».

    La troisième définition, celle proposée par Dietrich, la décrit néanmoins comme étant un terme basique et dénué de sens très souvent utilisé par des personnes voulant faire croire que leurs actions sont plus importantes et raisonnables qu’elles ne le sont réellement, et ceci bien sûr sans preuve empirique ou scientifique pour justifier ce choix. En d’autres termes, cette dernière définition, dite « cynique », coïncide avec « l’utilisation la moins crédible » du terme.

    « Je suis sûr que je ne suis pas le seul à avoir entendu les gens utiliser le terme "meilleures pratiques" pour justifier leurs actions quand il était clair que cette "pratique" n’a été ni empiriquement démontrée comme étant la meilleure ni approuvée par convention ou par un organisme de normalisation », déclare l’auteur de l’article. Selon lui, ceci peut aussi s’appliquer aux processus industriels. Il donne une liste d’exemples jugés comme étant de bonnes pratiques dans l’industrie des logiciels sans qu’il y ait pour autant de preuves universelles qui démontrent leur supériorité par rapport aux autres pratiques existantes. Parmi cette liste d’exemples, on peut citer :

    • Le développement agile
    • Le développement dirigé par les tests
    • L’intégration continue
    • Les design patterns
    • Le code review
    • Le pair programming

    Erik Dietrich insiste sur le fait que ces exemples sont souvent controversés, mais le fait est que l'industrie en général a évolué dans une direction où ces techniques sont largement adoptées. « Il y a une fine ligne entre la sagesse conventionnelle et la fausse idée commune » déclare-t-il. « Comment peut-on savoir si ces pratiques sont vraiment de bonnes idées et, plus important encore, comment peut-on savoir si ces pratiques sont bonnes pour le développeur et pour son organisation ? ».

    Source : DeadTech

    Et vous ?

    Que pensez-vous de l’avis d’Erik Dietrich ?

    Les exemples qu’il cite sont-ils de bonnes pratiques ou de simples fausses idées communes ?

  2. #2
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Je considère, pour ma part, que les 7 pratiques évoqués font partie sinon des "meilleures pratiques" de "bonnes pratiques" dans le développement logiciel.
    Pour moi, les ayant pratiqués plusieurs fois dans divers projets, je considère que leur pratique empirique m'a démontré qu’elles donnent de meilleurs résultats que de ne pas les utiliser.

    Là où je pense que la polémique est présent c'est que dans certain cas elle ne donne pas le résultat escompté par ce qu'on ne les met pas en place complètement: un peu d'agité, un peu de contrôle continue, un peu de TDD, pas trop de pair programming, ....
    Ces pratiques nécessite pas mal de changement dans la façon de penser à la fois de la part des développeurs, que du management et parfois, le changement est difficile.
    Il peut même s'opposer à des réticences ou des incompatibilité avec des intérêt personnels.

    Après, que l'on appelle ça "meilleures pratiques", "bonnes pratiques", "pratiques à la modes" ou "les pratiques d'Erik Dietrich", j'avoue que je trouve ça inutile comme débat et sans grand intérêt.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 769
    Points : 31 801
    Points
    31 801
    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.

  4. #4
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 532
    Points : 1 702
    Points
    1 702
    Par défaut
    Beaucoup de bonnes pratiques doivent prendre en compte le facteur humain ( ce qui ne ressort jamais dans les stats !).

    - Le TDD : c'est sur si on laisse pas le temps au développeur de faire les choses, ça va échouer ! ( ou pire on choisit un dev qui ne sait et ne veut pas savoir ce que c'est qu'un test unitaire)
    - Dans beaucoup d'équipes hétérogènes certaines personnes ne savent même pas ce que c'est , et il n'y a souvent pas d'architecte.
    - Le développement par pair : si le binôme n'est pas bon ou ne s'entend pas c'est l'échec. Par contre si il s’entendent, ça peut donner de superbes résultats.
    - L'agile est souvent du faux agile (XP avec 6 intermédiaires avant le métier, faut pas s'étonner que ça échoue )



    Bref les managers ne pensent souvent qu'en terme de coût (je simplifie avec une pincée de mauvaise fois ) donc l’intérêt des méthodes reste très difficile à prouver lorsque la moitié des projets échouent(ou dépassent le budget) à cause d'une mauvaise gestion.

  5. #5
    En attente de confirmation mail
    Femme Profil pro
    pape n'aimant pas les censeurs
    Inscrit en
    janvier 2010
    Messages
    803
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Vatican

    Informations professionnelles :
    Activité : pape n'aimant pas les censeurs

    Informations forums :
    Inscription : janvier 2010
    Messages : 803
    Points : 1 406
    Points
    1 406
    Par défaut
    C'est vraiment le genre de polémique pour mettre un peu d'ambiance à l'heure de l'apéro!!!

    Le plus important est de savoir que l'on peut établir toutes les "bonnes", "meilleures" et autres pratiques, la qualité du logiciel dépendra toujours en premier lieu de la qualité et de l'état d'esprit du développeur!!!

    Je parle bien d'état d'esprit et pas de diplôme!!! Le développeur doit être réfléchi et METICULEUX, avoir l'esprit du détail...

    J'ai ici une pensée émue pour les pseudo-développeurs que certainement tout le monde a eu à subir, de ceux qui, lorsqu'ils doivent corriger un bug, vous retournent un code avec 10 nouveaux bugs qui n'existaient pas avant leur intervention... Et ceux-là vous pouvez leur imposer toutes les bonnes pratiques du monde, ils vous fourniront toujours de la daube...

  6. #6
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 167
    Points
    1 167
    Billets dans le blog
    9
    Par défaut
    Que signifie le terme « meilleures pratiques » dans le développement logiciel ?
    Celle qui marche (qui ont fait leurs preuves), ainsi que le respect les conventions, par exemple pour les variables, ont ne les nommes pas n'importe comment, i et j son réservé dans les boucles, a b et c dans les calcules arithmétiques...

  7. #7
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 161
    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 : 2 161
    Points : 7 941
    Points
    7 941
    Par défaut
    Je suis en phase avec le post de Laurent 1973
    Si on se mets à débattre sur tous les termes de sémentique marketing, on n'a pas fini et surtout, il ne nous resterai plus de temps pour développer et les mettre en pratique justement lol

  8. #8
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 381
    Points : 8 641
    Points
    8 641
    Billets dans le blog
    43
    Par défaut
    Même si ce n'est pas très politiquement correct, la racine des problèmes de l'IT ce ne sont pas la sémantique autour des bonnes ou des mauvaises pratiques, mais c'est d'abord les bons développeurs et les mauvais développeurs, dans le sens de compétents, organisés et rigoureux.

    Les bonnes pratiques n'étant finalement que des sparadraps pour limiter la nuisance causée par les mauvais développeurs.

    Au fur et à mesure que le métier de développeur se démocratise, on a tendance à invoquer ces bonnes pratiques alors que le problème est ailleurs.
    Tutoriels et FAQ TypeScript

  9. #9
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Citation Envoyé par sazearte Voir le message
    .. comment, i et j son réservé dans les boucles, a b et c dans les calcules arithmétiques...
    Je suis d'accord sur avoir des conventions de nommages, c'est une bonne pratique en effet.
    Mais pour moi, je m'interdis les variables de moins de 3 caractères qui n'ont pas la signification de ce qu'elles contiennent.

    Pour une boucle ce sera plutôt "truc_index" et "machin_index" que i et j (voir k, l, m, n ... on en finit plus).
    Au moins, quand on reviens dans le code, on comprends plus facilement à quoi correspond chaque index de boucle.

    Pour information: dans beaucoup de langages, la longueur maximum d'une variable et d'une fonction c'est 255 caractères, alors on peux être explicite et éviter les abréviations incompréhensibles.

    Donc, désolé, mais utiliser i, j, a, b, c ... n'est pas pour moi une bonne pratique.
    Comme quoi la notion de bonnes pratiques est subjective aussi.

    Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
    - aucun warning en compilation
    - utilisation d'un outil d'analyse statique de code (comme lint en C++) avec zéro erreur à l’intégration continue

  10. #10
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 875
    Points : 39 722
    Points
    39 722
    Par défaut
    Citation Envoyé par Amine Horseman Voir le message
    • Le développement agile
    • Le développement dirigé par les tests
    • L’intégration continue
    • Les design patterns
    • Le code review
    • Le pair programming
    Dans le tas j'en vois quand même plusieurs qui contribuent indubitablement à la qualité du code :
    • design patterns : ce n'est pas pour rien qu'on appelle ça des patterns, ce sont des solutions éprouvées pour résoudre certaines classes de problèmes. A condition de les utiliser avec discernement, ça ne peut être que bénéfique.
    • code review : dans ma boite, on est longtemps passé à côté ; maintenant qu'on le fait régulièrement, 95% des code reviews permettent d'identifier en amont des problèmes qui se seraient peut-être révélés beaucoup plus tard autrement.
    • intégration continue : c'est clairement un des meilleurs moyens de s'assurer qu'on ne commite pas n'importe quoi...


    Pour le reste, c'est plus des questions d'opinion. Par exemple la méthode Agile a ses avantages, mais ce n'est sans doute pas une "bonne pratique" dans le sens où il faut obligatoirement le faire.

  11. #11
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 167
    Points
    1 167
    Billets dans le blog
    9
    Par défaut
    Pour une boucle ce sera plutôt "truc_index" et "machin_index" que i et j (voir k, l, m, n ... on en finit plus).
    Au moins, quand on reviens dans le code, on comprends plus facilement à quoi correspond chaque index de boucle.
    Sa dépend du langage je dirais, prend le c:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    for (i=1; i<6; i++) {
     printf("%d", i);
    
    }
    Je n'ai jamais vu de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    for (nombredepointeurdansmonobjetdemonprogrammesouslinux=1; nombredepointeurdansmonobjetdemonprogrammesouslinux<nombredepointeurquejedoismettrepourquesamarche; nombredepointeurdansmonobjetdemonprogrammesouslinux++) {
     printf("%d", nombredepointeurdansmonobjetdemonprogrammesouslinux);
    
    }
    C'est beau 255 caractère dans une variable , je reconnais je suis de mauvaise foi.
    Dans mon premier exemple, tu peut remplacer 6 par un nom explicite, mais je vois l’intérêt de remplacer i par autre chose ?

  12. #12
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Sa dépend du langage je dirais, prend le c:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    for (i=1; i<6; i++) {
     printf("%d", i);
    
    }
    C'est très jolie ta petite boucle.
    Mais à quoi correspond chaque itération de celle ci? un temps? la tentative d'une action qui peux échoué? une parcours dans une liste?
    De plus "6", numéro magique qui tombe comme un cheveux dans la soupe: privilégier l'utilisation d'une constante explicitant le sens de ce "6"

    Sinon, je trouve que "index_du_pointeurs_dans_mon_objet_de_mon_programme_sous_linux" et "nombre_de_pointeurs_que_je_dois_mettre_pour_que_ca_marche" sont plus lisible que "nombredepointeurdansmonobjetdemonprogrammesouslinux" et "nombredepointeurquejedoismettrepourquesamarche" mais chacun ses goûts .
    Et en tout cas bien plus que ton nombre "6"

    Et c'est pas parce que l'on utilise i, j, k dans les boucles depuis 40 ans (à une époque où les variables étaient limité à 8 caractères) que c'est une bonne chose.

    Bon, je suis aussi un peu de mauvaise foi au sens que je n'utilise jamais 255 caractères pour nommer une variables.
    Mais entre 10 et 30 c'est assez classique et cela m'évite de rajouter un commentaire pour expliquer son rôle.

  13. #13
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 3 715
    Points : 1 167
    Points
    1 167
    Billets dans le blog
    9
    Par défaut
    Et en tout cas bien plus que ton nombre "6"
    J'ai préciser que le nombre 6 doit être une variable explicite.

    Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique

  14. #14
    Membre confirmé
    Homme Profil pro
    Inscrit en
    octobre 2010
    Messages
    83
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : octobre 2010
    Messages : 83
    Points : 536
    Points
    536
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Donc, désolé, mais utiliser i, j, a, b, c ... n'est pas pour moi une bonne pratique.
    C'est aux mathématiciens qu'il faut expliquer ça
    les algorithmes qui oublient leur histoire sont condamnés à la répéter

  15. #15
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique
    Je ne dirais pas que tu as de mauvaises pratiques, mais par contre je considère que ce type de convention n'est pas vraiment une "bonne" pratique à donner en exemple (tu vois la nuance)
    Au moins, tu as conscience que les conventions ne nommage est une bonne pratique et je suis d'accord avec toi.

    Ensuite, si toi ou tes collègues n'avez jamais eu de souci de compréhension (sans mélanger i et j dans 2 boucles imbriqués complexe) d'un vieux code utilisant cette convention, pourquoi changer en effet.
    Les conventions sont parfois dépendant de l'organisation, du projet et des technologies utilisées.

    Je ne souhait pas conclure que tout ce qui n'est pas une bonne pratique, doit forcément être une mauvaise.
    On est humain et contrairement au machine, tout n'est pas binaire dans notre perception.

  16. #16
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 161
    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 : 2 161
    Points : 7 941
    Points
    7 941
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique
    Sans aller jusqu'à dire que c'est une "mauvaise" pratique
    On peut dire qu'elle n'est pas optimum

    Dans le billet de blog d'Erik Dietrich, il n'est pas question de bonnes ou mauvaises pratiques mais de l'utilisation du terme "meilleures" pratiques
    Je conviens que techniquement et mathématiquement, le nuance est de taille
    Mais en ce qui concerne l'expression orale, je trouve que c'est se prendre la tête pour pas grand chose

  17. #17
    Membre averti
    Profil pro
    Inscrit en
    juin 2006
    Messages
    186
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 186
    Points : 424
    Points
    424
    Par défaut
    Je dirais que dans un contexte de "bonne pratique", la question du i,j,k,l etc. ne se pose même pas, parce que 3+ boucles imbriquées dans une méthode est un sérieux indicateur comme quoi il est nécessaire de découper un peu plus son code.

  18. #18
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 272
    Points : 526
    Points
    526
    Par défaut
    Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
    - aucun warning en compilation
    - utilisation d'un outil d'analyse statique de code (comme lint en C++) avec zéro erreur à l’intégration continue
    Ton post m'émeut

    Je suis dans une mission où je désespère de faire accepter les bonnes pratiques que tu sites (en particulier la seconde), ainsi que de simples règles ... de bon sens.
    Impossible de faire comprendre l'intérêt d'avoir du code bien indenté, même quand le moteur de l'application est illisible, et que du coup personne ne sait comment il fonctionne ...
    Et bien sûr, quand j'ai remis de l'ordre là-dedans, j'ai eu beau livrer mes modifications régulièrement, personne n'a fait d'update fréquent. Résultat, au moment de la livraison : "Ho mais c'est le bazar, c'est tout rouge dans l'outil de merge !"
    Et au lieu de faire les fusions correctement, les collègues ont fait ... des revert à l'arrache sans analyse d'impact !
    Bonjour les bugs et les régressions !

    Bref, comme dit précédemment, ces bonnes pratiques dépendent beaucoup des développeurs.

  19. #19
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 516
    Points : 6 054
    Points
    6 054
    Par défaut
    Si j'ai bien tout compris, et dites moi si je suis hors-sujet, mais l'erreur générée en cas d'utilisation sans redémarrage des Boeing tous les 248 jours minimum provient d'un manque de prévoyance ou d'une incapacité pour cause de brevets logiciels à faire mieux ?

    Ceci est une pure question informative.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  20. #20
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 381
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 381
    Points : 8 641
    Points
    8 641
    Billets dans le blog
    43
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
    - aucun warning en compilation
    Ça me rappelle une anecdote qui avec le recul est plutôt amusante, lorsque j'ai eu à récupérer un jour une base de code d'un collègue. Je compile et le log inondé de warnings...

    Moi au collègue : Hmmm... Il y a comme un souci... Tu vois tous ces warnings ?
    Collègue : Oui et alors ?
    Moi : Ben, il faut les supprimer.
    Collègue : Fastoche ! C'est juste une option du compilateur à cocher !
    Moi :
    Tutoriels et FAQ TypeScript

Discussions similaires

  1. Que signifie 32768 ou 2^15 dans GetAsyncKeyState?
    Par genius4evers dans le forum C#
    Réponses: 9
    Dernier message: 18/07/2011, 19h08
  2. Réponses: 100
    Dernier message: 23/12/2010, 20h26
  3. Que signifie les #, $, @ dans des variables ?
    Par philuciole dans le forum Oracle
    Réponses: 12
    Dernier message: 28/08/2006, 19h38
  4. Question existentielle : Que signifie X dans MAC oS X?
    Par oOoOuuhmAn dans le forum Apple
    Réponses: 8
    Dernier message: 03/04/2006, 12h37
  5. Que signifie log dans un algo ?
    Par cryptorchild dans le forum Algorithmes et structures de données
    Réponses: 6
    Dernier message: 16/03/2006, 12h09

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