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
Oui
Non
Discussion :
Oui. Par contre, mon expérience me dit qu'il est toujours plus rapide d'écrire un .h puis de le transformer en diagramme uml (doxygen powa) que d'utiliser l'éditeur graphique pour le faire. Après, il y a sûrement des gens que ça éclate de faire des beaux dessins...Dessiner sous des outils comme RSA des rectangles désignant des classes c'est coder ces mêmes classes, les diagrammes UML n'étant que des vues sur le modèle de code.
Pour cette opération elle ne m'apporte de toute façon rien....Envoyé par white_tentacle
Tu es centré sur des cas d'erreur moi sur des cas de réussite l'approche est différente et cela ne va pas merder puisque je n'envois JAMAIS null (biensûr cela échouera pour qui écrira le testPar contre, je suis à peu près sûr que ça va merder quelque part ailleurs si tu passes un VFrame null (et au minimum, que ça n'a pas de sens), et pourtant, tu ne le mets pas dans la précondition du Add...
Le bon contrat c'est :)
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Mais si ça échouera et que tu ne l'as pas mis dans le contrat de ta fonction, comment veux-tu que celui qui utilise ta fonction (celui qui va reprendre le code, par exemple) le sache ?Tu es centré sur des cas d'erreur moi sur des cas de réussite l'approche est différente et cela ne va pas merder puisque je n'envois JAMAIS null (biensûr cela échouera pour qui écrira le test)
C'est à ça que ça sert, un contrat. Soit tu respectes le contrat en entrée (les préconditions), et on te garantit le bon fonctionnement (en tout cas, un comportement défini), soit tu ne le respectes pas et tu ne peux t'en prendre qu'à toi même.
Mais si tu penses qu'on peut respecter le contrat et que ça se vautre lamentablement, alors tu es passé complètement à côté de l'objectif de la programmation par contrat (cela dit, tu ne serais pas le premier).
Soit tu gères dans ta classe la possibilité d'avoir des frames null, soit tu l'interdis dans le contrat de Add (!= le vérifier dans le corps de Add). Mais toute autre solution est bancale et t'amènera des problèmes.
oui c'est vrai c'était rédigé à la volée ton exemple est plus juste pour toi, il y a différente façon aussi d'écrire et de retranscrire dans le code le contrat. Aussi ce n'est pas le contrat le plus important pour ce développement et l'erreur est rapidemment détectable avec un test unitaire par exemple
Justement si c'est important parce que la conception ne veut pas se lier/limiter au langage java exclusivement. Cela apporte qu'il doit exister une donnée membre initialisée et cela me semble effectivement important.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Ce que je veux dire c'est qu'une rétro-ingénierie UML sur un programme n'aura d'intérêt que si ledit programme est un programme objet correct, c'est à dire que son auteur sait modéliser en objet de manière satisfaisant. L'inverse n'a pas de sens. Prends par exemple un excellent programme en C : le diagramme UML correspondant risque d'être pour le moins dénué d'intérêt.
Là, peut-être que je n'ai pas bien compris ton approche. Il semblerait qu'il y ait un ou plusieurs architectes dans ton projet qui modélisent complétement l'application (c'est-à-dire en terme de classes et opérations précises) et que, dans un second temps, des développeurs viennent remplir les blancs (soit concrêtement les corps de méthodes). Donc effectivement, dans cette approche, le travail d'un développeur est borné par la classe sur laquelle il travaille, voire la méthode d'une classe.
Je n'ai jamais travaillé de cette manière mais je suppose qu'alors il devient cohérent que les développeurs puissent ne rien comprendre au modèle... Bon, ça me fait quand même un peu bizarre, comme si je devais parler à ma main pour qu'elle implémente mes classes (une variante de pair programming schizophrénique). Reste toutefois une petite question : quels commentaires peuvent bien avoir à écrire de tels développeurs au niveau du modèle UML ? Ce sont les architectures ayant défini classes et opérations qui savent ce qu'elles sont sensées faire non ?
Si c'est un choix fait en connaissance de cause, tout à fait d'accord. C'est juste que j'ai davantage l'habitude d'achats réflexes d'outils catastrophiques (genre cette grosse merde de ClearCase vendu à pris d'or) en amont plutôt que de restrictions en aval (justement parce que ça ne pèse pas des masses dans le budget).
UML aide à la documentation des projets afin d'alléger le code
Oui, c'est vrai que mon exemple n'a d'intérêt que pour Java. Je ne peux concevoir un developpeur qui n'ai pas une approche objet en Java sinon autant qu'il change de métier tout de suite avant d'allez au devant de grande désillusion.Prends par exemple un excellent programme en C : le diagramme UML correspondant risque d'être pour le moins dénué d'intérêt.
Ben nonLà, peut-être que je n'ai pas bien compris ton approche. Il semblerait qu'il y ait un ou plusieurs architectes dans ton projet qui modélisent complétement l'application (c'est-à-dire en terme de classes et opérations précises) et que, dans un second temps, des développeurs viennent remplir les blancs (soit concrêtement les corps de méthodes). Donc effectivement, dans cette approche, le travail d'un développeur est borné par la classe sur laquelle il travaille, voire la méthode d'une classe.Les gars ont fait leur projet avec ou sans UML. Ensuite ils veulent juste le documenter. Chacun rajoute la documentation sur ce qu'il a fait. Si un developpeur à fait une classe il dit pourquoi, si un développeur rajoute une méthode il fait un petit reverse de séquence et rajoute quelques note graphique. il explique aussi dans le classe diagramme s'il veut. Il y a aucune obligation dans cette approche, l'UML n'est qu'un support libre qui mappe le code Java en lui donnant une vision graphique UML, mais l'UML ne fait rien d'autre. C'est pour cela que c'est simple si on veut bien documenter. Le principe est le click sur le diagramme et sasie de texte dans une fenêtre ou reverse package, ou juste drag and drop de classifiers du package explorer vers le diagramme et ajout de commentaire graphique sur le diagramme. Même mon fils de 10 ans peut le faire, je lui ai dit qu'il ne pouvait pas faire de diagramme. Il m'a dit, non papa je peux. J'avoue que j'étais complétement scotcher devant un petit gars qui savait déjà utiliser un éditeur graphique sous Eclipse. Il a su drag and droppé les classes dans le diagrammes, clicker sur l'icone note de la toolbar et faire un commentaire. Il connait pas UML à son age mais il sait clicker sur les bouton et faire le drag and drop. Et ca suffit pour bien documenter son projet.
Ben oui c'est là le problèmequels commentaires peuvent bien avoir à écrire de tels développeurs au niveau du modèle UML ? Ce sont les architectures ayant défini classes et opérations qui savent ce qu'elles sont sensées faire non ?
Alors au temps pour moi, j'avais mal compris ta précondition. Par contre, il me semble plutôt que ce serait un invariant de ta classe. À noter aussi que ta précondition n'étant pas vérifiable par l'appelant, elle n'a aucune valeur.Justement si c'est important parce que la conception ne veut pas se lier/limiter au langage java exclusivement. Cela apporte qu'il doit exister une donnée membre initialisée et cela me semble effectivement important.
C'est une erreur de penser qu'on peut se passer de définir et documenter le contrat de ses fonctions (même si c'est ce que font 99% des développeurs).Aussi ce n'est pas le contrat le plus important pour ce développement
Je ne vois pas pourquoi cela devrait être vérifiable par l'appelant...
Pour le vérifier j'écris un test unitaire
Et la pré-condition est vérifiée.
Code : Sélectionner tout - Visualiser dans une fenêtre à part CheckNotNull(ArrayFrame);
C'est une erreur de penser qu'on peut définir et documenter tout les contrats de toutes les fonctions de toutes les classes de tous les modules de tous les systèmes....
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Pour qu'il n'appelle pas la fonction si la pré-condition n'est pas vérifiée.
Si je comprends bien ce dont tu parles ici, ce que tu vérifies dans cas c'est que le comportement de ton code est correct. Pas que la pré-condition est vérifiée lors de l'appel de ta méthode par un code étranger.
Ah d'accord je comprends mieux ce que voulait dire notre ami.
J'ai noté 1 pré-condition notre ami une autre le contrat peut inclure les 2 ce n'était qu'un exemple allégé.
La sienne concerne un paramètre de méthode la mienne concerne une donnée membre car même avec un paramètre non null (la fameuse pré-condition) sans la donnée membre non null(l'autre pré-condition) le contrat est tout autant allégé.
Cela vérifie bien une des deux pré-condition à savoir que la donnée membre soit initialisée pour le paramètre nous sommes d'accord.
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Pour basculer des questions venant du post code propre et après une relecture (très en diagonale) de celui-ci en mode panoramique ce qui revient avec les commentaires ce sont les tests parce que certains écrivent les commentaires avant le code de production et d'autres le code de test avant le code de production. Soit il y a la question du commentaire avant d'écrire le code de test...Il va falloir ouvrir un post sur les tests unitaire, intégration, système parce qu'ici cela dérive encore avec les tests.
Exemple de ce qui me laisse penser cela :
La plus part du temps en commençant avec des tests pour comprendre et vérifier les comportements en boîte noir par rapport à l'utilisation future. La documentation me sert effectivement au moment où il faut utiliser les paramètres et valeur de retour d'une méthode/fonction ou pour une vue plus globale ou plus micro du système.
Cependant cette documentation ne se trouve pas embarquée dans le code source de l'API en question (référence à une bibliothéque pour une carte de communication) quoique il y en a toujours un peu...
Souvent ce sont des exemples d'utilisation des fonctions dont je me documente plus que le code source de la fonction en elle même. Je ne vais pas lire le code source de la fonction openCard mais un code source d'utilisation de openCard.
Avec des tests autant faut-il que cela cette unité de code source soit testable en plus cela 'garanti' la non regression d'une refactorisation.
Je suis d'accord puisque la personne ne va probablement pas avoir accès au code de test pour comprendre comment on utilise dans un programme la fonction.
Maintenant le débat des commentaires a tendance à m'ennuyer un peu aussi comme Garulfo tandis que les tests me semblent plus prometteur *
*surtout en les générant automatiquement depuis les commentaires de code source
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Méthode empirique en bref.
Le souci d'utiliser des tests pour comprendre le fonctionnement d'une bibliothèque externe c'est que c'est long et qu'il est possible de tirer des conclusions erronés.
Autant je suis 100% d'accord pour passer des tests permettant de valider le comportement de la bibliothèque dans un premier temps puis pour valider l'intégration de la bibliothèque dans le soft final.
Autant je suis dubitatif sur l'utilisation de test pour comprendre le fonctionnement d'un bibliothèque quand d'autres moyens existent.
La documentation et les éventuels exemples me semblent effectivement plus pertinent.
Toutefois, les exemples ne montrent malheureusement pas tout.
Ce ne sont pas les tests qui font corriger ou refactorer quoique ce soit.
Ils sont certes indispensables et apportent une aide importante pour permettre les corrections et refactoring mais ne sont suffisants.
Quant à l'exemple en rapport avec la citation, j'ai bien peur que les tests n'aient pas pu apporter grand chose (les tests unitaires de la bibliothèque externe n'étant pas fournis et les tests de mon code testent le comportement des fonctions, pas leur détails d'implémentation (ne serait-ce que parce que les tests ne communiquent avec la fonction qu'à travers des paramètres et des valeurs de retour/exception).
Effectivement, il est rare que le code de test soit disponible en dehors de l'équipe écrivant le code testé.
Je pense qu'il y a également un critère que tu n'as pas pris en compte : le passage des tests peut dans certains cas (qui ne semble pas être le tien) être très couteux en temps et en ressource. De fait, il est des domaines dans lesquels on essaye de passer la batterie de test le moins souvent possible (idéalement uniquement sur la version livrée).
Excuse-moi, hegros, mais comme le dit gl ça c'est du comportement non professionnel..
Cela s'appelle "la méthode essais et erreurs", et est reconnue comme étant la plus improductive qui soit, en particulier pour les questions soulevées par gl (pur coup de bol, temps perdu considérable)...
Que cela soit (un peu) valable en développement, soit, si c'est relativement léger..
Mais par contre c'est totalement inapplicable et non professionnel pour l'utilisation d'une biblothèque (ou d'un programme) tierce...
Mais je comprend mieux, avec ce que tu avais mentionné dans un autre post.. Tu es un "geek", qui se retrouve dans le marché duu travail..
Et comment testes-tu si tu ne sais pas comment appeler les fonctions ??
Ben non, normalement elle figure dans une aide externe..
Cependant, et nous en avons tous eu le cas, il arrive fréquemment que cette documentation soit incomplète par rapport à nos besoins (par exemple justement quel(le) algo/méthode est utilisé(e), ou bien si il y a des tableaux internes, de quelle taille, etc etc..).
Et dans ce cas, les commentaires dans le code sont bien utiles...
Soit, pour un certain nombre de cas (bibliothèques fournies avec garanties, avec du matériel, etc etc).
et c'est valable très souvent pour du développement...
L'an dernier, dans le projet sur lequel je travaillais, chacun faisait son petit test dans son coin, mais le test global (le build complet) n'était fait qu'une seule fois par semaine (6-9h de compil et 3h de download sur chaque machine).
Maintenant, même pour du développement plus "léger", comme on l'a mentionné à propos des TU, même si tu passes tous les tests ça ne veut pas dire que ça marche, et c'est une très grave erreur que de croire ça...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
C'est une très grave erreur de conclure que cela concerneexclusivement des tests unitaires ce qui est plutôt une vision réductrice et minimaliste des tests. Tu devais le savoir avec les tests d'ergonomie dont il semble que tu es spécialiste que la variété des tests n'est plus à prouver et cela mérite bien un best of developpement
Soit pour toi cela ne te dérange pas de livrer à ton client un programme, un système ou une API pas testée c'est ton problème mais personne n'a dit ici ou ailleurs que passer tous les tests unitaires voulaient dire que cela va marcher pour tous les cas possibles et inimaginable ou que c'était suffisant ou se substituer au commentaire.
il y a des choses qu'on ne peut ni tester ni vérifier ni démontrer ni rien ok c'est vrai mais selon la loi des 80/20 c'est plutôt des cas du côté des 20 en tout cas il est préférable d'avoir un logiciel testable (à tout les niveaux j'entends) que non testable c'est évident(comprendre 80% testable).
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Hey je vais apporter mon ptit caillou à l'édifice
L'autre jour j'ai du comprendre une librarie pourtant claire, mais vaste et sans aucun commentaire ni documentation d'aucune sorte. C'était la guerre.
Sinon pour parler de choses plus intéressantes...
Plus haut, hegros, tu demandais un exemple de commentaire valide pendant plus de 10 ans.
Simple:
Un code un peu compliqué qui survit plus de 10 ans
Un commentaire adéquat qui l'accompagne durant sa carrière.
Pourquoi le commentaire perdrait-il soudain de la valeur si rien ne change ?
Tu disais aussi que personne n'ensegnait à commenter. C'est faux. Dès ma première année d'études les profs ont lourdement insisté sur ce point: préconditions, postconditions, invariants... (on n'en était pas aux considérations de conception bien sur)
Concernant la rêgle du 1/3 de commentaire, je ne suis pas d'accord. Non pas parce que c'est trop, ni parce que c'est trop peu. Simplement parce que c'est variable.
Pour prendre un exemple concret, des librairies utilitaires Python peuvent très bien inclure en pydoc des définitions et exemples complets d'utilisation de cette lib. Ca aide à la documentation en live, directement depuis la console.
Dans ces cas, il n'est pas rare (aouch, je mets des accents circonflexes sur "rares", il est temps que j'aille dormir) d'approcher des 40% de documentation.
Bref à mon sens, et comme dit maintes fois plus haut, il n'y a pas de proportion de code idéale. Tout dépend des cas. Néanmoins, un peu de documentation expliquant le fonctionnement général des packages / classes est quand même largement appréciable. Il en va de même pour les commentaires qui expliquent des bouts de code obscurs et qui donnent des précisions non évidentes sur des fonctions.
Désolé pour la redite, je sais qu'il y en a, mais peut-être qu'une petite brique a quand même été apportée par ce message
Ce qui est affirmer sans preuve peut-être infirmer sans preuve puisque comme les autres défenseurs des commentaires intemporel tu ne donnes aucun exemple convaincaint et réaliste.
Un commentaire qui traverse le temps 10 ans ou 20 ans ou 30 ans est forcément obsolète, inutile ou faux et surtout rarissime quand on sait la durée de vie des logiciels en moyenne...
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Commentez son code et test
Je suis entrain de lire ce poste et je me dis que tous ont raison, juste cela dépend du contexte.
Les tests sont indispensables mais couvre pas tout comme par exemple les tests des ihm. Seul un oeil humain peut voir le bug.
Il faut donc commenter son code, commenter sa documentation si possible en UML et faire des tests unitaires, tests humains etc....
Il y a un gros boulot bon courage
D'un autre côté, tu affirmes tout autant sans preuve qu'un commentaire perd de sa qualité malgré que rien autour de lui ne change...
Edit: Oh dis donc... tu voulais une preuve ?
J'ai trouvé un commentaire qui a survécu de 1994 à nos jours. Il est peut-être même plus ancien que 94.
Bon certes il a un peu changé, mais il contient toujours la même info.
Version 94:
Version 09:/*
* Commands to sys_syslog:
*
* 0 -- Close the log. Currently a NOP.
* 1 -- Open the log. Currently a NOP.
* 2 -- Read from the log.
* 3 -- Read up to the last 4k of messages in the ring buffer.
* 4 -- Read and clear last 4k of messages in the ring buffer
* 5 -- Clear ring buffer.
* 6 -- Disable printk's to console
* 7 -- Enable printk's to console
* 8 -- Set level of messages printed to console
*/
Devine d'où ça vient... Allez, un indice: c'est une alternative à m$./*
* Commands to do_syslog:
*
* 0 -- Close the log. Currently a NOP.
* 1 -- Open the log. Currently a NOP.
* 2 -- Read from the log.
* 3 -- Read all messages remaining in the ring buffer.
* 4 -- Read and clear all messages remaining in the ring buffer
* 5 -- Clear ring buffer.
* 6 -- Disable printk's to console
* 7 -- Enable printk's to console
* 8 -- Set level of messages printed to console
* 9 -- Return number of unread characters in the log buffer
* 10 -- Return size of the log buffer
*/
Re-edit: bon en fait je vais donner en mil d'où ça vient, sinon certains ne me croiront pas...
Kernel linux
version 1.0 pour 94
version 2.6.29 pour 09
dossier "kernel" fichier printk.c
Fichier qui, soit dit en passant, est passé de 5.2k à plus de 31k. Comme quoi il a bien changé.
Merci enfin quelqu'un qui trouve un exemple de commentaire sur 15 ans et cela concerne un système d'exploitation soit c'est un domaine de développement à part.
De plus il est open-source est destiné à être lu par des développeurs de tous les coins de la planète contrairement à des logiciels en général d'entreprise qui ont un autre modèle économique que l'open-source (soit probablement la majorité qui nous intéresse quoique cela reste discutable)
Mais c'est un très bon exemple de ce qui est réaliste et faire mieux me semble bien difficile... quand aux gains... il y en a surement pour ceux qui développent/maintiennent cette partie là à une certaine mesure par rapport à d'autres documentations online de la communauté linuxienne cela n'a jamais été nié.
En plus par rapport au thread initial il n'y a aucun rapport avec ce que tu montres puisque pour rappeler le contexte c'est dans quelle mesure un commentaire rend un code propre hors là il n'y a même pas de code....(enfin le printk.c mais bon...)
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
En même temps, il est difficile de donner un exemple autres qu'un logiciel comme ça puisque les développeurs de logiciels d'entreprise propriétaires n'ont pas l'autorisation de divulguer des parties du code
Je ne répondrai à aucune question technique en privé
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager