+ Répondre à la discussion Actualité déjà publiée
Page 7 sur 8 PremièrePremière ... 345678 DernièreDernière
  1. #121
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 539
    Points : 541
    Points
    541

    Par défaut

    En fait, je crois que je ne vais retenir que ce paragraphe là qui résume tout l'échange précédent

    Citation Envoyé par Matthieu Vergne Voir le message
    Mais ce que tu lis est que "le second est fondamentalement mieux que le premier", alors que ce n'est pas ce que je dis. Un exemple de mauvaise interprétation :
    en fait, il n'y a pas d'argumentaire…*Ce gros pavé ne sert qu'à délayer des phrases qui peuvent être prises dans un sens ou dans un autre, et tu le résume ici très bien puisque tu écris quelque chose que "je" lis (mais tu l'a bien lu ainsi) mais qui n'est pas ce que tu écris…*J'admet que l'art du sophisme est finalement assez bien maîtrisé à défaut du reste.

  2. #122
    Nouveau membre du Club
    Profil pro
    Inscrit en
    mai 2003
    Messages
    46
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : Hong-Kong

    Informations forums :
    Inscription : mai 2003
    Messages : 46
    Points : 37
    Points
    37

    Par défaut

    Ouvre un peu ton esprit et essaye de deviner. Je suis sur que tu peux deviner. Sinon tant pis, mon post n'était pas pour toi.

  3. #123
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 539
    Points : 541
    Points
    541

    Par défaut

    Citation Envoyé par miaous Voir le message
    Si je commente un getter et un setter sur un même attribut , il va avoir une répétition du commentaire. Trouvez cela normal , ou ne devrait-il pas avoir un mécanisme pour crée la doc de manière intelligente.
    Je ne crois pas voir un cas pratique où des getters et setters ont les mêmes complexités nécessitant un commentaire. Par contre, documenter des getters et setters a toujours été un sujet comique dans le monde Java qui ne traduit que l'aspect comique de leur existence et qu'il serait temps que les devs Java se forment à la POO…

    2° point, où mettriez vous ,le commentaire d'un classe comme ArrayList

    est-ce vous le mettez en debut de classe pour explique comment elle fonctionne d'une maniéré detaillé, et pas/ou peu de commentaire dans chaqu'une des methodes.
    ou vous mettez un petit commentaire sur la classe , et un commentaire détaillé ( avec de la redite ) sur l'ensemble des méthodes.
    À nouveau, un commentaire uniquement là où la raison de l'écriture du code de cette manière nécessite d'être expliqué, mais je ne vois pas trop ce qui ne pourrait pas être explicite par le nommage…

    si methode m1() de la classe A< B> fait une délégation sur la methode m1() de l'attribut b de type B
    la documentation/commentaire de A.m1 va faire reference à la documentation de B.m1

    Imaginons que la classe B1 étends la classe B ( et redéfinie la méthode m1 ), et A1 étends la classe A avec la contrainte suivante que l'attribut de b est du type B1 (au lieu de B).

    on pourrait avoir envie de redéfinir le commentaire de A1.m1 sans redéfinir cette méthodes.
    Tu parle de documentation ou commentaire ? Pour le commentaire, à nouveau, voir l'implémentation et quelle est la difficulté de compréhension du code. Pour la documentation, l'utilisateur de A; B; b, A.m1 ou A1.m1 ou whatever doit pouvoir être informé sur ce qu'il utilise. Tu fait donc en fonction des outils de génération de docs.

    On peut avoir le même problème avec l’héritage.
    Imaginons que l'on étends une classe HashSet (Java) pour ajouter un contrôle sur le add pour lever un exception si on tente ajouter un valeur non valable.
    On met un commentaire sur la méthode pour dire qu'elle peut lancer un exception.

    Doit-on ( ou est t-il normal ) de redéfinir la méthode addAll pour modifier la documentation et dire qu'elle peut lever une exception.
    En Java en particulier où une méthode déclare les exceptions levées, je ne vois pas pourquoi ajouter un commentaire, surtout lorsque cette levée d'exception sera documentée dans la documentation. Quand à redéfinir addAll, si le addAll parent ne lève pas d'exception mais le spécialisé oui, je pense que tu a ta réponse…

  4. #124
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 539
    Points : 541
    Points
    541

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Dans ma courte expérience et dans les témoignages que j'ai lus et entendus, en dehors des systèmes embarqués critiques :
    • Le client ne connaît pas toujours son propre besoin. Il peut y avoir plusieurs raisons :
      • Le client découvre son vrai besoin au moment où il utilise le logiciel. Par exemple, une fois, il y a un client qui a demandé d'implémenter un nouvel indicateur statistique, mais il avait besoin de voir les résultats pour juger si cet indicateur était vraiment pertinent.
      • L'interlocuteur côté client n'est pas l'utilisateur direct du logiciel. Il ne fait que rapporter ce qu'il a compris du besoin.
      • Le besoin lui-même est volatile. En cours de développement, le besoin change.
    Pour être plus exacte, il faudrait en fait faire la différence entre demande et besoin. Souvent, le besoin ne change pas tant que ça, c'est juste la demande qui est reformulée. Tu l'illustre avec le cas de ton client stats.

    Mais il faut bien comprendre la plupart des autres cas :
    - le client n'est pas toujours compétent en "l'IT", on a le monde idéal de la MOA, du cahier des charges, mais lorsque le client n'a aucune compétence dans le domaine
    - l'interlocuteur n'est pas l'utilisateur mais l'utilisateur n'a pour sa part rien demandé. Dans ce cas, généralement, l'utilisateur découvre l'intérêt de la demande d'évolution et une fois le produit avancé et alors remet en cause tout le modèle…
    - et le cas moins sympa du précédent, c'est lorsque le demandeur agrège plusieurs utilisateurs qui eux n'ont rien demandé et n'aideront pas (régulier pour les ministères)

    • Les délais sont serrés.
    • La hiérarchie met beaucoup de pression sur le court terme. La plupart des développeurs cèdent à la pression et travaillent comme des gros bourrins.
    La "hiérarchie" (ça veut dire quoi) et plus généralement le management met la pression sur des délais. Mais ce que le développeur devrait comprendre, c'est que ces délais sont souvent définis pour problématiques business. Tant que le produit n'est pas en production, le projet est un centre de cout et c'est tout. Un exeple extrême (pas tant que ça) : oui le service doit être livré mercredi soir pour derniers tests jeudi. Si il n'est pas fonctionnel pour vendredi, soit pour le Black Friday, on perd 25 % de nos revenus annuels, dit autrement, nous ne pourrons pas payer 25 % de nos salariés…

    Dans certains cas, il arrive qu'on écrive du code pas beaucoup moins clair que de la documentation pour développeur. Dans ces cas-ci, ce que je propose, c'est de ne pas répéter dans la doc pour développeur ce que l'on voit déjà dans le code.
    Il faut quand même finir par comprendre de quoi on parle quand on parle "documentation"…*Ici, le sujet est le commentaire, ce que tu propose ne fait que paraphraser le post initial et finalement les pratiques déjà largement définies. Les commentaires sont destinés à ceux qui maintiennent ou font évoluer le code, donc ils verront bien les deux.

    La "documentation", c'est ce que tu cite je pense au paragraphe suivant et qui est destinée à ceux qui utilisent ton code sous forme de "bibliothèques". Ceux-là n'ont pas à aller voir le code, une "doc" complète est donc indispensable.

    Mais "complète" ne signifie pas kilométrique. La bonne pratique propose que la doc soit succincte car plus elle est longue, moins elle est facile à maintenir et faire évoluer (essaye de reformuler une doc pour ajouter une levée d'exception par exemple). Le développeur n'est pas un littéraire…

    Une fois que le code est fini, si le code est suffisamment clair pour qu'on y voit directement l'algorithme, on peut mettre le document dans la corbeille.
    Why ? La plupart des langages ont des outils de génération de docs et cette doc ne se limite pas à la doc du code. Cette description d'algo a toute sa place là…

    Citation Envoyé par dranduncandane Voir le message
    Les commentaires ne doivent pas commenter le code mais le business. Il faut commenter des (mauvais) choix business. On a tous eu a faire du code dégueulasse parce que le business nous force a faire ainsi pour n'importe quel raison valable ou pas.
    J'aime bien le dev de base qui juge la pertinence du business…

    Sauf que le commentaire n'est destiné qu'aux devs qui interviennent sur le code, donc n'expliquent que pourquoi le code a été écrit de cette manière. Donc rien à voir avec le choix business (qui apparait dans les fonctions/classes/libs)

    Les commentaires sont aussi là pour commenter une situation passagère.
    On sait très bien que toute situation passagère est là pour toujours…

  5. #125
    Membre chevronné
    Avatar de CodeurPlusPlus
    Profil pro
    Inscrit en
    septembre 2013
    Messages
    632
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 632
    Points : 2 232
    Points
    2 232

    Par défaut

    Tu critiqueras le "dev de base" (on dit "pisseur de code", non, pour faire encore plus méprisant ?) quand tu auras son niveau.

  6. #126
    Nouveau membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    novembre 2014
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : novembre 2014
    Messages : 22
    Points : 29
    Points
    29

    Par défaut

    Citation Envoyé par dranduncandane Voir le message
    J'en reviens pas que cela fasse débat. Les commentaires ne doivent pas commenter le code mais le business. Il faut commenter des (mauvais) choix business. On a tous eu a faire du code dégueulasse parce que le business nous force a faire ainsi pour n'importe quel raison valable ou pas. Les commentaires sont aussi là pour commenter une situation passagère.

    Parle pour toi, personnellement pour moi la principale cause de code dégueulasse c'est les noobs qui sortent des écoles d'ingés sans jamais avoir codé un vrai projet. A pars faire des stages ou ils codent "from scratch" des applis ou alors en maintenant des applis cacas, et ou tu n'apprends rien parce qu'une fois chez toi t'as autre chose à faire. C'est normal pour le "business" de vouloir aller vite, et eux ils en ont rien à faire du code. Le code, c'est juste toi et ta conscience. ET puis c'est tellement facile de bullshiter que personne ne s'en rend compte.

    My 2 cents lol

    ps: Et parfois t'es quand même obligé d'écrire du code tout sale parce que les mec qui code l'API X don't tu à besoin on fait n'importe quoi et par conséquent ton code est pas propre. (ex: une api qui ne renvoie jamais le même modèle, qui mélange camel case et uppercase, majuscules et minuscules...), etc

    ps2: Je ne voulez pas t'agresser, désolé ^^

  7. #127
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 539
    Points : 541
    Points
    541

    Par défaut

    Citation Envoyé par CodeurPlusPlus Voir le message
    Tu critiqueras le "dev de base" (on dit "pisseur de code", non, pour faire encore plus méprisant ?) quand tu auras son niveau.
    "Pisseur de code", c'est une évaluation technique. Lorsqu'un "dev" (quel que soit le niveau technique) juge le business, voir même qui les considère de "golios", c'est juste un dev qui n'a rien compris au rôle de l'IT et à ce qu'il a à faire.

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

    Par défaut

    Citation Envoyé par martopioche Voir le message
    La "hiérarchie" (ça veut dire quoi) et plus généralement le management met la pression sur des délais. Mais ce que le développeur devrait comprendre, c'est que ces délais sont souvent définis pour problématiques business. Tant que le produit n'est pas en production, le projet est un centre de cout et c'est tout. Un exeple extrême (pas tant que ça) : oui le service doit être livré mercredi soir pour derniers tests jeudi. Si il n'est pas fonctionnel pour vendredi, soit pour le Black Friday, on perd 25 % de nos revenus annuels, dit autrement, nous ne pourrons pas payer 25 % de nos salariés…
    Dans certains cas, oui, il est pertinent de privilégier la productivité à court terme.

    Mais, quand une entreprise a une équipe de développement qui est toujours en sous-effectif, quand ce manque d'effectifs impose aux développeurs d'augmenter à fond la dette technique pour respecter les délais court-terme et quand il y a pourtant assez de trésorerie pour embaucher de nouveaux développeurs, c'est qu'il y a un problème quelque part.
    Or, quand on fait tout le temps du court-terme au détriment du long terme, ce seront les délais futurs qui ne seront pas respectés, y compris ceux qui auront la même importance que le Black Friday de ton exemple.

  9. #129
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 839
    Points : 5 805
    Points
    5 805
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Le client ne connaît pas toujours son propre besoin
    En début de projet, oui c'est normal, mais si à la fin du projet il ne les connaît toujours pas, y'a un soucis. D'ici là tu as la transition. Maintenant relis ce que j'ai écris et que tu as cité, et tu verras que ça inclus ce point. Ça commence par "Bottom-up n'est à faire".

    Les bonnes pratiques, dès lors qu'on s'accorde qu'elles sont bonnes, soit on peut les appliquer tout de suite et on le fait, soit on ne peut pas le faire tout de suite et on tente d'y converger. Dire que c'est mort sous prétexte qu'au début ça peut ne pas se faire, c'est pas être réaliste, c'est admettre que ça ne nous préoccupe pas plus que ça.

    Citation Envoyé par Pyramidev Voir le message
    Les délais sont serrés.
    Ah, les délais... si ton évaluation des délais n'inclus pas le temps de faire un code propre, tu ne peux t'en prendre qu'à toi. Si c'est l'évaluation d'un autre, fait-lui comprendre que le dév, ce n'est pas aussi trivial qu'il le pense. Si tu n'as aucun impact sur cette évaluation, ben change de boîte ou admet que tu es dans un contexte où parler de bonne pratique n'a de toute façon aucun intérêt, car tu suis les ordre et que les ordres ont dit non. On va encore me sortir l'argument du "faut nourrir sa famille", donc je prend un coup d'avance : je connais des gens qui ont préféré changer d'environnement plutôt que de suivre le mouvement. Bien sûr que c'est plus difficile, mais ça se fait, c'est une question de volonté. Moi je suis comme ça, d'où l'argumentaire en conséquence.

    Citation Envoyé par Pyramidev Voir le message
    La hiérarchie met beaucoup de pression sur le court terme. La plupart des développeurs cèdent à la pression et travaillent comme des gros bourrins.
    Excuse, pas argument. Il y a aussi ceux qui ne cèdent pas et ceux dont la hiérarchie est plus ouverte. La liberté d'expression, il y a des situations où il n'y en a pas (e.g. militaires, Corée du Nord), mais on ne va pas pour autant en tirer la conclusion que c'est juste de la belle théorie sans existence pratique derrière. C'est bien de parler de la réalité du terrain, mais il ne faut pas prendre les habitudes pour des lois naturelles. Les habitudes ça se change, on ne peut pas dire qu'une pratique discutée n'est pas bonne parce que des pratiques actuelles ne l'autorisent pas. Tout l'intérêt de ce genre de débats est de remettre les pratiques actuelles en question. Je suis d'accord qu'il ne faut pas être idéaliste, mais il ne faut pas non plus abandonner l'idée sous prétexte que "on fait pas comme ça".

    Citation Envoyé par Pyramidev Voir le message
    Comme le besoin change souvent, plus on écrit tôt de la documentation, plus la quantité de choses à y réécrire sera grande.
    C'est vrai, mais le problème est ailleurs. Si le besoin change souvent, c'est qu'il n'est pas clairement identifié. Faire beaucoup de conception alors qu'on n'a pas clairement identifié le besoin, c'est un excès de cycle en V, il faut être plus agile. Si tu me sors à ça que l'entreprise à décidé cycle en V donc il faut... cf. Corée du Nord.

    Citation Envoyé par Pyramidev Voir le message
    Dans certains cas, il arrive qu'on écrive du code pas beaucoup moins clair que de la documentation pour développeur. Dans ces cas-ci, ce que je propose, c'est de ne pas répéter dans la doc pour développeur ce que l'on voit déjà dans le code.
    Pourquoi ? Parce que :
    • Modifier à la fois la documentation et le code est plus lent que de modifier directement le code. Or, dans le monde industriel, il faut aller vite. Donc, si un passage de la documentation n'a pas assez de valeur ajoutée au code pour augmenter la productivité à long terme, ce n'est pas la peine de l'écrire.
    • Même quand on est quelqu'un de consciencieux qui fait attention à la cohérence entre les documentations et le code, il faut anticiper que, quand on ne sera plus là, le code aura plus de chances d'être repris par un gros bourrin développeur normal que par quelqu'un qui tient à l'intégrité des documentations.
    Je conseille d'écrire la doc quand même, mais encore une fois car cette doc dépend des specs, pas du code, donc pas besoin de la changer à chaque fois qu'on change le code. On peut changer le code pour le rendre plus optimisé, auquel cas tu peux perdre en lisibilité. La doc étant déjà là, tu n'as pas à juger à chaque modif "est-ce que mon code est encore assez clair pour ne pas avoir besoin de la doc ?", question mal choisie car au fur et à mesure que tu gagnes en expérience, tu as peu de chances de trouver ton propre code peu clair, à moins d'avoir mis des commentaires un peu partout au fur et à mesure car tu te disais "je ne vais pas faire une doc juste pour expliquer ce petit bout qui est moins clair". Le long terme, ça ne se devine pas, ça se prépare.

    Citation Envoyé par Pyramidev Voir le message
    Concernant la documentation générée par des commentaires du code, l'avantage, c'est que le commentaire est près du code et qu'on peut le modifier via le même éditeur que le code. Donc ça facilite la mise à jour des deux en même temps.
    Encore une fois, à condition de partir de l'hypothèse que la doc dépend du code, ce qui n'est pas mon hypothèse, justement car une doc qui se contente de reprendre le code est, pour moi, un investissement peu rentable.

    Citation Envoyé par Pyramidev Voir le message
    Concernant la démarche de partir du haut niveau pour arriver jusqu'au bas niveau, ben, oui, c'est la bonne manière de raisonner quand on implémente un nouvel algorithme. Mais ça n'a aucun rapport avec le sujet de la documentation. Ce n'est pas parce qu'on a écrit dans un document texte l'algorithme d'une fonction qu'il faut absolument copier-coller cet algorithme dans la doc. On garde ce document de côté, puis on code. Une fois que le code est fini, si le code est suffisamment clair pour qu'on y voit directement l'algorithme, on peut mettre le document dans la corbeille.
    Pourquoi mettre un travail effectué à la corbeille ? Encore une fois, il faut se mettre dans un cadre de bonnes pratiques. A priori, tu utilises des abstractions (e.g. List, Set), et tu vas choisir des implémentations particulières en fonction du contexte (e.g. ArraysList, LinkedList). Ton implémentation particulière vise à implémenter un algorithme particulier, d'où l'intérêt de mettre cet algo dans la doc de l'implémentation. Ton code peut alors se permettre d'évoluer, la doc, elle, reste la référence indiquant le but de la classe/méthode, et donc permet aux futurs arrivants d'en comprendre le but et de la revoir de manière cohérente avec ce but.

    Cette approche qui fait faire le code avant la doc me semble justement être la source du problème : dès lors qu'on se permet de faire le code avant la doc, la doc n'a alors plus aucun intérêt que celui de permettre aux autres d'y voir plus clair dans notre code. Autant dire qu'on n'a strictement aucun intérêt personnel à l'écrire, et de là on la bâcle voire on l'ignore. Tout l'intérêt de s'obliger à faire la doc avant est de s'efforcer de clarifier ce qu'on souhaite faire avant de taper la moindre ligne de code. C'est du même acabit que le TDD : d'abord on comprend ce qu'on doit faire (i.e. on identifie les critères de test), ensuite on l'implémente. Là, d'abord on comprend ce qu'on doit faire (i.e. on établit le cahier des charges de la classe/méthode), et ensuite on l'implémente. Ça force justement à concevoir avant de coder, plutôt que de coder tout de suite.

    On s'en fait une étape nécessaire avant d'écrire la moindre ligne de code. Si on prend la doc comme une préparation au codage, on lui redonne un intérêt perso à la faire, car on se donne les moyens de la faire pour qu'elle nous aide à coder. Ce n'est plus une étape ingrate de post-codage. De la même manière : un projet peut être fait sans cahier des charges, mais il me semble que tout le monde ici est d'accord que c'est une préparation nécessaire à tout projet sérieux. Si on prend la doc comme le cahier des charges dédié de la classe/méthode, il devient évident que :
    - ça doit être écrit avant le code
    - ça ne doit pas changer juste parce que le code change
    - ça doit permettre de comprendre ce que le code est censé faire, même si ça ne décrit pas comment

    Ceux qui auront compris ça devraient tout comprendre de ce que j'ai écris avant.

    Citation Envoyé par miaous Voir le message
    On dit à juste raison qu'il ne faut pas dupliquer du code mais plutôt faire à la place une fonction qui sera appelé autant de fois que nécessaire.

    mais on accepte de devoir dupliquer des commentaires ou de la documentation.
    Y'a pas de raison. Si on a de la doc redondante, c'est qu'on a une responsabilité partagée, et donc qu'un peu de découplage serait le bienvenue.

    Les commentaires, ça vient avec le code. Si on duplique le code, on duplique les commentaires, juger de la duplication de commentaires et équivalent à juger de la duplication de code.

    Citation Envoyé par miaous Voir le message
    Si je commente un getter et un setter sur un même attribut , il va avoir une répétition du commentaire. Trouvez cela normal , ou ne devrait-il pas avoir un mécanisme pour crée la doc de manière intelligente.
    Attention, fait bien la différence entre commenter et documenter. La documentation se trouve juste avant le getter, pour le décrire en tant que boîte noire, alors que ses commentaires se trouvent dans son code.

    Je suis pas contre de l'automatisation quant à la génération de la doc, mais la doc de ce genre de méthode est extrêmement courte. Et il me semble qu'un EDI comme Eclipse est capable de gérer ça (il est capable de proposer la création de getter/setters, doit y avoir moyen d'adapter le modèle utilisé avec de la doc en conséquence).

    Citation Envoyé par miaous Voir le message
    où mettriez vous ,le commentaire d'un classe comme ArrayList
    • est-ce vous le mettez en debut de classe pour explique comment elle fonctionne d'une maniéré detaillé, et pas/ou peu de commentaire dans chaqu'une des methodes.

    • ou vous mettez un petit commentaire sur la classe , et un commentaire détaillé ( avec de la redite ) sur l'ensemble des méthodes.
    Je mettrais une documentation à la classe, pour décrire ses contextes d'utilisation (e.g. List qui varie peu) et objectifs (e.g. implémenter une List avec accès lecture/écriture en O(1)). Je mettrais une documentation à chaque méthode indiquant les spécificités de la classe (e.g. get(i) et set(i, e) avec accès 0(1)). La redondance n'est pas un problème ici, mais un outil, car chaque documentation a son utilité. Pour choisir si oui ou non la classe est pertinente à utiliser, lire la doc de la classe doit suffire. La doc des méthodes doit permettre de comprendre quelles sont les méthodes à utiliser pour implémenter notre procédure.

    Les commentaires, ça dépend du code, mais a priori aucun.

    Citation Envoyé par miaous Voir le message
    si methode m1() de la classe A< B> fait une délégation sur la methode m1() de l'attribut b de type B
    la documentation/commentaire de A.m1 va faire reference à la documentation de B.m1
    En dehors d'un adaptateur, je n'en vois pas l'utilité. Un adaptateur se contente a priori d'adapter une instance pour lui donner une autre interface, donc la doc est déjà donnée dans la définition de l'interface cible. Ton adaptateur ne vise alors qu'à adapter l'instance source, et donc une doc très courte indiquant juste cela est a priori suffisant. Tu as besoin de plus si certaines méthodes cibles nécessitent des traitements supplémentaires plutôt qu'un simple appel à une méthode source.

    Sinon, A et B ont visiblement une responsabilité partagée qu'il vaudrait mieux découpler. Soit au profit de A, soit au profit de B, soit au profit d'une classe dédiée C.

    Citation Envoyé par miaous Voir le message
    On peut avoir le même problème avec l’héritage.
    Imaginons que l'on étends une classe HashSet (Java) pour ajouter un contrôle sur le add pour lever un exception si on tente ajouter un valeur non valable.
    On met un commentaire sur la méthode pour dire qu'elle peut lancer un exception.

    Doit-on ( ou est t-il normal ) de redéfinir la méthode addAll pour modifier la documentation et dire qu'elle peut lever une exception.
    Potentiellement, ta classe perso pourra être utilisée à la place de n'importe quel HashSet, et donc ton implémentation doit respecter le contrat imposé par HashSet. Préfère faire ta propre classe (qui implémente Set) avec sa doc dédiée, quitte à utiliser en interne un HashSet pour te simplifier la vie.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  10. #130
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 539
    Points : 541
    Points
    541

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Dans certains cas, oui, il est pertinent de privilégier la productivité à court terme.
    "privilégier la productivité à court terme"…*C'est moi ou cette phrase n'a aucun sens ?

    Mais, quand une entreprise a une équipe de développement qui est toujours en sous-effectif, quand ce manque d'effectifs impose aux développeurs d'augmenter à fond la dette technique pour respecter les délais court-terme et quand il y a pourtant assez de trésorerie pour embaucher de nouveaux développeurs, c'est qu'il y a un problème quelque part.

    Or, quand on fait tout le temps du court-terme au détriment du long terme, ce seront les délais futurs qui ne seront pas respectés, y compris ceux qui auront la même importance que le Black Friday de ton exemple.
    Ce n'est pas la trésorerie qui détermine si il est possible d'embaucher mais l'activité…

    C'est quoi un "délais court-terme" ? Il y a un délais à respecter dans tout projet, c'est tout.

    Et la question de la dette technique, évidemment, mais il faut accepter que c'est une notion qui ne sort pas du département IT… Sérieux, avez vous déjà quantifié cette "dette technique" autrement qu'en alimentant un backlog ? Si vous l'avez chiffré, l'avez-vous répercuté sur l'évolution ? La dette technique, de manière générale, c'est les heures sup' bénévoles que vont réaliser les copains qui reprendront le code, pas le cout du projet. Car franchement, quel délais futur n'a pas été respecté (oui la concordance des temps est particulière…) ?

    Du coup, il y a un problème si vous ne livrez pas. Si vous livrez, c'est bien qu'il n'y a pas de problème…

  11. #131
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 839
    Points : 5 805
    Points
    5 805
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par martopioche Voir le message
    Du coup, il y a un problème si vous ne livrez pas. Si vous livrez, c'est bien qu'il n'y a pas de problème…
    Les petits chinois livrent, donc pas de problème. Ben oui quoi, les français ont juste cet ego surdimensionné qui leur fait croire qu'ils sont plus qu'une simple ressource. Non mais z'ont rien compris ceux-là !
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

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

    Par défaut

    Citation Envoyé par martopioche Voir le message
    La dette technique, de manière générale, c'est les heures sup' bénévoles que vont réaliser les copains qui reprendront le code, pas le cout du projet. Car franchement, quel délais futur n'a pas été respecté (oui la concordance des temps est particulière…) ?
    Ben, c'est arrivé.
    L'autre conséquence de la dette technique visible en dehors du département IT, c'est un amas bogues qui sommeillent depuis plusieurs années dans le code de l'appli et qui se réveillent du jour au lendemain.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 619
    Points : 19 041
    Points
    19 041

    Par défaut

    Citation Envoyé par Matthieu Vergne Voir le message
    En début de projet, oui c'est normal, mais si à la fin du projet il ne les connaît toujours pas, y'a un soucis. D'ici là tu as la transition. Maintenant relis ce que j'ai écris et que tu as cité, et tu verras que ça inclus ce point. Ça commence par "Bottom-up n'est à faire".(.../...)
    Ben oui, mais en fin de projet, le projet est terminé. A quoi bon demander au client de documenter en détail ce qu'on vient de coder?

    J'ai connu ça, dans un exemple extrême. Le besoin de la direction était "nos avis d'échéance imprimés et envoyés au client sont moches"(vrai). Le besoin des utilisateurs était : "on sait que ça marche et que c'est juste, mais on ne sait pas ce que ça fait - les sachants sont tous à la retraite". Le besoin des équipes techniques était "cette horreur date de 1972(on était en 2008), il faut la rendre maintenable, et la direction nous en donne enfin le prétexte et le budget. Ah, et les autres prestataires à qui on a proposé la mission ont fui en courant"(ils m'ont vraiment dit ça - je ne sais pas jusqu'à quel point c'était vrai).

    A la fin, 172 jours de boulot, plus d'un équivalent temps plein en maintenance définitivement économisé, et seulement deux tous petits documents : le dessin de chaine(une page) et le répertoire des données renvoyées à l'impression(avec dedans le nom du programme ou c'était calculé, on parle de COBOL, hein, l'objet on oublie...). Donc, si quelqu'un veut savoir comment est calculé la taxe d'assurances automobile, il sait que ça s'appelle (P)TAXE-ASSURANCE-AUTO et que c'est calculé dans le programme MA22AUTO. Pas besoin de plus. Si on a besoin de l'information, on la retrouve facilement. Pas besoin de passer deux jours a faire une belle doc qui reprend l'algorithme assez merdique qu'il y a derrière. Il y avait 140 données en sortie, et ça aurait couté bien trop cher de tout documenter. Et de toutes façons, la documentation n'aurait jamais suivi les évolutions, faute de mains. Donc le code fait référence, et quand il y a des modifications, eh bien le nouveau code fait référence. La demande vient évidemment du haut, mais il n'y a pas forcément de valeur ajoutée à documenter tout ce qui vient du haut.
    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.

  14. #134
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 839
    Points : 5 805
    Points
    5 805
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Ben oui, mais en fin de projet, le projet est terminé.
    Arrête de faire ton binaire, j'ai parlé de transition : au début y'a que quelques trucs de clairs, puis de plus en plus, et en fin de projet tout doit être clair. La doc évolue de la même manière, c'est pas comme si toute ta doc devait être faite à la fin. Sauf si tu code avant de documenter, là oui je comprends, mais mon gros post précédent devrait être assez explicite sur ce point.

    Citation Envoyé par el_slapper Voir le message
    A quoi bon demander au client de documenter en détail ce qu'on vient de coder?
    Comme je l'ai dit, y'en a pas vraiment, c'est pour ça que je documente avant de coder, parce que la doc doit servir au codeur avant tout. Relis mon post, ça commence à "Cette approche qui fait faire le code avant la doc". C'est sûr que si tu ne pars pas des même hypothèses, tu n'as aucune raison d'arriver aux même conclusions.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  15. #135
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 539
    Points : 541
    Points
    541

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Ben, c'est arrivé.
    Et ça a remis en cause l'itération précédente ou l'équipe actuelle ?

    L'autre conséquence de la dette technique visible en dehors du département IT, c'est un amas bogues qui sommeillent depuis plusieurs années dans le code de l'appli et qui se réveillent du jour au lendemain.
    C'est pour ça qu'il y a une équipe de maintenance… Mais c'est un autre budget, voir un avenant…

    Citation Envoyé par el_slapper Voir le message
    Ben oui, mais en fin de projet, le projet est terminé. A quoi bon demander au client de documenter en détail ce qu'on vient de coder?
    Je ne sais pas si c'est une erreur, mais ce n'est pas au client de documenter.

    Sinon, on rajoute de manière plus pragmatique que si le projet est terminé, sur quoi va-tu imputer…

    J'ai connu ça, dans un exemple extrême. Le besoin de la direction était "nos avis d'échéance imprimés et envoyés au client sont moches"(vrai). Le besoin des utilisateurs était : "on sait que ça marche et que c'est juste, mais on ne sait pas ce que ça fait - les sachants sont tous à la retraite". Le besoin des équipes techniques était "cette horreur date de 1972(on était en 2008), il faut la rendre maintenable, et la direction nous en donne enfin le prétexte et le budget. Ah, et les autres prestataires à qui on a proposé la mission ont fui en courant"(ils m'ont vraiment dit ça - je ne sais pas jusqu'à quel point c'était vrai).
    Tiens… J'ai connu quelque chose de similaire…*Quand tu est presta dans cette situation, tu sais que le projet a été "sous-vendu", pas forcément de la faute de tes commerciaux. Dans notre cas, c'était du Java + shell (oui, oui…). On aurai pu passer par une phase de rétro-conception, mais quand le client ne paye pas pour ça (ben quoi, ça marche, on ne comprends pas pourquoi vous n'avancez pas sur ce qu'on vous a demandé…) finalement, écrire la javadoc permet de s'y retrouver (je crois que c'est bien plus facile avec un langage comme Java que pour Cobol mais je n'y connais rien en ce dernier). Ce projet m'a démontré que dans certains cas, il vaut mieux demander les specs et repartir de 0…

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

    Par défaut

    Citation Envoyé par martopioche Voir le message
    Et ça a remis en cause l'itération précédente ou l'équipe actuelle ?
    Citation Envoyé par martopioche Voir le message
    C'est pour ça qu'il y a une équipe de maintenance… Mais c'est un autre budget, voir un avenant…
    Je travaille dans une PME, donc les développeurs ont généralement plusieurs casquettes.
    En particulier, les développeurs qui ajoutent des fonctionnalités sont aussi ceux qui corrigent les bogues et ceux qui aident le help desk quand ce dernier ne connaît pas assez le logiciel pour poursuivre une enquête sur un problème soulevé par le client.
    On a donc un ensemble de tâches qui viennent s'intercaler entre les développements et aussi au milieu des développements.

    Par conséquent, en plus de l'imprévisibilité des durées de développements de nouvelles fonctionnalités, il faut ajouter l'imprévisibilité des autres tâches, toutes ces imprévisibilités étant amplifiées par la dette technique.

    Ce que la hiérarchie semble remettre en cause le plus souvent, c'est l'ordonnancement des tâches. Il y a des périodes où l'accent est plutôt mis sur les développements de nouvelles fonctionnalités et d'autres où l'accent est plutôt mis sur les autres tâches.
    En terme de temps de travail, on est toujours en sous-effectifs à la fois pour développer de nouvelles fonctionnalités et pour les autres tâches, mais parfois plus en sous-effectifs d'un côté et d'autres fois plus en sous-effectifs de l'autre.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 619
    Points : 19 041
    Points
    19 041

    Par défaut

    Citation Envoyé par martopioche Voir le message
    (.../...)Tiens… J'ai connu quelque chose de similaire…*Quand tu est presta dans cette situation, tu sais que le projet a été "sous-vendu", pas forcément de la faute de tes commerciaux. Dans notre cas, c'était du Java + shell (oui, oui…). On aurai pu passer par une phase de rétro-conception, mais quand le client ne paye pas pour ça (ben quoi, ça marche, on ne comprends pas pourquoi vous n'avancez pas sur ce qu'on vous a demandé…) finalement, écrire la javadoc permet de s'y retrouver (je crois que c'est bien plus facile avec un langage comme Java que pour Cobol mais je n'y connais rien en ce dernier). Ce projet m'a démontré que dans certains cas, il vaut mieux demander les specs et repartir de 0…
    Ben, c'était pas tout à fait pareil. En fait, j'étais en régie, donc au final, pas de bobo pour ma boite en cas de plantage de ma part. L'équipe technique avait réussi à vendre à la direction que son projet était infaisable sans tout refondre(ce qui était quasiment vrai, en fait). Même si son objectif réel était de finir avec un truc maintenable, et seulement accessoirement de faire de belles impressions comme demandé par la direction. Le vrai souci, c'est qu'en 36 ans, les docs sont perdues(rachat et rerachat), et les sachants sont à la retraite(et sans doute morts de vieillesse pour une bonne partie d'entre eux). Donc, la seule doc, la seule référence qui existe, c'est le code. Sans commentaire, sans noms de variables parlants, rien. Et la position dans la grille d'impression de la donnée, qui elle seule permet de s'y retrouver.

    Les boucles étaient faites ainsi :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    *
         MOVE 1 TO II.
     A121.
         IF JJ(II) > 0 THEN ADD JJ(II) TO ZZ
         ADD 1 TO II
         GO TO A121.
     A120.
    Que j'ai approximativement refondues telles que :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    *Grace à la moulinette précédente, on sait qu'il n'y a rien après la première valeur nulle dans le tableau des valeurs
     CALCUL-CUMUL-MONTANTS.
         MOVE 1 TO POS
         PERFORM UNTIL VALEUR-ASSUREE(POS) = 0
             ADD VALEUR-ASSUREE(POS) TO CUMUL-MONTANTS
         END-PERFORM
         .
    Bon, en plus propre que ça, hein, j'ai un peu perdu la main, ça fait quelques années.

    Fatalement, doc ou pas doc, le code est déjà plus lisible. Le but du commentaire, ici, est de rappeler le contexte du calcul. La position est initialisée parce-que c'est une variable standard utilisée partout(sans doute un truc améliorable, d'ailleurs, j'aurais pu faire un perform varying from 1 by 1 avec une sortie conditionnelle). Le cumul ne l'est pas parce-qu'il est déclaré avec une valeur initiale, et qu'il n'est pas utilisé ailleurs. Ce sont deux trucs standards en COBOL, donc je ne les commente pas. Par contre, ce qui est dans le commentaire sera faux dans la plupart des cas. Ici, c'est vrai, donc le commentaire permet de ne pas se poser de questions : l'optimisation qui sort de la boucle avant la dernière occurrence du tableau est juste. Simplement, quand on fouille dans un vieux code, on a pas forcément tout en tête. Le commentaire, ici, permet de gagner du temps à la lecture, et de ne pas se poser de questions sur une sortie de boucle, euh, inhabituelle.

    L'autre raison de mettre un commentaire, c'est pour justifier un choix fonctionnel. Au cas ou la doc se perde(c'est si fréquent.....)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     B12.
          IF YY = 1 AND MM < 100000000 MOVE 1 TO TT
          IF YY = 1 AND MM >= 100000000 MOVE 4 TO TT.
          IF YY = 2 AND AA = 0 MOVE 2 TO TT
          IF YY = 2 AND AA <> 0 MOVE 3 TO TT.
          IF YY = 3 MOVE 4 TO TT.
     B112.
    remplaçé par
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    *Si le montant dépasse un million, alors on ne peut pas utiliser de TIP. Le préimprimé n'a pas assez de cases. Il faut passer par chèque
     CHOIX-MODE-PAIEMENT-REEL.
         SELECT CASE TRUE
             CASE TYPE-PAIEMENT-DEMANDE-TIP AND MONTANT-A-PAYER < 100000000
                 SET TYPE-PAIEMENT-REEL-TIP TO TRUE
             CASE TYPE-PAIEMENT-DEMANDE-VIREMENT AND TYPE-AGENCE-PAIEMENT-CENTRALISE
                 SET TYPE-PAIEMENT-REEL-VIREMENT-CENTRALISE TO TRUE
             CASE TYPE-PAIEMENT-DEMANDE-VIREMENT
                 SET TYPE-PAIEMENT-REEL-VIREMENT-AGENCE TO TRUE
             CASE ELSE
                 SET TYPE-PAIEMENT-REEL-CHEQUE TO TRUE
         END-SELECT
         .
    Bon, le COBOL est verbeux et les majuscules ont tendance à faire fuir les petits jeunes, désolé. Et tout ceci marche parcequ'on a soigneusement préparé ses booléens en amont. Le SELECT CASE TRUE est considéré comme une horreur dans d'autres langages, mais en COBOL, ça passe très bien, parce-que ça colle parfaitement avec le genre de specs que les banquiers/assureurs nous font, et que le ELSE IF pose des problèmes de syntaxe. Il y a d'autres astuces de langage dans ce code que j'oublie sciemment dans mon commentaire : comment ça marche, en gros. Et le fait que le montant sont en centimes. Et même ce que ça fait : le nom de paragraphe, normalement, se suffit à lui-même, dans un cas pareil. Mais j'ai quand même mis un commentaire, pour un truc qui est impossible à mettre simplement dans un nom de variable/label.

    Ma doctrine, c'est : le code doit pouvoir se lire sans commentaire. Et on commente quand même un peu, parce-que bon, la doc, ça se perd. Javadoc, pour ça, est bien, et manque cruellement au cobol. La petite ligne que j'ai mise est restée dans le code, mais elle aurait bien fait(sans doute sous un format plus riche) de se retrouver dans une doc accessible aux gens du métier. A qui il a fallu trèèèèèès longtemps pour comprendre pourquoi leurs lointains prédécesseurs s'étaient fait chier à rajouter cette règle du million.

    Je vous laisse aussi le soin de deviner le temps que j'ai passé sur la partie "rétrodoc", avec des noms de variables aussi parlants (un mois pour 5000 lignes, à peu près. Je rêvais cobol tous les soirs. Ce qui ne m'étais jamais arrivé, et ne m'est jamais arrivé depuis). Ce n'est pas le code le plus vieux sur lequel j'ai eu à travailler(1970 est mon record), mais c'est le plus impossible résidu d'une époque sanglante qui bannissait les commentaires pour économiser quelques octets. Fatalement, ça influe sur ma vision des choses. Quand le management fait bien son boulot, il y a toujours de la doc à disposition. Il est fort rare que le management se préoccupe de bien faire son boulot(trop occupé à ne pas se faire virer à cause de la dernière lubie du grand patron). Donc, moi, je considère que dans des conditions réelles, le code doit être auto-documenté autant que possible. Dans les noms de variables partout ou c'est possible. Dans les commentaires partout ailleurs.

    Après, si on peut se permettre de faire une conception de haut niveau d'abord, je suis preneur. Si on a la maitrise des évolutions pour pouvoir se permettre d'avoir toujours le code qui suit la demande qui vient d'an haut, moi ça me plait. Simplement, dans la vraie vie, c'est assez rare. A mon niveau, je dois souvent faire aussi de la conception de haut niveau(et pas seulement de bas niveau, c'est-à-dire des détails de code) qui ne correspondent pas au besoin exprimé, mais sans laquelle rien ne marche. Et sur des trucs qui n'intéressent pas le client,qui va de toute façons l'expurger de sa belle spec à lui(genre le recyclage des enregistrements en erreur, un exemple vécu).

    La conception bottom-up correspond à un mode de fonctionnement ou le client ne sait pas exprimer ce qu'il veut - ou n'a pas vraiment le temps matériel de le faire. Et le temps de lui faire un truc qui lui plait, son besoin à changé. Donc une doc complète et exhaustive, ça n'est jamais à jour. Donc ça ne sert à rien. Moi, ma doc, sur le projet de refonte ci-dessus, elle disait juste "la donnée CUMUL-MONTANTS est calculée dans le module AVIS0005. La donnée TYPE-PAIEMENT-DEMANDE est calculée dans le module AVIS0008". Après, les gens savent ouvrir un code et le lire. Surtout si il a été bien fait(pas comme ces sagouins en 1972). Et ça suffit. Le jour ou le préimprimé TIP change, eh bien le code change, et pour retrouver la règle, on va toujours lire le code dans AVIS0008. Plus besoin de mettre la doc à jour - sauf nouvelle donnée, évidemment. On sait exactement ou chercher.
    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.

  18. #138
    Membre chevronné
    Avatar de CodeurPlusPlus
    Profil pro
    Inscrit en
    septembre 2013
    Messages
    632
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 632
    Points : 2 232
    Points
    2 232

    Par défaut

    Citation Envoyé par martopioche Voir le message
    "Pisseur de code", c'est une évaluation technique. Lorsqu'un "dev" (quel que soit le niveau technique) juge le business, voir même qui les considère de "golios", c'est juste un dev qui n'a rien compris au rôle de l'IT et à ce qu'il a à faire.
    Tu marques un point : je n'ai jamais rien compris eux gens qui ne faisaient que du business ; je n'ai jamais eu aucun respect pour eux parce que je ne leur ai jamais rien trouvé comme compétence.

    En revanche des développeurs qui ont aussi un pied dans le business, c'est autre chose, il y en a des bons.

  19. #139
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    3 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : avril 2005
    Messages : 3 859
    Points : 16 619
    Points
    16 619
    Billets dans le blog
    3

    Par défaut

    Qu’en pensez-vous ?

    Citation Envoyé par Michael Guilloux
    Mais certains en font peut-être un peu trop avec les commentaires, en essayant de les placer à chaque petit coin du code ; une pratique qui est désapprouvée par beaucoup de développeurs expérimentés.
    Heeeeeeu... si t'as déjà été confronté à pléthore de commentaires plutôt qu'indgence, tape dans tes mains !

    Les commentaires sont là souvent pour expliquer les choix un peu exotiques ; car soit on code n'importe comment (on déclare 18 variables inutilisées ou on oublie de faire un cast sur deux variables de type différents ce qui provoque des choses bizarres) soit on fait un truc bizarre en tant que workaround, parce que pour raison X ou Y la ligne de commande simple ne fonctionne pas (et qu'on n'a pas le temps, time is business).

    Les exemples ci-dessous sur le nom des fonctions ? J'espère que c'est toujours d'actualité en 2017 ; en 2001, mon prof nous enseignait déjà d'appeler nos librairies, fonctions, procédures, méthodes, variables, par des noms explicites. Bon certes, quand on avait un haut niveau, pour switcher deux variables on utilisait A, B et C. Mais lorsqu'on faisait notre premier projet "Mon Agenda", les variables étaient Nom et Prenom (puis plus tard sNom ou sPrenom pour identifier le type).

    De ce fait, j'ai jamais vu un gus commenter une ligne c = a + b // c contient la somme de a et b

    À quelle fréquence pensez-vous utiliser des commentaires ? Rarement, souvent, très souvent ?

    Malheureusement, je l'avoue, de moins en moins souvent... on apprend toujours à l'école qu'un projet c'est du 40 / 20 / 40, c'est-à-dire 40% de specification, 20% de développement et 40% de tests... Hahaha, la blague, c'est plutôt du 10 / 80 / 10, voire du 10 / 85 / 5... Le commentaire, c'est à ton bénévolat le dernier jour à 22h après la livraison (et quand un CP te demande de faire de la doc et du commentaire soudainement et que t'es presta, c'est que ça pue la fin de mission... ressenti deux fois)

    Quelles règles observez-vous pour insérer des commentaires dans votre code ?

    Voir ci-dessus... commenter que lorsqu'un choix vraiment exotique a été fait... après le niveau d'exotisme dépend de tout un chacun. Une seule fois je suis tombé sur un code, avec des commentaires où je me suis dit que limite, c'est moi qui l'avais commenté.

    Sinon, lorsque je suis en TMA, une petite astuce que j'aime bien : je créée une sorte de cartouche en tête de fichier, fait uniquement de commentaire, avec mon trigramme, la date et un commentaire d'une ligne. Puis je copie colle la ligne à l'endroit où j'ai modifié le code. Du coup, lorsque je reviens sur le fichier, j'ai juste à copier et coller la ligne pour me retrouver où j'ai modifié le code (avec un vrai commentaire si besoin).

    Exemple :

    // 05/05/2015 XDE modification de la formule du taux de rendement
    // 10/07/2016 ABE rajout des produits spécifiques
    // 11/08/2017 GLT correction de la précision des frais d'entrée

    Code CODE CODE, et à la ligne 518

    // 11/08/2017 GLT correction de la précision des frais d'entrée
    // Voir anomalie 123456789, la variable n'avait que deux chiffres après la virgule donc les arrondis sont erronnés sur des gros montants. On étend le nombre de chiffres après la virgule à six, l'arrondi se faisant sur l'interface utilisateur

    CODE
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 619
    Points : 19 041
    Points
    19 041

    Par défaut

    Allez, exemple vécu ce matin..... Bon, je dois écrire un script qui agit sur notre client lourd, et notamment rentrer le code 10 dans le type de transport. Alors j'avais ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    		ActiveX("Transport").Type "10" + micTab
    Et ça ne marche pas, parce-que quand on tape 1 puis 0, même par robot, l'appli va sur le 0, pas sur le 10. Donc j'ai désormais ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    		'.ActiveX("Transport").Type "10" + micTab - ne marche pas, donne zéro
    		.ActiveX("Transport").Type "9" + micDwn + micTab 'permet de taper 10, en fait
    qui signifie que je tape neuf, je tape sur la flèche en bas, et oh miracle, ça me sélectionne le 10. Et puis ça fait TAB pour continuer sur la case d'après.

    Dans ce genre de cas, le commentaire technique me parait indispensable - parceque la manière de faire qui permettrait de comprendre ne fonctionne pas(et je ne vais pas faire une usine à gaz pour remplacer les fonctions natives de UFT, juste pour ça). En tous cas celui de la deuxième ligne. Garder la première en code mort, ça m'emmerde, j'hésite, par contre. Ce n'est pas inutile(ça permet de voir facilement ce qu'on voulait faire), mais comme tout code mort, c'est moche, par définition.

    Encore une fois, je ne commente pas le micDwn. Quelqu'un qui fait du UFT doit savoir ça, ou le retrouver facilement. Juste l'astuce horrible qui fait que le code est tordu pour un résultat qui paraissait simple à obtenir...
    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.

Discussions similaires

  1. Réponses: 25
    Dernier message: 06/01/2013, 17h22
  2. Faut-il commenter son code source pour le rendre plus lisible et maintenable ?
    Par mayayu dans le forum Débats sur le développement - Le Best Of
    Réponses: 149
    Dernier message: 09/11/2009, 02h30
  3. Bien commenter son code Java
    Par shaun_the_sheep dans le forum Général Java
    Réponses: 2
    Dernier message: 27/05/2008, 11h13
  4. Comment commenter son code source proprement ...
    Par basnifo dans le forum MFC
    Réponses: 3
    Dernier message: 31/03/2006, 16h22

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