pointe-le sur quelques discusssions ici-même
Salut à tous.
Voici une anecdote vécue qui illustrera non pas ce qu'est un professionnel (personne ne l'est ni toujours, ni tout à fait), mais une approche professionnelle d'un problème.
Un jour, un réseau électrique à moyenne tension a été déclenché brièvement puis réenclenché, afin de mettre hors service une petite ligne en vue de coupes forestières. Lors du réenclenchement, il a semblé ne rien se produire d'anormal, mais, environ 35 minutes après, une gigantesque explosion s'est produite dans la sous-station. Quand je dis gigantesque, ça veut dire les éclats de porcelaine des isolateurs incrustés dans le crépis des murs, les bobinages du transformateur tordus en tous sens comme si King Kong était passé par là, etc. Alors, le directeur des forces motrices m'a fait venir et m'a dit: "Résolvez-moi ce problème". Comme cahier des charges, c'est assez succinct.
Comment aborder un tel problème ? La première étape a été d'aller en fin de journée dans les divers bistrots de la localité, et de boire des demis avec les ouvriers. Eux ne connaissaient pas la théorie, mais ils avaient peut-être observé des choses importantes. L'ouvrier lambda ne parle pas volontiers de faits anormaux dans le bureau du directeur. Il dit des choses beaucoup plus intéressantes devant un demi. De ces discussions, j'ai déduit qu'il devait s'agir d'un phénomène de ferrorésonance, dont en fait je ne connaissais pas beaucoup plus que le nom, et c'est sur cette base que j'ai pu modéliser le phénomène, le simuler sur ordinateur et proposer les moyens de faire en sorte qu'il ne puisse plus se reproduire à l'avenir.
Tout ça pour vous dire que le développeur doit être "tout-terrain". Les problèmes qu'on lui soumettra viendront de gauche et de droite, et il devra être capable d'improviser en fonction des besoins, d'apprendre de cas en cas ce qu'il ne sait pas encore.
Jean-Marc Blanc
Bonjour,
Pour aller dans ton sens, FR119492, je disais ceci, dans mes mémoires (mon mémoire) concernant ma façon de travailler :
La plupart du temps, pour ne pas dire tout le temps, l'intégration d'un gestionnaire de base dans le petit cercle de conception de l'étude préalable puis du cahier des charges, n'a d'autre objectif que de lui faire accepter plus facilement le logiciel lorsqu'il aura été développé (à lui et aux autres gestionnaires de base), pas de recueillir son avis. Cette démarche "évidente", un chef de projet l'avait exprimée autrefois sans honte dans un dossier "Développement" de 01Hebdo. C'est peut-être bien ce qui se fait toujours.En immersion dans le service de gestion, la majorité des informations et des documents est directement accessible et compréhensible sans qu'il soit nécessaire de mener des interviews. Le chef de service peut s'étonner voire même s'inquiéter d'être si peu sollicité. La réalisation d'un produit (une édition ou un écran) amène d'éventuelles questions qui trouveront leurs réponses directement auprès des interlocuteurs les plus pertinents : l'utilisateur final (le terminaliste), le chef de service.
.../...
Le dialogue développeur/chef de service se situe au même plan que le dialogue développeur/gestionnaires. Face à l'urgence des développements à réaliser, la hiérarchie n'est plus de mise. Le chef de service apporte sa connaissance des règles de gestion, les gestionnaires leur capacité à exercer leur tâche selon ces règles. Car si les chefs de service connaissent la mission de leur service, ils ne s'intéressent pas forcément à la façon dont leur personnel réalise cette mission. Ils ignorent la plupart du temps comment le travail de leur service se réalise concrètement. C'est si vrai qu'ils ne s'intéresseront pas davantage à l'applicatif qu'utiliseront leurs gestionnaires. D'autant moins qu'ils sont naturellement rétifs à l'informatique. Il ne s'agit pas de les en blâmer, c'est un constat, leurs préoccupations se situent ailleurs.
.../...
Concevoir un applicatif avec les seuls chefs de service pour interlocuteurs, c'est se priver d'une masse d'informations très riche susceptible d'orienter de façon pertinente les développements ; c'est créer à coup sûr un outil inadapté, intégrant sans doute les règles de gestion, mais occultant la réalité quotidienne.
La prog spontanée oui sa m'arrive, pour de petit projet perso.
Bon euh ...
Gentil ou Méchant ? ... Aller gentil
C'est pas de la programmation spontané, c'est de la bidouille.
Si un jour t'est développeur dans une entreprise sans changer de discour tu a trois choix :
1/ t'y arrivera jamais car tu va te prendre une claque dans tes études
2/ tu comprendra jamais rien et tu va foirer tout tes projets sans t'en rendre compte.
Aussi je souhaite bon courage a tout ceux qui auront a travailler avec toi
En effet, je vais donc continuer a salement coder ma réponse :
Code : Sélectionner tout - Visualiser dans une fenêtre à part nbChoix--;
Je n'ai pas eu le courage de tout lire.
Je vais donc juste donner mon avis.
Mis à part peut être quelques exceptions, je pense qu'un développeur débutant ne peut pas faire du bon développement en programmant en "live". De même que je ne pense que ça soit une bonne chose dans un travail en équipe avec les méthodes habituelles.
Maintenant, pour un développeur expérimenté qui développe seul, mon avis est plus nuancé. Il m'arrive de développé en "live" en pensant Objet. Je pense que me comprendrons ce qui font de même. Cela signifie juste qu'on raccourcie les étapes. Au lieu de dessiner une classe d'un diagramme, on la crée. On ajoute les méthodes dans la classe à la place du schéma. etc ... Au lieu de prendre une gomme, on fait du refactoring ...
Cela s'approche en soi du développement agile, de l'eXtreme Programming (qui se fait à 2).
A mon avis cette capacité de travailler existe en codant sans passer par la phase d'analyse version papier existe chez tout le monde. Cependant chez la plupart des individus elle n'est pas très développée et les oblige à déléguer une grande partie de la mémorisation de l'analyse à un autre support que leur simple réseau de neurones.
Je m'explique, en réalité ceux qui affirment être capables de faire de la programmation spontanée ne font pas réellement du spontané ou du live comme ils le croient; bien au contraire ils font une analyse du problème et le schématisent même très bien, sauf qu'à l'opposé de monsieur tout le monde ils n'ont nullement besoin d'un support extérieur pour effectuer toutes les tâches de mémorisation et de traitement des données résultant de leur analyse. En quelque sorte ceci disposent de plus de mémoire vive que tout le monde dans leur système CERVEAU
De plus parmi eux ils existe encore d'autres individus capables d'une prouesse encore plus grande qui est celle de pouvoir effectuer la phase d'analyse du problème en un temps très court: le fameux flash décrit par certains intervenants du débat.
Après libre à chacun de croire ce qu'il veux, ils y en à bien qui croient aux prophètes et pas d'autres sans que cela n'empêche le monde tourner rond... quoi que
Au secours Daniel ! Ils ont 20 ans et veulent remettre des colliers aux chiens !Bon euh ...
Gentil ou Méchant ? ... Aller gentil
C'est pas de la programmation spontané, c'est de la bidouille.
Si un jour t'est développeur dans une entreprise sans changer de discour tu a trois choix :
1/ t'y arrivera jamais car tu va te prendre une claque dans tes études
2/ tu comprendra jamais rien et tu va foirer tout tes projets sans t'en rendre compte.
Aussi je souhaite bon courage a tout ceux qui auront a travailler avec toi
Rien à voir avec mon propos ?...
De toute façon, la programmation spontanée, c'est comme la génération spontanée : ça n'existe pas.
doloop lui-même en initiant sa discussion émettait immédiatement cette réserve quant à l'expression qu'il utilisait pour identifier sa façon de développer. Pressentant son imperfection il tenta d'en préciser le contour par cette double définition :... Ce type de programmation porte t'elle un autre nom ?
Sa proposition de définition n'est rien d'autre que celle du dictionnaire. L'adjectif "spontané" laisse entendre qu'il n'y a pas de réflexion ni avant, ni pendant la programmation. C'est sans doute ce qui suscite un tel déchaînement des puristes, qui dure maintenant depuis 4 ans et demie. Si sa "programmation spontanée" n'existe pas, en tout cas elle aura fait crépiter pas mal de claviers.Programmation spontanée : Qui se fait de façon naturelle, sans arrière-pensée / Que l'on fait de soi-même, sans sollicitation extérieure.
J'imagine que doloop qui ne se manifeste plus depuis plus de 4 ans, cherchait simplement à recueillir l'avis, la perception, l'expérience d'autres développeurs ayant la même approche que lui, sans doute pour se rassurer, peut-être pour argumenter davantage sa démarche qu'il avait cependant déjà bien analysée ou pour savoir ce qu'il y avait de l'autre côté du miroir. Vu sous cet angle, tous les membres qui se manifestent hostilement dans cette discussion sont tout simplement hors sujet.
L'expression "programmation spontanée" me gêne également mais je comprends très bien le concept que doloop voulait exprimer. Pour avoir fait le même cheminement et être allé encore plus loin, jusqu'à la conception d'application (l'autre côté du miroir), je parle plutôt de "Développement APL/AML", c'est-à-dire : "Au Pied Levé/A Main Levée". Ça n'existe pas ?... Si, ça existe puisque je l'ai pratiqué pendant 35 ans. Afin de ne pas choquer les âmes sensibles, je relativise mon propos en précisant que je n'ai jamais eu l'opportunité d'informatiser la mise sur orbite géo-stationnaire d'un satellite. Mon domaine s'est limité humblement à l'informatique de gestion de type départemental (je suis obligé de parler au passé maintenant). Mais je me répète...
Dans la vie, chacun cherche son chat, j'ai trouvé le mien, doloop cherche peut-être encore le sien. L'important, c'est de témoigner que l'on peut développer autrement. Ceux que cela dérange ne sont pas obligés de changer leur façon de travailler.
En réalité ce qui m'as dérangé dans ce sujet, n'est pas le thème qui est la programmation spontané, mais la manière de penser un peu hautaine que j'ai vu émerger de lui.
Ce type de programmation existe et je pense que toutes personnes ayant été autodidactes a leurs débuts sont non seulement passé par la, mais ont tendance a toujours continuer comme ça.
Faisant partie de ces gens là j'ai moi aussi pensé que certains de mes programmes était révolutionnaire et je pensais que j'étais surhumain. Avec le temps (je n'ai que 20 ans mais ça c'est hors sujet) j'ai appris que tout ce que je faisais existait déjà, en beaucoup mieux, et que même pire, il existe des concepts très poussé dans le domaine depuis depuis des dizaines d'années.
Au travers de mes études et de mes stages en entreprise j'ai compris ce que c'était véritablement développer, et que programmer comme ça a l'arrache, c''était de la bidouille.
Concevoir des applications permet de mettre a plat tous les problèmes majeure que l'on aura, et avoir une vue d'ensemble que l'on a pas en travaillant tête baissé.
J'ai donc trouvé de sa part agressif de dire de manière détourné : comment ça se fait que vous être obligé de réaliser une phase de conception alors que moi je m'en sort seul, suis-je un surdoué ?
Pour moi tout le monde est capable de concevoir une application a la volé, mais la qualité s'en ressentira très grandement.
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.
Partager