Tout à fait d'accord avec MadArcher !
J'ai déjà tenté des trucs sans rien préparé et j'ai tout abandonné.
Maintenant quand je développe, j'écris tout, je prépare, je commente !
Tout à fait d'accord avec MadArcher !
J'ai déjà tenté des trucs sans rien préparé et j'ai tout abandonné.
Maintenant quand je développe, j'écris tout, je prépare, je commente !
Mieux vaut rien dire que de se taire !
Je pense que l'exemple de la musique pour la programmation spontanée n'est pas très bien choisi. Il me semble que les échecs et en particulier ce que l'on nomme jouer en aveugle (sans échiquier) me semble plus proche du sens que l'on peut donner à la programmation spontanée. Jouer en aveugle, cela ne s'improvise pas. Il faut beaucoup s'entraîner, beaucoup travailler et ce n'est pas un débutant voire même un joueur moyen qui pourront le faire.
Aussi, ce que je trouve trompeur, c'est le terme de "spontané" comme s'il s'agissait d'une "génération spontanée". A mon sens, il y a beaucoup de travail en amont (ou un code merdique en aval). On retrouve le même schéma sur le génie (qui n'est souvent guère plus qu'un talentueux travailleur forcené et monomaniaque) ou sur l'intuition (dont à tendance à croire qu'elle surgit "spontanément").
On peut aussi prendre l'exemple du mathématicien qui va se passer du papier pour raisonner. Il faut avoir atteint un certain niveau pour être capable de faire des démonstrations de tête, d'explorer différentes branches d'un raisonnement. A cela s'ajoute en plus la mémoire qu'il vaut mieux de ne pas avoir enfumé à coups de vapeur de hash.
Après, lorsqu'on doit rendre des comptes sur son code à une équipe ou à un supérieur, cela n'empêche pas d'avoir des notes plus ou moins succinctes, plus ou moins détaillées, pour expliciter ses schémas de pensée.
Bref, tout ça pour dire qu'il ne faut pas aller plus vite que la musique et qu'improviser, cela ne s'improvise pas.
La pensée sur papier est le meilleur moyen d'obtenir une solution propre et réfléchie. La "programmation spontanée" (terme que je n'avais jamais entendu) ne permet que rarement d'obtenir des résultats concrets et fiables. Il faut alors forcèment revenir sur ce qui a été fait donc perte de temps considérable.
Mais comme l'a dit Dakshinamurti, tout dépend après de la façon dont pense celui qui développe et ses facultés. Il est clair que moi en mathématiques, il me faudra toujours poser sur papier mes idées. Jamais je ne pourrai émettre un raisonnement de tête. En programmation, c'est un peu différent mais je préfère malgré tout prendre les devants et limiter les risques.
Le seul intérêt que je trouve à la comparaison avec la musique, c'est que pour certains (comme moi), la programmation s'est apprise en "autodidacte" comme certains peuvent le faire avec la musique.
Cela fait deux ans que je fais de la programmation de manière professionnelle. Et je peux t'assurer qu'en deux ans je n'aurais jamais penser faire de la programmation spontannée.
Tout d'abord quand tu travailles en équipe, tu veux pouvoir partager ce que tu fais avec les autres, bénéficier de l'expérience de personnes qui sont plus compétente que toi (après tout on apprend beaucoup au contact des autres).
De même au sein d'une entreprise de développement, tu va être amenés à travailler sur des projets différents. Après x années on peut te demander de revenir au premier programme que tu as fait ou tout simplement te poser des questions sur le fonctionnement de certaines parties. Je peux te dire que je préfère me référencer à une doc fonctionnelle (le meilleur des cas serait la doc technique mais malheureusement elle n'est pas toujours à jour) plutôt que de devoir replonger dans le code pour comprendre ce que j'avais voulu faire à l'époque (et pourtant autant te dire que je privilége les commentaires qui sont TRES utiles et que j'ai une bonne mémoire). Les commentaires sont faits pour nous faciliter la vie autant les employer, ce n'est certainement pas une perte de temps.
Toutefois, j'ai quand même eu le temps de pratiquer la programmation spontannée. Cela était lors de mes études à l'unif où les programmes étaient relativement court et dont on se fichait pas mal de leur évolution future.
Avec le temps et l'expérience que j'ai acquise dans les véritables projets informatique (et grâce aux conseils d'autres experts) je me rend compte que la programmation spontannée ne m'a pas toujours permis de choisir la solution la plus efficace mais bien au contraire la première solution qui me passait pas la tête et qui était facilement réalisable (sans me compliquer la vie). Je n'oserais même pas aller revoir mes vieux programmes. Mais bon ça fait quand même partie des expériences de la vie ;-)
En ce qui me concerne, si je peux me permettre,
je suis un programmeur spontané, je pense comme le code est écrit.
je suis aussi un informaticien métier, au sein de mon entreprise, ma fonction m'amène à traiter des volumes d'information.
Ce que je fais, c'est ce que les informaticiens ne veulent ou ne savent pas
faire, quand les équipes dédiées me disent c'est impossible, et que j'ai besoin du traitement j'écris le programme.
Bien évidemment c'est horrible et très laid, mais c'est efficace.
évidemment ce n'est jamais 800 000 lignes de codes.
Ce que je fais c'est ce que les informaticiens ne peuvent pas faire rapidement, quand ils me disent semaine 43, nous n'avons plus de planning, mais on veut bien étudier ton projet en semaine 50, je sais qu'après trois réunions étalées semaine 2, 4, et 6 de l'année suivante,
j'aurais une solution semaine 8, avec un bel environnement d'esai bien
illisible, et un jeu de tests assez nul, alors semaine 43 je prends 3 jours
et je développe un monstre.
évidemment, je ne documente pas, ou si peu, évidemment je n'ai pas de normes et jamais je ne nommerais un champ analyse_effect parceque ca m'amuse de le le nommer anal, et que je n'ai pas envie de frapper un nom aussi long, évidemment je ne recule devant rien et je peux très bien nommer une variable toto, mais MOI j'ai des solutions rapides.
Par contre mes programmes fournissent des résultats vérifiables, et exact,
alors que je découvre tous les jours des erreurs dans les traitements soi_-disant blindés par les méthodes, et le profesionnalisme.
Je ne parle pas des difficilutés de compréhension des informaticiens, j'aime voir passer dans leurs yeux cette lueur de compréhension après
des heures d'explication.(à chacun son métier).
Mais j'aimerais parler de leurs coûts, quand je vois passer un logiciel de
gestion des immos facturé 20 000 euros alors que je pourrais le
développer en une semaine j'en suis malade.
J'adore aussi leurs méthodes, leurs mcd, et leur merise pour un schéma que je mettrais une demie journée à maqueter sous access.
J'aime aussi leur mépris objectif de l'utilisateur, leurs mots de passe redondants, leurs écrans mal foutus et peu ergonomiques, leurs back up qui n'en sont pas, les code en dur dans les programmes.
Elle est pas belle la vie ?
C'est bien l'un des problèmes de ce genre de programmation, le code est inmaintenable, si tu pars de la boite et que ton code doit être modifié tes successeur iront plus vite en repartant de zero.Bien évidemment c'est horrible et très laid, mais c'est efficace.
Moi je pense et je le constate par ma maigre expérience, qu'à chaque fois que quelqu'un fait de la programmation spontanée le code sera inmaintenable, la plus part du temps il comportera des bugs qui auraient put être évités, que le temps qu'il passe à écrire son code et à le débuguer est supérieur au temps de réflexion + le temps de codage.
Seul un programme n'a pas besoin de réfléchir pour écrire du code
Enfin il y a peut être des génies capables de faire ça mais j'en ai jamais vu, la programmation spontanée ça ressemble à construire une maison de façon spontanée, si tu es doué ça ressemblera à une maison mais elle ne sera jamais aussi belle et fiable qu'une maison construite avec des plans.
Bon courage
random, là il s'agit plutôt des problèmes qui proviennent du fait que parfois, les méthodes acquierrent une vie propre.
Si c'est pas objet, c'est pas bon
Si y a pas de mcd, c'est pas bon
...
résultat on se rassure on suivant ces méthodes et on perd de vue à quoi servent ces méthodes. (Et ça m'est arrivé aussi, surtout sur l'objet, y a un tel tapage là-dessus).
un lien qui recense certaines de ces Lois de l'Informatique
http://www.manageability.org/blog/ar...ew_and_if/view
Là il faut changer de programmeurs, pas remettre en cause la conception.
D'ailleurs, tu pourrais en profiter. L'avantage immédiat c'est la suppression de la phase de "mise au point" qui parfois se termine en une refonte architecturale, en gros un recommencement.
Tout le monde s'accorde sur la même chose. C'est d'ailleurs pour cela qu'il existe un anti-pattern[1] --dont j'ai oublié le nom-- qui stipule simplement que la programmation sans analyse préalable amène inévitablement à un mauvais logiciel.
________________________
[1] il s'agit d'un pattern processus évidemment
Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS
Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android
Hello,
je viens apporter mon témoignage en faveur de la programmation NON spontannée qui ne devrait exister que pour les petits projets personnels.
J'ai déjà fait de la programmation spontannée, à l'université dans les projets personnels. Là les projets étaient petits, nous savions dès le départ qu'ils ne devraient pas être continués, ni maintenu, et que la taille du projet permettait une telle méthode.
Cependant au fur des années d'étude les projets sont devenus plus compliqués, les algorithmes à trouver demandaient une certaine réflexion et donc l'aide d'un crayon et d'un papier et des analyses préalables. Ceux qui affirment pouvoir tout coder directement sans analyses sont des menteurs prétentieux, car il a été prouvé en sciences cognitives que l'on peut retenir 7 choses simultanément (mémoire immédiate), or il existe certains problèmes qui pour être résolus utilisent plus bien plus de 7 variables. Bien sur pour les petits algorithmes que tout le monde connais c'est possible, mais dès qu'il y a un besoin pour des structures ou algorithmes non conventionnels il faut analyser avant de coder pour étudier les propriétés de ces structures et algorithmes. Dès lors pourquoi ne pas noter toutes ces analyses dans un document, et documenter le code pour qu'un autre développeur n'aie pas à refaire tout ce raisonnement ?
La je ne parle que d'un algorithme mais même chose pour toute la gestion d'un projet, faire des analyses et des graphes permet d'avoir une vision globale et synthétique de tout un projet assez rapidement. C'est une manière de bien synchroniser toute une équipe et de bien s'assurer que tout le monde comprend le projet de la même manière. Cela facilite aussi l'intégration d'un nouveau membre dans l'équipe.
Je me demande aussi si les adeptes de la programmation spontannée ont déjà du reprendre dans leur vie ne fusse qu'un seul programme non documenté de plusieurs milliers de lignes ? C'est une horreur ! Car vous affirmez avoir la capacité de comprendre n'importe quel algorithme en le lisant mais si la personne que vous relisez à un esprit tordu et programme plutôt mal ce n'est pas facile de voir ce qu'elle à voulu faire,... Dans ce cas des commentaires sont plutôt appréciables pour comprendre le but de l'autre programmeur et l'on peut alors éventuellement améliorer le code. De plus un algorithme peut coder de la logique provenant de plusieurs disciplines,... Un algorithme peut résoudre des problèmes mathématiques, physiques, économiques,... Vous prétendez peut être être des spécialistes dans tout ces domaines ? Moi pas alors un petit commentaire ne fusse que pour décrire le problème résolu n'est pas de refus.
Pour moi les adeptes de la programmation spontannée n'ont apparement jamais eu à :
- inventer un algorithme non conventionnel autre que ceux qu'ils étudient par coeur dans leurs livres
- travailler dans une grande équipe avec d'autres personnes
- reprendre le travail d'un gros projet implémenté par un adepte de la programmation spontannée
dans le cas contraire ce ne sont que des prétentieux qui cherchent un moyen de se vanter,...
Quand j'ai des idées qui viennent et que j'ai mon PC à porté de main alors oui!
Je suis peut-être une exception parmi vous.
Ou alors je ne suis pas encore assez pro dans la programmation.
Pas mal de bugs que je resoud, c'est la nuit, dans mon lit, en dormant. Je me réveille, je plonge sur mon code qui plante, je l'ai retourné dans tous les sens dans ma tête pendant toute la nuit en me réveillant je sais ou ça va pas...
Il y a des périodes ou je passe en Hard-core-codeur et je code comme un fou, rien ne peux m'arrêter, la fatigue, la faim, rien... Je ne fais que de coder, coder...
C'est spontané dans le sens ou ce que je veux tapper est dans ma tête et que mes mains n'arrivent pas le coller sur l'écran aussi vite que j'arrive à le penser...
Première grosse démo en construction :
http://bitbucket.org/rafy/exo2/
Attention quand même à pas virer geek autisteEnvoyé par Rafy
Nas'
Je suis d'accord avec la majorité, un programme ne doit pas etre entiérement fait de manière spontané. On doit commencer par en faire la structure, établir un cahier des cahiers des charges, se documenter sur les spécificités du type de programme qu'on va faire, ...
Mais par contre, je trouve que des que tout est défini, on peut se permettre un peu de spontanéité sur telle ou telle fonction, bon bien sur, par faire 1000 lignes de codes de suite de facon spontanée...
Donc je pense qu'on ne devrait etre spontané qu'apres avoir structuré
hum hum, as-tu déjà bossé sur un projet de TMA (correction bug des autres ) ... Et bien je peux te dire que quand tu passes (peut importe le langage) derriére quelqu'un d'autre qui a SA façon de programmer et SA façon de penser et bien tu es bien content qu'il y est des commentaires dignes de ce nomEnvoyé par Doloop
Je pense que des bonnes bases pour TOUT projet c'est :
- une bonne modélisation,
- des régles strictes (pour les commentaires, les structures, ...)
- le respect des régles du langage
- ...
j'en oublie mais sans tout ça, aussi si tu es tout seul qu'à plusieurs, le jour ou il faut reprendre le projet, laisse tomber
Perso, quand je reviens à la structure des premiers sites web que j'ai fait mon dieu, j'ai honte d'avoir fait un "truc" aussi mal fait
Enfin aprés ... Chacun son expérience et j'espére que tu en aura bientot une qui te prouvera que le respect du cycle du projet est très important...
(\ _ /)
(='.'=)
(")-(")
Bonjour à tous,
Pour moi, programmer est comme de la poésie, ça vient comme
ça peut repartir...
En même temps ça reste un loisir chez moi
effectivement, dans cas là, tu peux te le permettre mais ... même pour du perso, quand on reprend un site ou du code quelques mois voir années après ... bon courageEnvoyé par ArHacKnIdE
Mais c'est vrai que tant que tu n'as pas été confronté au soucis et surtout à l'expérience des autres, pas facile de bien structurer ça tout seul :o
(\ _ /)
(='.'=)
(")-(")
En même temps c'est plus dur d'avoir de la motivation pour
faire un programme/projet seul, car si c'est une initiative perso,
faut avoir le courage qui suit...
Tandis que quand c'est demandé par une autre personne... pour
le boulot par exemple, c'est une réelle motivation !
Personellement je n'arrive pas à me fixer un projet.
Je fais des petits bouts de tout et un peu partout
Un peu d'accord avec toi ArHacKnIdE, mais ca dépend du projet perso... Si c'est un site web pour présenter un projet à ta famille (vacances passées ensemble, naissance, nouvelle maison, ...) si t'es motivé par le projet ca se suit ...
Mais après il faut effectivement en avoir l'utilité car programmer pour programmer ca m'arrive jamais de me lever la nuit car j'ai une "folle" envie de programme
(\ _ /)
(='.'=)
(")-(")
S'il ne doit y avoir qu'une chose humaine qui n'est pas limitée, c'est bien les Mathématiques...Envoyé par cedricgirard
Si seulementEn math on peut avoir la certitude qu'il existe ou non une solution
Pour le reste, je suis d'accord...
Je poste un message pour un ami qui se reconnaitra :
Ne connaissant que le monde industriel de base, et non celui de l'informatique, j'ai pu remarquer d'après mon expérience des cas similaires à ce que vous appelez spontané.
Dans le milieu industriel, nous les appelons tout simplement les bons.
Attention, ces personnes n'ont pas pris la grosse tête, d'ailleurs ils ne savent même pas qu'ils sont bons, pour eux ils sont tout simplement normaux et font les choses naturellement sans se poser plus de questions.
Des bons, il n'y en a pas des tonnes, mais tout au long de ma carrière, j'ai pu en observer quelques-uns, qui valaient le coup d'être en leurs présences.
J'ai pu assister à l'évolution d'un simple coursier donc sans diplôme (contrairement à ceux de maintenant), qui à gravi les échelons professionnels que beaucoup enivrait sûrement.
Les ingénieurs de l'entreprise avaient monté un système automatique que vous qualifieriez d'usine à gaz. Le dirigeant lui avait fièrement montré en quoi consistait le travail de son entreprise.
Il y avait des vérins partout et le dirigeant a simplement demandé au coursier ce qu'il en pensait. Il leurs avait simplement demandé pourquoi il n'avait pas simplement mis un plus gros au milieu. Tout le monde en est tombé sur le cul, de ne pas y avoir pensé. D'ailleurs, le coursier n'y connaissait rien. Et encore les ingénieurs de l'époque étaient mieux formés que ceux de maintenant, vous pouvez me croire.
Il a tout appris sur le tas.
Une fois, les ingénieurs avaient essayé de dépanner une chaîne de fabrication durant son absence (avec les plans mis à jour, pas d'excuses), 3 jours arrêtes, trouve pas, obligé d'aller le chercher à la gare (appel au micro) avant qu'il parte en vacance, 5 minutes tournevis à la main c'était réparé, pas besoin de consulter les schémas, il sait ce qu'il fait lui.
Sans un mot, le moindre regard de travers de sa part (même pour de rire) sur le travail de quelqu'un qui le redoute, et le doute s'installe, au point d'enchaîner les clops et d'arriver avec une tête de zombie le lendemain le matin, alors qu'il n'y avait rien.
Et pourtant ce n'était qu'un petit coursier, qui a accédé à tous les postes techniques jusqu'a celui bureau d'étude avant de poursuivre ailleurs.
C'est comme les gosses de 14 ans qui découvrent des comètes non répertoriés avec des télescopes qui ont le même âge. Et dire que les scientifiques avaient calculé toutes les trajectoires de ce qui pouvait percuter la planète sans voir celui-là. Surtout ne leurs en veuillez pas si demain le soleil ne se lève pas.
Il existe des artistes dans tous les domaines, l'informatique et autres domaines ne sont pas exclus.
Tout le monde à une vision différente des choses, même avec une scolarisation identique.
L'état de compréhension varie d'un individu à l'autre, il y en a qui sont plus apte à réfléchir que d'autre, et ça vous comme moi n'y pouvont rien.
Contrairement à beaucoup, je ne crache pas sur ces personnes là, mais plutôt je les admire en regrettant sincèrement de ne pas en faire moi-même parti.
Vous voyez le verre à moitié vide pour eux, alors qu'il est complètement rempli, voir même qu'il déborde d'imagination et d'inspiration.
Moi ça me fait plaisir de voir enfin des têtes qui sortent du lot, et qui sans eux l'informatique serait encore monochrome, dans le meilleur des cas.
Couper les ailes d'une fourmille volante, ne l'empêchera pas de devenir reine.
J'espère vous avoir apporté réflexion, sans oublier d'apprendre à observer autour de vous, peut-être à votre tour d'autres récits vous viendront à l'esprit.
Zeuro_P1 comme beaucoup.
Première grosse démo en construction :
http://bitbucket.org/rafy/exo2/
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