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 :
j'avais oublié ça. Je precise bien, je n'ai pas dit que la conception ne sert à rien. On concoit d'abord dans la tête. Ensuite il faut exprimer sa conception. Si c'est possible de l'exprimer directement dans un langage de programmation, c'est pas la peine de passer par UML ou d'autre doc.Envoyé par Nip
Le but du formalisme est de réduire l'ambiguité liée au langage naturel.
Hum... j'espère que tu es bien payé si tu es capable de faire ça dans un délai raisonnable
Oui, je suis d'accord sur le principe d'auto-documentation du code.
Mais c'est toujours agréable d'avoir une ou deux lignes en haut d'une classe ou d'une fonction pour expliquer à quoi elle sert... Surtout si elle est mal codée
Je crois que l'objectif des docs et consort c'est de faciliter la maintenance et l'extensibilité d'un soft. Pour corriger un Bug dans un soft ou pour y ajouter/modifier une fonctionnalité, on n'est pas obliger de comprendre le fonctionnement du soft entièrement. On n'est pas obligé de lire les 1 500 000 lignes de codes que ce soft pourrait avoir. Si le soft est programmer "proprement" et si on utilise un IDE riche, franchement je ne vois pas comment des docs supplémentaires et autres UML diagramme pourraient simplifier la correction d'un bug ou la modification d'une fonctionnalitéHum... j'espère que tu es bien payé si tu es capable de faire ça dans un délai raisonnable
En général, pour ce qui es de la documentation du code lui même, même si je suis capable de m'y retrouver dans un code sans commentaires, quelque soit le nombre de lignes de celui-ci, même si le code est un peu tordu, je suis tout de même assez pointilleux sur ces quelques règles élémentaires :
- Un nom "parlant" pour chaque variable, procedure/fonction ou objet : au moins, on sait de quoi parle la variable, pas besoin de commenter à quoi elle sert si le nommage à été bien réfléchi.
- sauf pour quelques noms de variables génériques :
- i, j, k et index pour des compteurs entiers (utilisés pour des boucles);
- a, b, c, d pour des coefficients dans une fonction mathématique,
- e ou epsilon pour une tolérance
- s : pour une chaîne de caractère fourre tout ou temporaire.
- p pour un pointeur fourre tout ou temporaire
- r pour un réel // // //
- trouve : pour un booleen indiquant que l'on a trouvé ce que l'on cherchait
- x,y,z pour des coordonnées 2D/3D ou u,v pour le résultat d'une projection ou un second système de repère
- W pour une largeur (Width), H pour une Hauteur.
- Commenter, même succintement un bloc de code, en particulier :
- si le bloc représente un algorithme connu, le nom de cet algorithme
(exemple : "tri à bulle", "tri de shell", "quicksort",
"projection de Mercator", "distance de Levenshtein")
- Si la description de la procedure ne tient pas en moins de 3 mots, ou si le nombre de paramètres >3.
(par exemple, pas besoin de commenter ChargeFichier(),
on sait à quoi ça sert.... )
- éviter les blocs de codes qui font plus d'une page de lecture à l'écran, les subdiviser si possible en sous blocs.
- séparer le code en plusieurs blocs de codes dons les buts sont différents : Interface utilisateur d'un côté, manipulation des données de fichiers d'un autre, acces aux base de données dans un autre, bibliothèque d'utilitaires ailleur, etc... ça évite de se mélanger les pinceaux ey du coup ont sait localiser assez facilement où apporter une évolution ou corriger un bug.
La première chose dont je m'occupe quand je développe, c'est la structure des données (leur hiérarchies, qu'elles sont elles, les evolutions possibles de cette structure que ce soit pour un fichier binaire, texte ou une base de données), où les placer sur le disque dur, sous quelle forme.
A partir de là, si cet aspect à été bien réfléchit, 50% du boulot est fait.... y'a plus qu'à. Personellement, je me passe de papier pour cette étape, parce qu'il y a toujours des ajustements à faire, mais dans un groupe j'admet qu'un certain formalisme, quitte à reboucler par la suite, est nécessaire pour que tout le monde parte sur la même base solide.
Que la documentation soit faite avant ou après le projet, ce n'est pas la question, le tout est que la documentation soit faite à un moment donné ou à un autre, et BIEN faite : c'est à dire détaillée et reflétant ce qu'elles sont une fois le projet terminé.. Même dans des grosses boites où les formalismes officiels sont soit disant de rigueur (je cite carrément GFI ou Cap Gémini), j'ai vu des documentations merdiquement scandaleuses à ce niveau... Bref on se fout de la méthode, c'est ce avec quoi vous vous retrouvez entre les mains une fois le projet achevé qui compte : que ce soit fait avec telle ou telle méthode (UML par exemple), on s'en tape, ça doit être du français clair, net, précis, carré, assorti d'un gros schéma mettant en valeur les relations entre les différents fichiers ou tables si nécessaire, avec les noms exacts utilisés dans le code, point final.
Puis c'est la question de comment y accéder (sécurité (login, mot de passe), cryptage, routines de chargement, de sauvegarde, de mise à jour),
C'est une phase assez "relax"...
Puis les routines qui décrivent l'interaction entre les différentes données, les algorithmes qui les manipulent, les procédures qui permettent au code de l'interface d'y accéder où aux données de renvoyer leur état (évènements).
A partir de cette étape, on peut s'accorder le droit de retoucher les structures de données (première étape), sans oublier d'adapter le code de la seconde, ni (et surtout) de mettre à jour la doc de la première étape si elle à déjà été faite.
C'est à l'issue de cette étape que je documente ma première étape, celà me permet de prendre du recul par rapport au projet en faisant un break dans le développement proprement dit. Une fois terminé, c'est "peanuts" pour la suite...
- de là découle l'écriture des classes objets.
A cette étape, je me fait mes propres composant réseau, graphiques, etc... j'évite comme la peste les composants tierce partie, même freeware ou Open-Source (à l'exception de quelques uns que j'ai testé en long en large et en travers). Ca demande du temps, mais on est jamais aussi bien servi que par soi-même : mon expérience me l'a démontré plus d'une fois --> au moins, si bug il y a, on sait d'où ça vient (et d'une), Un composant développé spécifiquement ne comporte pas 10.000 paramètres inutiles (et de deux), si il y a une évolution à faire sur le composant, il n'y a pas de problême de droit d'auteur, de boite qui à coulé, d'abandon de la boite qui l'a développé, etc...
Ah, c'est sur, ça rallonge le cycle de développement, mais il faut savoir ce qu'on veut : vite fait mal fait, ou béton maison.
- l'interface utilisateur est soignée et fignolée en dernier lieu en rebouclant avec les utilisateurs en leur demandant leur avis (certains préfèrent des gros boutons, d'autres de la couleur, des alertes). L'accent est mis ici sur la facilité de prise en main, pas la peine d'embarasser l'utilisateur avec une interface où les menus se déroulent au kilomètre : l'utilisateur DOIT pouvoir s'y retrouver sans se plonger dans une doc. Contre exemple dans mon administration : Lotus Notes, belle merde....
Au final, il y a un CD d'installation, une doc utilisateur papier, une doc utilisateur électronique, la doc qui va bien pour reprendre le bébé derrière, les sources, (l'outil de dev qui à servi est conservé précieusement à cet effet...), et roule ma poule...
Je vous garantie que cette approche permet un développement "au-fil de l'eau" vraiment efficace... Je ne m'embarasse effectivement pas de formalismes "officiels", mais j'ai quand même les miens, que je me suis forgé sur ma propre façon d'aboder le développement, ma personalité, mon tempérament, etc...
Encore une fois, on s'en moque de savoir comment celà à été fait, ce qui compte c'est le résultat non ?
TOUT formaliser sur le papier AVANT de se lancer peut en rassurer certains, tout le monde n'en a pas besoin... Moi je n'en ai pas besoin et j'ai une trentaine de logiciels (réseau, système, bases de données, graphismes, cartographie, scientifique, sécurité, etc...) qui tournent sans bugs, sans planter depuis, pour certaines, 12 ans ! Et pour la plus ancienne qui à tourné sur Win95, elle a été testé sur la béta de vista sans anicroche, on l'a juste recompilée avec 2-3 modifs pour pour avoir un look à la XP : 1 heure de boulot...
Bonjour
Dans ce thread, on retrouve souvent : "Je suis le seul dév (j'ai pas vu...), je n'ai pas besoin d'utiliser les formalismes (je rajoute "officiels" et je répond : vrai) et tout coucher sur papier. (avant de développer, ben non...)"
Prions pour que le client ne redonne pas l'application, pour une évolution ou une migration, à un autre informaticien...ben voyons... comme si la qualité de la doc était conditionné par la méthode de dev utilisée : "si c'est pasun truc de "pro" officiel qu'on voit dans les bouquins de la FNAC ou exposé dans les amphis, c'est caca", bien sur, bien sur... n'importe quoi...)
Assez binaire...
Il y a aussi la catégorie 3, qui sait exactement où elle va et comment elle y va sant tout poser sur le papier avant, il n'y a pas besoin d'être un génie pour ça, c'est juste une histoire d'expérience et de rigueur...
Et la catégorie 4, qui planifie tout (pas forcément bien, sans avoir une expérience des obstacles techniques qu'elle rencontrera lors du developpement) et qui derrière soit ne sait pas coder ou bien code "une chose" différente de ce qu'elle a planifié. J'ai déjà vu, merci pour le résultat...
Bref, je suis un peu plus d'accord avec [B]Hachesse [/Bpour la remarque qu'il fait après, mais :
D'accord aussi,
pour les équipe >10 personnes : notations standardisées
pour les équipe <=10 ça dépend si l'équipe est formée de gens qui se connaissent bien ou non... rien n'empèche d'utiliser des formalismes maison.
pour un développeur seul : les formalismes "officiels", on en a rien à cirer..., en avoir oui, peut-être, si ça te chante.
Des formalismes officieux, oui, au moins un : de la rigueur, être méthodique et ça suffit.
D'ailleurs, si c'est bien programmé, il n'y a pas de bugs...
Mais sinon, si, même 2 mois après j'arrive à m'y retrouver, même six mois (quelle mémoire hein ?), mais de toute façon, c'est bien de commenter et de laisser une trace (même écrit à la main dans un classeur).
Si, moi j'y arrive, merci pour le plus...
j'en ai retouché (recommentés, assainis, réindentés) des codes mal écrits et mal commentés : en général (pas toujours heureusement), ils sont truffés de bugs...
Et j'admet avoir "lu" comme un bon bouquin des codes sans aucun commentaires mais tellement bien écrits, structurés, etc que ça a été un régal
Par contre, c'est sur, tout le monde n'est pas capable de "lire" du code comme ça, il faut aussi penser à eux...
Je me souvient d'une époque où certains pestaient contre le C en disant que le code était illisible, vraiment n'importe quoi : ça dépendait surtout de comment c'était structuré au niveau du code...
Sinon je suis d'accord avec TOUT le reste de tes commentaires.
Pour moi, un formalisme, c'est une méthodologie, pas un outil de communication, donc rien à voir une histoire d'ambiguité du langage naturel, qui est effectivement plus que suffisant pour décrire quelque chose de façon clairre.
Oui et non, plus ton code est clair moins tu as besoin de doc, mais de la doc c'est toujours utile, même si ton code est nickel, il faut l'admettre... (sans en
sortir des tonnes inutiles, non plus).
Pense aux développeurs qui ne savent pas lire le code, comme ça, comme nous quoi... C'est quand même abstrait un bout de code, comme une équation mathématique : si elle est très complexe, les matheux s'en sortiront haut la main et te dirons : "ha, ça ? c'est l'expression du noyau dans la chomologie non abélienne d'un groupe"
Alors là, je suis COM-PLE-TE-MENT d'accord. Et au fond, par rapport au sujet, c'est surtout ce point là l'objet de la discorde.
@Nip : on a pas dit que la phase conception était inutile, t'enfonces pas, on a dit qu'elle ne passait pas forcément par le papier...
Par contre, à un moment donné ou à un autre, exprimer cette conception sur le papier est important : toi tu préfères cette étape avant de coder pour avoir un base documentaire, d'autres comme kisitomomotene ou moi-même préférons l'exprimer d'abord en lignes de code. Ca n'empêche pas de le faire après, ni de le faire bien.
Et arrêtez d'être pointilleux sur chaque mot choisis par chacuns parce que je suis absolument sur de ceci :
- Sur ce fil de discussion, vous êtes (j'ose pas dire nous, j'ai peur qu'on dise que je me prend pour un génie ou que j'ai les chevilles qui gonflent) tous des développeurs d'excellent niveau.
- Chacun à sa ou ses méthodes de dev qui lui conviennent et conviennent à l'organisation pour laquelle on travaille (sinon on serais déjà chômeurs).
- Nous avons au moins un point commun : le souci de bien faire (ça c'est important...)
- Les formalismes, il en faut, de la doc aussi, mais en ce qui concerne les formalismes ils peuvent prendre des formes très variées : ça dépend d'un contexte (tout seul, en équipe), de l'expérience et du tempérament de chacun, ils peuvent passer par le papier, pas toujours.
- c'est le résultat qui compte, il faut que ce soit impeccable, pour que n'importe qui, même 20 ans après, puisse reprendre le code sans s'y perdre.
- l'XP en équipe, moi non plus, je n'y crois pas trop... pourtant mes méthodes s'y apparente, c'est dire.
Conclusions :
- le problême n'est pas l'utilisation ou non d'un formalisme "officiel" ou non, mais plûtot comment celui-ci est utilisé lors de la programmation : celui qui programme comme un pied, avec ou sans formalisme, avec ou sans phase de conception avant de se jeter dans la programmation proprement dite, n'arrivera à rien du tout.
- le papier est un support de réfléxion pour certains, pas pour d'autres : ça n'empêche pas ces derniers de sortir des programmes monstrueux (par le volume de lignes de code et leur complexité), mais pourtant maintenable, évolutifs, etc...
-il n'y a pas une façon de faire ou que les méthode officielles : je ne cherche pas à vous faire changer de méthode de dev, mais à vous faire admettre que ce qui n'est pas fait comme vous faites peut tout aussi bien être valable...
avant qu'UML (par exemple) ne soit un formalisme officiel, était-il pour autant mauvais ?
J'ai l'impression que pour avoir le droit au titre de développeur faut avoir travaillé sur des projets de plus de 100 000 lignes ici.
C'est pas la quantité qui prime, mais la qualité. Et que l'on vienne pas me faire croire que des codes aussi gros sont confiés à une seule personne, se serait de suicide...
Maintenant, je pense que ceux qui on eu l'occasion de bosser sur des projets aussi gros, visent des secteurs d'activités bien précis et ne sont généralement pas seul face au projet (doit y avoir un paquet de copains derrière).
Donc, il est facile de mettre en place une organisation de développement intégrant des formalismes quand on est 50 sur un projet, et que machine fait ci, un machine fait ça...
Mais quand on est en équipe réduite, et que les délais sont les mêmes que pour une équipe étendue, on fait comment les champions ?
Non, ce n'est pas ce qu'on dit. C'est juste que quelqu'un qui explique qu'il est capable de comprendre (suffisamment pour connaître l'impact d'une modif majeure) un soft de plusieurs millions de lignes, et ce juste en lisant le code... Je trouve ça peu vraisemblable. Après, peut-être que c'est possible, je ne sais pas. Mais moi je n'en suis pas capable.
Personne ne l'a dit, tu as raison !
Parfait ! Tu as résumé ce que tout le monde dit depuis le début !
Dans une équipe importante, un minimum de documentation (UML ou autre) est indispensable pour la communication et la synchronisation des intervenants.
Dans une équipe restreinte, une documentation minimale suffit, son but étant principalement ici de permettre à un intervenant ultérieur d'avoir une idée de l'organisation du code et/ou de la structure du soft.
@Waskol
Je suis le thread depuis le début... ta mauvaise foi m'effraie...
Les formalismes officiels ne sont pas là pour faire beau ou pour faire plaisir à un chef de projet...
Tous les mecs de l'OMG perdent leur temps. D'ailleurs le MDA n'a aucun avenir car il s'appuie sur des formalismes officiels et nous n'en avons pas besoin parce que nous, on pratique la programmation spontanée...
Il me semble qu'UML est un formalisme mais certainnement pas une méthodologie.Pour moi, un formalisme, c'est une méthodologie, pas un outil de communication, donc rien à voir une histoire d'ambiguité du langage naturel, qui est effectivement plus que suffisant pour décrire quelque chose de façon clairre.
Voir plus hautAlors là, je suis COM-PLE-TE-MENT d'accord. Et au fond, par rapport au sujet, c'est surtout ce point là l'objet de la discorde.Citation:
kisitomomotene a écrit :
j'avais oublié ça. Je precise bien, je n'ai pas dit que la conception ne sert à rien. On concoit d'abord dans la tête. Ensuite il faut exprimer sa conception. Si c'est possible de l'exprimer directement dans un langage de programmation, c'est pas la peine de passer par UML ou d'autre doc.
Bon courage
Je ne vois très bien pourquoi si on est plusieurs dans un projet, un code source ecrit "proprement" ne peut pas servir d'outil de communication. Je l'avais dejà dit, il existe des IDE qui ont de puissants outils de reverse ingenierie et d'isolation de code. Donc dans un code source, on tructure parfaitement et simplement le code, on y ajoute au besoins de commentaires de code, et des commentaires du style "javadoc", on crée dans le projet un fichier readme.txt pour donner l'orientation initail ( les principales classes "main" et d'autre unfo utiles pour une bonne introduction).Parfait ! Tu as résumé ce que tout le monde dit depuis le début !
Dans une équipe importante, un minimum de documentation (UML ou autre) est indispensable pour la communication et la synchronisation des intervenants.
Dans une équipe restreinte, une documentation minimale suffit, son but étant principalement ici de permettre à un intervenant ultérieur d'avoir une idée de l'organisation du code et/ou de la structure du soft.
Par la suite si quelqu'un veut comprendre ton soft, s'il tient tend à UML, il peut utiliser les outils reverse ingenierie pour avoir une vision globle de l'architecture de ton soft, il peut toujour utiliser l'IDE pour ne visualiser que la doc ( créer par les commentaire du style "javadoc"), s'il trouve superflu certain commentaire, il peut toujours les masquer dans l'IDE, pour se concentrer uniquement sur le code lui même. Bref comme je l'avais tjrs dis, si c'est possible d'aller directement dans le code source pour s'exprimer je trouve que c'est la façon la plus simple et la plus optimale.
Je n'ai jamais dit ça, tout au contraire même, merci pour la mauvaise foi...
Des formalismes il en faut, mais le choix de tel ou tel formalisme et l'aspect qu'il prend dépend d'un contexte.
Quand je bosse en équipe, ne t'inquiètes pas, j'utilise aussi des formalismes officiels : c'est souvent utile et indispensable dans ce cas (je n'ai pas dit que ça l'était toujours).
Bref je n'ai pas dit qu'il fallait tout mettre à la poubelle, loin de la...
Je ne dénigre en rien leur boulot que je respecte et que je trouve utile et même nécessaire : mais dans certain contextes (grosse équipe, ou petite équipe disséminée).Tous les mecs de l'OMG perdent leur temps. D'ailleurs le MDA n'a aucun avenir car il s'appuie sur des formalismes officiels et nous n'en avons pas besoin parce que nous, on pratique la programmation spontanée...
sinon, avec davcha on est tombé d'accord sur tout plein de chose et on s'est surtout rendu compte que nos désaccords dépendaient de la définition que l'on donnait à ce terme : "la programmation spontanée". C'est cette expression qui est en fait le piège de tout le fil de discussion.
C'est quoi pour toi "la programmation spontanée" ?
Ne me dit pas que c'est développer sans avoir tout planifié ou sans avoir un but précis, parce si ça peut te rassurer c'est impossible de se lancer dans un programme si on a pas une idée de ce qu'on veut faire ni même d'aboutir à quelque chose de sérieux si on ne sait pas comment on va s'y prendre : que ce soit déjà écrit sur le papier ou non.
Bon, apparemment, on s'exprime tous en langage naturel, mais on a quand même des problèmes de communication
On n'a pas dit que le code ne pouvait pas servir d'outil de communication, on a dit que dans certains cas, il n'était pas suffisant.Je ne vois très bien pourquoi si on est plusieurs dans un projet, un code source ecrit "proprement" ne peut pas servir d'outil de communication
Donc tu créés une doc.Donc dans un code source, on tructure parfaitement et simplement le code, on y ajoute au besoins de commentaires de code, et des commentaires du style "javadoc", on crée dans le projet un fichier readme.txt pour donner l'orientation initail
Celà dit, comment tu fais pour que 50 personnes réussissent à "structurer parfaitement et simplement le code" sans s'être mis d'accord avant ? Il faut bien des docs qui expliquent à chacun comment le code doit être structuré, non ? Sinon tu peux être sûr qu'il y aura au moins un gars qui ne fera pas comme tout le monde !
On définit des guidelines que chacun doit suivre quand il programme, ah ça non chacun ne programme pas comme bon lui semble. Ce sont des procèdures internes de la maison, ou si tu veux c'est la doc de la boite et non la doc du soft qu'on est entrain d'écrire.
Concernant l'ambiguïté qu'aurait le langage naturel. J'ai dejà vu des diagrammes UML vraiment ambigus. Si quelqu'un maitrise mal UML, son expression en UML serra aussi ambigu. Et je crois que c'est posible de s'exprimer un langage naturel, ou avec des schémas non conventionnel sans être ambigu et en se faisant parfaitement comprendre.
Effectivement, tout est problème de définition. C'est d'ailleurs de ça que je voulais parler en évoquant l'ambiguité du langage naturel.
+1
Pour moi, ça serait réfléchir à ce qu'on va faire, dans sa tête, peut-être en discuter avec un ou deux collègues qui bossent sur le même projet, puis se mettre à coder. Et c'est tout (rien avant, rien après).
Je l'ai déjà fait sur de petits projets, mais uniquement pour des maquettes, ou des projets dont on savait qu'ils ne seraient jamais repris (durée de vie limitée à quelques jours, par exemple).
Si de nombreuses personnes sont impliquées, ce n'est plus possible. Tout simplement parce que réfléchir et discuter ensemble (et surtout se comprendre) à plus de 50 personnes (éventuellement réparties géographiquement), sans utiliser de support physique, c'est presque impossible. Donc là, la "programmation spontanée", telle que je l'imagine, n'est plus applicable (sauf peut-être pour le petit bout de code dont je serais responsable).
La discussion en cours est la preuve que le langage naturel est ambigu. Un même mot sera compris de façons différentes selon la personne, en fonction de son expériences, de son vécu, du contexte, etc. L'objectif des documentations techniques, des langages formels, des schémas, et des spécifications en général est justement de réduire ces différences de compréhension en donnant plusieurs visions du problème de façon à s'assurer que tout le monde a compris la même chose. Et même comme ça, ce n'est pas forcément gagné !
Après, personne ne dit qu'UML est idéal, surtout mal utilisé. On est tous d'accord pour dire que l'on peut faire des schémas ambigus si l'on veut. Et on est aussi tous d'accord pour dire qu'il est possible de s'exprimer clairement en langage naturel.
Celà dit, allier des schémas clairs et un texte précis ne peut qu'améliorer la compréhension entre les intervenants.
Je comprend mieux ton point de vue vu sous cet angle.
OK, comme ça par rapport à tout ce que tu as dit.
dans ma démarche spontanée, donc seul ou en équipe restreinte, je rajoute systématiquement quelque chose après : la doc qui va bien, issue de cette réflexion et du code qui a été écrit.
Du coup, par rapport à ta vision de la spontaneité, je ne suis plus dans la catégorie de ceux qui pratiquent la "programmation spontanée".
sauf pour les "bricoles" que je fait pour moi-même.
c'est clair que pour ça, on peut s'affranchir de tout formalisme officiel et de doc. +1 aussi. Mais attention tout de même, j'ai déjà vu des maquettes ou des projets "temporaires" être repris ou perdurer : celà reste tout de même bon de laisser une trace, si minime soit-elle.
C'est aussi ce que j'ai déjà dis a maintes reprises, même avec la programmation spontanée "telle que je l'imagine, c'est-à- dire avec le "quelque chose" après.
+1 et pour moi, en équipe c'est ça le minimum vital; celà n'implique pas forcément de passer par des formalismes officiels (plus de 10 personne si, il faut que tout le monde parle le même langage), ce qui compte c'est d'ètre compris.Celà dit, allier des schémas clairs et un texte précis ne peut qu'améliorer la compréhension entre les intervenants.
@zooro :
Pour ma gouverne : Yann me trouve de mauvaise fois, le suis-je à tes yeux ? rassures moi STP.
Pas d'après ce que j'ai vu. Peut-être s'agit-il d'un problème de définition ?
Rassuré ?
Ouf ! merci cher amiPas d'après ce que j'ai vu. Peut-être s'agit-il d'un problème de définition ?
Rassuré ?
Qules projet ?
... pour quel type de projet doit t-on intégrer une cinquantaine de personnes ? Pour le jeu vidéo OK, je comprend car il y a diverses spécialisation (3D, audio, vidéo, gameplay, test...), mais pour une application de gestion, là je vois pas l'utilité d'une si grande équipe...
Pour moi, le programmeur spontanée part d'une idée de base. Il visualise l'application finale, son utilisation et éventuellement pense déjà aux technologies qui seront utilisées.waskol a écrit :
on s'est surtout rendu compte que nos désaccord dépendait de la définition que l'on donnait à ce terme : "la programmation spontanée". C'est cette expression qui est en fait le piège de tout le fil de discussion.
C'est quelqu'un qui n'aime pas être dépendant de méthodes, de contraintes (temps, techniques...) et qui n'applique que les siennes. C'est quelqu'un de créatif, qui possède une bonne expérience des NTIC et est un "touche-à-tout".
Souvent étiquetté de "bidouilleur" ou de "pisseur de code", car ne suivant que très rarement les formalismes du métier, il en est pas moins productif et compétent.
C'est aussi quelqu'un qui rencontre des difficultés à formuler les aspects d'un projet car il lui manque souvent du vocabulaire technique (quelque chose dont il ne trouve que rarement l'utilité).
Voila ma définition en ce qui concerne la programmation spontanée et le profil que j'ai souvent rencontré par ceux qui la pratique.
Eh bien... Je vois les applis télécom (pas toutes, mais si tu regardes un peu les standards 3GPP et autres protocoles télécom, tu te rendras compte que tout avoir dans la tête, même si on est "créatif", c'est impossible), des projets de refonte de SI dans les banques, des applis médicales, certains projets de la défense, des projets aéronautique (tu te vois coder tout seul tout le système informatique d'un Airbus ???)...
Et je suppose que tout le monde a quelques exemples personnels à donner.
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