Discussion :

[zooro]

Y réfléchir : je n'ai jamais dis que c'était sans réfléchir. J'ai dis qu'il n'y avait pas besoin de réfléchir avec du papier, le cerveau suffit.
Avant de passer par le papier, j'espère que ton idée passe par ton cerveau, non ?
Après, certains ont besoin de "formaliser" leur réflexion sur le papier, qui leur sert de support pour marquer leurs idées, d'autres non.

Curieusement, je n'ai jamais réussi à partager les pensées des équipes de dév avec lesquelles j'ai travaillé (et c'est d'autant plus difficile quand des équipes sont réparties dans plus de 3 pays (France, Chine, Japon) comme le projet sur lequel j'interviens actuellement)...
Je suis d'accord avec toi pour les petits (ou moyens) projets individuels (ou à la rigueur de deux ou trois personnes). Comme je l'ai dit, j'ai déjà réalisé tout un projet avec des spéc relativement vagues et une simple réflexion.
Par contre, dans les projets plus gros, une documentation permettant de guider le développement (le cahier des charges ne suffit pas dans ces cas-là) est indispensable, ne serait-ce que pour la communication et la synchronisation des équipes. Si tu développes une API, l'interface doit être spécifiée pour que les autres développeurs du projet puissent commencer à travailler avant que tu ais complètement terminé ton boulot. Je suppose que tu ne peux qu'être d'accord, non ?

[zooro]

rédiger un minimum de spec. On appelle ça le cahier des charges, l'expression des besoins. D'accord ça conditionne le développement mais ce n'est pas ça qui te permet d'écrire ton code. Les specs te permettent juste de donner un objectif (il vaut mieux en avoir un, c'est sur...*), mais ne te disent pas comment tu vas l'atteindre.

En fait, non. L'expression de besoins est ce que l'utilisateur veut ("je veux pouvoir téléphoner et recevoir la télé sur mon téléphone mobile"). Le cahier des charges te dit, de façon un peu plus formelle, ce que le client veut. Pas comment faire.
Ca, c'est le but des spécifications (les normes 3GPP vont être utilisées, il va falloir les implémenter. Voilà comment on va faire: il y aura une bibliothèque qui va gérer tel système. Tel mécanisme permettra de garantir les performances prévues par le cahier des charges, etc.).
Après, les spécs peuvent être plus ou moins détaillées. Tu peux rester au niveau général, ou aller jusqu'à définir les méthodes principales de chaque classe.

[5:35pm]

Ce sujet fait couler beaucoup d'encre pour rien!

Quelque soit le domaine, la preparation et l'organisation est important dans la realisation d'un travail.

Pour realiser un batiment, l'architecte prepare les plans, et le chef de chantier organise le travail de ses macons.
Celui qui dis "je programme spontannement" (le concept et l'organisation sont representes dans ma tete), c'est celui qui veut faire une cabane.

On retrouve ce schema dans tout projet:

Conceptualisation -> Organisation (planning, repartition des taches) -> mise en application.

[Hephaistos007]

Oui, c'est bien ce que j'ai dit. C'est une évidence, mais 18 pages ne suffisent toujours pas à convaincre certains.

[zecreator]

... on est d'accord pour dire que l'application des formalismes est essentielle pour des projets d'envergures, à tavers un travail d'équipe et nécesist

[zooro]

Oui, c'est bien ce que j'ai dit. C'est une évidence, mais 18 pages ne suffisent toujours pas à convaincre certains.

J'en suis aussi convaincu, moi. Comme tu dis, c'est évident.

[zecreator]

..on est d'accord pour dire que l'application des formalismes est essentielle pour des projets d'envergure, à travers un travail d'équipe et nécessitant une maintenance logicielle régulière. Il s'agit là d'un contexte de développement plutôt ciblé "grands compte", et non petites PME ou PMI, ou de l'interne...

Comment appliquer cette méthode quand on est seul développeur, que l'on doit effectuer de la semi-administration serveur, et faire de la hotline, former les utilisateurs finaux et que vous devez répondre à des besoins informatiques quasi quotidiens ?

Même si un développement méthodique permet au final de gagner du temps (pas toujours sûr) et de l'argent, il faut avoir les moyens d'en dépenser beaucoup avant je suppose.

En passant, petite question : Ceux qui utilisent les formalismes, peuvent-ils nous donner leur secteur d'activité professionnel, et s'ils travaillent seuls ou en équipe sur leurs projets ?

Dali peignait après avoir effectué ses tracés au crayon. Picasso se lançait directement au pinceau. Et pourtant, c'est 2 fabuleux artistes...

[zooro]

..on est d'accord pour dire que l'application des formalismes est essentielle pour des projets d'envergure, à travers un travail d'équipe et nécessitant une maintenance logicielle régulière. Il s'agit là d'un contexte de développement plutôt ciblé "grands compte", et non petites PME ou PMI, ou de l'interne...

Comment appliquer cette méthode quand on est seul développeur, que l'on doit effectuer de la semi-administration serveur, et faire de la hotline, former les utilisateurs finaux et que vous devez répondre à des besoins informatiques quasi quotidiens ?

Même si un développement méthodique permet au final de gagner du temps (pas toujours sûr) et de l'argent, il faut avoir les moyens d'en dépenser beaucoup avant je suppose.

En passant, petite question : Ceux qui utilisent les formalismes, peuvent-ils nous donner leur secteur d'activité professionnel, et s'ils travaillent seuls ou en équipe sur leurs projets ?

Dali peignait après avoir effectué ses tracés au crayon. Picasso se lançait directement au pinceau. Et pourtant, c'est 2 fabuleux artistes...

Je travaille pour une SSII d'une dizaine de personnes, généralement chez des grands comptes, dans les domaines des télécom, de l'imagerie médicale, et de l'industrie.
Il m'est arrivé de travailler seul ou à deux sur des projets petits ou moyens (quelques mois), et sur de gros projets de plusieurs centaines de personnes réparties dans 3 pays.
Comme je le disais, sur les projets individuels, le formalisme peut être minimal (il faut quand même penser que l'on peut tomber malade par exemple, ou démissionner) et doit permettre à quelqu'un de comprendre rapidement les grandes lignes du projet. (je parle en connaissance de cause, ayant déjà repris un projet sans aucune doc...)
Sur les projets plus importants, le formalisme est plus important, évidemment.

[2Eurocents]

Dali peignait après avoir effectué ses tracés au crayon. Picasso se lançait directement au pinceau. Et pourtant, c'est 2 fabuleux artistes...

Dans ce domaine, une anecdote - attribuée à Rembrandt mais ça demande à être vérifié - ou plutôt une belle histoire :
Le peintre reçu, un jour, un bourgeois de la ville qui lui demanda à peindre le portrait de sa fille.
Le peintre accepta, fixa un prix prohibitif à la commande - que le bourgeois accepta - et fixa un rendez-vous six mois plus tard.
Le commanditaire n'entendit plus parler du peintre jusqu'au rendez-vous ...
Le jour dit, le peintre arriva chez le bourgeois avec chevalet, toile et peinture, convoqua le modèle et en peint le portrait en une journée.
Au moment du paiement, le bourgeois, satisfait du portrait, mais vexé que sa réalisation en soit si rapide, refusa de payer le tarif convenu. Il estimait qu'une journée de travail, fusse d'un artiste, ne valait pas ce prix.
Le peintre le traîna alors jusqu'à son atelier, lequel était jonché d'esquisses, de croquis de la fille pris "au naturel", d'études de drapés, de lumières, etc.
Le commanditaire comprit alors que l'oeuvre qu'il avait vu naître en une journée n'était que l'accomplissement d'un travail excessivement important et totalement invisible à ses yeux.

Je respecte celui qui peut pratiquer la "programmation spontanée" à la manière de ce peintre : se jeter sur le code et le "cracher", valide du premier coup parce qu'étudié auparavant dans les moindres détails, pratiqué, éprouvé de nombreuses fois au préalable, etc. Le codage n'est alors pas si spontané car le développeur a appliqué un ensemble de méthodes, de canevas, voire de "design patterns" dont il a la parfaite maîtrise.

Celui-ci, en général, est aussi capable de réaliser, a posteriori, les documents et formalismes nécessaires à une reprise du code par un tiers ou à une date ultérieure.

Par contre, celui qui pratique la "programmation spontanée" en n'ayant pas d'idée préconçue, pas de plan d'attaque, pas d'expérience préalable du domaine, va - à mon avis - droit dans le mur sur le long terme.

Celui-là construira des programmes dont on peut douter des possibilités d'évolution, d'intégration et de maintenance. La vision d'ensemble qu'il aura de son programme sera un patchwork de résolutions individuelles de petits problèmes rencontrés au fûr et à mesure du codage.


Finalement, on en vient à opposer deux approches du codage :

• Le "top-down", qui consiste à prendre le problème dans son ensemble et à le décomposer jusqu'à obtenir les éléments atomiques que l'on codera.
• Le "bottom-up" qui consiste à construire l'application pièce par pièce, en les codant "spontanément" l'une après l'autre.

Ces deux approches sont aussi opposées en conception (au sens "mécanique", "bureau d'études") et même si chacune peut avoir ponctuellement des avantages par rapport à l'autre, cela reste une querelle sans fin.

[yann2]

Bonjour

Dans ce thread, on retrouve souvent : "Je suis le seul dév, je n'ai pas besoin d'utiliser les formalismes et tout coucher sur papier."

Prions pour que le client ne redonne pas l'application, pour une évolution ou une migration, à un autre informaticien...

[zecreator]

... on a tendance à voir le client comme quelqu'un de totalement ignorant des techniques informatiques, une personne obscure qui ne peut qu'être satisfait que d'un travail pro, clean, et réadaptable à n'importe quel moment.

Faut arrêter de balader cette image que je trouve très négative. Je bosses avec des clients depuis pas mal d'années et j'ai toujours eu un très bon contact avec eux. Actuellement je développes un série de produits (et tout seul en plus) pour le compte d'un client travaillant en international(Amérique du nord, brésil, espagne, allemagne...), et c'est il à l'écoute des contraintes techniques, de temps et de moyens.

Avoir une bonne relation avec ses clients, se faire confiance et se comprendre mutuellement me semble être très bon pour l'élaboration de projets solides.

[zooro]

... on a tendance à voir le client comme quelqu'un de totalement ignorant des techniques informatiques, une personne obscure qui ne peut qu'être satisfait que d'un travail pro, clean, et réadaptable à n'importe quel moment.

En même temps, quand il te paie 500 euros par jour (voire plus) pendant plusieurs mois, il est en droit d'attendre un travail pro, clean et réadaptable...
Enfin, c'est mon avis et je le partage !

[jfdeterme]

Perso, à mes débuts, je programmais de manière spontanée mais dès que l'algorithme devient plus complexe, je fait alors un schéma global de mon algorithme.
De plus, si on travaille en équipe, il vaut mieux planifier les structures clés du programme afin de répartir au mieux les taches et pour que chaque développeur sache ce qu'il a à faire.

C'est ce que je pense en tout cas.

[zecreator]

Pour ma part, je suis absolument d'accord pour avoir une bonne organisation des tâches et un bon suivi des développements en travail d'équipe.

Mais je ne peux m'empêcher de penser que l'on a une droit intellectuel sur nos tâches, et qu'il est tout à fait légitime de ne pas vouloir divulguer tous nos "trucs".

De plus, le contexte actuel dans l'informatique laisse parfois le développeur amère, surtout quand on lui demande un profil "étendu" et qu'il n'est pas toujours rémunéré en conséquence.

Donc, faire de la programmation spontanée permet aussi de pouvoir "protéger" son travail de la réutilisation abusive, et d'espérer créer un besoin de ses compétences.

[zooro]

Donc, faire de la programmation spontanée permet aussi de pouvoir "protéger" son travail de la réutilisation abusive, et d'espérer créer un besoin de ses compétences.

Eh bien, si le projet est assez réduit pour que tu puisses ne pas utiliser de documents papier (j'inclus là dedans les notes, les gribouillis devant la machine à café et tout ça), il sera sans doute simple à reproduire par une autre personne. Et donc il est inutile de le protéger.

Dans le cas contraire, si le projet est plus "grand" (il y a un autre débat en cours pour savoir ce qu'est un grand projet), l'absence de documentation risque de mettre le projet en péril. Et donc ce ne sera pas ton dév que tu devras protéger mais ton job

Bref, dans tous les cas, une doc, même minimale, est utile.

[zecreator]

Eh bien, si le projet est assez réduit pour que tu puisses ne pas utiliser de documents papier (j'inclus là dedans les notes, les gribouillis devant la machine à café et tout ça), il sera sans doute simple à reproduire par une autre personne. Et donc il est inutile de le protéger.

Dans le cas contraire, si le projet est plus "grand" (il y a un autre débat en cours pour savoir ce qu'est un grand projet), l'absence de documentation risque de mettre le projet en péril. Et donc ce ne sera pas ton dév que tu devras protéger mais ton job

Bref, dans tous les cas, une doc, même minimale, est utile.

Je suis d'accord avec la dernière partie, j'ai toujours documenté un minimum mes applications, ne serait-ce pour moi lorsque je reviens dessus après 2 mois sans y avoir touché.

Maintenant, grand ou petit, tu amènes obligatoirement ta créativité et ta reflexion personnelle à un projet, et c'est cela qu'il faut protéger je pense.

J'ai fais l'amère expérience dans mon ancienne boite, où j'avais passé 3 mois (sur mes heures libres hein) à bosser sur un générateur de cours online. Tout le monde était ravi d'avoir cet outil, et lorsque que je suis parti pour de nouveaux horizons, j'ai voulu négocier un droit d'exploitation de mon outil.

Ben je te le donne en mille, ils ont gardé le produit, et m'ont rien donné du tout car ils estimaient que mon salaire avait payé ce produit et que de toute façon, le concept du produit ne me serait pas venu si je n'avais pas été embauché chez eux.

Je ne sais pas si cette méthode de récupération est monnaie courante dans l'informatique, mais aujourd'hui je préserve mon travail, je commente mon code bien sûr, mais je ne laisse plus traîner mes écris.

[kisitomomotene]

Voici ce que je crois, et qui est la solution la plus optimale.

je me place du point de vue des developpeurs. J'ai une idée pour resoudre un problème. Je l'exprime d'abord en langage naturel, en UML, en langage de programmation? Si je peux l'exprimer directement de façon claire et comprehensible avec eventuellement des commentaires (je rappele que même les commentaires sont des exceptions..) dans le langage de programmation, alors je le fais directement. Contrairement à ce que quelqu'un avait retorqué dans un de mes précédents posts, s'exprimer simplement dans un langage de programmation, ne signifie pas qu'on est entrain de traiter des problèmes triviaux. Tout dépend des capacités du programmeur à structurer simplement des chose compliquées et de la maitrise qu'il a sur son langage. Faisant ainsi, on simplifie plutôt la maintenance, car on n'aura pas à naviguer entre plusieurs documents pour comprendre une application.
En fait le point de départ pour comprendre le fonctionnement d'une application doit être son code source. C'est à partir de celui si, qu'on devrait avoir éventuellement des renvois vers d'autre documents, si le code source et ses commentaires ne suffisent pas à exprimer SIMPLEMENT ce qu'on l'on fait.
Concernant UML j'ai de plus en plus de doute sur sa nécessité. De toute les façons si quelqu'un tient tellement à UML, il existe beaucoup de solutions de reverse ingenierie. D'autre part, je me voie mal donner un document en UML à un client ( il ne va rien comprendre, c pas son langage). Donc d'après moi UML doit être l'exception extrème ( si le langage de programmation, et le langage naturel sont inadaptés pour une expression simple, je peux jetter un coup d'oeil vers UML)

[zooro]

Voici ce que je crois, et qui est la solution la plus optimale.

je me place du point de vue des developpeurs. J'ai une idée pour resoudre un problème. Je l'exprime d'abord en langage naturel, en UML, en langage de programmation? Si je peux l'exprimer directement de façon claire et comprehensible avec eventuellement des commentaires (je rappele que même les commentaires sont des exceptions..) dans le langage de programmation, alors je le fais directement.

Pas d'accord du tout ! Les commentaires doivent être la règle. Ne serait-ce que par courtoisie pour celui qui reliera ton code dans quelques semaines/mois/années. Après, évidemment, il ne faut pas commenter n'importe comment non plus.
Les commentaires du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int a; // déclaration de la variable a

sont totalement inutiles et même stupides !

Contrairement à ce que quelqu'un avait retorqué dans un de mes précédents posts, s'exprimer simplement dans un langage de programmation, ne signifie pas qu'on est entrain de traiter des problèmes triviaux. Tout dépend des capacités du programmeur à structurer simplement des chose compliquées et de la maitrise qu'il a sur son langage. Faisant ainsi, on simplifie plutôt la maintenance, car on n'aura pas à naviguer entre plusieurs documents pour comprendre une application.

On est d'accord. Si ton code est propre et lisible, tu maîtrises ton sujet. Enfin, pour un professionnel, on s'y attend un peu...
Celà n'empêche pas de faire une doc explicative (un simple schéma décrivant la structure du soft peut parfois être suffisant). Encore une fois, et comme pour les commentaires, il ne faut pas faire des docs pour le plaisir d'en faire. Il faut qu'elles soient utiles.

En fait le point de départ pour comprendre le fonctionnement d'une application doit être son code source. C'est à partir de celui si, qu'on devrait avoir éventuellement des renvois vers d'autre documents, si le code source et ses commentaires ne suffisent pas à exprimer SIMPLEMENT ce qu'on l'on fait.
Concernant UML j'ai de plus en plus de doute sur sa nécessité. De toute les façons si quelqu'un tient tellement à UML, il existe beaucoup de solutions de reverse ingenierie.

Hum... Toi tu n'as pas du avoir l'occasion encore de travailler sur un soft de 1.300.000 lignes de code (je ne compte pas les lignes blanches et les commentaires), écrites par des non francophones... Même avec les docs, comprendre ce que fait un bout de code est difficile. Alors imagine si on devait se contenter du code !!! Et je ne te parle même pas du soft en entier !

D'autre part, je me voie mal donner un document en UML à un client ( il ne va rien comprendre, c pas son langage). Donc d'après moi UML doit être l'exception extrème ( si le langage de programmation, et le langage naturel sont inadaptés pour une expression simple, je peux jetter un coup d'oeil vers UML)

C'est pas le but d'UML. L'objectif est d'avoir un langage commun avec les autres informaticiens (et relativement compréhensible également par un non informaticien) pour pourvoir discuter et expliquer l'architecture statique et dynamique d'un logiciel et de ses composants.

Bon, après, chacun est libre d'avoir un avis différent du mien.

[Nip]

Il serait peut etre utile que certains relisent les 3-4 pages qui precedent leur intervention

Concernant UML j'ai de plus en plus de doute sur sa nécessité.

C'est bien que tu ais des doutes ...c'est bien, ca te forcera peut etre a te renseigner un peu plus avant de parler et de dire

je me voie mal donner un document en UML à un client ( il ne va rien comprendre, c pas son langage)

T'es serieux quand tu dis ca? je demande juste au cas ou. Le seul diagramme UML que le client est amene a eventuellement connaitre est celui de cas d'utilisation (celui avec les petits bonhommes et les bulles) et c'est tout: le DC ou les DSS ou autres sont la pour la technique, pas pour faire mumuse. Le but premier de UML n'est pas de discuter avec le client mais, comme l'a dit zooro, de permettre une meilleure communication entre les developpeurs.

De toute les façons si quelqu'un tient tellement à UML, il existe beaucoup de solutions de reverse ingenierie.

Ben voila on peut faire la conception apres le code, puisque la phase de conception ne sert a rien, tout est logique jusque la, j'arrive a suivre...

Voici ce que je crois, et qui est la solution la plus optimale.

J'adore!! Ca resume bien ces 18 pages de discussion, vraiment merci pour ton intervention et de nous remettre tous dans le droit chemin.

Tout dépend des capacités du programmeur

Tiens la premiere affirmation avec laquelle je suis d'accord.

Le gros probleme dans ton discours, kisitomomotene. c'est que les exemples que tu donnes se situent au niveau de l'implementation technique, et la UML ne peut en rien resoudre les problemes (la modelisation d'algo est par ailleurs, exceptionnelle); de plus le "quelqu'un avait retorqué dans un de mes précédents posts" est Hephaistos007 et le post en question ets celui la: http://developpez.net/forums/showpos...postcount=243; profites en pour le relire je crois que tu n'as pas compris ce qu'il expliquait.

Maintenant qu'on connait la verite on va passer aux choses dont on est moins sur ou pour le moins qui sont soumises a discussion:

Pas d'accord du tout ! Les commentaires doivent être la règle. Ne serait-ce que par courtoisie pour celui qui reliera ton code dans quelques semaines/mois/années. Après, évidemment, il ne faut pas commenter n'importe comment non plus.

Il y a pas mal de gens qui remettent ca en question, notamment du cote de l'XP, ypicot en parle sur ce post: http://developpez.net/forums/showthread.php?t=217313, c'est assez interessant de regarder ce qui se dit la dessus.

[kisitomomotene]

T'es serieux quand tu dis ca? je demande juste au cas ou. Le seul diagramme UML que le client est amene a eventuellement connaitre est celui de cas d'utilisation ..

Si ce n'est que les diagrammes des cas d'utilisations qui peuvent permettre de dialoguer avec un client, c'est que je le trouve superflu. Le langage naturel bien structuré est suffisant, de toutes les façons je ne peux pas dessiner des petits bonhommes pour présenter à un client (je ne c pas si j'aurais le temps pour lui donner une formation sur l'interprétation d'un diagramme des cas d'utilisation, qui n'est pas aussi simple si on utilise des notions comme des points extension, l'héritage etc.)
d'ailleur chui même pas d'acoord avec vous, car je ne vois pas pourquoi un client qui a pu comprendre le diagramme des cas utilisations, aura du mal à comprendre un diagramme d'activité (qui est proche des organigrammes que presque tout le monde connait) ou même d'autre diagramme, il suffit d'utiliser uniquement des objet "metiers" dans ces diagrammes pour qu'un utilisateur qui a de la volonté les comprennent.

. Le but premier de UML n'est pas de discuter avec le client mais, comme l'a dit zooro, de permettre une meilleure communication entre les developpeurs.

Tout faux. S'il faut communiquer entre developpeur un code source qui a été ecrit dans l'objectif d'être bien interpreté aussi bien par la machine que par un lecteur Humain peut suffire largement (et c'est possible même si le code à 1 500 000 lignes). Je trouve que UML est plus utile pour communiquer avec des non informaticiens qui font parti d'un projet.