Ca me semble la maniere la plus sympa de procéder, tout en garantissant la qualité. C'est la base de XP ;-)Envoyé par hachesse
Ca me semble la maniere la plus sympa de procéder, tout en garantissant la qualité. C'est la base de XP ;-)Envoyé par hachesse
Marrant ça me rappele une pub mal traduite de l'américain pour le "Pouvoir ZON", qui est censé pousser les gentils vers la réussite alors que les méchants tombent dans le puit du malheur, et le tout sans effort.Envoyé par Doloop
Ceci n'est qu'une anecdote, je trouve ton style un peu enflammé ;-) mais c'est bien comme ça.
Concevoir l'algo mentalement ou sur papier ne me semble pas changer grand chose - juste une différence d'outils. Ensuite lire le code facilement est une capacité. Je me focalise justement en ce moment sur le refactoring en extreme programming, technique qui aide à rendre le code limpide d'une maniere fiable, en conjonction avec des tests unitaires.
Pratique tu les tests unitaires?
Bien que je sois pas convaincu par le dev spontanné, je suis persuadé que ecrire un programme est plus une activité littéraire que technique/mathématique. Avis partagé par quelques un de mes profs passés (depuis plusieurs années je précise)Envoyé par mat.M
Etant attiré par l'écriture romanesque, et pour ce que j'ai lu sur divers auteurs, la maniere de faire d'un developpeur et d'un écrivain n'est pas si éloignée
J'approuve, je vote +1.Envoyé par cedricgirard
Moi j'aimerais bien voir quelques centaines de lignes de programmation de doloop![]()
Approuve +1Envoyé par cedricgirard
Ce qui nous conforte dans l'idée de l'analyse quand on vois le travail de preparation realisé par un ecrivain avant de coucher le moindre ligne (bien sur si on cite les editions arlequin ça conforte l'idée du developpement spontané mais bon....)
Salut à tous,
Je rajoute un petit complément d'information à propos du livre des 10 % en question.
Citation du livre : programmation du 6502 de Rodnay Zaks aux éditions SYBEX (dépot légal initial : 3 e trimestre 1981)
L'auteur a enseigné la programmation et les microprocesseurs à plus de 3000 personnes dans le monde entier. Il est ingénieur de l'Ecole Centrale et docteur de l'université de Berkeley où il a développé un interpréteur APL microprogrammé, ...Le tracé de l'ordinogramme est une étape hautement conseillé entre la spécification de l'algorithme et le codage proprement dit de la solution. Il est remarquable que l'on ait observé que peut-être seulement 10 % de la population des programmeurs sont capables d'écrire un programme correct sans passer par l'ordinogramme.
Malheureusement, on a observé aussi que 90 % de la population croient faire partie des 10 % qui n'ont pas besoin d'ordinogramme.
Il en résulte que en moyenne, 80 % des programmes ne fonctionneront pas à leur premier passage en machine. (Ces nombres n'ont bien sûr pas la prétention d'être très précis). En bref, la plupart des programmeurs novices voient rarement la nécessité de tracer un ordinogramme. Ceci entraîne habituellement des programmes "boiteux", ou erronés. Ils doivent alors passer un temps considérable à tester et à corriger leur programme (cela s'appelle la phase de mise au point). Il est donc fortement recommandé d'avoir la discipline de tracé l'ordinogramme dans tous les cas. Cela demandera un petit supplément de temps avant le codage, mais il en résultera habituellement un programme clair qui s'exécutera vite correctement. Lorsque les ordinogrammes sont bien compris, un faible pourcentage des programmeurs sont capables de franchir cette étape mentalement sans avoir à faire de tracé sur papier. Malheureusement, dans ce cas, les programmes qu'ils écriront seront difficiles à comprendre pour quelqu'un d'autre privé de documentation que constitue l'ordinogramme. Il est donc universellement recommandé d'avoir la stricte discipline de tracer l'ordinogramme pour tout programme important.
Bonne continuation.
@ +
J'ai personnellement une méthode qui, si on l'observe superficiellement, s'apparente à de la programmation spontanée, car je m'attarde peu à de longues analyses, ne réalisant pas de très gros projets (essentiellement des sites Web en JSP). Mais je prends quand même le temps de composer un plan de ce que j'ai à faire, ne serait-ce que pour discerner les points stratégiques du développement et établir des priorités dans la production.
J'apparente l'analyse à l'établissement d'un budget. En effet, on arrive facilement à vivre sans établir de budget, quand on ne brasse pas de trop grosses affaires. Cependant, dès que l'on a des placements, des obligations, des investissement, on perd le fil, sans budget, et l'on s'expose à de gros ennuis, comme la faillite, ou l'on ne tire pas le meilleur rendement de nos avoirs.
Mes analyses peuvent parfois tenir sur un bout de papier, comme le budget d'un étudiant, mais au moins ai-je une idée précise de tout ce qu'il y a à faire pour mener mes projets à terme avec le meilleur des rendements.
La programmation spontanée c peut être bien tout seul ( et encore ... ) mais pas en équipe ( cf toutes les raisons citées précédemment )...j aimerais savoir si c'est utilisé en entreprise, si oui je réviserais mon jugement.
Bien sur que c'est utilisé en entreprise !!!
"-C'est pour quand ça boss ?"
"-Pour hier soir !!!"
C'est le cas typique où j'utilise la prog spontanée.
ça te fais réviser ton jugement ?![]()
Je reformule ma questionest ce que c est utilisé en entreprise dans des cas autres que celui où le travail était à rendre pour hier ou plus généralement qu'on a pas le temps...
La question n'est pas tant de savoir si c'est utilisé en entreprise (où des conneries monstrueuses sont souvent faites) mais si c'es *efficace* dans le cadre de l'entreprise, c'est à dire sur le long terme (genre 10 ans)
J'ai peut etre quelques pb d'orthographe mais je lis encore assez bien le francais et le "peut etre seulement" me semble indique que l'auteur est lui-meme sceptique sur les 10%,mais pas sur les 90% qui croient en faire partie,si j'etais toi j'essaierais serieusement l'autre methode,-artistique et +traditionnelle tu pourrais avoir des surprises.Envoyé par Doloop
Pour ajouter aux autres moi je fais essentiellement des ihm sur BdD.
La derniere en date a une structure partiellement algoritmique.Pour la comprendre il nous a fallu + d'un mois il est hors de question que mes programmes ne possede pas de commentaires .En effet peut etre que mes algoritmes seront clair mais je vois pas en quoi ca aidera la personne qui me suivra a comprendre 1)ce que la base fait 2)ce que j'ai voulu afficher de la base
En plus lorsque le développement se fait en groupe il peut êtr très utile de résumer le fonctionnement d'une "grosse" fonction en 2-3 lignes. ça évite de se taper la lecture de tout le code....
Autre chose utile préciser le variables modifiées par la fonction...
Même si le code est clair ça peut être un gain de temps, en effet "on commente une fois un code mais on peut lire mille fois un code"
Clairement l'extrait cité par Doloop incite à commenter le code, et est un argument contre la "programmation spontannée"
Salut Chromozome,Envoyé par Chromozome
Je fais une réflexion à partir de ce que tu as écris...
Les programmes ne sont plus conçus d'un seul fichier de code. Pour exprimer toute l'ampleur d'un programme, il faut en connaître la structure, puis les composantes. Ce qui souligne encore l'importance d'une bonne analyse documentée.
Alors, les quelques centaines ou milliers de lignes de codes que tu voudrais voir, je les imagine mal. À moins que l'on ait conçu le programme à la manière des années 1970 ou dans un langage de programmation dépassé.
On peut ignorer certaines techniques d'analyse, ce qui inhibe la productivité, mais on ne peut plus ignorer la programmation orientée objet et les librairies de fonctions. Toutefois, pour s'y retrouver, il faut une documentation quand plusieurs personnes travaillent ensemble.
Bien sûr que dans un environnement de développement en solitaire, on n'est pas soumis aux mêmes contraintes qu'en équipe. La documentation revêt alors moins d'importance, préférant investir plus de temps en production pour arriver à répondre à des échéanciers de plus en plus serrés.
Je trouve que le débat oppose les travailleurs indépendants et ceux qui font partie d'une équipe en entreprise. Ce débat porte sur les méthodes de travail. Or, je ne crois pas que la méthode du travailleur indépendant et celle d'un travailleur en équipe dans un entreprise puissent être comparées, puisque les contextes sont différents.
À suivre (peut-être, car il est tard et j'en ai marre)...
Heu... oui et non... Travailleur indépendant ne signifie pas forcément travailleur solitaire. Il faut bien livrer, et même souvent participer à un projet qui implique plusieurs acteurs. L'indépendance n'est pas au niveau du travail, mais juste au niveau de la forme juridique.Envoyé par Claude Pelletier
Depuis que je suis indépendant, j'ai l'impression, en toute modestie, que mes méthodes de travail sont meilleures et plus adaptées au travail en équipe que lorsque j'étais en entreprise..
J'ai été prof de Pascal dans les années 80 (sousCP/M).
Mon argument sur la programmation structurée : Le 1° programme de gestion de l'USAF : 3$/instruction à l'écriture, 2000$/instruction à la maintenance parceque mal structuré (mal écrit).
Enfin on les excuse : en '70 y'avais pas autant de mémoire disponible que maintenant alors les altérations dynamiques et autres ruses ça y allait !
Serge
J'ai lu toute votre prose, et il me semble que personne n'a parlé d'une chose capitale : la programmation n'est qu'une étape dans le développement d'un logiciel. D'ailleurs en Génie Logiciel on parle d'implémentation, et non de programmation.
Je me permets d'illustrer mes propos en présentant mon cas : j'ai appris à programmer seul, avec des bouquins. J'ai ensuite travaillé dans une PME, où je faisais de la programmation robotique, système sympathique parce que multitache et temps réel. Notre approche d'un projet était ce que vous appelez la programmation "spontanée" : peu d'analyse, peu de doc et quand il y en avait elle était faite a posteriori (!), le nez dans la machine, et en avant. C'était passionnant, on avait l'impression de faire corps avec le robot, expérience quelque peu métaphysique parfois. Par contre, chacun avait son style, il fallait plusieurs jours pour rentrer dans un programme. On travaillait seul, les projets étaient petits (<10 000 lignes).
Comme la programmation me passionnait, j'ai fait une école d'ingénieurs en Génie Logiciel, affiliée à un grand groupe industriel. Là j'ai appris le Génie Logiciel. Et là j'ai compris que faire un logiciel ce n'était pas seulement programmer. L'implémentation ne doit théoriquement représenter que 30% du temps du développement, dans un cycle en V classique : spécification, conception, implémentation, intégration, validation.
J'ai appris qu'une spécification et conception font toujours gagner du temps, et que la qualité du logiciel en dépend étroitement.
Aujourd'hui je travaille dans une équipe de 12 développeurs, tous en parralèlle, sur un projet de 1 500 000 lignes. Comment appréhender un projet de cette ampleur en lisant le code ?
En conclusion, je pense que même si on est bon, la programmation n'est qu'une étape dans la réalisation d'un logiciel, que la spécification et la conception sont des étapes primordiales, que la documentation ne peut être qu'obligatoire; le tout dans un contexte industriel, bien sûr.
Certes il faut un cadre autour de la programmation, mais puisque tu semble passioné jette un coup d'oeil sur la méthode extreme programming, qui a surtout d'extreme qu'elle refuse le cycle en V pour lui préférer un peu plus de souplesse, partant du principe qu'une spécification initiale parfaite est impossible. Au début ça choque, après on ne peut plus s'en passer.
Partager