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

Débats sur le développement - Le Best Of Discussion :

Quel est le meilleur conseil quand on programme ?


Sujet :

Débats sur le développement - Le Best Of

  1. #101
    Membre actif
    Profil pro
    Responsable de service informatique
    Inscrit en
    Août 2006
    Messages
    174
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2006
    Messages : 174
    Points : 232
    Points
    232
    Par défaut
    Bonjour à tous,

    Ce que je conseille en général:

    1_ bien comprendre le besoin final

    2_ réfléchir

    3_ écrire les commentaires du code

    4_ coder

    Natso.

  2. #102
    Candidat au Club
    Profil pro
    CEO
    Inscrit en
    Août 2007
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : Cameroun

    Informations professionnelles :
    Activité : CEO

    Informations forums :
    Inscription : Août 2007
    Messages : 2
    Points : 3
    Points
    3
    Par défaut code fonctionnel
    je crois que le conseil de Bill Wagner est le meilleur. Rendre d'abord le code fonctionnel avant l'amélioration continue.

  3. #103
    Expert confirmé
    Avatar de Loceka
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    2 276
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2004
    Messages : 2 276
    Points : 4 845
    Points
    4 845
    Par défaut
    Citation Envoyé par mitkl Voir le message
    Pour vous, quel est le meilleur conseil que l'on peut donner ?
    Moi je reprendrais le conseil de Solo (Han) : Coder l'air décontracté

    Sinon, un conseil qui ne revient pas assez souvent : ne jamais coder fatigué !

  4. #104
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Le meilleur conseil que j'ai reçu ?
    Premature optimization is the root of all evil.

    Pendant plusieurs années j'ai ridiculement cherché (et de façon contre-productive bien sûr) à écrire du code performant. Un jour j'ai compris que tout ça n'avait aucun importance, qu'il fallait seulement chercher à écrire un "bon" code (lisible, élégant, maintenable, concis, etc), que l'optimisation viendrait à la fin en s'appuyant sur des mesures.

    Et mes programmes ne sont pas moins rapides : soit ils le sont dans des proportions indécelables, soit ils sont plus rapides parce qu'un code propre est plus facile à modifier une fois arrivé au stade final où l'on a les métriques sur lesquelles appuyer son optimisation.

  5. #105
    Membre éclairé Avatar de Ceddoc
    Homme Profil pro
    Développeur Java
    Inscrit en
    Janvier 2009
    Messages
    493
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : Janvier 2009
    Messages : 493
    Points : 698
    Points
    698
    Par défaut
    Citation Envoyé par Loceka Voir le message
    Sinon, un conseil qui ne revient pas assez souvent : ne jamais coder fatigué !
    C'est en parfaite contradiction avec ce qu'explique Swizec Teller

    D'après lui :
    La deuxième raison évoquée est beaucoup plus originale. Pour Swizec, « être fatigués nous fait mieux coder ».

    Contrairement aux idées reçues, la journée et un cerveau en pleine possession de ses moyens n’aideraient pas à faire un travail soigné. Ils amèneraient plutôt au multitâche et à la dissipation.

    Etre fatigué serait donc beaucoup plus productif « parce que quand votre cerveau est fatigué il doit se concentrer ! Il n’a pas assez d’énergie pour se permettre de perdre la moindre miette de concentration […] Avec un esprit un peu vanné je peux coder pendant des heures et des heures sans même penser à vérifier mon Twitter ou mon Facebook ». Un phénomène paradoxale que l’on retrouverait, d’après lui et de manière peu scientifique, dans le fait de programmer dans un état de légère ébriété.
    J'avoue que je ne sais pas si je suis d'accord, j'ai tendance, au contraire, à être encore plus facilement distrait quand je suis crevé.

  6. #106
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2010
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 7
    Points : 22
    Points
    22
    Par défaut
    Personnellement, une période de fatigue me fait produire plus de bugs que d'habitude. La fatigue du cerveau, ça empêche quand même d'être parfois lucide.

  7. #107
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    Novembre 2011
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Novembre 2011
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Le plus censé est celui de Wagner: il faut d'abord programmer et tester la fonctionnalité avant de faire les détails.

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

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Je dirais "savoir écrire du code, ce qui s’acquiert au moins par de l'expérience et en utilisant un Coding Style [même personnel]"

    Ceci permet de ne pas réfléchir sur "est-ce qu'il faut écrire un commentaire ou pas?", "est-ce que mon code est lisible ou pas?", "est-ce que mon code est maintenable ou pas?"
    Parce qu'un programmeur qui passera derrière toi devra comprendre ton code et aura toujours des questions à poser [ou alors tu as codé comme un dieu ]

    Le conseil "écrire le moins de code possible" est possible, mais cela passe par du refactoring.
    Et comme on dit: "Le plus difficile c'est de faire simple"

    Et enfin, le conseil "Bien réfléchir avant de coder", je dirais que cela dépend de ton application, et à quel moment tu interviens.
    Parce que des fois, il ne faut pas 100 ans pour mettre sur pied un algo et faire son intégration.
    Par contre ce qui demande le plus de réflexion et des tests, c'est la logique générale - la colonne vertébrale de l’application.
    Par exemple, l'enchainement des écrans, l'appel des fonctionnalités, l'architecture client-serveur, etc...

    Ensuite, c'est comme "une boule de neige qui dévale une piste": ton logiciel grossit au fur et à mesure.
    Chaqu'à ce qu'une fonctionnalité demande plus d'intégration ou voire pire nécessite un refactoring

    D'ailleurs le conseil de Bill Wagner je le comprends comme cela: "même si ton application n'est pas complète, il faut quand même que toutes les fonctionnalités présentes soient fonctionnelles, c'est à dire, bien intégrées, ne plantent pas et fassent ce qu'elles sont censées faire"

  9. #109
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Avril 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2014
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Ne pas coder en étant fatigué ^^, il arrive que je pense à quelque chose, et j'écris autre chose !

  10. #110
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    24
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 24
    Points : 39
    Points
    39
    Par défaut
    - être humble et curieux
    apprendre, apprendre, apprendre, de nouveaux outils qui permettent d'être plus efficace, des domaines de l'informatique même repoussant (regex, encodage de caractères, etc..) car on passe toujours par eux, apprendre auprès de ses collègues. Cela veut dire aussi se remettre en question

    Par exemple, être humble c'est savoir que même si tu es content d'un code que tu fais aujourd'hui, tu sais que quand tu le reverras dans 2 ans, tu y trouveras des failles nombreuses et des défauts

    - ne pas procrastiner et se lancer vite dans une 1ère itération. Le perfectionnisme peut être une plaie, car on cherche à trouver la solution parfaite, en voulant éviter tous les pièges. Faire les choses au plus simple, façon "it's just work" ou version maquette, permet de mieux se rendre compte de la difficulté du chantier.

    - désacraliser le code de son application
    refondre des pans entier d'un applicatif est possible, si l'on a les bons outils pour ça, en particulier des tests de non régression. Il faut avoir l'intrépiditié de le faire (et les entreprises devraient récompenser ça plutôt que récompenser le statut quo). Comme une maison, un code vieillit et il faut parfois se retrousser les manches.

    - améliorer son style de codage au niveau le plus bas. J'aime à ce titre le spartan programming. Le but est d'écrire le moins possible, tout en restant lisible. http://blog.codinghorror.com/spartan-programming/.

    - penser son code comme une API. Pour les fonctions de plus haut niveau, imaginer comment un autre développeur va utiliser MA fonction. Dès lors qu'on réfléchit à ça, on ne peut plus se permettre de trouver une signature avec 14 paramètres. Il suffit dans le commentaire de mettre 2-3 exemples d'utilisation pour voir la praticité ou non de la signature

  11. #111
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par pomauguet Voir le message
    Faire les choses au plus simple, façon "it's just work" ou version maquette, permet de mieux se rendre compte de la difficulté du chantier.
    L'expression correcte est "it just works".

    Désolé si j'ai l'air de pinailler mais je suis intervenu parce que le sens est totalement différent ("ce n'est que du travail" contre "ça fonctionne, un point c'est tout").


    penser son code comme une API. Pour les fonctions de plus haut niveau, imaginer comment un autre développeur va utiliser MA fonction. Dès lors qu'on réfléchit à ça, on ne peut plus se permettre de trouver une signature avec 14 paramètres. Il suffit dans le commentaire de mettre 2-3 exemples d'utilisation pour voir la praticité ou non de la signature
    J'ai envie de dire que si tu as besoin de mettre des commentaires c'est sans doute que la fonction n'est pas encore assez simple.

  12. #112
    Membre expert

    Développeur NTIC
    Inscrit en
    Janvier 2011
    Messages
    1 670
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Janvier 2011
    Messages : 1 670
    Points : 3 942
    Points
    3 942
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    J'ai envie de dire que si tu as besoin de mettre des commentaires c'est sans doute que la fonction n'est pas encore assez simple.
    Va dire ça aux deux guignols qui ont évalué mon projet de BTS (synthèse et reconnaissance vocale en Java), ils m'ont dit clairement que si je ne mettais aucun commentaire ils ne m'embaucheraient jamais (alors que toutes les fonctions étaient clairement nommées et le code bien plus que lisible). Bon, ils m'ont aussi emmerdé sur mon analyse alors que je l'avais faite avec l'aide de deux de mes profs
    L'homme est un fou pour l'homme. Toi qui viens de me mettre un aie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.

  13. #113
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    24
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 24
    Points : 39
    Points
    39
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    L'expression correcte est "it just works".
    J'ai envie de dire que si tu as besoin de mettre des commentaires c'est sans doute que la fonction n'est pas encore assez simple.
    Bien vu! Merci d'avoir corrigé, car le sens était différent.

    C'est un peu radical de ne pas mettre de commentaire , mais je plussoie sur l'idée derrière ta règle.
    Si une fonction est suffisamment bien conçue (dans son nom, ses paramètres entrants, ses exceptions, et son retour), en théorie le commentaire n'est plus autant indispensable.
    C'est d'ailleurs la nouvelle mode en Ruby et Javascript (par exemple Underscore ou JQuery) de faire des méthodes, dont l'utilisation peut se lire presque comme une phrase en français.

    Ce que je trouve peu intéressant en fait à l'usage, c'est de faire une conception UML sur un outil. Pour ma part, il me suffit d'un crayon et d'un papier pour faire une première esquisse. Puis je code (en commençant par les fonctions de plus haut niveau, qui me permet de me concentrer sur le Quoi plutôt que sur le Comment), et j'itère jusqu'à ce que ça me convienne.
    Quand j'ai dû utiliser un outil comme Rose, je suis toujours tombé sur des modèles qui n'étaient pas à jour. Modifier une conception devient une tâche lourde de gestion de projet. La conception ne devrait être que le reflet du code, d'où mes doutes sur ce genre d'outil.

  14. #114
    Membre éprouvé

    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 448
    Points : 1 234
    Points
    1 234
    Par défaut
    Avoir l'envie de bien faire les choses.
    Étendre au maximum le champ d'application de chaque fonctionalité/comportement.
    Manger 5 fruits et légumes par jour.
    Most Valued Pas mvp

  15. #115
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par pomauguet Voir le message
    C'est un peu radical de ne pas mettre de commentaire , mais je plussoie sur l'idée derrière ta règle.
    En fait tu as de plus en plus de gens qui soutiennent cette idée.

    Les arguments principaux en faveur de l'abandon en général des commentaires (sauf exception) sont :
    a) 95% des commentaires systématiques (JavaDoc/XmlDoc) sont inutiles (ClientAccount clientAccount : the client's account).

    b) 95% des commentaires sont avantageusement remplacés par de bons choix de noms et une fine granularité (méthodes courtes ne faisant qu'une seule chose - celle indiquée par le nom - et classes à responsabilité unique).

    c) Les IDE modernes avec leurs outils de navigation dans le code (surtout pour typage statique) ont contribué à rendre obsolètes un nombre toujours croissant de commentaires.

    d) Les longs commentaires (notamment JavaDoc et XmlDoc) nuisent à la lisibilité du code.

    e) Comme tout artefact de documentation, les commentaires tendent à devenir obsolètes et source de désinformation.

    f) A budget équivalent d'autres dépenses sont plus judicieuses : programmation par paire, revues de code, effort sur les tests, ou autres artefacts de documentation (diagrammes par exemple).

    g) Métriques à l'appui, les commentaires sont rarement lus, surtout si le code est bien écrit.


    En pratique, sur une équipe de taille raisonnable, je n'ai vu que des avantages après l'abandon des commentaires.


    Ce que je trouve peu intéressant en fait à l'usage, c'est de faire une conception UML sur un outil. Pour ma part, il me suffit d'un crayon et d'un papier pour faire une première esquisse. Puis je code (en commençant par les fonctions de plus haut niveau, qui me permet de me concentrer sur le Quoi plutôt que sur le Comment), et j'itère jusqu'à ce que ça me convienne.
    Quand j'ai dû utiliser un outil comme Rose, je suis toujours tombé sur des modèles qui n'étaient pas à jour. Modifier une conception devient une tâche lourde de gestion de projet. La conception ne devrait être que le reflet du code, d'où mes doutes sur ce genre d'outil.
    Ah ! UML ! Une très bonne idée au départ sauf qu'on a voulu en faire tout et n'importe quoi, en particulier un support pour les documents contractuels, un outil de validation et un générateur de code. Et l'agnosticisme codifié dans le marbre atteint vite ses limites. Au final c'est un mauvais outil pour la conception, les éditeurs sont beaucoup trop lourdingues, moches (ça compte pour la créativité) et rigides, et cette norme n'est même pas un bon outil de communication. Bref, un méfait de plus de la bureaucratie.

    Par ailleurs les problèmes les plus complexes à mon avis relèvent de toute façon davantage de la bonne façon de traiter de l'information, de la faire circuler et d'en disposer au bon moment. Alors que le choix d'un bon découpage des classes est plutôt simple avec de l'expérience, et même le plus souvent automatique. Donc aucun diagramme de classe ne m'aidera, ce n'est qu'un outil de communication à mes yeux. En termes d'aide à la conception je ne vois que les diagrammes libres pour illustrer des exemples, des cas particuliers ou des algorithmes, voire un diagramme de séquence dans les cas parallèles/asynchrones (mais j'évite de suivre fidèlement les conventions UML en la matière, trop lourdingues).

    Du coup j'utilise Visio ou draw.io pour les diagrammes libres et les diagrammes de séquence. De toute façon la synchronisation avec le code est toujours médiocre pour les diagrammes de séquence et je n'ai trouvé aucun bon éditeur. Concernant les diagrammes de classe je tape directement l'esquisse du code et je laisse VS générer automatiquement les diagrammes plutôt que de chercher à travailler en UML.

    Quoiqu'il en, soit, le jour où un bon éditeur apparaîtra, je sais qu'il aura un rapport flexible avec UML et ne cherchera pas à faire le café et le repassage en même temps.

  16. #116
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Citation Envoyé par DonQuiche Voir le message
    En pratique, sur une équipe de taille raisonnable, je n'ai vu que des avantages après l'abandon des commentaires.
    Face à cet argument, je serais comme mon collègue

    Citation Envoyé par pomauguet Voir le message
    C'est un peu radical de ne pas mettre de commentaire , mais je plussoie sur l'idée derrière ta règle.
    Comme tu l'as dit, 95% des commentaires sont inutiles. Et de ceux-là, on s'en passe aisément.

    Mais il reste les 5%. Et ceux-là ont toutes leurs importances, bien supérieure souvent à n'importe quelle règle de bonne écriture de code.

    Qui n'a jamais eu affaire à un algorithme subtil à coder ou quelques lignes de commentaire en début de fonction, indiquant les particularités, épargnent des heures de réflexion et d'épluchage de doc pour savoir comment ça marche ...
    Qui ne sait jamais retrouver devant une fonction censée traiter tout un tableau mais ne commençant qu'à l'index 1 et non pas 0 ...

    Il ne faut pas bannir les commentaires, juste les inutiles.


    Et encore, moi, perso, j'en met, de particulièrement inutiles.
    J'aime bien, juste avant la signature de chaque méthode, mettre une ligne de * ou de # sur toute la largeur de ma page, pour bien découper mon fichier source et identifier immédiatement le début de chaque méthode. Utile lorsqu'on doit passer en revue du code source sur des IDE qui ne savant pas trop gérer la coloration syntaxique.
    Il m'arrive aussi de faire de même dans les grosses fonctions (je maintiens, contre les "bonnes pensées" actuelles qu'il n'est pas forcément toujours pertinent de découper des longues fonctions en sous-fonctions), notamment dans des fonctions de traitement séquentiel par exemple, de mettre une petite ligne de commentaire (*, #, ., -, ou autre) pour bien identifier et séparer chaque étape.
    (Sachant que personnellement, j'ai une horreur viscérale de l'accumulation de lignes vides dans le but de séparer du code)
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  17. #117
    En attente de confirmation mail

    Profil pro
    Inscrit en
    Septembre 2013
    Messages
    639
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2013
    Messages : 639
    Points : 2 347
    Points
    2 347
    Par défaut
    Citation Envoyé par Mr_Exal Voir le message
    Va dire ça aux deux guignols qui ont évalué mon projet de BTS (synthèse et reconnaissance vocale en Java), ils m'ont dit clairement que si je ne mettais aucun commentaire ils ne m'embaucheraient jamais (alors que toutes les fonctions étaient clairement nommées et le code bien plus que lisible).
    Un peu d'humilité ne te ferait pas de mal. Tu ne peux pas évaluer objectivement la lisibilité du code que tu produis. Et si tu penses que tu peux faire lisible sans aucun commentaire, c'est que tu te sur-estimes complètement. Mais ce débat a déjà été fait et refait maintes fois.

    Tu te permets de traiter de "guignols" des personnes qui connaissent mieux que toi leur métier.

  18. #118
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Mais il reste les 5%. Et ceux-là ont toutes leurs importances, bien supérieure souvent à n'importe quelle règle de bonne écriture de code.
    Nous sommes d'accord : quand j'ai parlé d'abandon des commentaires je ne voulais pas dire leur éradication totale, seulement l'arrêt des commentaires systématiques (JavaDoc/XmlDoc) et la recherche en priorité d'alternatives par le renommage ou le redécoupage.

    Nous ne sommes pas commenticides !


    Quant aux séparateurs que tu affectionnes, c'est une affaire de préférence, comme les espaces. A chaque équipe son choix en la matière.

  19. #119
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    Décembre 2007
    Messages
    206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 206
    Points : 849
    Points
    849
    Par défaut
    S'agissant des commentaires j'applique le principe suivant : "Si tu peux le dire en code, dis le en code et utilise les commentaire pour le reste". Le reste c'est, par exemple, les en-tête de fichier (description, contexte, auteur, date de dernière modification, ...), selon les langages, les pré-condition, post-condition et invariant des méthodes, fonction ou procédure, des références bibliographiques ou des explications à propos d'un algorithme, du JavaDoc/XmlDoc pour la partie documentée d'une API, etc.

    Pour les conseils, je pense que la refactorisation est très importante mais pour la pratiquer réellement il faut avant tout de bons tests unitaires et d'intégration. Faire de la refactorisation efficace nécessite de pouvoir autant que possible se libérer l'esprit de la peur de casser le code existant, sans tests cette peur est plus que légitime. Avec de bon tests en revanches, on sait que si après une modification les tests passent, sans pour autant avoir de certitude, on a un niveau de confiance raisonnable que l'on a rien cassé et s'il s'avère par la suite que c'était le cas, on pourra alors corriger le test fautif et/ou ajouter un ou plusieurs tests pour traiter spécifiquement le problème.

  20. #120
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Citation Envoyé par ptah35 Voir le message
    Le reste c'est, par exemple, les en-tête de fichier (description, contexte, auteur, date de dernière modification, ...),
    Le genre de commentaire que, personnellement, je considère justement parfaitement inutile (et je sais de quoi je parle, j'en ai gérer pendant plusieurs années pour un client). La notion d'auteur peut être très vague lorsqu'on est dans une équipe de plusieurs développeurs, voire dans une boite comportant plusieurs équipes de plusieurs développeurs. Et si en plus en considère le turn-over de la boite .... Sauf à y renseigner l'annuaire, ça sert pas à grand chose.
    Les notions de modifications, dernière modification, etc, sont souvent rarement à jour au delà de la 4 ou 5ème version du fichier, surtout lorsque les entêtes en question concerne à la fois le fichier lui-même mais aussi chaque méthode dans le fichier.

    De plus, dans une structure organisée, qui possède un gestionnaire de source type svn ou github, ce genre de commentaire est rendu obsolète par le gestionnaire de source, bien plus efficace à ce niveau là.

    Mais après, effectivement, chacun voit son propre intérêt dans sa façon de faire.

    Pour le cas que j'ai eu à gérer durant plusieurs années, sur ce point là et sur la doc qui allait avec, il n'était pas rare qu'il me faille 1/2h pour faire une modif, et ensuite 3 jours pour gérer toutes ces notions de versions, tant dans les sources que sur la doc qu'il fallait modifier entièrement. Sans compter les tests, qui, au delà du test fonctionnel de la modif, consistaient à redérouler l'entièreté des tests pour la non régression, une inspection de code, un file-compare, une relecture complète de la doc, ...
    Bref rien de très productif.
    Alors qu'avec un gestionnaire de source, il suffit de produire un rapport d'évolution entre les 2 releases, ça prend 30sec !
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

Discussions similaires

  1. Quel est le meilleur langage pour la programmation parallèle en 2015 ?
    Par dourouc05 dans le forum Programmation parallèle, calcul scientifique et de haute performance (HPC)
    Réponses: 7
    Dernier message: 15/05/2015, 13h34
  2. Quel est le meilleur conseil que vous ayez reçu dans la conception de sites Web ?
    Par rodolphebrd dans le forum Général Conception Web
    Réponses: 48
    Dernier message: 26/03/2014, 20h57
  3. Quel est le meilleur langage pour la programmation parallèle ?
    Par dourouc05 dans le forum Programmation parallèle, calcul scientifique et de haute performance (HPC)
    Réponses: 70
    Dernier message: 12/04/2012, 22h49
  4. Quel est le meilleur choix de programmation ?
    Par moithibault dans le forum Général Python
    Réponses: 9
    Dernier message: 04/12/2010, 12h30
  5. Réponses: 2
    Dernier message: 15/07/2007, 22h03

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