Discussion :

[zecreator]

Pour revenir sur la question d'origine "Qui pratique la programmation spontanée ?", je répond "MOI".

Pour complêter ma réponse, je dirai que même si j'admet que ce n'est pas la meilleure des méthodes de développement, c'est certainement celle qui permet une réelle liberté créatrice.

Pour avoir pratiqué pendant des années le développement que j'appelerai "formatté", j'ai constaté que ça m'éclatait pas de passer mon temps à faire des diagrammes UML, des organigrammes, des plans et tout le bazar.

Pas par un manque de compétences, juste que j'avais plus vite fait de développer l'application une fois le storyboard effectué, car j'avais déjà schématisé toute la technicité dans ma tête. Rien ne m'empêche de documenter mon application, avec quelques commentaires dans le code, un p'tit doc PDF...

Encore une fois, ce n'est pas la meilleure méthode de développement. Comme toute méthode elle a ses faiblesses, et je pense qu'elle n'est praticable que par des personnes ayant une bonne maîtrise des technologies, et une motivation à acquérir des nouvelles connaissances techniques.

Mon expérience sur de gros projets m'a permit aussi de constater que les formalismes sont surtout l'affaire de temps et d'argent. Dans les domaine comme la finance ou l'assurance, je comprend très bien la volonté de "traçabilité" des applications et des délais très serrés (compétitivité oblige).

Mais cela se recent terriblement dans l'ergonomie des interfaces, la créativité et l'ergonomie sont 2 facteurs manquants, qui semblent avoir été totalement rayés dans ces domaines (je vais me faire taper dessus je le sens ).

Et pour cette raison, je préfère passé pour un développeur moins "pro", et continuer de développer spontanément...

Bref, je préfère garder du temps à ma créativité et ma veille technologique, à l'élaboration de nouvelles techniques, qui me permettent de m'épanouir dans mon métier de développeur.

[kisitomomotene]

Salut à tous

Je crois qu'on ne doit pas confondre l'exception à la régle!!

Un programme bien structuré (dont la structure est surtout simple) avec les noms de varibales, methoses, classes etc. suffisamment explicite n'a pas besoin d'être commenté, ni d'y ajouter de la doc supplémentaire et autre diagramme UML. On ajoute exceptionnelement les commentaires, documentation etc., lorsqu'on estime que la structure de l'application est compliquée, et on ne doit ajouter que ce qui n'est pas possible d'exprimer directement et simplement dans le code source.
Quant à concevoir en amont en utilisant UML, d'après moi c'est encore une exception, et non la règle. UML est un langage. Si c'est possible d'exprimer directement, avec suffisamment de simplicité dans un langage de programmation ce que j'exprimerais en UML, pourquoi d'abord passer par UML?
Un bon programme de test (code bien structurer etc.), eventuellement bien commenté, peut bien remplacer un document de cas d'utilisations (je crois)

Je pense que rien ne remplace un code propre avec des tests propres. Et la programmation en binôme devrait renforcer la capacité d'une équipe à ecrire des codes propres.

[Hephaistos007]

Quant à concevoir en amont en utilisant UML, d'après moi c'est encore une exception, et non la règle.

C'est une "best practice" comme on dit, il n'y a aucune obligation. C'est juste qu'on essaye de trouver une solution au gouffre financier qu'est la maintenance logicielle pour les entreprises de developpement, et ce, depuis 30 ans. Mais les entreprises y sont hermétiques, tant pis pour elles....

UML est un langage. Si c'est possible d'exprimer directement, avec suffisamment de simplicité dans un langage de programmation ce que j'exprimerais en UML, pourquoi d'abord passer par UML? .

Parce qu'UML est un langage plus abstrait et donc qu'il simplifie encore d'avantage l'information. C'est le principe fondamental de l'abstraction.
Si tu arrives à exprimer une information claire avec un langage de programmation, c'est que ton problème est trivial. Si il est trivial, le génie logiciel (i.e la science du logiciel) est inutile dans ce cas. Et si le GL est inutile, c'est que tout cela n'a rien à voir avec ce débat.

[Hephaistos007]

Pour complêter ma réponse, je dirai que même si j'admet que ce n'est pas la meilleure des méthodes de développement, c'est certainement celle qui permet une réelle liberté créatrice.

Jamais vu cet argument auparavant. Les formalismes utilisés en amont du devellopement représentent les mêmes connaissances que celles contenu dans ton code, mais sous différents angles, et de façon plus abstraite. Où est le frein a ta créativité ??

[davcha]

Jamais vu cet argument auparavant. Les formalismes utilisés en amont du devellopement représentent les mêmes connaissances que celles contenu dans ton code, mais sous différents angles, et de façon plus abstraite. Où est le frein a ta créativité ??

J'avais tiqué là dessus l'autre jour en le lisant aussi.
Je m'étais dit que c'était même plutôt l'inverse : les "formalismes" et autres "discussions" (avec le client par exemple), c'est souvent à ces moments là que les idées fusent dans tous les sens, rarement pendant la phase "pissage de code".

[LadyWasky]

rarement pendant la phase "pissage de code".

1) Quelle belle et noble expression.
2) Ben voyons... comme si le cerveau avait besoin d'un bout de papier pour avoir des idées

[davcha]

1) Quelle belle et noble expression.
2) Ben voyons... comme si le cerveau avait besoin d'un bout de papier pour avoir des idées

Il me semblait que, nous deux, nous nous étions compris, non ?
Alors pourquoi venir remettre en question ce dont on a déjà discuté ?

[LadyWasky]

Il me semblait que, nous deux, nous nous étions compris, non ?
Alors pourquoi venir remettre en question ce dont on a déjà discuté ?

Je ne remet pas en question ce que tu as dit, ni ce sur quoi nous sommes tombés d'accord, j'ai juste réagi parce que je n'aime pas ce genre d'expression :
"pissage (pisser, pisseur) de code"


Bref, je m'aperçois que beaucoup sont stupidement restés campés sur leur position, et n'ont pas réussi à faire la part des chose lors de la lecture de nos échanges. Tu vois ce que je veut dire ?

je trouve que ces vraiment désavouer l'effort de programmation qui, même si il est vaint pour certains, reste respectable.

D'ailleurs je suis surtout d'accord pour dire que les idées peuvent arriver à n'importe quel moment, aussi bien lors d'une étude préliminaire que lors du développement à proprement parler.

[davcha]

J'ai utilisé cette expression simplement parce qu'il arrive bien un moment où tu arrêtes de réfléchir à la structure de ton truc pour vraiment ne plus faire que "pisser du code".

[LadyWasky]

Tu es tout excusé, mais méfie toi de ce genre d'expression, parce que d'autres que toi, moins conciliants et plus à cheval sur "leur façon de faire officiel qui est la seule qui existe et le reste c'est du caca" auraient peut-être tendance à rebondir dans l'exces avec. Il n'y a qu'a voir tous les posts qui ont précédés avant nos échanges.

En tout cas, ça fait vraiment plaisir de voir quelqu'un qui comme toi, à compris qu'il n'existait pas UNE méthode universelle.

Je conçoit tout à fait l'utilité des formalismes officiels, pour certains, mais je maintient toujours qu'ils ne sont pas toujours utiles. Des formalismes, pour un développement "durable", il en faut, certes, mais je ne parle pas forcément des formalismes et méthodes de dev officiellement reconnues : on peut très bien se forger ses propres formalismes et ses propres méthodes.

Pour le travail en équipe, c'est autre chose : dans le formalisme, il faut que tous les intervenant parlent "le même" même langage. Les formalismes officiels trouvent là leur place où tout le monde ne se connait pas forcément mais ont au moins appris une méthode commune. Dans une petite équipe, celà peut prendre la forme de formalismes "maison", mais pour une équipe de 100 développeurs, le formalisme "officiel" devient une nécessité absolue, même si elles ne sont pas toujours ni très souples, ni très adaptées.

tu vois, je ne suis pas catégorique et en tant que développeur "fou" je saurais toutefois très bien m'adapter.

[davcha]

En tout cas, ça fait vraiment plaisir de voir quelqu'un qui comme toi, à compris qu'il n'existait pas UNE méthode universelle.

Bah ça, c'est un peu ridicule de penser ça, non ?
Je veux dire... La méthode que tu vas employer (enfin... en tout cas c'est ce que moi je fais) dépend aussi de contraintes que tu as vis à vis de tes clients.

Dans le genre, j'ai entre autre deux clients actuellement.

L'un d'eux est très proche (vraiment très proche) de moi géographiquement ce qui fait qu'il peut voir l'évolution de ce que je lui fais quasiment en temps réel. C'est génial pour le développement je trouve, ça va très vite dans la bonne direction, il y a énormément de communication entre nous et les cycles de développement sont très courts.

L'autre, c'est tout l'inverse, il habite plutôt loin de chez moi et il est assez difficile de communiquer directement de visu. Si j'utilisais la même méthode ça nous obligerait à dépenser des fortunes en carburant pour nos véhicules et on passerait notre temps à voyager. Dans un cas pareil, faut bien avoir un cycle de développement un peu plus long et avoir tout de même quelques formalismes - que nous comprenons tous les deux (c'est pas un informaticien, alors l'UML...) - pour pouvoir travailler efficacement.

Alors que tu me dises qu'il existe des développeurs affectionnant tellement UNE methode de travail au point de dire que les autres c'est de la "merde" (pour parler sans détours), ça me fait peur moi. J'aurais certainement pas envie de travailler avec des gens comme ça.

[millie]

Pour revenir sur la question d'origine "Qui pratique la programmation spontanée ?", je répond "MOI".

D'après ce que j'ai pu lire, on a surtout parlé de grosse application. Mais même pour de petites applications, pratiquer de la programmation spontanée peut être quasiment impossible.

Si un jour, tu arrives à pondre une application de simulation d'écoulement de fluide sans passer par le papier, bravo. Car dans ce genre d'appli (qui peut être particulièrement petit, le gros peut être programmer en qq heures avec les algorithmes), tu peux passer 9/10 (voir largement plus) de temps à réflechir au problèmes, à la théorie et aux algorithmes (et optimisation) qu'à la programmation.

L'algorithme, on l'invente directement dans le programme au fur et à mesure des besoins qui se font ressentir au moment de focalisation sur des points précis.

Si t'arrives à te dire au cours d'un algorithme. "A tiens, j'ai une bonne idée, on va approximer ces valeurs en utilisant une méthode spectrale de collocation Tchebychev, l'algorithme coule de source d'ailleurs." Appelles-moi...



J'avais bossé sur une application permettant l'optimisation de la gestion des feux tricolores (minimiser les temps d'attentes...). Le programme n'est pas énorme mais demande beaucoup de réflexion. Mais la prochaine fois, je saurai, je te demanderai et tu trouveras tout de suite qu'il me fallait utiliser des algorithmes de recherche de cliques et de résolution de simplexe.

[zooro]

Si t'arrives à te dire au cours d'un algorithme. "A tiens, j'ai une bonne idée, on va approximer ces valeurs en utilisant une méthode spectrale de collocation Tchebychev, l'algorithme coule de source d'ailleurs."

J'imagine bien la scène !

[LadyWasky]

Alors que tu me dises qu'il existe des développeurs affectionnant tellement UNE methode de travail au point de dire que les autres c'est de la "merde" (pour parler sans détours), ça me fait peur moi. J'aurais certainement pas envie de travailler avec des gens comme ça.

Oui, il y en a...

[LadyWasky]

J'imagine bien la scène !

Toi, tu n'imagines rien du tout parce que tu ne l'as pas vu...

Qui n'a rien vu n'y crois pas... vous êtes vraiment obtus !
Allez sur la page des défis Delphi et dites si vous pensez que celà soit faisable, sans étude préliminaire : moi je vous répond, oui, oui, oui, et oui.

Mais c'est vrai que quand je me lance dans le code, j'ai en général déjà l'idée d'utiliser une chaîne de Markov cachée, une Distance de Levenshtein, un polynôme de tchebitchev, un mappage conformel pour simplifier les calcul dans un autre repère spatial, etc... que ça vous plaise ou non. les ajustements et optimisation se font en quelques traçages et test.
Bref, j'ai déjà un plan.

Non seulement vous êtes des incrédules mais en plus vous êtes obtus.

[davcha]

faisable, sans étude préliminaire : moi je vous répond, oui, oui, oui, et oui.

[...]

Bref, j'ai déjà un plan.

C'est sûrement une forme d'auto-dérision.

[LadyWasky]

C'est sûrement une forme d'auto-dérision.

Bien sur

[zooro]

Toi, tu n'imagines rien du tout parce que tu ne l'as pas vu...

Qui n'a rien vu n'y crois pas... vous êtes vraiment obtus !
Allez sur la page des défis Delphi et dites si vous pensez que celà soit faisable, sans étude préliminaire : moi je vous répond, oui, oui, oui, et oui.

Mais c'est vrai que quand je me lance dans le code, j'ai en général déjà l'idée d'utiliser une chaîne de Markov cachée, une Distance de Levenshtein, un polynôme de tchebitchev, un mappage conformel pour simplifier les calcul dans un autre repère spatial, etc... que ça vous plaise ou non. les ajustements et optimisation se font en quelques traçages et test.
Bref, j'ai déjà un plan.

Non seulement vous êtes des incrédules mais en plus vous êtes obtus.

Du calme !

Tu ne peux pas concevoir et réaliser un boulot qui va durer plusieurs mois (voire plusieurs années), et impliquer une vingtaine de personnes, sans y réfléchir avant, et rédiger un minimum de spec.
Si tu penses en être capable, c'est bien. Mais j'en doute.

Maintenant, si on parle d'une appli que tu vas développer seul en deux semaines, je veux bien qu'une spéc approfondie soit souvent inutile. Je l'ai déja fait aussi.

[LadyWasky]

Tu ne peux pas concevoir et réaliser un boulot qui va durer plusieurs mois (voire plusieurs années), et impliquer une vingtaine de personnes, sans y réfléchir avant, et rédiger un minimum de spec.

Y réfléchir : je n'ai jamais dis que c'était sans réfléchir. J'ai dis qu'il n'y avait pas besoin de réfléchir avec du papier, le cerveau suffit.
Avant de passer par le papier, j'espère que ton idée passe par ton cerveau, non ?
Après, certains ont besoin de "formaliser" leur réflexion sur le papier, qui leur sert de support pour marquer leurs idées, d'autres non.

rédiger un minimum de spec. On appelle ça le cahier des charges, l'expression des besoins. D'accord ça conditionne le développement mais ce n'est pas ça qui te permet d'écrire ton code. Les specs te permettent juste de donner un objectif (il vaut mieux en avoir un, c'est sur...*), mais ne te disent pas comment tu vas l'atteindre.
Dans 98% des cas, à partir du moment ou je sais qel est le but que je poursuis, j'ai déjà tout structuré en tête : TOUT. Et je t'assures que ça, je n'ai pas besoin de le coucher sur le papier pour m'y retrouver sic mois après.
Et je ne dois certainement pas être le seul comme ça...

Après, pour les formalisme, il me semble en avoir déjà parlé si le développement lui-même impliquait une équipe de plusieurs personnes.

Après, pour ce qui est de la documentation, des explications de code et d'algorithme, rien n'empêche de le faire au fil de l'eau, après avoir pissé le code. Je ne vois absolument pas où est le problême.

* Si tu n'as pas d'objectif, tu ne développes rien. Si tu te lances à développer quelque chose, c'est que tu as déjà une idée de ce que tu veux faire. Là, il faut être logique.
"ho j'ai envie de faire un programme mais je ne sais pas quoi, je tape des instructions au hasard, on verra bien ce que ça donne"

[Hephaistos007]

Visiblement, les formalismes dont je parlais ne sont pas clairs dans la tête de certains. Vous parlez de documentation. Mais la documentation est une tâche qui peut être faite après la production de code et n'est donc pas du tout représentative des formalismes dont je parlais et qui sont très en amont dans le cycle de développement. En particulier je pensais aux diagrammes UML bien sur, mais aussi à la méthode B ou encore aux langages de description d'architectures (ACME, Wrigth, Unicon), et tant d'autres. Et oui, l'ingénierie du logiciel ne se résume pas à la production du code, cette dernière tâche n'étant, je le repette, que la dernière étape d'un cycle. La programmation spontanée est donc le fait ramener un dévellopement à cette unique étape, en omettant les étapes précédentes (d'où la spontanéité de l'approche). Alors les nombreuses interventions que j'ai vu parlant de "nommage de variables" et autre "commentaires dans le code" sont hors sujet puisque que tout cela concerne uniquement la dernière étape du cyle ! Quant aux remarques du style "oui mais j'ai reflechi dans ma tête avant de coder, donc c'est pas spontanée !", c'est... .

Ensuite, pour bien comprendre l'enjeu, la métaphore de la construction de bâtiment est bien appropriée (comme souvent en informatique) :

Lorsque des architectes se voient confier un grand projet, comme la construction d'une tour au centre ville par exemple, en tant qu'être intelligents et bien formés, il vont peut-être chercher à detecter en amont les éventuelles erreurs plutôt que de commencer à construire pour s'apercevoir en plein milieu du chantier que le vent risque de tordre la structure par exemple. Les conséquences financières serait dramatiques (vous vous reconnaissez ? ). Au lieu de cela, les architectes construisent une maquette qui subit ensuite des tests en soufflerie, alors seulement ils valident et lancent la construction. Ca vous parait plus sûr, plus logique ? Alors pourquoi vous ne l'appliquez pas à la construction de grands logiciels ?

Les méthodes/outils/langages destinés à la spécification des logiciels sont des supports de communication certes, mais ils servent surtout à detecter à priori les erreurs structurelles ou comportementales (par exemple), avant de se lancer bêtement dans la production du code. Pour continuer sur la métaphore, les architectes portent le même nom en informatique et les ouvriers sont les programmeurs. C'est une séparation nette et bénéfique des préoccupations, comme dans n'importe quelles entreprises d'ouvrages.