Discussion :

[Nip]

"que tu veuilles comprendre ou comprenne"
Après si tu me traites d'imbécile en disant que je comprends rien c'est ton problème!

Loin de moi l'idee de te prendre pour un imbecile, il s'agit juste ici de comprendre de que Hephaistos007 explique, et dans ton cas je ne sais pas si c'est de la mauvaise foi ou pas.

Moi je donnais juste mon avis parce qu'au départ sur ce sujet y'a pas marqué "réservé pour les professionnels qui codent au minimum 1000 lignes de code par petite partie de programme"

La n'est pas la question, chacune de mes parties de programme ne font jamais 1000 lignes (a part quand c'est genere par un outil) , c'etait du programme complet dont je parlais.

Je disais juste que même si tu programmes directement sans faire une analyse de 1h au papier sur chaque petite partie de ton logiciel (comme j'ai montré sur mon message précédent, c'était en aucun cas pour montrer "regardez je suis un génie j'ai tapé 20 lignes de codes") t'es pas forcément un "pisseur de code" comme vous dites

Alors oui tous les developpeurs ecrivent du code sans pour autant passer 1heure a concevoir leur algorithme, mais seulement tout ceci s'inscrit dans une demarche globale: le developpeur sait d'ou il vient et ou il va (tout le contraire de la programmation spontanee) et j'ai l'impression que c'est ca que tu ne saisis pas (et je ne te prends pas pour un imbecile ); Et cette lisibilite, cette vue d'ensemble, comme l'a dit Hephaistos007, tu ne l'as qu'en applicant certains formalismes.

[davcha]

J'ai l'impression qu'il y a un début de confusion entre la "programmation spontanée" et la methode XP.

Programmer spontanément une vingtaine ou quelques centaines de lignes, bref : un petit truc, c'est à la portée de toute personne programmant de manière "naturelle" (J'ai envie de dire "de toute personne ayant un peu de talent", mais j'ai peur de me faire des ennemis ).

En revanche, programmer "spontanément" un gros logiciel, donc sans faire le point aux moments importants du développement, sans faire de plan, sans chercher à regarder plus loin que le bout de son nez, c'est la garantie de faire une bouse infâme qui ne fonctionnera pas.

La programmation spontanée à une grande échelle (= gros logiciels), ça n'existe pas. Dans le cas contraire, après tout, je peux me tromper : citez-moi quelqu'un qui a programmé spontanément (donc tout seul) et avec succès, quelque chose d'aussi conséquent que windows vista.

[LadyWasky]

citez-moi quelqu'un qui a programmé spontanément (donc tout seul) et avec succès, quelque chose d'aussi conséquent que windows vista.

JE SAIS, JE SAIS : Bill Gates !!!! avec MS-DOS

Sinon, Windows n'est pas un modèle de la programmation réfléchie : à tout bien réfléchir, je préfère la programmation "spontanée"

Non sérieux, arrêter de dire que vous êtes capable de pondre un logiciel de 15000 lignes de code (ce qui n'est déjà pas si mal) entièrement sur le papier, ça ne fait vraiment pas sérieux... Vous êtes forcément confrontés à des "obstacles" auquels vous n'aviez pas pensé initialement.

Par contre, un projet de 15000 lignes de code documenté "au fil de l'eau", ça oui, j'ai fait tout seul : tourne depuis 7 ans sans planter, sur un parc hétérogène (de Windows 95 à XP en passant par NT4 et Millenium) avec 8 modules différents répartis sur 3 sites distants dans un rayon 50 km et une 20aine de PC avec SGBDR, communications réseau et serveur intranet...

Ha ça oui, je suis tombé sur des obstacles non prévus, c'est sur, mais le résultat est là : ça marche et les compliments aussi...

Sinon, pour info, XP c'est 9 millions de lignes de code, alors un projet comme Vista, tout seul, tu en as pour une vie (et encore ), il n'y a même pas de comparaison à faire.

L'algorithme, ce qu'il t'apprend, c'est à savoir découper ton problême complexe, en sous-problêmes. Quand tu sais faire, tu t'en passe.
Par contre, rien n'empêche de documenter pour quelqu'un qui reprend la "bête" derrière toi, comme il a été dit plus haut, mais je n'ai pas l'impression que tu ais pris la peine de tout lire....

OUI, on peu documenter et expliquer APRES avoir codé, et ce n'est pas une hérésie...
Ne pas documenter du tout ou mal documenter, là, oui c'est pendable. Et c'est autant l'apanage des développements que certains qualifient de pros (pro en quoi ? parce qu'un illustre bonhomme a dit qu'il fallait faire comme ci et que tout le monde dit Amen comme si c'était l'unique façon valable de faire ?), que des développement spontanés (j'inclue dedans l'extrême programming)

Décidemment, certaines idées préconçues ont vraiment la vie dure...

[Hephaistos007]

JE SAIS, JE SAIS : Bill Gates !!!! avec MS-DOS

MS-DOS n'est qu'une version légèrement modifiée du DOS (racheté par Bill Gates aux alentours de 50000$ à l'époque si mes souvenirs sont bons). Tu le savais j'espère.

OUI, on peu documenter et expliquer APRES avoir codé, et ce n'est pas une hérésie...

Qu'utilises-tu pour documenter et expliquer APRES avoir codé ? (c'est une simple question)

[LadyWasky]

MS-DOS n'est qu'une version légèrement modifiée du DOS (racheté par Bill Gates aux alentours de 50000$ à l'époque si mes souvenirs sont bons). Tu le savais j'espère.

Là, c'était pour rire, tu ne m'a pas pris au sérieux, dit ?

Qu'utilises-tu pour documenter et expliquer APRES avoir codé ? (c'est une simple question)

Word, Excel, des outils de dessin (paint, et un que j'affectionne particulièrement qui s'appelle Grids) pour les outils
et en utilisant toutes mes notes de développement comme base de travail.
J'évite les outils qui font tout automatiquement, je n'aime pas trop le résultat.

Ce que j'essaie de faire dans mon développement, c'est de bien séparer certaines catégories : IHM, Traitements, Fonctions utilitaires, données.
Du coup, au niveau doc, elle sera constituée en 4 parties :
- Des diagramme de flux sur les interaction utilisateur/traitement (Cliquer sur tel bouton, engendre quel traitement)
- Les Traitements spécifiques de l'application : c'est la partie algorithme.
Si le traitement est simple (un tri) je n'expliquerais que la procedure/la fonction effectue un tri (de quel genre : quicksort, tri de shell, par insertion), paramètres en entrées, paramètres ou résultat en sortie.
Si le traitement est complexe, je me fendrais plus d'un bon diagramme pour "visualiser" le code plutot que d'un algorithme en pseudo-français.
- Les fonctions utilitaires seront classées par ordre alphabétique avec diverses informations : que fait la fonction, paramètres en entrée, en sortie, exemple de code d'une dixaine de lignes maxi.
- La structure des données : diagramme UML (si base de donnée il y a), description des champs de chaque table/fichier.

Quand je dit après, c'est clair que je ne m'aventure pas à documenter du code que j'ai écrit 6 mois avant.
Ce que je fais, c'est que, lorsque je développe, je code du Lundi au Jeudi, en prenant des notes sur un carnet, et le Vendredi je documente ce que j'ai fait et je classe soigneusement.

Comme ça, même trois mois après, je peu revenir sur une "étape" de mon développement.

Et lorsque le projet est terminé, il ne me reste plus que la doc utilisateur à faire, la doc de développement étant déjà rédigée et classée...

Le seul moment ou je réfléchi avant de faire, c'est lorsque je modélise la partie structure de données (Base de données, format de fichiers utilisés).

Bref, j'attache tout de même une grande rigueur à la documentation.

Pour les développements perso à la Maison (pour moi même), je suis un vilain canard, je ne documente pas autant.

En tout cas, tu auras sans doute compris, que pour la partie codage, d'abord je code à partir d'une idée, d'un schéma que j'ai "en tête", puis lorsque celà me parait convenable et fonctionnel, je documente. En général, "ça marche" du premier coup. Oh, bien sur, celà m'arrive de faire marche arrière, parce que sur telle ou telle portion de code, j'ai trouvé mieux, ou plus clair, ou plus optimisé, ou les utilisateurs m'ont fait part de leur avis dont je tiens compte : continuer coûte que coûte sur une idée fausse ou un modèle erroné, c'est suicidaire.
C'est ce que je reproche à la méthode, "j'écris d'abord sur le papier, et ce qu'il y a sur le papier, je le développe jusqu'au bout, puis je passe ensuite à l'étape suivante, etc..." : Pour moi, ça s'appelle foncer la tête droit dans le mur, et à l'arrivée ça donne peut-être quelque chose, mais complêtement bancale et inadapté.

A contrario d'autres disciplines (Bâtiment, Aéronautique), en informatique, c'est une réalisation que l'on documente, pas un projet... en toutcas, c'est comme ça que je le vois.

Voilà, voilà...

[davcha]

Non sérieux, arrêter de dire que vous êtes capable de pondre un logiciel de 15000 lignes de code (ce qui n'est déjà pas si mal) entièrement sur le papier, ça ne fait vraiment pas sérieux...

Qui a dit ça ? Je n'ai pas dit que je réalisais tout sur papier d'abord. J'ai dit que je ne me lançais pas dans la phase "pissage de code" sans savoir où j'allais ; c'est très différent.

Ensuite, avec le suivi des produits, au fil des versions, il y a de moins en moins de ces obstacles imprévus dont tu parles. Ce qui est tout à fait normal, dans la mesure où tu sais de mieux en mieux où tu vas.

Par contre, un projet de 15000 lignes de code documenté "au fil de l'eau", ça oui, j'ai fait tout seul : tourne depuis 7 ans sans planter, sur un parc hétérogène (de Windows 95 à XP en passant par NT4 et Millenium) avec 8 modules différents répartis sur 3 sites distants dans un rayon 50 km et une 20aine de PC avec SGBDR, communications réseau et serveur intranet...

Là, tu vois, je suis persuadé qu'on s'est mal compris. Pour tenter de te faire comprendre ce que je disais avant, dis-moi :

tu as codé ces 15000 lignes de code, sans te poser de temps en temps, pour réfléchir à ce que tu avais déjà réalisé, histoire de décider si c'était satisfaisant ou non, notemment pour ce que la suite allait exiger et à ce que tu allais devoir réaliser par la suite, et comment tu allais t'y prendre pour l'intégrer dans l'existant.

ou bien, tu as codé ces 15000 lignes spontanément, sans te poser de questions.

A mon avis, on ne parle pas de la même chose (pas la même définition de ce qui est spontané, faut croire).

L'algorithme, ce qu'il t'apprend, c'est à savoir découper ton problême complexe, en sous-problêmes. Quand tu sais faire, tu t'en passe.

On ne s'en passe jamais à mon avis de l'algorithme. Même quand tu écris directement ton programme ou ton "bout de programme" dans ton IDE préféré, tu produis des algorithmes.
Même quand "tu sais 'faire' ton problème complexe", que tu connais la solution, cette solution est divisée en sous-solutions, chacune répondant à une partie du "problème complexe".

Décidemment, certaines idées préconçues ont vraiment la vie dure...

C'est mûrement réfléchi au contraire.

Comme je le disais plus haut, à mon avis, tout le débat tient au mot "spontané" qui est ici très mal choisi (c'est mon opinion personnelle, hein).

Le dictionnaire va dire quelque chose comme : "Spontané : ce qui se fait naturellement, sans intervention extérieure". Dans notre débat, c'est vraiment pas clair comme définition, donc pas clair non plus comme mot.

En ce qui me concerne la "programmation spontanée" tient au fait de programmer sans suivre de plan préétabli.

Que ce plan préétabli soit écrit dans un cahier des charges de 10000 pages ou ne soit existant que dans l'esprit du programmeur, ça n'a pas d'importance.
Ce qui est important c'est que ce plan soit existant avant que le développeur ne commence à "pisser du code" (rien de péjoratif dans l'expression, c'est uniquement pour exprimer l'idée d'écrire le programme).

Si le programmeur commence à pisser du code, sans avoir de plan préétabli, c'est à dire que ce plan va se construire petit à petit alors que le programmeur pisse du code, alors c'est de la programmation spontanée, oui, ce plan n'ayant plus rien de "préétabli".

C'est sûrement ce qu'Hephaistos007 voulait dire, par ailleurs, quand il parlait de "savoir/ne pas savoir où on est et où on va". (Dis-moi si je me trompes )

Je crois qu'il faut aussi préciser que ce "plan préétabli" n'est pas (forcément) un plan qui va couvrir 100% des problèmes rencontrés. Il y aura une certaine dose d'imprévus suivant la qualité du plan.

Il faut sûrement aussi préciser que suivant les méthodes de travail, ce plan préétabli peut être remit en question, peut changer beaucoup, pendant le développement (exemple : l'XP).

Il peut même être partiel : la prog modulaire c'est très chouette, et si le coeur de l'application est bien réalisé (les clients web c'est vraiment le bonheur pour ça d'ailleurs, même s'ils font 15000 lignes), on peut moins faire attention à ce qu'on fait, on se rapproche donc un peu plus de la "prog spontanée". Ce qui est logique dans la mesure où on découpe le logiciel complet en un ensemble d'outils plus petits. Néanmoins, si on ne fait pas suffisamment attention, si on ne fait pas de plan, quand les outils commencent à intéragir entre eux, on obtient assez facilement une usine à gaz.

[LadyWasky]

Post croisé

Je vois que l'on a pas mal de points communs finalement et que l'on commence a se comprendre (lit bien mon post, juste avant le tien)
La différence entre nos deux façons de faire tiens juste à ceci :
- Tu effectues une analyse avant que tu couches in extenso (idée globale qui conduit au résultat comprise) sur le papier, alors que de mon coté pour la partie code de cette analyse, j'en réalise une maquette dans mon IDE. Effectivement, je ne pars pas dans le codage sans idées...
D'ailleurs, je ne pense pas si, sans idée de comment faire quelque chose, on puisse le faire... et là on est complêtement d'accord.
- l'analyse du code et de l'idée qui y a conduit, je la fais "à posteriori", pour le reste, nos méthodes sont assez similaires finalement

La documentation dont je pars avant de me lancer, c'est l'expression des besoins, le cahier des charges, le résultat souhaité par les futurs utilisateurs... mais ça je ne le catalogue pas dans la partie codage du projet en fait.

Edit : c'est vrai que, du coup, le terme "Spontané" est franchement ambigü.
Définition 1 : sans idée, même floue, de comment on va aboutir au résultat.
Définition 2 : sans avoir pris soin, au préalable, d'avoir écrit un algorithme sur le papier.

La première définition est suicidaire, je me demande même si c'est possible de réaliser quelque chose avec ce genre de spontanéité !
La deuxième, est, avouons le, franchement plus concevable.

[davcha]

Tout à fait d'accord.

Si, personnellement je retiens la première définition, c'est que la seconde est peu convainquante, je trouve.
Pourquoi coucher ses idées précisément sur du papier ? Pourquoi pas dans word, directement dans l'IDE ou encore dans sa mémoire (pour peu qu'on travaille seul et qu'on ait une mémoire d'éléphant ) ?

[zecreator]

... la meilleure méthode de développement n'est t-elle pas celle que l'on maîtrise le mieux. Pourquoi une méthode serait-elle plus efficace qu'une autre, si le résultat et la possibilité de modifier le projet sont là ?

Comme le dit waskol, est-ce parce qu'un homme a décreté que sa méthode était la meilleure qu'il faut l'utiliser ?

Est-ce que dans les petites structures nous donnons du temps aux développeurs de faire des diagrammes UML ? Je ne pense pas.

Productivité et rentabilité sont les méthodes les plus couramment rencontrées. Et aujourd'hui, quand on voit comment son codées les applications dans les SSII, par briques de codes, peut-on encore croire en une méthode puriste de développement ?

UML, schémas, organigramme ne risquent-ils pas de finir par être utilisés comme de "faire-valoir" plus que par des processus utiles ?

Je développe spontanément, à la demande, on me félicite de mon travail et je m'en félicite. Le reste n'est que formattage et prise de tête.

[MicaelFelix]

Bon j'ai pris du retard, là je viens de lire vos nouveaux messages, franchement c'est déjà beaucoup plus constructif!

Non sérieux, arrêter de dire que vous êtes capable de pondre un logiciel de 15000 lignes de code (ce qui n'est déjà pas si mal) entièrement sur le papier, ça ne fait vraiment pas sérieux... Vous êtes forcément confrontés à des "obstacles" auquels vous n'aviez pas pensé initialement.

Je suis du même avis... parce que sinon c'est des génies !

Qui a dit ça ? Je n'ai pas dit que je réalisais tout sur papier d'abord. J'ai dit que je ne me lançais pas dans la phase "pissage de code" sans savoir où j'allais ; c'est très différent.

Ça c'est clair qu'on va pas pondre un code sans savoir ce qu'on va écrire avec ou bien sans savoir quel est le shéma sur lequel on va se placer... là faut revoir la définition de la programmation spontanée. Comme on le comprends dans le premier message à mon avis, c'est que la grande partie de l'idée à implémenter doit être dans la tête du programmeur (ou sur du papier, mais franchement c'est la tête qui compte le plus, surtout dans le cas du programmeur).
Qui peut programmer sans savoir ce qu'il va faire? D'ailleurs à quoi ça servirait de programmer si on avait pas déjà un but précis en tête.
C'est pour ça que j'ai réagit quand on voit qu'on interprête programmation spontanée avec "pisseur de code", parce que pour moi si tu programmes tu sais forcément où tu vas! La programmation spontanée dans la définition que j'utilise c'est plutôt pour dire que l'idée de base est là, mais que tu vois progressivement d'autres détails qui se forment d'eux même (exemple: comment procéder pour faire telle fonction, en combien de parties cela sera fait...), bref pour moi c'est un plan non absolu (c'est à dire pas totalement défini et qui peu s'étendre de toutes parts) mais qui a une idée de base solide sur laquelle on peut travailler sans craindre de modifier trop sa structure (je parle de l'idée de base).

On ne s'en passe jamais à mon avis de l'algorithme. Même quand tu écris directement ton programme ou ton "bout de programme" dans ton IDE préféré, tu produis des algorithmes.

Exact, vu que c'est le fondement de la programmation. C'est pas parce que tu n'as pas les algorithmes sur un bout de papier que tu n'utilises pas d'algorithme.

Que ce plan préétabli soit écrit dans un cahier des charges de 10000 pages ou ne soit existant que dans l'esprit du programmeur, ça n'a pas d'importance.
Ce qui est important c'est que ce plan soit existant avant que le développeur ne commence à "pisser du code" (rien de péjoratif dans l'expression, c'est uniquement pour exprimer l'idée d'écrire le programme).

Je suis entièrement d'accord, mais ce plan n'est pas forcément totalement fixé au départ.

Définition 2 : sans avoir pris soin, au préalable, d'avoir écrit un algorithme sur le papier.

A mon avis écrire l'algorithme sur le papier est une idée intéressante vu qu'on peut parfois faire apparaître les faiblesses de notre pensée, mais de toutes façons ça implique que tu l'ai dans la tête aussi, donc ce n'est pour moi pas du tout une nécessité.
Je ne développe pas d'énormes applications donc peut être que ceci te paraîtra faux, mais moi je n'ai pas la nécessité d'écrire un algorithme sur le papier, sauf quand il y a un bug dans ma pensée (bref que je n'arrive pas à implémenter correctement la solution, ou lorsque le programme ne fait pas ce que je veux par exemple). Ça reste très rare.

Voilà ce que je peux en dire

[davcha]

On peut aussi ajouter que le "papier" (en fait les notes concernant le projet, son "plan de réalisation", bref, le cahier des charges ou tout autre moyen de communication) devient vite indispensable dès qu'on travaille en équipe, qu'on travaille sur un projet de taille plus importante et/ou dès qu'on veut faire les choses sérieusement du point de vue temps passé/rémunération.

[zecreator]

D'accord avec toi davcha. La programmation spontanée est généralement utilisée par un développeur travaillant seul sur un projet. Il est évident que ce type de programmation, en équipe, manquerait de communication.

Un coder seul face à un projet doit adapté son organisation de travail aux délais de production. Donc, les diagrammes UML et tout le toutim, on laisse de coté, trop contraignant en temps...

Pourtant, c'est pas faute d'avoir essayé, mais les 3 boites pour lesquelles j'ai bossées m'ont tout dit la même chose :
"Le client, il se foût du papier, lui il veut voir l'appli tourner. On perd pas du temps avec ça...".

Mais ceci dit, les applis tournent super bien, et ce n'est pas des petits projets, donc, les formalismes ne sont-ils pas un idéal que cherche à atteindre tout développeur se respectant, dans le seul but de paraître un peu plus pro que les autres ?

[Nip]

je ne reviendrais que la dessus, et des que j'ai un peu plus de temps j'essaierai de commenter le reste, dont une partie me fait herisser les poils .

Un coder seul face à un projet doit adapté son organisation de travail aux délais de production. Donc, les diagrammes UML et tout le toutim, on laisse de coté, trop contraignant en temps...

Voila le discours de quelqu'un qui n'a jamais utilise UML ...ou mal. UML n'est pas une methode (donc n'impose pas de reelle contrainte), mais s'integre dans une methode de developpement: en gros tu prends ce dont tu as besoin et tu jettes le reste et ce dont tu as besoin ce sont principalement (mais tu peux en ajouter selon les cas) les diagrammes de cas d'utilisation, diagramme ideal pour presenter les fonctions de ton logiciel au client et lui faire comprendre comment tout va marcher, et de classe; le diagramme de classe est indispensable a mon sens pour garder une vision globale de ton appli, des que tu commences a avoir quelques 10aines de classes ca peut vite devenir un foutoir pas possible, tu gardes avec ce type de diagramme un oeil sur ce que doit etre ton appli. Tout ca ne prend pas bcp de temps, te permet de reflechir au fonctionnalites de ton logiciel, d'en discuter avec le client et surtout surtout, de limiter (dans une certaine mesure) les erreurs de design: quand toute ton appli est modeliser sous forme de classe tu vois comment chaque classe interagit l'une avec l'autre, ca te permet de mieux apprehender le ou les problemes.

Pourtant, c'est pas faute d'avoir essayé, mais les 3 boites pour lesquelles j'ai bossées m'ont tout dit la même chose :
"Le client, il se foût du papier, lui il veut voir l'appli tourner. On perd pas du temps avec ça...".

Le client, il aime qu'on ne le prenne pas pour un idiot, que quand il teste son appli (au bout de 18 mois pas avant surtout, parce que les cycles de vie en spirale c'est pour les couillons), ca soit pas pour qu'elle reparte 3 mois en dev pour un truc qu'il avait demande mais qu'il avait mal explique (ben oui c'est toujours la faute du client, le client est un imbecile qui ne comprend rien a notre genie). Mais les bouts de papiers pour lui expliquer comment tout ca va fonctionner, qui t'aurais pris 3 jours a faire pour bien lui exposer les principes, va couter des milliers d'euros, 30 jours de dev supplementaires et le mecontentement du client... tout bonnement genial.

Mais ceci dit, les applis tournent super bien, et ce n'est pas des petits projets, donc, les formalismes ne sont-ils pas un idéal que cherche à atteindre tout développeur se respectant, dans le seul but de paraître un peu plus pro que les autres ?

Ouaaaaaaaaais exactement, a bas les 10aines d'annees de recherche de chercheurs et professionnels qui ne cherchent qu'a se faire mousser: reinventons la roue, on a que ca a faire. Les developpements multicouches, les injections de dependances, RUP, Merise, les TDD (qui sont aussi de la documentation de code par ...du code), j'en passe et des meilleurs, tout ca c'est de la frime et n'assure pas plus d'avoir de bon logiciels, performants evolutifs et maintenables qu'un developpement "au fil de l'eau".
Je suis desole mais ces developpeurs, ces professionnels ne "paraissent" pas plus pros...

[Hephaistos007]

Je partage à 100% les propos de Nip. Mais vous vous en seriez doutez n'est-ce pas ? (PS: vive le forum Conception)

[zecreator]

... je ne remets pas en question les annees de recherche de ces grands hommes qui nous on fournit l'informatique et les processus de developpement d'aujourd'hui.

Pour l'UML, merci de l'info, j'ai cru pendant des annees qu'il s'agissait d'un appareil volant...

Maintenant, pour etre clair sur mes propos, je reconnais l'efficacite de developper avec des formalismes, seulement, il ne faut pas que cela devienne une religion, ou celui qui ne suit pas les regles est un heretique.

Le developpement doit surtout se faire avec passion, et avec la methode que l'on maitrise le mieux.

Pour moi, developper avec tous ces formalismes reste une image d'Epinal. L'ideal du developpement pour des raisons qui semble encore assez diverses selon les cas. Pour ma part, j'ai rarement (mais un peu tout de meme hein ?)eu le temps necessaire ni les moyens de mettre en place de telle formalismes.

Si vous pouviez me dire comment vous faites pour sortir 15 pages de diagramme, 30 pages de cahier des charges, 50 pages de story, 100 pages de cahier technique, et fournir l'appli au bout de 2 mois, je serai ravi

[Nip]

... je ne remets pas en question les annees de recherche de ces grands hommes qui nous on fournit l'informatique et les processus de developpement d'aujourd'hui.

C'est pas vraiment d'eux dont je te parlais mais de ceux qui continuent de travailler a faire evoluer ces concepts et ces methodes, enfin ce n'est pas vraiment le sujet non plus .

Pour l'UML, merci de l'info, j'ai cru pendant des annees qu'il s'agissait d'un appareil volant...

Moi aussi avant de faire de l'info .
Il n'empeche que les remarques du style "houla UML c'est pour se masturber les neurones, c'est beaucoup trop complique, ca sert a rien et puis moi je suis un warrior j'en ai pas besoin, tout me vient comme ca" on le lit et l'entend a longueur de journee; une precision s'imposait.

Maintenant, pour etre clair sur mes propos, je reconnais l'efficacite de developper avec des formalismes, seulement, il ne faut pas que cela devienne une religion, ou celui qui ne suit pas les regles est un heretique.

Comme tu le dis ces formalismes sont tres efficaces, ont fait leurs preuves, mais ne sont pas totalement rigides et peuvent s'adapter a ton projet (la methode agile en est un parfait exemple), d'ailleurs ils evoluent tous pour s'adapter aux nouvelles contraintes (certains disparaissent comme waterfall, d'autres sont en plein essor comme agile). Apres que tu assimiles le mise en pratique de ces methodes a celui d'une religion, soit, avec l'avantage quand meme d'avoir le choix de tres nombreuses religions, de pouvoir passer de l'une a l'autre sans contrainte et de les faire evoluer en l'adaptant a tes besoins, moi je trouve ca pas mal .

Le developpement doit surtout se faire avec passion, et avec la methode que l'on maitrise le mieux.

Euh ben nan ca ce sont des discours de bisounours , sinon tu restes a ton niveau de sortie de bts ou de fac et ca sert plus a rien d'apprendre autre chose puisque ta methode tu la maitrises (2 a 5 ans de formation sur les bancs de l'ecole ca pese), on va aller loin comme ca. Et la passion c'est bien beau, c'est toujours un argument a sortir au client: "j'ai 6 mois de retard, mais c'est 6 mois de passion"; la passion c'est formidable mais c'est pas suffisant, si tu n'ajoutes pas une certaine rigueur de travail (que t'apportent mieux que tout le reste ces fameux formalismes), tu risques d'aller droit dans le mur. Reste qu'il est tout a fait possible de developper passionnement tout en adoptant une methode de dev, je vois pas ou est le souci la dedans, la passion est un moteur c'est ca qui te donne envie d'apprendre (la passion de juste pondre des lignes de code a longueur de journee j'ai du mal a y croire).

Pour moi, developper avec tous ces formalismes reste une image d'Epinal. L'ideal du developpement pour des raisons qui semble encore assez diverses selon les cas. Pour ma part, j'ai rarement (mais un peu tout de meme hein ?)eu le temps necessaire ni les moyens de mettre en place de telle formalismes.

Malheureusement, la est tout le probleme et je suis bien d'accord avec toi; ce ne sont pas des choses qu'on apprend a la Fac en tout cas pas dans le mienne) et c'est en ca aussi que consiste aussi notre travail, s'autoformer et la ou intervient la passion (il en faut quand meme pour voir ca tout seul dans son coin ), l'ideal etant bien evidemment de tomber dans un environnement ayant deja mis en place ces formalismes ou les mettant en place. Mais ce n'est pas facile, en tout cas c'est beaucoup plus difficile que le developpement "spontane", c'est en perpetuelle evolution, mais apres les benefices sont a la hauteur de l'investissement.

Si vous pouviez me dire comment vous faites pour sortir 15 pages de diagramme, 30 pages de cahier des charges, 50 pages de story, 100 pages de cahier technique, et fournir l'appli au bout de 2 mois, je serai ravi

En meme temps si tu penses avoir besoin de tout ca pour une appli que tu developpes en 2 mois c'est que tu n'as absolument pas compris a quoi et comment pouvaient servir ces fameux "formalismes". J'ai bien sur saisi que tu grossissais le trait, mais la c'est legerement exagere dans la mesure ou on parle de cas reels et d'une application quotidienne de ces "formalismes", on est pas dans le domaine de la fantaisie comme cette remarque le fait croire.
Sinon pour ton exemple, j'en ai un tout chaud sous la main puisque je ai aussi fait un developpement en 2 mois en suivant une certaine methode: 4 jours pour la conception et modelisation du logiciel et validation par le client; vu qu'il sait que les delais sont serres, les reponses sont donnees rapidement, les echanges sont clairs et precis et comme c'est 2 mois de dev c'est pas une usine a gaz non plus, la conception n'est pas si dificile que ca: UC, DC et DSS plus une description ecrite de chacun des cas et des fonctionnalites developpees pour que tout le monde soit d'accord: le client visualise les fonctionnalites avant meme que le developpement soit commence...
Et apres tu bosses vite et bien: Outils de mapping O/R pour gagner un max de temps sur la partie rebarbative de l'acces aux donnees, tests unitaires sur les parties critiques (mais pas toutes les parties, on a pas le temps, les delais sont serres), developpement en n-tiers avec, donc, une couche metier (mais tu sais ou tu vas parce que les cas d'utilisation sont ecrits et te donnent les controleurs a developper). Tu appliques un developpement pilote par les risques, histoire de te debarasser des points critiques en premier; premieres fonctionnalites developpees, tu fais une interface fonctionnelle (comme c'est une separation des couches, tu pourras la faire evoluer comme bon te semblera sans toucher au coeur de l'appli) et tu fais valider par le client, y a pas tout mais suffisemment pour qu'il ait une idee generale de la bete. Tout en continuant le developpement, t'as les premiers retours et commentaires et tu t'adaptes, tu repasses la matinee, voire plusieurs avec le client et tu le tiens au courant regulierement (c'est contraignant pour toi mais ca le rassure et ca permet de meiux le comprendre).
La documentation technique, elle, t'es fournie en partie grace aux tests, plus les commentaires et la generation automatique de documents et surtout, surtout grace aux diagrammes (notamment le DC).
Tu assures un suivi des bugs (une appli sans bug, j'en ai encore malheureusement jamais vu) et tout le monde il est content: le client bien sur mais toi aussi puisque si le client revient 6 mois apres pour ajouter des fonctionnalites (il te fait confiance t'as fait un bon boulot ) t'as les diagrammes pour te rememorer en 15 minutes comment le logiciel est concu (plus efficace que de replonger dans des milliers de lignes de code), donner une reponse rapide et zou c'est reparti .
T'as d'autres manieres de faire bien sur .

[Lambrosx]

+1 pour Nip.
Je suis tout à fait d'accord avec ce qu'il dit, et pourtant je ne suis qu'un étudiant.
Toutes les personnes avec qui je parle en général, soulèvent la nécessité d'utiliser des méthodes. Il y a beaucoup de choses qui peuvent parraitre être une perte de temps au départ, je voudrais dire de ca que si on perd quelques minutes pour commencer on les retrouve bien vite après. Modéliser un problème fait partie de ces choses. C'est pour moi une étape utile, surtout sur un système complexe qui évolue tous les jours. Comment savoir ou on en est si des nouvelles informations arrivent tous les jours et qu'aucune modélisation papier est faite. J'ai du mal à croire qu'il soit possible de travailler seulement avec la mémoire. Surtout que dans le cas ou l'on développe à plusieurs, il est important de laisser une base saine de travail à ses collègues. Je suis confronté à ca dans une société puisque je suis en alternance. On est obligé de poser des règles et des méthodes, sinon ca part dans tous les sens.
Modéliser, c'est comme bien organiser son code (on va dire un minimum), ca a beaucoup d'avantage. Quand tu débug, si tu n'as pas fait des fonctions propres que tout est pas bien structuré dans ton code, je suis persuadé qu'on passe beaucoup plus de temps. Pareil pour un logiciel qui contient des centaines de fichiers, on peut pas s'amuser à ouvrir fichier par fichier et lire le code à chaque fois, c'est quand même plus simple de faire une doc (doxygen par exemple)
En tout cas je tiens à remercier ceux qui font des docs complètes, car sans MAN ou MSDN, je ne suis pas sur qu'on arriverait à comprendre toutes les fonctions seulement en lisant le code.

Maintenant faut que tout le monde se retrouve avec sa méthode

[zecreator]

... sortant d'une formation professionelle (dans le cadre d'un CIF) a l'université de Jussieu, constituée essentiellement de développeurs en poste, nous avons tous constaté que l'enseignement universitaire ne tiens aucun compte du marché et des conditions dans lesquels sont produites les applications. Une très bonne théorie certes, mais une mise en pratique sur le marché assez hazardeuse...

Toutes ces méthodes de développement qui pronent la modélisation et le respect des formalisemes devraient commencer par s'adapter au marché réel.

Bon nombre d'étudiants qui viennent faire leur stages chez nous, et qui sortent de ces institutions sont absolument incapables de faire une applications en dehors des frameworks étudiés. Demendez-leur de compiler du code C++ en dehors de Visual Studio, ou du Java en dehors d'Eclipse, c'est la gamelle assurée...

Les formalismes, très bien pour assurer un suivi technique d'applications utilsiant toujours les mêmes technologies, pas bon pour s'approprier une diversité de connaissances techniques...

[2Eurocents]

Toutes ces méthodes de développement qui pronent la modélisation et le respect des formalisemes devraient commencer par s'adapter au marché réel.

Dans certains cas, c'est peut-être aussi un peu au marché réel de s'adapter à ces méthodes ... après tout, ce ne serait pas la première fois que des acteurs économiques se tireraient une balle dans le pied en ayant une myopie stratégique et en négligeant des outils qui, s'ils font perdre du temps à court terme, pérennisent le travail accompli.

Bon nombre d'étudiants qui viennent faire leur stages chez nous, et qui sortent de ces institutions sont absolument incapables de faire une applications en dehors des frameworks étudiés. Demendez-leur de compiler du code C++ en dehors de Visual Studio, ou du Java en dehors d'Eclipse, c'est la gamelle assurée...

Encore un mythe d'entrepreneur ... l'étudiant, stagiaire, qui sait déjà tout faire et qui vient en entreprise pour être efficace et rentable.

Il me semble qu'il faut quand même rappeler qu'un étudiant en stage reste un étudiant, et qu'il est donc là pour apprendre. Il est normal qu'ils n'aient vu que certains aspects de leur formation. Le passage en entreprise est là pour leur donner une autre vue, et confronter leurs apprentissages à la réalité de l'entreprise, justement ... et comme on apprend peu de ce qui se passe bien ...

De façon générale, il faut considérer l'arrivée d'un stagiaire en entreprise comme une baisse de 20% environ de la productivité du personnel qui va l'encadrer. Le gain de productivité lié à la personne supplémentaire ne peut jamais être garanti ... L'accueil d'un stagiaire est donc un pari sur :

1. les capacités du stagiaire à produire immédiatement et efficacement (perle rare !)
2. les capacités du stagiaire à apprendre, s'adapter à l'entreprise et être productif à terme, dans l'optique d'une embauche ultérieure.

Pour être gagné, ce pari doit donc être joué sur le long terme ...

Les formalismes, très bien pour assurer un suivi technique d'applications utilsiant toujours les mêmes technologies, pas bon pour s'approprier une diversité de connaissances techniques...

Est-ce que le formalisme ne peut pas, justement, permettre de mettre en commun ce qu'il y a d'invariant dans cette fameuse diversité de connaissances techniques ? Il peut servir de passerelle, d'une technique à une autre, non ?

Ainsi, pour reprendre l'exemple bateau de l'algorithme, c'est quand même en en ayant une trace que l'on pourra migrer une application d'une plate-forme et d'un langage à un autre.

Se passer de formalismes et de documentations, c'est bruler ses bibliothèques et ses modes d'emploi.

[Nip]

J'ai bien l'impression que j'ai du mal a me faire comprendre, donc en complement des explications de 2Eurocents auxquelles j'adhere totalement:

Toutes ces méthodes de développement qui pronent la modélisation et le respect des formalisemes devraient commencer par s'adapter au marché réel.

Je ne sais pas de quelles methodes de developpement tu parles, mais de toutes les formations que j'ai pu voir (je ne les ai pas toutes vues non plus), je n'en connais pas qui enseigne la methode agile ou XP et leur mise en pratique... Pourquoi? tout simplement parce que ces methodes par exemple sont applicables dans un contexte professionnel et qu'il est tres difficile de l'enseigner assis derriere un bureau.
De plus il ne t'ai jamais venu a l'idee que les formateurs et developpeurs en poste ne savent pas tout, ou peuvent meme avoir tord? Combien sont les professionnels qui frequentent ce forum et qui s'arrachent les cheveux en reprenant du code ou en s'integrant a une equipe de developpement en cours qui ne suit ou n'a suivi aucun formalisme. L'idee que ces formalismes et methodes de developpement ne sont la que pour les universitaires est ridicule, et n'est avancee que par les gens qui n'ont jamais utilise ces methodes.

Bon nombre d'étudiants qui viennent faire leur stages chez nous, et qui sortent de ces institutions sont absolument incapables de faire une applications en dehors des frameworks étudiés. Demendez-leur de compiler du code C++ en dehors de Visual Studio, ou du Java en dehors d'Eclipse, c'est la gamelle assurée...

Je commence a ne plus te suivre la. Quel est le rapport entre l'utilisation d'IDE, qui ne sont que des outils et la plupart du temps ne demandent que quelques heures avant d'etre productif et les formalismes et methodes de developpement?

Les formalismes, très bien pour assurer un suivi technique d'applications utilsiant toujours les mêmes technologies, pas bon pour s'approprier une diversité de connaissances techniques...

Malheureusement je crains que tu n'ais absolument pas compris de quoi nous parlions sur nos precedents echanges. L'interet de ces formalismes c'est justement de pouvoir faire abstraction de ces frameworks de dev, ce ne sont que des outils parfaitement interchangeables: t'es independant de tout langage, de tout IDE, de toute implementation technique.