Bien figures toi, que moi ouica m'arrive jamais de me lever la nuit car j'ai une "folle" envie de programme
Bien figures toi, que moi ouica m'arrive jamais de me lever la nuit car j'ai une "folle" envie de programme
Je suis très loin de mon PC ces temps-ci, je n'ai jamias autant eu envie de programmer que en ce moment...Envoyé par nebule
Je me rends compte maintenant que programmer c'est comme un drogue.
Vous faîtes peur là Faut se calmer mais ce que vous décrivez devient de plus en plus fréquent j'ai l'impression c'est pourquoi des psys existent dorénavant pour aider ces gens-là N'hésitez pas à consulter
Nas'
Je suis moi aussi de type spontané.
L'UML et les diagramme de "donnée" ca me parle absolument pas. Si je suis forcé de tracer un diagramme, ou si je travaille sur un projet qui dépasse mon buffer de mémoire au cerveau, alors je dessine un shema des table avec les liaisons, sans plus. Le reste est innutile et ne s'applique pas réellement au développement.
ATTENTION! Il faut savoir tracer la ligne: quand on travaille en équipe, il faut bien entendu penser aux autres.
Quand je programme, je met toujours des commentaires, mais souvent, APRÈS avoir fini le code. J'ai concu quelques projets de moyennes envergure seul. (Je parle de l'ordre de 2000 heures de travail pour le plus gros)
Mais mon code est le plus propre possible, et bien commenté. Mais je ne passe que TRÈS rarement par une phase "papier" avant. Quand je le fait (pour moi-même) il s'agit généralement de représentation graphique de structure de base de donnée afin de voir comment je vais organiser mes informations. Mais pour le coté application : jamais.
Donc en résumer:
- Je ne prépare jamais la structure de mon code
- Je prépare la structure de mes bases de données lorsqu'il m'est impossible de les retenir par coeur dans ma tête ( mon projet de 2000 heures avait 78 tables donc mon cerveau est pas assez puissant. )
- Je commente parceque je n'ai pas une bonne mémoire à long terme et aussi parceque ca rajoute de la couleur dans mon code (c'est pas une blague, ca détend)
- Je garde toujours un code propre car sinon c'est laid.
Je n'ai jamais pris plus d'une heure pour "penser" à comment j'allais débuter un projet.
Comme si la vie ne voulais pas me donner tord, j'ai travaillé en équipe avec un fan des diagrammes en tout genre. Il était doué pour les diagrammes, mais j'ai retappé tout son code parcequ'il était rempli de bug, faille de sécurité et c'était TRÈS peu optimisé. Ce qui m'apporte à dire que ce n'est pas parceque la préparation est bien que le résultat le sera aussi.
Ps.: Ses diagrammes étaient vraiment beaux par contre.
Détails sur moi:
- J'ai 21 ans, j'ai commencé à programmer à 14 ans environ
- Je programme en PHP Mysql
- Je sais comment fonctionne la programmation objet mais je ne l'Applique pas encore (et la je concède que si je l'appliquait, le niveau de préparation augmenterais surement)
- Malgré que le ne programme pas en objet mais codes sont clair et quand mes pages prennent plus de 0.09 secondes à se générer, je me sens mal intérieurement.
- Je ne prétend pas être un génie ou avoir la solution idéale et toujours les meilleures solution, si une meilleure idée m'est proposée, je suis toujours là pour apprendre des autres et m'améliorrer.
^^ Voilà, j'espère que vous serez pas trop méchand ;p
C'est comme les légos.Envoyé par Rafy
C'est con à dire hein ?
En fait, y'a des gens qui sont créatifs, qui ont besoin d'être créatifs.
Il y a quelques années, ça me déprimait d'avoir lézardé pendant 2 heures durant une journée, fallait que je "fabrique" quelque chose tout le temps.
Après un bon pétage de plomb, je me suis quand même rendu compte que c'était sympa aussi de se reposer, de lézarder.
Par contre, programmation spontané... pas spontanée...
En ce qui me concerne, le problème de la prog spontanée est que si on a pas les idées claires ou si on est inconstant, le résultat, même s'il fonctionne sera désastreux.
Autrement dit, c'est pas parce qu'on est capable de programmer sans prendre le temps de réfléchir que le résultat sera suffisamment robuste pour supporter la multitude de modifications, de réglages, etc. qui attendent impatiemment, dans le couloir, d'être implémentés.
En fait, c'est juste une question d'habitude je pense.
Moi j'ai commencé à 5-6 ans (je recopiais des programmes tout nazes sur un TRS-80 )
Moi, je programme comme toi
Sinon :
En fait c'est plutot l'inverse : c'est parce que j'ai sentis/compris l'ensemble du programme que je me passe de l'algorithme : je t'assure que ça vient tout seul...Envoyé par quicky2000
En fait je commence en "structurant" de façon globale mon programme, puis petit à petit je descend dans les détails. En gros je crée mon algorithme avec le langage de programmation que j'utilise.
Celà dit, il m'arrive parfois (c'est rare) d'avoir recours à un petit croquis, ou des prendre des notes sur telle ou telle variable importante. J'ai toujours un bloc note à portée de main.
Ben si, j'y arrive aussi (18000 lignes de code environ, ça m'est déjà arrivé)Envoyé par quicky2000
Celà dit, ça ne m'empêche pas de bien documenter après (procedures, structure des fichiers utilisés, reprise des annotations et croquis sur mon bloc-note, etc...)...
Sinon, je comprends que ça puisse être difficile de comprendre ce que j'ai fait pour ceux qui passent après moi.
Enfin, je suis aussi un accroc du developpement...
La programmation spontanée c'est pour ceux qui ne savent pas que le dévelloppement est un cycle. C'est pour les pisseurs de code quoi !
1) En tout cas je sais que développement ne prend qu'un "l"Envoyé par Hephaistos007
2) Faut pas pisser à coté c'est sur, sinon ça ne fait pas propre après... (je parle de la propreté du code bien sur !)
Excuses moi, ce n'est pas méchant mais c'est vrai que je n'ai pas pu m'en empêcher.
Blague à part : rien n'empêche d'être structuré dans ce style de programmation. Tout comme dans la façon "académique" de le faire, si tu ne suis pas certaines rêgles, tu ne risques pas d'aller bien loin...
En fait, je ne pense pas que le problême soit la façon de faire, de programmer, de développer mais plutôt un problême de rigueur dans le style que tu choisis.
J'ai vu des projets abominablement codés et documentés aussi bien chez les "pisseurs de code" (on est d'accord là dessus), que chez les (appelons les comme ça) "Académiques" (si, si je vous le jure, livré à la DGAC par une boite très connue - j'ai peur de facher en donnant le nom de l'entreprise... ne m'en voulez pas si vous travaillez chez eux : GFI), ou à contrario des codes magnifiquement documentés dans les deux camps.
Celà dit, il faut être honnète et reconnaitre que le style "Académique" conduit à un tout (Expression du besoin/Cahier des charges/Code/Documentation/Formation/Maintenance) acceptable plus souvent qu'avec "l'Extreme Programming" (je n'aime pas ce terme, mais bon).
Bien souvent, les mauvais résultats donnés par les "pisseurs de codes" proviennent du fait qu'ils ne connaissent pas, ne se fixent pas, nient ou rejettent (bandes de fainéants vas..) la rigueur nécessaire à un développement correct.
Il ne faut donc pas, selon moi, s'enfoncer dans un "absolutisme 100% comme ça" qui n'existe pas.
Personnellement, j'estime avoir la chance d'avoir les facilités qui me permettent de me passer d'un algorithme (il est modeste le gars...), mais ça ne m'empêche pas d'être rigoureux dans mon travail et d'obtenir, malgrès le scepticisme que je comprend, des résultats apréciés de tous (les utilisateurs, et ceux qui passent derrière moi); Et c'est tout ce qui compte à mes yeux... C'est à la fin du bal que l'on compte les musiciens, pas vrai ?
La fainéantise ne prend pas deux e accents aigus.Envoyé par waskol
En réalité, tu ne te passes pas d'un algorithme. Tu te passes de la description manuscrite d'un algorithme, ça oui. Mais c'est le cas de beaucoup de développeurs, je pense.Envoyé par waskol
Comme tu parles de musiciens après, c'est un peu comme si tu disais que les musiciens se passaient de la notion de mesure, de gamme ou du rythme pour jouer ou improviser, tout ça parce qu'ils ont "le rythme dans la peau".
En réalité, ils ne s'en passent pas, mais ils sont tellement habitués (ou doués) qu'ils se passent peut-être volontiers des partitions.
Dans la discussion de ce sujet, c'est pareil, il me semble.
Par contre, tout comme je souhaiterais bonne chance à un musicien qui composerait de tête un morceau de 35 minutes, je souhaiterais bonne chance à un développeur qui "pisserait du code" sur 50000 lignes.
Effectivement, la programmation spontanée est possible pour les petites applications. Pour faire le site internet de la pépinière "JolieFleurs" on peut se permettre de ne pas expliciter les étapes du cycle du développement pour passer directement au pissage du code.
Cela est inconcevable dans un véritable projet informatique. On a pas inventé la modélisation (par exemple) pour faire plaisir à quelques intellectuels ou pour faire jolie.
bonjour
Quelle chose merveilleuse la programmation spontannée !!! Je me demande pourquoi des petites entreprises (comme IBM par exemple) s'embêtent à adopter des choses comme MOF, UML, XMI, MDA (et j'en passe parce que je n'en connais même pas le dixième) et développent des outils pour ces standards alors que Notepad suffit largement à écrire un programme !
Franchement la prog spontanée c'est bon pour un HelloWorld !
Après pour les apps (même les toutes petites) on est content de retrouver la doc !
bon courage...
C'était justement à cela que je pensais quand j'ai écris mon précédent post. Merci de l'avoir explicitéEnvoyé par yann2
La programmationspntanée ca passequand on crache du code pour des pllications ne nécessitant pas trop d'appel.
Dés que l'on attaque un système qui doit communiquer, réagir, faire des appels il est nécessaire de penser au delà et d'utiliser les méthodes de conceptions de programmation.
Il faut juste savoir quand utiliser l'une ou l'autre.
je travail depuis 10 ans comme vous dites de manière spontané, je mene a bien mes projet mais parfois j'ai des mauvaise surprise ou je doit refaire tous un procéssus parfoi tous le projet, je penque que c'est le faite de travailler seul et de vouloir allez vite qui nous pousse a travailler spontanement
Personellement, je suis un adepte de la programmation spontanée:
Et pourtant mes lignes de codes se comptent par milliers et la plus part de mes projets sont en évolutions permanentes.
Ils m'arrive tout de même de faire quelques diagrammes avant de programmer mais c'est quand je veux confronter deux approches ou bien lorsque la partie de projet sur laquelle je travailles va être longue et que je n'ai pas que cela à faire: alors il faut savoir ou reprendre.
En revanche il m'arrive de travailler à postériori:
Au cours de la programmation j'ajoutes des commentaires sur l'action d'une ligne de code ou sur l'action de quelques lignes de codes.
Ensuite dés qu'un groupe de ligne fonctionne il m'arrive d'ajouter en tête de ce groupe un gros commentaire de type titre avec une petite explication.
Ces titres de groupe de lignes peuvent ensuite être repporté dans un diagramme permettant de mieux comprendre la démarche. Je fais ce report
quand je sens qu'une démarche est longue, lourde, fastidieuse (mais dans ce cas j'essayes de la simplifier au maximum).
Je suis seul à travailler sur la plus part de mes projets.
Mais l'été dernier, j'étais à 500 km du boulot quand il a fallu que j'assumes une boulette: mise en fabrication d'une partie de mon programme avec 1 mois de retard suite à la bourde d'un collègue. Un autre collègue a tenté de débeugué mon code et n'as pas eu le temps en 8 heures. (après il était en congé)
Et bien mon entreprise m'a fait revenir et il s'est avéré que c'était une faute de frappe... pour 1 caractère, je me suis tapé 1000 km un collègue a bossé 8 heures et moi 1 heure...
Depuis j'ai refondu l'ensemble de mes projets. Je travaillais essentiellement sur évènements dans mon application. Maintenant, j'ai un process beaucoup plus claire et une démarche plus claire permettant d'identifié le diagramme même lorsqu'il n'est pas documenté hors du programme.
D'ailleurs je prends un mois de congé (en cours) sans soucis, sans craindre d'entendre mon téléphone sonner...
Mattetfamilly.
Jamais je n'oserais créer un programme sans une analyse préalable... Pour éviter justement les désagréments possibles si quelqu'un d'autre doit bosser dessus, pour bien pouvoir optimiser le code etc... Je trouve que l'étape d'analyse est essentielle!
Allucinant d'absurdités ce topic!
Bon franchement, je n'ai lu que les premieres pages car ça començait sérieusement à m'ennuyer, m'énerver etc...
Sérieux Doloop, comme certains ici, je pense que tu es jeune... par l'age ou par l'expérience mais en tout cas tu es un débutant dans le monde de la prog. (quel que soit ton niveau, tu es un débutant)
La prog spontanée moi j'en ai fait aussi dans mes débuts... déjà il faut un bon cerveau au niveau mémoire donc ça ne dure pas tres longtemps. (soyons réaliste)
De plus cela ne peut fonctionner que si on est tout seul pour bosser (utiliser soit meme ses programmes etc...) oubien si on a trouvé un client assez con pour acheter un truc sans suivi/documentation/...
Sérieux, quelle boite voudrait acheter un programme qu'elle ne pourrait pas maintenir, modifier, etc... ??? (franchement c'est se tirer une balle dans le pied d'acheter un truc sur lequel on a auncun controle!!!)
Encore autre chose;
travailler avec des gens comme toi est comme je l'ai dis extremement risqué et donc plutot idiot. Le moindre truc qu'il t'arrive et hop la boite qui t'emploie est dans la merde.
Si tout le monde pensait comme toi, le GNU n'existerait pas, Linux et autres n'existeraient pas... (meme windows, meme...)
Tous ceux qui pensent comme toi (il y en a quelques un qui ont répondu et d'autres qui n'ont pas osé) sont voué à l'échec ou tout du moins à rester petit comme ce que vous etes actuellement. Travailleur indépendant ou EURL au mieux mais pour la plupart c'est l'échec et la perte des clients, jamais de boite solide.
A mon avis, vu l'aspect trollistique qu'a pris ce topic et le nombre de page, la personne d'origine (Doloop - 7 messages au compteur) ne lira malheureusement jamais ton messageEnvoyé par silverman
Partager