La programmation spontanée, ça me rappelle ce qu'un de mes professeurs appelait la méthode boxeur ; on frappe d'abord, on réfléchit après (mais c'est pas obligé).
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
Discussion :
La programmation spontanée, ça me rappelle ce qu'un de mes professeurs appelait la méthode boxeur ; on frappe d'abord, on réfléchit après (mais c'est pas obligé).
Modérateur Langage SQL
Règles du forum Langage SQL à lire par tous,
N'hésitez pas à consulter les cours SQL
N'oubliez pas le bouton
et pensez aux balises [code]
Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.
Bonjour à tous,
C'est dingue comme un topic peut-être aussi éclatant, et encore, j'ai pas fini de le lire. J'ai loupé quelques pages au milieu mais j'y reviendrais, c'est sur!
Sinon j'aurais voulu ajouter ma contribution, en effet j'ai l'impression qu'il y a une certaine dérive sur la fin.
Galen, ton article est très intéressant mais, pour ce qui est inséré dans ton post, il traite plus de l'écriture spontanée d'un algorithme qui bien entendu se comprend du fait de l'expérience acquise.
Seulement, il me semble que le sujet est l'écriture d'un programme, dans son ensemble, sans aucun support, par la seule force de la "mémoire procédurale".
Même si je ne suis pas un informaticien expérimenté, et que je m'oriente le plus souvent vers une forme de programmation sans trop de support (pour les projets persos).
Je ne peut évidemment pas conseiller à qui que ce soit de travailler de cette manière, elle n'est pas réfléchi, ne laisse aucune trace donc ne permet aucun retour d'expérience,...
C'est tout simplement du bricolage pour se détendre
Je suis heureux d'avoir dis ce que j'avais sur le coeur, et d'avoir alimenter ce magnifique Troll
Dès lors que le projet prend de l'ampleur, developper sans structuer est
impossible et source de beaucoup beaucoup de problèmes par la suite.
C'est valable pour tout type de projet.
Si tu dois raconter une histoire de 5 minutes a quelqu'un, tu va te lancer tout de suite et ce n'est pas grave si tu dois corriger par la suite une chose où tu t'es trompé au début.
Mais si tu veux écrire un roman, tu va commencer par structurer tes idées, ecrire une trame grossière que tu va préciser au fur et à mesure...
Sinon bonjour les incohérences !
C'est aussi valable dans le développement avec encore d'autres plein d'autres raisons :
Structurer permet de découper le travail et donc d'y affecter plusieurs personnes.
Cela permet aussi de ne pas s'apercevoir que tout un module qui a pris un mois de developpement devient inutile ou incompatible avec une autre partie de l'application.
Quand tu developpes à la "one-again" pour un tout petit projet, tu peux te permettre de recommencer toute une partie de ton programme si tu t'aperçois que tu as fait le mauvais choix (même si la fois suivantes tu reflechis plus longtemps avant de coder) mais sur un gros projet tu ne peux pas te permettre de perdre un mois de travail.
La méthode spontanée est, à mon humble avis, uniquement valable quand on met en oeuvre des procédés fréquemment utilisés et donc maitrisés par le développeur.
Dans les autres cas, une analyse du problème est essentielle afin de bien cerner chaque étape du processus de développement et permettre une maintenance du programme aisée pour ceux qui suivront.
Avec la méthode spontanée on arrive vite a un code que seul le codeur peut comprendre (et encore...).
Mais il est vrai que ce type de prog est assez utilisé, moi-même je programme de façon spontanée sur les projets perso...
pas forcément: dans une vie antérieure mon équipe a été amenée à réaliser une application pour laquelle:Envoyé par Commodore_Psykopate
- personne ne comprenait bien le problème
- il n'y avait aucune expérience connue (à notre connaissance)
on a passé un temps très important à faire des petites maquettes spontanées sur ce qui nous semblait être des éléments ponctuels et critiques. Petit à petit des stratégies se sont dégagées et les allez-retours entre les petits programmes ciblés et l'architecture d'ensemble se sont affinés.
à la fin on a tout réécrit presque à zéro à la lumière de l'expérience accumulée.
Bien que chaque point ait été bien documenté je ne peux pas dire que le projet ait suivi un trajet classique d'analyse conception. L'intuition a joué un rôle important.
maintenant le résultat: sur un projet sans planning, sans suivi prévisionnel notre "sponsor" s'est fait un tas de blé + j'ai revu un gros client 8 ans après "alors ça tourne toujours ? " ... "impecc"
ne croyez pas que notre équipe ait été composée de génies par contre les tests ont été féroces dès le début.
moralité: le meilleur bouquin que je connaisse sur la méthode en informatique date de 1832! ce sont les premiers chapitres de "De la Guerre" de Clausewitz!
A lire avant d'avoir toute position dogmatique!
J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
(mon excellentbouquin sur Java : https://eska-publishing.com/fr/livre...822407076.html)
Un passe temps aussi, pour certains...
Salut à tous, j'arrive un peu en retard, mais ce que tu dis, Hachesse, n'est pas forcément le cas.
Personnellement, j'ai participé à un projet de fin d'étude en bts informatique qui a duré 5 mois. Certes, nous avons passé pas mal d'heure à réfléchir à 6 sur le cahier des charges. Puis ensuite nous nous sommes mis à programmer après avoir fait toute la partie "analyse".
Toutefois, nous nous sommes heurtés à des problèmes auquels nous n'avions pas prété attention au départ, qui nous ont obligé à changer d'optique et de revoir notre manière de procéder.
Xavier
De toutes les manieres n'importe quel humain doit reflechir avant d'agir dans de bonnes conditions même si avec l'experience la phase "reflechir" devient de plus en plus courte (et heureusement)Tu l'as dit: même rapidement tu te fais un plan d'action. Un cahier des charges allégé, en quelque sorte
Perso je developpe ma premiere appli en c# histoire d'apprendre a manier l'IDE VS C# Express et un peu le langage ... je n'ai fais aucun algo , par contre ca fait quelques jours que je n'ai pas gratté une vrai ligne de code parcque "je reflechis".
J'envisage une maniere de procedé et je la fais tourner dans ma tete pour vois si tous tourne bien rond ... mais a part les IHM et mon petit MCD/Diagramme de classe je n'ai rien mis sur papier niveau algo.
Et je code sur le tas donc... apres avoir pensé... mais c'est surement a ce genre de fonctionnement que faisait reference l'auteur de ce topic.
C'est amusant tous ces avis vachement tranchés sur la question.
Déjà il y a un truc qu'il faut bien comprendre en la matière, c'est que tous les developpeurs n'ont pas le même niveau !!!
C'est d'une banalité à pleurer hein ? Mais c'est pourtant la première chose à comprendre lorsqu'on passe du coté obscur : celui de l'encadrement.
Pour résoudre le même problème il va falloir avec tel développeur faire une longue analyse, tout plannifier, tout expliciter...alors qu'un autre va partir direct en disant "ok, je vois où on va"...et va aller encore plus loin que le premier.
Ensuite il y a la question du temps...Tous ceux qui bossent en SSII savent ce qu'est le manque de temps. Et quand on en manque on sabre inévitablement les phases d'analyse. Dans ces cas là il vaut mieux avoir un vieux très bon développeur à vue longue pour maintenir le projet à flot.
D'une manière générale et en fontion des contraintes (temps, qualité des dev) un projet se compose de phases très plannifiées et d'autres plus "spontanées".
Pour ma part, comme je sais d'expérience qu'on ne développe jamais un soft de la manière dont on l'a conçu au départ, je préfère procéder par affinage successif :
On détermine d'abord les très grandes lignes: on va aller de A à E. On passera sans doute par B, C et D.
Ensuite on revient au clavier et on écrit un squelette d'application qui comporte TOUTES les parties, quasi vides, mais avec les principaux appels. L'important c'est que l'application existe dans son entier le plus vite possible, après on affine.
On refait alors une passe de conception où on tire les conclusions de la premiere passe et où on commence à rentrer dans le détail des sous phases B,C,D...
Et ainsi de suite.
Et je vous garantie que ça marche à merveille.
Pour recoller plus au débat "spontanée ou non" je dirais pour ma part que la conception d'une application n'est jamais "spontanée" alors qu'un algo lui s'ecrit de manière spontanée (sauf cas très compliqués, mais ça concerne <1% de la population)
Le problème principal n'est pas à mes yeux de mettre en oeuvre avec succès (souvent "spontanément") la construction prévue mais bien de réfléchir à la façon de construire de telle façon que si des rajouts ou des modifications doivent ensuite être apportés (que ce soit en raison d'une évolution de l'application ou pour toute autre raison), la chose se fasse avec un minimum de douleur et sans tout avoir à reconstruire ni aboutir à une usine à gaz..
Celà demande beaucoup de réflexion....
Quant à l'algo, il esiste toujours, que ce soit en pensée ou qu'il soit écrit...
Certains sont tout-à-fait capables de garder en mémoire tous les détails du mécanisme de leur pensée.... d'autres ont besoin de "figer" et visualiser la chose sur papier...
Le tout ressemble un peu aux habitudes des joueurs d'échecs.
Je trouve quand même que coder directement et spontanément, c'est un peu comme ... une phase de reconnaissance en terrain inconnu ^^ ce qui n'empeche pas d'élaborer un schéma général du programme dans son ensemble bien sûr.
Mais dans mon cas - je m'en suis rendu compte au fur et à mesure - c'est face à un problème que je maîtrise mal ou que je ne connais pas que j'adopte ce comportement.
Et en général ça aboutit inévitablement à trouver la bonne méthode réutilisable (donc l'algorithme) pour ce problème maîtrisé petit à petit, tout doucement, en se familiarisant avec lui par tâtonnement, par affinage successif de ma méthode. C'est un peu comme un cercle vertueux, le destin de toute méthode spontanée n'est elle pas de devenir à son tour une méthode structurée ?
J'ai toujours à mal concevoir entièrement sur papier des procédés que je ne maîtrise pas bien, j'ai besoin de mettre la main à la patte en quelque sorte pour bien comprendre ce qui se passe et ensuite écrire un algo mieux adapté. C'est ça que signifie pour moi la programmation spontanée.
On fait souvent un parallèle entre programmation et cuisine, eh bien la comparaison tient pour ça également : comment peut-on inventer un plat sans avoir testé plusieurs recettes spontanées ni gouté aucun aliment ?
Alors qu'à l'inverse, pour tout ce que je maîtrise bien, je n'ai aucun souci pour détailler une fois pour toute sur papier ce que je dois faire et comment je dois le faire.
En gros, ce que je voulais dire c'est que la programmation spontanée convient bien aux codeurs qui ont du mal à raisonner de manière abstraite s'ils n'ont pas encore touché "concrètement" à des procédés de programmation. Pour eux, l'algorithme prend limite forme en dernier.
Ben voyons...
C'est peut-être vrai pour toi, mais personnellement, quelque sit l'ampleur du projet je nn'ai absolument aucun mal à passer par l'une ou l'autre méthode...
L'essentiel dans tout développement, c'est :
- il faut que ça marche.
- Que quelqu'un puise reprendre le bébé derrière
Le reste, la méthode "Académique" ou non, on en à AB-SO-LU-MENT rien à cirer !
C'est vrai que plus hau j'ai expliqué ma façon de faire, gentiment, qui n'est pas un modèle pour tous mais qui me convient parfaitement.
La meilleure des méthodes, c'est celle avec laquelle vous arrivez le mieux au résultat voulu, après...
Après affirmer qu'un algorithme est indispensable ce sont des conneries que je laisse aux bien pensants.
Je sens que je faire plaisir là...
Bidouilleuse Delphi
C'est sûr que je parlais de mon expérience, par contre j'ai pas compris comment tu as cité un passage de post dans le lien ^^ on dirait une phrase sorti de son context.
Mais c'est évident que c'est une question d'expérience et de capacités personnelles, voir même de style personnel, après ça dépend du projet et du context.
A ce propos je crois que cet article est très intéressant : http://french.joelonsoftware.com/Art...iveWorlds.html
on est pas obligé d'être d'accord mais ça montre bien qu'il n'y a pas de méthode universelle pour toutes les situations.
Par contre quand tu dis "Après affirmer qu'un algorithme est indispensable ce sont des conneries que je laisse aux bien pensants." tu as tout à fait raison ^^
Pas d'algorithme, pas de programme, pourtant... Maintenant ça veut pas dire "écrire un algorithme en pseudo-code sur un bout de papier d'abord".
Même quand on programme spontanément, on a un algorithme (ça y est le mot est dit) en tête, qu'on s'applique à retranscrire dans un autre langage (C, C++, C#, Java....).
Merci pour cette précision avec laquelle je suis d'accord.
J'aurais du préciser "algorithme posé sur un papier avant de coder".
En tout cas, ce qui est clair, c'est que lorsqu'on conçoit un algorithme, on ne fait ni plus ni moins qu'écrire du code avec son propre "langage de programmation que l'on a inventé tout seul dans sa tête"
En gros, écrire :
n'apporte rien de plus que de coder directement :
Code : Sélectionner tout - Visualiser dans une fenêtre à part TANT QUE blabla FAIRE blablabla
En fait, ça revient à écrire le code deux fois, de façon différente... je vous laisse juge de l'utilité de la chose et du temps perdu.
Code : Sélectionner tout - Visualiser dans une fenêtre à part While blala do blablabla;
Après, pour la relecture du code, pour quelqu'un qui passe derrière, la documentation est indispensable (commentaires, flowchart, description des formats de fichiers, etc...), mais là ça n'a rien à voir avec un quelconque algorithme.
L'algorithme était indispensable au temps des cartes perforées, c'est clair : une erreur de codage et c'était la Cata, juste un caractère manquant et c'était l'horreur.
Mais enfin, depuis l'apparition des éditeurs de codes et les possibilités de debogages et de traçage qui les accompagnes : bof, bof...
A part obtenir une bonne note sur un examen d'info quand vous êtes étudiant... (je vais me faire des copains profs là...)
Après, on ne se lance pas forcément à corp perdu dans du code sans trop savoir où l'on va ni comment on y va, c'est sur... Mais une idée en tête suffit la plupart du temps.
L'autre jour, je suis tombé sur internet sur un code écrit en Fortran et qui était la retranscripton exacte d'un algorithme :
http://www.scp.byu.edu/software/idl/ipolster.pro
C'est un code qui est censé calculer l'inverse d'une projection stéréographique polaire.
Pour les novices en la matière, vous avez des coordonnées latitude et longitude pour un point sur la planète et vous désirez par exemple dessiner le pôle sud sur votre écran : vous projetez ce point sur votre carte en effectuant une projection stéréographique polaire qui vous transforme votre couple latitude/longitude en coordonnées X/Y ou en coordonnées R/Theta (au choix)
Le code ci-dessous permet (enfin, il est censé le faire) d'effectuer la transformation inverse.
C'est un code très sérieux, mis au point par un éminent professeur et est actuellement utilisé pour traiter des données en provenance d'un satellite de la NASA (ERS-1 en l'occurence)
En le décortiquant, vous vous apercevrez que c'est du flan et que ça ne fait rien du tout...
Au lieu de suivre ce processus :
Algorithme --> codage --> je m'en lave les mains
Le type qui a pondu ça aurait mieux fait de suivre celui-là :
Je code en BASIC direct --> je teste --> si ça marche pas j'affine, sinon, je met sur internet et à disposition de la NASA.
Le mieux, c'est quand on voit les coorections apportées :
Heureusement qu'il y a relecture et modification, parce que ce code ne marche toujurs pas...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
J'ai codé ma propre procédure en Delphi, sans algo et je peux vous dire que celà fonctionne à merveille !
Bidouilleuse Delphi
Ton article est très intéressant
Bidouilleuse Delphi
En même temps, je pense pas que... Enfin, peut être au tout début de ce sujet, mais bon, ça c'est évident.... (Ayé, j'ai dit plein de trucs sans rien dire)
En bref, programmer un truc relativement simple d'un point de vue conception, genre une fonction. Parce que cet exemple de la NASA, c'est guère plus qu'une fonction en définitive.
Bon, ben ça, c'est clairement le genre de truc où la phase de "reflexion avant la prog" n'est pas très importante (que ce soit "importante en temps = de longue durée" ou "importante en design").
Faut espérer que les gars de la NASA qui fabriquent des fusées, navettes et autres robots genre mars pathfinder passent un peu plus de temps à concevoir leurs trucs qu'ils n'en passent à griffonner 30 lignes de codes sur une fonction "simple".
Tu vois ce que je veux dire, j'en suis sûr.
Oui, je comprend tout à fait, mais c'est vrai aussi qu'aussi petite soit-elle cette fonction est quand même importante; Et de là à dire qu'ils passent plus de temps pour les robots ou sondes spatiales, pas sur :En même temps, je pense pas que... Enfin, peut être au tout début de ce sujet, mais bon, ça c'est évident.... (Ayé, j'ai dit plein de trucs sans rien dire
En bref, programmer un truc relativement simple d'un point de vue conception, genre une fonction. Parce que cet exemple de la NASA, c'est guère plus qu'une fonction en définitive.
Bon, ben ça, c'est clairement le genre de truc où la phase de "reflexion avant la prog" n'est pas très importante (que ce soit "importante en temps = de longue durée" ou "importante en design").
Faut espérer que les gars de la NASA qui fabriquent des fusées, navettes et autres robots genre mars pathfinder passent un peu plus de temps à concevoir leurs trucs qu'ils n'en passent à griffonner 30 lignes de codes sur une fonction "simple".
Tu vois ce que je veux dire, j'en suis sûr.
Ils ont pas perdus une sonde comme ça en confondant les miles et les kilomètres ?
Bidouilleuse Delphi
lol, je pourrais pas dire, je suis pas trop l'actualité des sondes spatiales.
Sinon, il est évident que la moindre fonction a tout de même son importance, mais ce que je voulais surtout dire c'est qu'il est beaucoup plus aisé de re-programmer une unique fonction que de re-programmer toute une application pour la faire "coller" à un nouveau design totalement différent.
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