Discussion :

[koala01]

Mais arrêtez enfin, là c'est vous qui êtes extrêmes ! Je suis pas en train de dire qu'un parfait abruti peut devenir un expert sur le simple fait d'apprendre ce qu'est un diagramme de classe !

Encore heureux

Admettez au moins que le fait d'apprendre UML ou tout autre langage de modélisation te donne plus de chances de mieux structurer tes concepts plutôt que d'y aller au feeling !

Je peux effectivement l'admettre

Au même titre qu'apprendre 1 technique inspirée d'anciens experts est mieux qu'en chercher une par soi-même depuis 0. Parce qu'au moins tu as une base à utiliser pour te faire penser à certains points importants.

mmouaip... à condition que ce soit quand même un ancien qui ait fait un minimum de "veille technologique"

Vous prônez la réinvention de la roue en toute circonstance là !

En tout cas, pas moi

Mais je peux t'assurer que, quand on voit certains "experts", ca fait franchement peur une fois que tu sors de l'utilisation de son EDI préféré et des classes qu'il se contente d'empiler.

Et le pire, c'est qu'il est capable de te citer tous les DP de tête... mais incapable de les mettre correctement en pratique :-P

[Matthieu Vergne]

Après parler d'expert n'a pas de sens sans préciser le domaine d'expertise. Et je ne parle pas d'experts qui n'ont que le titre. Ma thèse étant sur la recommandation d'experts en ingénierie des exigences, j'ai dû me documenter un minimum sur ce qu'était un expert, alors me faites pas passer pour quelqu'un qui dit ce genre d'âneries {>_<}.

Si on avait parlé de "faire le boulot à la place de" je vous aurais suivi. Mais là on parle de "faciliter", ce qui est radicalement différent. C'est comme si on parlait de techniques pour "pouvoir mieux jouer" aux échecs et que vous y répondiez "un élève ne remplacera jamais un maitre". Merci pour l'évidence, mais ça ne veux pas dire qu'il n'y a que les maitres qui savent jouer.

[Mat.M]

Les méthodes et outils (langages inclus) ont évolué, ce qui permet de faire tout ça au moins plus facilement que dans le temps (ou de faire plus complexe avec la même difficulté, ce qui revient au même). .

eh bien c'est ce que j'ai écris donc on abonde dans le même sens non ?

[Mat.M]

Je te conseillerais de te documenter plus profondément, et de lire les débats, ici-même, sur le sujet...[*]Les méthodologies n'existaient pas ?????? Tu rigoles , j'epère.....[*]UML n'est qu'un outil, ça ne change rien à la manière[*]le C++ date de bien avant que ça, Delphi (avec ObjectPascal) est sorti en 1990. Et C++ est fabriqué gràce à C, et à son compilateur.[*]X11 (XWindows), comme après lui Motif, est écrit en C, en objet, et date de .. 1978.. Première version publique 1984. Tu devrais sérieusement regarder le code XFree86 ou de X11.... Tu y verrais de l'objet, de l'encapsulation, de l'héritage, de la surcharge, des événements, des handlers, des exceptions.. et tout ça en C pur....

oui mais bon faut pas exagérer non plus les projets informatiques n'étaient pas aussi sophistiqués que maintenant et puis si c'est pas il y a 20ans c'est il y a 30ans ou 40ans ; tu est en train de jouer sur les mots de manière un peu idiote...c'est pinailler pour rien
Lorsque j'ai préparé un BTS d'informatique par correspondance en 1988 on en était encore au Turbo Pascal , au GW Basic et au Quick C et Windows c'était 2.0 donc UML , les Design Patterns , AGILE, SCRUM c'était dans les cartons ou peut-être dans la tête de génies à Harvard..
Bon ok c'était il y a plus de 20ans mais c'est pinailler inutilement je t'ai connu plus subtil tout de même.
Ensuite il y a 20ans ou 30ans ou whenever la France était littéralement sous-développée questions moyens informatiques , Unix c'était pour le CNRS ou les mega-boites comme IBM..
moi môssieu je n'ai pas eu la chance de travailler au CNRS ou être directeur de projet informatique de 25 développeurs

Révises et renseignes-toi, stp... Excuse-moi, mais là tu fais le parfait ignorant qui se croit supérieur... et ne fais que raconter des âneries...sur ces derniers posts[/I])

oui mais bon l'informatique j'ai pas commencé ce matin non plus...
et puis si j'étais vraiment supérieur je n'aurais pas eu des misères de salaires comme j'ai eu et un sous-programmeur comme je suis

[Mat.M]

Voir plus haut..... Vous vous gourez totalement : avoir un tournevis qui te donne le courant et le voltage ne fera pas de toi u électronicien, et encore moins un électronicien de haut vol...

ça d'accord...mais en parlant d'architecture de projet je voulais écrire que le fait de bien structurer un projet tout en ayant l'impression de perdre du temps au début en définitif ça en fait gagner..et donc ça coûte moins cher question finances à finaliser un projet informatique
En d'autres termes si tu conçois et développe un projet informatique à l'arrache et que tu fais croire à ton équipe qu'en étant performant tu seras meilleur ton projet te coûtera plus cher car ça sera difficilement gérable à faire évoluer et à maintenir.
D'où l'intérêt de bons commentaires dans le code source
Et c'est pour cela que "bien développer" c'est devenu une tautologie

[Mat.M]

Première version publique 1984. Tu devrais sérieusement regarder le code XFree86 ou de X11.... Tu y verrais de l'objet, de l'encapsulation, de l'héritage, de la surcharge, des événements, des handlers, des exceptions.. et tout ça en C pur....

Un peu de bon sens ! Là c'est vraiment exagérer à la limite mauvaise foi ou de l'affabulation
En 1984 c'est tout juste si on pouvait se payer un Amstrad 464 donc l'IBM compatible PC c'était un doux rêve puisque ça coûtait 10000 francs de l'époque.
Seuls les universitaires ou les huiles des grosses boites pouvaient toucher à Unix..et encore
Ensuite pour apprendre l'informatique c'était soi le Basic ou l'Assembleur
Donc désolé mais il faudrait arrêter la mauvaise foi.
C'est toi qui prend les gens pour les idiots

[Mat.M]

Il est réellement étrange que vous croyiez à ce point vous-mêmes ou vos techniques tellement supérieur(e)s qu'elle rendraient le boulot de tous vos prédeceseurs stupide, mal fagoté, mal structuré, pas pensé, pas conceptualisé...

c'est pas du tout ça.....apparemment tu n'as pas travaillé sur un projet informatique depuis longtemps..
les projets de développement informatiques deviennent plus complexes avec plus de lignes de code c'est normal les clients veulent plus de fonctionnalités.
Donc soit tu architectures bien le projet soit c'est un projet titanic.

Dans les années 80 c'était pas possible à cause du matériel informatique pas aussi largement démocratisé que maintenant et surtout avec peu d'outils à disposition

[souviron34]

Je ne répondrais pas, tellement tu es dans les choux....

c'est pas du tout ça.....apparemment tu n'as pas travaillé sur un projet informatique depuis longtemps..
les projets de développement informatiques deviennent plus complexes avec plus de lignes de code c'est normal les clients veulent plus de fonctionnalités.
Donc soit tu architectures bien le projet soit c'est un projet titanic.

Dans les années 80 c'était pas possible à cause du matériel informatique pas aussi largement démocratisé que maintenant et surtout avec peu d'outils à disposition

Relis l'historie de l'informatique, et renseigne-toi, c'est tout ce que je peux te dire..

Les projets ne sont pas plus gros aujoud'hui qu'avant.. J'ai travaillé (et continue) sur des projets de 1975 à 1985, et des plus récents, qui comptent tous entre 2 000 000 et 7 000 000 lignes...

Mais bon.. Tu as raison vous êtes les plus forts.. Comme on dit au Québec : "pète-toi les bretelles" comme tu peux avec des gens de ta génération, mais n'essaie pas de sotir des trucs comme ça avec des vieux, hein ?? parce que les autres te riront au nez... C'est tout je que je peux te dire..


PS: je vais finir par poster mon CV sur ce site, et j'aimerais que d'autres de ma génération le fassent aussi... Honnêtement, il est impossible de discuter avec ces a-priori que vous avez.. Alllez, bonne continuation...

[moldavi]

Bonjour.

Je trouve cette discussion enrichissante, et tous les intervenants intéressants.

Ca me permet de m'enrichir, et pour le cas, de maintenir ma position de base. En effet dans le premier message que j'ai posté, j'ai signalé, que pour moi, les commentaires dans le code nuisaient à la lisibilité du code. Quand je travaille sur un code, je veux voir du code, pas des trucs verts (commentaires sous VS), qui vous obligent à scroller, et à scroller, et à ...

Cela ne veut pas dire que je suis contre les commentaires. Je suis plutôt contre les commentaires dans le code.

Lorsque j'utilise une API dont je n'ai pas les codes sources, je suis content d'avoir une documentation bien fournie.

Je suis plus favorable à une documentation extérieure au code. Pour moi il y a le code et la documentation. Deux choses distinctes qui ne doivent pas se mélanger.

PS: je n'aime pas l'argument qui consiste à dire qu'une documentation extérieure peut se perdre. Elle doit tout simplement se trouver avec le projet.

PS2: si vous ne comprenez pas la logique de codage d'un développeur, pourquoi seriez-vous certain de comprendre sa documentation. Lorsque je m'exprime, peut-être ne comprenez-vous pas le fond de ma pensée. Alors si je commente mon code, pourquoi seriez-vous assuré que mon commentaire va vous permettre de débugguer le programme.

PS3: les commentaires que je trouve le plus intéressant dans un code, c'est :

FIXME,TODO.

Au moins on sait ce qu'il reste à faire.

[Matthieu Vergne]

PS2: si vous ne comprenez pas la logique de codage d'un développeur, pourquoi seriez-vous certain de comprendre sa documentation. Lorsque je m'exprime, peut-être ne comprenez-vous pas le fond de ma pensée. Alors si je commente mon code, pourquoi seriez-vous assuré que mon commentaire va vous permettre de débugguer le programme.

Je pense que c'est la différence centrale entre les anti- et pro-commentaires (sans vouloir faire passer qui que ce soit pour un extrémiste, juste pour avoir des noms illustratifs). Les premiers estiment que le code vaut aussi bien que le langage naturel, si on ne sait pas se faire comprendre dans l'un y'a pas de raison qu'on sache le faire dans l'autre donc autant se concentrer sur un seul plutôt que de s'éparpiller sur deux, alors que les seconds estiment que parler deux langues c'est se donner plus de possibilités d'expression et donc de quoi compléter plus aisément.

Si je le vois comme ça je comprends tout à fait que les deux soient valables, dans le sens où :

Objectif anti-commentaires : rapprocher le code du langage naturel en ayant des nommages explicites et des fonctions réduites à leur algo de plus haut niveau.
+ exploite le formalisme du code pour rendre la conception moins ambigüe
+ utilise les possibilités des outils (détection d'erreur y compris au niveau sémantique, tests unitaires, etc.) pour certifier la validité de ce qui est exprimé.
- tient tant que le langage permet effectivement d'exprimer tout ce dont on a besoin
- implique de se donner comme contrainte de chercher à coder toujours plus haut niveau, donc plus abstrait, donc plus difficile à comprendre pour un néophyte

Objectif pro-commentaires : se focaliser plus sur un code ouvert aux habitudes et préférences du programmeur, avec la possibilité de commenter pour traduire l'idée derrière le code dans un langage plus commun
+ plus souple car demande moins de rigueur au niveau lisibilité du code
+ le langage naturel a priori nous est plus familier que du code, donc les commentaires sont plus faciles à écrire de manière lisible
- doit faire confiance à un bout de texte qui n'est pas forcément vérifié, voire plus à jour
- sujet aux ambigüités de la langue naturelle

Ça me semble fortement complémentaire tout ça. Les premiers poursuivant un idéal ou finalement on arrive aux "commentaires compilables" en quelque sorte (on en voit déjà les couleurs vu les dernières recherches) et les seconds cherchant à exploiter de manière simple mais complémentaire tout ce qu'ils ont sous la main.

Est-ce que je résume bien ?

[el_slapper]

Mais là encore, a priori, si le nom des fonctions de tests est correctement choisi, ben, étant donné que c'est une exécution relativement rectiligne (même si tu commence à gérer dans ton script le fait que chaque fonction peut réussir ou non), les commentaires n'apporteront sans doute pas grand chose si tu peux te permettre de rajouter les appels supplémentaires à la fin du script (ou peu s'en faut).

Il s'agisait de scripts de tests de transactionnel. L'ordre était donc prépondérant.

Evidemment, si tu veux que tes tests soient effectués dans un ordre particulier (module par module, par exemple), là, je peux concevoir que l'on mette un commentaire pour permettre aux gens de savoir où ils doivent rajouter l'appel, mais cela n'aura quand même pas grand chose à voir avec la "compréhensibilité" du code

Au contraire. Par rapport au plan de test fourni par les homologateurs, il est absolument essentiel de savoir qu'on a planté au point III.B.1.f., que c'est un remplissage de textbox(la 414) suivi d'un appui sur bouton(le 9318), à quel élément fonctionnel ça se rapporte, et quel est le résultat attendu. Toutes choses assez difficilles à faire ressortir par le code seul.

[jouana]

Petit retour sur refaire la roue.

En projet il est clair que ça sert à rien et pire c'est anti productif.
Mais même avec peu d'expérience, je me sens dans certain cas plus à l'aise que les expert que j'ai pu côtoyer.

Pcq je sais refaire la roue ce qui me permet d'avoir un meilleur visibilité de l'action que je met en place au travers, d'un framework ou autre et pire je sais comment sortir des clous pour rendre exploitable mes bout de code dans bien des situations.

Le problème c'est pas les experts, les débutants ou autres mais les bases que nous pensons maîtriser et la capacité à prendre du recul sur un projet.

La différence entre un "expert" et un "débutant" c'est le nombre de problèmes rencontré, mais le débutant avec des bases solides peu arriver plus rapidement au titre d'expert et avoir une connaissance et une mise en application bien solide.

Après les commentaires pour ma part c'est comme tout dans ce monde oui mais avec modération

[gl]

Au contraire. Par rapport au plan de test fourni par les homologateurs, il est absolument essentiel de savoir qu'on a planté au point III.B.1.f., que c'est un remplissage de textbox(la 414) suivi d'un appui sur bouton(le 9318), à quel élément fonctionnel ça se rapporte, et quel est le résultat attendu. Toutes choses assez difficilles à faire ressortir par le code seul.

Pour le coup, plus que dans le commentaire c'est dans le message de résultat du test que je mettrais (si l’environnement de test le permet bien entendu).

[Ecva233]

les projets de développement informatiques deviennent plus complexes avec plus de lignes de code c'est normal les clients veulent plus de fonctionnalités.
Donc soit tu architectures bien le projet soit c'est un projet titanic.

La complexité des développements n'est pas seulement liée aux nombre de fonctionnalités supplémentaires demandées. Je penserai même qu'elle n'est pas liée. La complexité, est surtout dû à un mouvement que j'ai constaté depuis pas mal d'année lié à la paramétrisation à outrance des applications.

Personnellement je me suis retrouvé confronté (récemment) à des applications qui appellent une trentaine de table de paramètre et à partir des informations retournées, définir le type de traitement à effectuer. Donc là des commentaires dans la langue de Molière s'imposent sinon on risque de perdre beaucoup de temps à comprendre le pourquoi du comment ...

Et je préfère lire en commentaire "les centimes perdus suite au calcul au prorata de l'avenant d'un contrat d'assurance sur ses garanties, ont été rajoutés sur la garantie possédant le montant net le plus important".
Cela me prend 30 secondes à lire, alors que j'aurais perdu 20 minutes à comprendre le code aussi bien écrit soit il.

Donc même si un code non documenté, et bien écrit, il reste quand même difficile à appréhender, si on n'a pas une connaissance globale de l'architecture, du métier, des fonctions, de l'organisation ...

[Matthieu Vergne]

D'une part la complexité ne se joue pas sur une unique dimension. La paramétrisation, les fonctionnalités différentes, les structures imbriquées, etc. sont autant de dimensions sur lesquelles ton appli peut se voir complexe.

D'autre part, si tu relis ton dernier paragraphe, et si tu y réfléchis un peu, tu verras que pour comprendre le commentaire, et non le code, il te faut plus ou moins la même chose.

Un peu de lecture pour les intéressés :
http://dl.acm.org/citation.cfm?doid=2507288.2507318

C'est pas sur les commentaires en particulier, ça vise plus large, mais certaines parties y sont directement applicables.

[Ecva233]

D'autre part, si tu relis ton dernier paragraphe, et si tu y réfléchis un peu, tu verras que pour comprendre le commentaire, et non le code, il te faut plus ou moins la même chose.

Merci de me le souligner, je n'en ai pas l'habitude ...

[Mat.M]

La complexité, est surtout dû à un mouvement que j'ai constaté depuis pas mal d'année lié à la paramétrisation à outrance des applications.

P ...

eh bien c'est ce que j'ai écris non ? Avant de vouloir me contredire
Déjà "paramétrisation" c'est une faute de français
Ensuite "paramétrer" un logiciel ça signifie d'une base "standardisée" comme avec un ERP vouloir rajouter des fonctionnalités demandées par le client qui n'existe pas en standard donc ça complexifie les choses

La complexité des développements n'est pas seulement liée aux nombre de fonctionnalités supplémentaires demandées. Je penserai même qu'elle n'est pas liée.
P ...

ah bon comme c'est amusant ; on est en dépit du bon sens...
si pour un projet d'entreprise on me demande un module de compta puis 4mois après un module de gestion de prospect commercial puis 4mois après un module de facturation c'est clair que les choses se simplifient

[jouana]

Ca dépend de ton archi. Si les changements sont prévus à la base tu peux centraliser beaucoup de ton code peu importe le module

[Ecva233]

si pour un projet d'entreprise on me demande un module de compta puis 4mois après un module de gestion de prospect commercial puis 4mois après un module de facturation c'est clair que les choses se simplifient

Ca pour moi ce n'est pas du paramétrage, c'est de l'évolution fonctionnelle, ce qui est normal dans la vie d'une application et qui existe depuis la nuit des temps, tout comme la factorisation et l'encapsulage.

Je pense que c'est aussi ton travail, de prévoir les éventuelles évolutions futures, et donc de définir ton architecture en ce sens.

Paramétrer, et ce que je dénonce, c'est vouloir absoluement tout mettre en table de paramètre, jusqu'à la bêtise extrème les valeurs "Oui" et "Non" (déjà vu). C'est ce phénomène qui rend les applications de plus en plus lourdes, complexes, immaintenables (désolé pour la faute de français pour les puristes), de plus en plus gourmandes en ressource machine. Ce sont les opérations d'entrée sortie sur les bases, fichiers de données qui sont les plus couteuses. La difficulté réside à trouver le juste équilibre.

Pour ma part, j'ai déjà vu un projet ne pas aboutir, car même un mainframe (et là faut quand même en vouloir) ne pouvait pas supporter les nouvelles applications car développées sur ce principe "tout est paramétrable" (fonctions, données, ...).

[Mat.M]

Je pense que c'est aussi ton travail, de prévoir les éventuelles évolutions futures, et donc de définir ton architecture en ce sens.

Paramétrer, et ce que je dénonce, c'est vouloir absoluement tout mettre en .

pour les gros projets oui ; pour les petites entreprises elles n'ont pas les moyens de définir une bonne architecture de projet il faut être performant et développer à la va-vite