Discussion :

[e-ric]

car dès fois on se demande tout de même si le bon code est recherché. C'est en tout cas l'impression que j'ai quand on me refuse un devis considéré comme trop cher et qu'on me demande si je ne connais pas un jeune qui débute qui voudrais se faire les dents sur le projet.

Et quand le projet va vraiment mal ou qu'il faut le maintenir ou encore parce qu'on se rend compte qu'un programme qui marche ça sert bien aussi, on appelle le pompier de service i.e. un bon développeur qui ramasse toutes les bouses de ses prédécesseurs. Il règne dans le monde de l'informatique, en particulier de gestion, une philosophie selon laquelle la programmation est en quelque sorte du boulot de saisie, sans grande qualification, et que seule la conception prime d'où l'importance accrue des CDP et de la MOA au détriment des développeurs. Ces derniers sont généralement considérés comme des petites mains.

Le problème est que l'un ne va pas sans l'autre une super conception sans une bonne réalisation ne vaut pas plus qu'une réalisation qui tente de compenser une conception ratée. Une absence de conception est parfois préférable car il laisse le champ libre pour un développeur qui connaît son boulot.

la complexification croissante des EDI qui en apportant du confort à des développeurs confirmés ne sont plus à la portée du premier venu. Il n y a qu'à comparer les EDI actuels et celui de TurboPascal 4.0.

Pour rigoler, chez un client, les développeurs micro étaient classés bureauticiens, tout un symbole.

[e-ric]

@fcharton2: De toutes façons, les développeurs mêmes doués, n'ont pas tous le niveau de M Lamport et à quoi cela servirait-il ? à pisser des MOVE dans des programmes COBOL pourris, bonjour l'investissement !!
Il convient plutôt de comprendre au mieux ses outils et les problèmes à résoudre afin d'atteindre une bonne solution, à condition que celle-ci soit vraiment voulue.

[el_slapper]

@fcharton2: De toutes façons, les développeurs mêmes doués, n'ont pas tous le niveau de M Lamport et à quoi cela servirait-il ? à pisser des MOVE dans des programmes COBOL pourris, bonjour l'investissement !!

Plus précisément, LATEX est un outil, et sa philosophie d'applique certainement mieux aux outils qu'aux codes plus spécifiques qu'on trouve en entreprise. On peut avoir des choses très complexes avec juste des MOVE en COBOL, mais la complexité n'est pas mathématique : elle est métier.

Il convient plutôt de comprendre au mieux ses outils et les problèmes à résoudre afin d'atteindre une bonne solution, à condition que celle-ci soit vraiment voulue.

En bref : s'adapter. Et ne pas suivre aveuglément une petite recette prédéfinie, fut-ce par un grand esprit qui LUI a eu besoin de mathématiques avancées.

[atha2]

Il règne dans le monde de l'informatique, en particulier de gestion, une philosophie selon laquelle la programmation est en quelque sorte du boulot de saisie, sans grande qualification, et que seule la conception prime d'où l'importance accrue des CDP et de la MOA au détriment des développeurs. Ces derniers sont généralement considérés comme des petites mains.
Le problème est que l'un ne va pas sans l'autre une super conception sans une bonne réalisation ne vaut pas plus qu'une réalisation qui tente de compenser une conception ratée. Une absence de conception est parfois préférable car il laisse le champ libre pour un développeur qui connaît son boulot.

Le mot Conception peut signifier tout et n'importe quoi (souvent n'importe quoi d'ailleurs ), je vais donc préciser comment je l'utilise ici : analyse du projet qui se déroule avant l'écriture de la moindre ligne de code (à part pour tester une API ou la faisabilité d'un point nécessaire au projet) qui comprend la définition :

• des besoins fonctionnels
• du modèle de donnée (via un MCD(Merise) ou un diagramme de classes (UML))
• des différents traitements à effectuer (régulièrement ou à la demande)
• de l'architecture globale de l'application (diagramme de classes et/ou de package (UML))
• des entrées et sorties de l'application et de leurs formats
• si présente, de l'interface graphique (SNI, Wireframe)

Avec une conception, telle que je la décris, faite correctement, il parait difficile de faire foirer un projet si le développeur suit à la lettre la conception. Le seul problème est que pour que ces étapes soient faites correctement, la personne (CDP, MOA) qui conçois doit avoir une bonne connaissance et maitrise de différents outils (UML, Merise, POO, Forme Normale, XML, SNI...), ce qui à mon avis sont (pas forcément devrait) plus des compétences que possède un développeur.

En soit un conception est nécessaire et si on ne fourni pas une conception correcte au développeur, c'est malheureux à dire mais c'est à lui de la faire/corriger avec le peu d'information qu'il possède. Et après classiquement, si le projet foire, ça retombe sur lui parce qu'il n'a pas assez posé de question ou n'a pas remonter le problème

[fcharton2]

Je n'ai pas cité ce livre qui comme le numerical recipies sont marqués par l'âge...
D'innombrable livres plus accessible sont parus depuis.

Je veux bien des références (ça va être facile, vu qu'elles sont innombrables...)

Personnellement, je dois en être à mon troisième NumRec. J'ai racheté la seconde édition deux fois (mon premier volume a fini par tomber en miettes), puis la troisième, et ça me parait TRES à jour. Mais je dois être très en retard sur mon temps. Quant à Knuth, les dernières version sont très récentes, et rudement à jour. Comme pas mal de textes de référence, ces livres sont réédités régulièrement, et mis à jour (en maths, l'exemple le plus frappant est le Hardy et Wright, en théorie des nombres : la première édition date de 1938, la dernière en date, la sixième, de 2008, et est mise à jour par quelques spécialistes assez renommés)

Mais plus généralement, en maths comme en algorithmique, beaucoup de théories sont anciennes, et certains textes de référence, même s'ils n'intègrent pas les dernières nouveautés, sont toujours d'actualité. C'est une différence de fond entre les maths et les téléphone portables (ou les jeux vidéos)...

Bof, j'en ai pas eu l'impression quand j'ai vu des statisticiens et le data mining...

Les statistiques sont assez formalisées (comme une branche de l'analyse) depuis les années 30 (Kolmogorov et les autres). Quant au data mining, les approches actuelles, qui tournent autour de l'apprentissage automatique (des SVN aux HSIC), c'est TRES matheux. Maintenant, ce sont des maths difficiles, parce que cela part de concepts qui s'apprennent après les classes prépa (l'intégrale de Lebesgue et les espaces de Hilbert, notamment, sans eux, tu ne vas pas loin en probas).

Une lecture des programmes de l’agrégation et du premier cycle universitaire me fait penser le contraire : les bases de grobner sont généralement absentes, les combinatoires datent d'avant ma naissance et n'ont pas profité des développements récents, au niveau supérieur la théorie de Galois est absente...

La théorie de Galois était au programme de l'agrégation de maths il y a quelques années. Cela a peut être changé, mais je ne vois pas très bien le rapport. L'agrégation, c'est un concours servant à recruter des profs de lycée et de classes prépa, et comme tout concours, il se fait sur un programme, nécessairement restreint (les maths c'est très larges). Et puis, ce n'est pas parce qu'il n'y avait pas marqué "bases de grobner", ou "théorie de galois" sur le programme que tu as lu, que ces sujets n'étaient pas étudiés...

J'ai fais des études ( que je regrettes ), et y ai croisé des monstres du même niveau, un exemple : un grand expert (*) de la géométrie-algébrique réelle qui arrivait sans préparer ses cours et qui le jours de l’examen final constatait benoitement que presque personne n'avait compris le trimestre de cours : 6 sur un amphi ont eu la moyenne.Et à la fin des trois heures il nous demandait "mais pourquoi vous n'y arrivez pas?".

Si je te comprends bien, si la moyenne était faible, c'était forcément la faute du prof... Je comprends mieux ta remarque précédente sur les livres "accessibles". J'ai également eu des cours d'un niveau très élevé, ou le prof ne faisait pas beaucoup d'effort, et où la plupart des élèves (dont moi) morflaient à l'examen. Mais en les relisant, quelques années plus tard, je me suis presque toujours rendu compte que c'étaient de très bon cours, et que le problème, ce n'était pas le prof.

Je pense sincèrement que si tu as un numrec ou un knuth sous la main, tu devrais prendre le temps de les lire. Ca ne se lit pas comme un roman, ou si tu préfères c'est la différence entre Katherine Pancol et Balzac, mais ce n'est pas totalement un hasard si on continue à les lire après tellement d'années.

Francois

[Marco46]

Êtes-vous d'accord avec l'expert ?

Un développeur professionnel travaille au sein d'une équipe et doit rendre compte à une hiérarchie qui doit elle-même rendre compte à ses clients.

Dans ce contexte, lire de sa part que le développeur a tord de ne pas planifier c'est oublier que non seulement il ne peut pas forcément, mais qu'il n'en a pas forcément non plus le droit.
Attention je ne dis pas qu'il a tord de dire qu'il faut planifier pour coder propre, je dis que le développeur a très rarement ce pouvoir !

Bref, ce monsieur est à l'ouest.

Et puis quid des tests unitaires et de l'intégration continue qui se mettent en place depuis quelques années ? Ces pratiques pénètrent de plus en plus les entreprises. Aujourd'hui les dernières techno web sont capables de faire de même ( AngularJS ). C'est pas une progression dans la qualité ça ?

Grand respect pour ses créations mais on dirait plus un savant fou dans une tour d'ivoire qui juge la populace sans ne l'avoir jamais rencontrée.

[fcharton2]

@fcharton2: De toutes façons, les développeurs mêmes doués, n'ont pas tous le niveau de M Lamport et à quoi cela servirait-il ? à pisser des MOVE dans des programmes COBOL pourris, bonjour l'investissement !!

Je n'ai pas le niveau de Lamport, mais j'ai du mal à voir mon métier de développeur comme "pisser des MOVE".

Je ne connais pas le COBOL, mais je n'ai encore jamais vu un programme qui ne bénéficie pas d'une bonne modélisation. Cela se traduit presque toujours par du code plus rapide et plus évolutif. Ensuite, on peut évidemment se dire que le client ne fait pas la différence, et que le commercial de SSII s'en fout, voire n'aime pas les programmes efficaces et maintenables, parce qu'ils se prêtent moins à des facturations complémentaires. On peut aussi se dire qu'en tant que développeurs sous payés, on aurait tort de s'embêter... On peut... mais il ne faudra pas se plaindre de se voir délocalisés, ou remplacés par des machines qui "pissent des MOVE".

A mon avis, l'informatique bon marché est appelée à disparaitre, parce qu'elle pourra soit être automatisée (une machine peut produire du code de stagiaire), soit être délocalisée vers des pays à très faible salaire (les chinois sont sur le coup, depuis que leurs salaires non qualifiés sont moins compétititifs). Et la vison de Lamport d'une informatique plus scientifique et plus efficace, c'est NOTRE avenir.

Francois

[el_slapper]

@fcharton2

Moi j'ai pissé des MOVE pendant des années - et il n'est pas exclu que je recommence à moyen terme. Dans plein de cas, dans les grands comptes, la spécification ressemble à un inventaire à la Prévert de choses à faire. "Type de paiement : Si le client a rempli le formulaire, alors il aura un TIP - sauf si le montant ne tient pas dans le préimprimé. Sinon, si il est en prélevement, et en gestion agence, alors....." Et tout ça au kilomètre.

La difficulté, là-dedans, franchement, ça n'est pas la conception de haut niveau, l'architecture, ou la réutilisabilité(de toute façon, tout est tellement spécifique que rien ne sera jamais réutilisé, même si réutilisable). La difficulté, c'est de faire un inventaire lisible, compréhensible, et testable exhaustivement. La difficulté, c'est de garantir que tout a bien été pris en compte. Mais, dans 90% des cas, une bête procédure linéaire est plus que suffisante comme conception. Dans 9% des cas, on a 3 ou 4 cas qu'on sépare, et basta. Effectivement, 1% des cas recqièrent une attention plus soutenue dès la conception, mais on les voit arriver de loin - ou alors on se casse les dents dessus et on se met à faire une vraie conception de haut niveau parceque soudain ça apparait comme nécéssaire(en 9 ans de COBOL, ça m'est arrivé 2 fois; la première fois j'avais vu venir le truc et bien préparé mon coup. La deuxième fois, ça m'est tombé dessus en raison de l'imprécision de la spec).

Mais imagine un projet ou il faut :
_extraire quelques données du référentiel
_éliminer les cas qui ne conviennent pas
_créer des critères de tri
_trier
_restituer sous forme d'un fichier plat trié au format prédéfini

Crois-tu vraiment qu'il faille faire référence aux espaces préhilbertiens réels pour mettre en place le dessin de chaine et la conception de haut niveau??? Non, la difficulté, c'est de ne rien oublier, de s'assurer qu'il n'y a pas d'effets de bord, de gérer les cas à la con, mais pas d'avoir une belle conception. Le reste, c'est du mapping. Et la plupart des projets grands comptes ressemblent à ça. Les algorithmes qui méritent de la conception mathématique sont rarissimes(mais offrent un changement bienvenu).

[fcharton2]

@el_slapper:

A peu près la moitié de mon temps de développement, ce sont des routines de traitement de données, et ca ressemble pas mal à ce dont tu parles... En général, tu récupères un gros tas de donnée en vrac (mais sous un format moderne et verbeux, XML, JSON), que tu dois lire dans un temps raisonnable (ie en une passe), contrôler (sachant que la spec des contrôles à faire évoluera au fil du temps, en fonction des erreurs rencontrées...), puis remettre dans un format tabulaire, filtrer, trier et exporter.

Comme toi, ce sont presque toujours des processus linéaires, mais ça n'exclut pas la conception, et surtout la modélisation, et les maths. En général, les volumes de données augmentent au fil du temps, la qualité tend plus souvent à se dégrader qu'à s'améliorer (au fur et à mesure que les chaînes de production sont réputées "automatisées", et donc ne sont plus contrôlées), et surtout les évolutions sont rares, ce qui signifie que tu auras à reprendre cette chaine dans longtemps, et qu'il vaudra mieux que la structure du programme soit logique.

Et généralement, il y a des maths à tous les étages. Pas d'espaces de Hilbert, mais du dénombrement, parfois des probas pour tester la cohérence des erreurs observées (sur des données, c'est généralement un moyen radical de repérer les bugs), et surtout beaucoup de réflexion sur la façon dont on va organiser le processus, et modéliser les données. Et les maths sont réellement utiles, parce qu'elles permettent souvent, en quelques calculs coin de table, d'éviter de choisir la solution qui va transformer le "petit traitement" en un monstre consommateur de ressources, ou de fusionner en une chaine maintenable, une batterie de petites demandes indépendantes.

Je ne crois pas être le seul à raisonner comme cela: j'en veux pour preuve les exemples des livres des "grands anciens" (à commencer par Knuth). Ce sont presque toujours des problèmes assez banals, issus de la gestion, pour lesquels on peut imaginer une solution brutale et inélégante, ou un truc propre, qui généralement sera rapide, évolutif et maintenable.

Et contrairement à ce qu'on croit, modéliser gagne généralement du temps: le programme met un peu plus de temps à être écrit, mais on économise souvent sur les tests et le débogage.

Francois

[bpy1401]

Bonjour à tous
On sais que dans tout logiciel il y x bugs par ligne de code. Multipliez le nombre de ligne de bugs, vous multiplierez aussi le nombre de bug, et donc les chances qu'ils deviennent plus visible.

La spécification n'empêche pas les bugs, mais elle peut aussi en inclure, et par expérience, j'ai déjà des vu des softs spécifiés qui plantaient plus que les autres.

Remarque de manageurs que j'ai vu.

• Si le programmeur code sans erreur, Cela ne sert à rien de tester un logiciel
• Vu dans un slide pour un démarage projet : Le logiciel ne coute rien.

[el_slapper]

Après, la "qualité", c'est un bien grand mot. Parle-t-on de maintenabilité, de taux de bugs, de fiabilité sous contraintes, de performances(moyennes ou aux limites)?

Préparer ce que l'on va faire, c'est bien, mais ça peut être contre-productif : si il y a une erreur dans la conception, et que chacun essaye de couvrir son derrière au lieu de corriger la conception, on peut vite arriver à des situations ubuesques(vécu : 60 personnes qui tournent en rond pendant 6 ans à cause de ça, quelque part à la défense, parcequ'on a sur-conçu, et que ça ne peut pas marcher si on est conforme, et que le grand chef qui a validé la spec ne veut pas se dédire).

Une grande partie du rejet de ces méthodes vient aussi du découpage vertical des activités(qui est une catastrophe). Si un gugusse(ou une, hein, je suis pas misogyne) fait la conception mathématique préliminaire, et un(e) autre code, il y aura plus de casse que si l'autre avait juste codé au kilomètre. Raison : le(la) deuxième intervenant(e) ne peut pas lire dans le cerveau du premier, et comprendra beaucoup de choses de travers.

Après, pour être honnête, je fais toujours un peu de conception de haut niveau. Dans ma tête, sans aucune formalisation. Je visualise le sujet, je m'en impregne, je visualise des solutions, j'en choisis une, et seulement à ce moment, j'attaque. Ou pas - si c'est vraiment compliqué, papier et crayon m'aideront dans cette phase. Simplement, le discours "il faut concevoir avant de coder" est contre-productif : le manager moyen de la boite moyenne va comprendre qu'il lui faut un concepteur qui ne soit pas le codeur. Ben oui, c'est con, un employé, ça fait un truc...ou un autre. Et on va se retrouver avec des situations ubuesques, des tonnes de docs aussi exhaustives que pourries, des budgets pharaoniques, et des réalisations liliputiennes - quand elles marchent. Tu vois, Fcharton2, tu vois peut-être les avantages, moi je vois surtout les inconvénients(sans doute ma double casquette d'homologateur - le verre est toujours un peu vide, et il me faut le remplir jusqu'à ras-bord, toujours).

Je sais, beaucoup de codeurs de basse qualité ne comprennent rien à ce qu'ils font, mélangent juste des snippets de code trouvés sur internet, font n'importe quoi jusqu'à ce que le résultat ressemble à leur objectif, et se prennent pour des cadors. Mais est-il réaliste d'exiger de ces gens-là qu'ils fassent des conceptions mathématiques impeccables? Je ne le crois pas. Les gens qui savent coder, réellement coder, créer un code un peu compliqué ex-nihilo et en expliquer les moindres recoins, eux, font toujours un peu de conception. Certains la formalisent, d'autres pas.

[Invité]

...

Je suis d'accord !

A mon avis, l'informatique bon marché est appelée à disparaitre, parce qu'elle pourra soit être automatisée (une machine peut produire du code de stagiaire), soit être délocalisée vers des pays à très faible salaire (les chinois sont sur le coup, depuis que leurs salaires non qualifiés sont moins compétititifs). Et la vison de Lamport d'une informatique plus scientifique et plus efficace, c'est NOTRE avenir.

D'après ce que l'on raconte les chinois ont un enseignement basé sur le par cœur, mais vu le nombre qui est venu en occident et qui va ramener des méthodologies plus modernes en chine, ce que vous dites là sera faux dans 15 ans car ils appliqueront ce que nous essayeront de faire mais en mieux.
( exemple des éoliennes, ils n'ont pas inventé mais amélioré celles venant d'europe...).

• Si le programmeur code sans erreur, Cela ne sert à rien de tester un logiciel
• Vu dans un slide pour un démarage projet : Le logiciel ne coute rien.

Brillant !

Personnellement, je dois en être à mon troisième NumRec. J'ai racheté la seconde édition deux fois (mon premier volume a fini par tomber en miettes), puis la troisième, et ça me parait TRES à jour. Mais je dois être très en retard sur mon temps. Quant à Knuth, les dernières version sont très récentes, et rudement à jour. Comme pas mal de textes de référence, ces livres sont réédités régulièrement, et mis à jour (en maths, l'exemple le plus frappant est le Hardy et Wright, en théorie des nombres : la première édition date de 1938, la dernière en date, la sixième, de 2008, et est mise à jour par quelques spécialistes assez renommés)

Il ne faut pas pousser mémé dans les orties! La qualité des livres n'est pas la question première.
Si beaucoup de livres sont parus c'est que ceux-la sont trop "dures" ! Soit ils demandent trop de connaissance, soit trop d'effort voir d'autres raisons, l'exemple du "concrete mathematics" de knuth est l'inverse facile à lire, 700 pages mais chaque chapitre est probant le livre apporte quelque chose d'utile et de réutilisable AU PLUS GRAND NOMBRE contrairement aux livres sus-cité.
Ors le niveau moyen est un facteur de mouvement dans le bon sens.

Mais plus généralement, en maths comme en algorithmique, beaucoup de théories sont anciennes, et certains textes de référence, même s'ils n'intègrent pas les dernières nouveautés, sont toujours d'actualité. C'est une différence de fond entre les maths et les téléphone portables (ou les jeux vidéos)...

C'est vrai mais le monde réel c'est une formation diluée : exemple http://www.amazon.fr/R%C3%A9duction-...3034806&sr=1-2 livre qui a sur sa couverture le commentaire de Pierre Gabriel
"... Je viens de passer la semaine dernière à lire (des parties de) votre manuscrit. Il s'agit bien de fleurs, de beaucoup de fleurs, des fleurs communes et des rares inconnues de moi, un champ de fleurs..."

Il y a un vrai problème de vulgarisation des connaissances.

Les statistiques sont assez formalisées (comme une branche de l'analyse) depuis les années 30 (Kolmogorov et les autres). Quant au data mining, les approches actuelles, qui tournent autour de l'apprentissage automatique (des SVN aux HSIC), c'est TRES matheux. Maintenant, ce sont des maths difficiles, parce que cela part de concepts qui s'apprennent après les classes prépa (l'intégrale de Lebesgue et les espaces de Hilbert, notamment, sans eux, tu ne vas pas loin en probas).

Je sais que c'est une spécialisation de master, mais de nos jours tout le monde devrait connaitre un peu de l'analy se des données http://www.manning.com/pharrington/ par exemple qui est accessible à tous ( mais pas tout à fais ce dont je parlais)

La théorie de Galois était au programme de l'agrégation de maths il y a quelques années. Cela a peut être changé, mais je ne vois pas très bien le rapport. L'agrégation, c'est un concours servant à recruter des profs de lycée et de classes prépa, et comme tout concours, il se fait sur un programme, nécessairement restreint (les maths c'est très larges). Et puis, ce n'est pas parce qu'il n'y avait pas marqué "bases de grobner", ou "théorie de galois" sur le programme que tu as lu, que ces sujets n'étaient pas étudiés...

Je ne vois pas de Galois dans le pdf de 2014...

Ca me gène, car se sont des sujets importants ( base de grobner pas enseigné de bac+1 à +5 dans mon ancienne fac, lamentable ) il ne viendrait pas à l'esprit de qui que ce soit de virer les séries entières, de fouriers,... des programmes de bac+2 mais personne ne veut y mettre les bases de grobner ( même niveau ) qui sont une entrée sur la géométrie-algébrique pour le plus grand nombre sans parler de l'aspect programmation fort difficile, mais celle-ci n'est pas au programme jusqu'à bac+5.

Si je te comprends bien, si la moyenne était faible, c'était forcément la faute du prof... Je comprends mieux ta remarque précédente sur les livres "accessibles". J'ai également eu des cours d'un niveau très élevé, ou le prof ne faisait pas beaucoup d'effort, et où la plupart des élèves (dont moi) morflaient à l'examen. Mais en les relisant, quelques années plus tard, je me suis presque toujours rendu compte que c'étaient de très bon cours, et que le problème, ce n'était pas le prof.

Oui, j'explique si le DEUG avait la moitié d’algèbre, ce n'était pas le cas de la licence ( 3 de nos jours ) où une unité sur quatre pouvait être de l'algèbre ( les trois autres : calculs diff, lebesgue, analyse complexe obligatoires).

Donc oui en temps qu'enseignent il aurait du peser pour favoriser l'apprentissage de l'algèbre.
Que son cours soit bon ou pas, ne compensera pas le manque d'entrainement et de variabilité de l'enseignement. De toutes façons on n'apprend pas les maths dans un seul cours, mais il faut être préparé pour lire des livres et y trouver d'autres approches. Sauf que ces gens se sont habitués aux cours peu volontariste qui envoient des étudiants à l'agrégation ( leurs objectifs en tant que fac ) année où les étudiants doivent apprendre de nouvelles choses
tardivement et les cristalliser pour un concours.
Sauf que paris ne s'est pas faite en un jour.

Je pense sincèrement que si tu as un numrec ou un knuth sous la main, tu devrais prendre le temps de les lire. Ca ne se lit pas comme un roman, ou si tu préfères c'est la différence entre Katherine Pancol et Balzac, mais ce n'est pas totalement un hasard si on continue à les lire après tellement d'années.

Je suis d'accord, mais je ne le ferais pas pour l'instant je me concentre sur mon boulot et les lectures qui vont avec et sur les livres de chez springer (gtm) qui comblent mes lacunes universitaires...

[Luckyluke34]

Avec une conception, telle que je la décris, faite correctement, il parait difficile de faire foirer un projet si le développeur suit à la lettre la conception.

Ca dépend si tu considères comme foiré ou pas un projet ne répondant plus du tout aux besoins fonctionnels ni aux réalités techniques du terrain au moment de sa livraison
Tu connais un projet où une telle conception figée avant même d'écrire une ligne de code s'est au final avérée exacte de A à Z sans nécessiter un seul ajustement au niveau fonctionnel, une seule adaptation à des contraintes empiriques sur le plan technique ?

Personnellement, ça ne m'est jamais arrivé.

[atha2]

Ca dépend si tu considères comme foiré ou pas un projet ne répondant plus du tout aux besoins fonctionnels ni aux réalités techniques du terrain au moment de sa livraison
Tu connais un projet où une telle conception figée avant même d'écrire une ligne de code s'est au final avérée exacte de A à Z sans nécessiter un seul ajustement au niveau fonctionnel, une seule adaptation à des contraintes empiriques sur le plan technique ?

Personnellement, ça ne m'est jamais arrivé.

j'ai jamais dit que je présentait une situation réelle , l'idée était plutôt que le niveau du développeur importe moins si la conception est bien faite. Pour répondre à ta question, je n'ai jamais eu la chance de travailler sur un projet dont la conception était faite telle que le l'ai décris. De manière général, je suis déjà content quand j'ai un cahier des charges

Il est évident que les besoins évoluent en cours de projet. Mais quand je vois le nombre d'erreurs ou trous dans les documents que je reçoit... Là ce n'est plus un problème d'évolution des besoins/fonctionnalité, mais une analyse des besoins/fonctionnalités qui est mal faite au départ. Ce n'est pas la même chose !

[e-ric]

Je n'ai pas le niveau de Lamport, mais j'ai du mal à voir mon métier de développeur comme "pisser des MOVE".

C'est pourtant le cas de beaucoup de développeurs.

Je ne connais pas le COBOL, mais je n'ai encore jamais vu un programme qui ne bénéficie pas d'une bonne modélisation.

Gros veinard !! Où travailles-tu ? Tu peux me coopter ?

Cela se traduit presque toujours par du code plus rapide et plus évolutif. Ensuite, on peut évidemment se dire que le client ne fait pas la différence, et que le commercial de SSII s'en fout, voire n'aime pas les programmes efficaces et maintenables, parce qu'ils se prêtent moins à des facturations complémentaires. On peut aussi se dire qu'en tant que développeurs sous payés, on aurait tort de s'embêter... On peut... mais il ne faudra pas se plaindre de se voir délocalisés, ou remplacés par des machines qui "pissent des MOVE".

Je comprend ton point de vue, mais tout cela me semble très éloigné de ce que j'ai vécu dans ma carrière.

A mon avis, l'informatique bon marché est appelée à disparaitre, parce qu'elle pourra soit être automatisée (une machine peut produire du code de stagiaire), soit être délocalisée vers des pays à très faible salaire (les chinois sont sur le coup, depuis que leurs salaires non qualifiés sont moins compétititifs). Et la vison de Lamport d'une informatique plus scientifique et plus efficace, c'est NOTRE avenir.

Elle disparaît déjà... Et je pense que la vision de Lamport reste très onirique, elle est plus l'exception que la norme. De toutes façons, dans les SSII, la plupart des commerciaux ne comprennent rien à l'informatique.

En outre, imaginer que les pays à bas coût feront toujours les tâches bas de gamme est une grave sous-estimation technique et économique. Les techniciens de ces pays ne sont pas forcément plus cons ou plus mal formés que nous (en Inde j'ai même l'impression que les boîtes forment plus souvent leurs salariés, pas comme les SSII françaises qui ont les poches en peau de hérisson et qui ne connaissent pas le mot investissement). Economiquement, il peut être intéressant de travailler à de basses tâches car on entre chez les clients et on en approfondit la connaissance qui pourra être exploité plus tard pour travailler à plus haut niveau.

[fcharton2]

Je comprend ton point de vue, mais tout cela me semble très éloigné de ce que j'ai vécu dans ma carrière.

Je crois que c'est lié au modèle économique qu'on met derrière le développement. J'ai toujours travaillé pour des éditeurs qui vendaient des logiciels sous licence, et pas du développement à la journée. Dans ce contexte, le développement est un investissement, et tu as intérêt à faire du code propre et bien conçu, parce que c'est toi qui devra le faire évoluer quand il sera vendu (et il a intérêt à se vendre, sinon...)

Je crois que ce que tu as rencontré tient à la conjonction de deux phénomènes. D'abord, il y a la culture SSII, qui se développe un peu partout, qui fait qu'on facture à la journée, et qu'il est parfois intéressant de rendre quelque chose de bâclé (tant que cela respecte la lettre du cahier des charges), sur lequel on pourra faire plein de jours supplémentaires en maintenance (vendue comme évolutive, mais qui sert en fait à corriger le bâclage initial).

Et ceci est aggravé par une vision, poussée par le développement de l'open source, qui fait du développeur une sorte d'assembleur de composants pris ici et là (de roues qu'il n'a pas réinventées, pour reprendre le jargon à la mode). Dans ce modèle, la conception est difficile, parce que l'organisation du programme est souvent dictée par les librairies externes qu'on choisit d'utiliser (souvent pour de mauvaises raisons : tel Framework parce qu'il est à la mode, telle librairie hyper pointue parce qu'un des clients en a parlé en réunion, telle autre parce qu'un des devs voudrait s'y former, telle troisième sur un malentendu...)


Ceci dit, je conçois que mon point de vue est minoritaire, et passablement vieux jeu. J'en veux pour preuve certaines réactions lors d'entretien d'embauche... Beaucoup de développeurs n'ont connu que la culture SSII, et on du mal à s'imaginer en dehors (même s'ils expliquent qu'ils ne veulent plus travailler en SSII...)

Francois

[robinsondesbois]

Pour moi les diagrammes de classes, de séquences, et autre machines à état permettent de rendre le code plus lisible, de mieux comprendre comment à été pensé le logiciel. Cela permet aussi d'anticiper des erreurs de conception ou de voir des incompatibilité entre telle et telle bibliothèques.
Par contre cela n’empêchera pas un développeur de mettre du scotch sur du sparadrap pour que le programme tienne debout.

[ailereve]

On a encore ouvert une porte qui n'était pas fermé et ça donne un article : Bravo !

Plus sérieusement ?
La programmation a toujours été partagée entre les pro et les intuitifs.
Avec le Basic livré sur les PC d'autrefois, on faisait, chez soit, de la "pro-spag" (programmation spaghetti ou programmation ficelle) On lui donnait ce nom parce qu'une fois le code tapé, sans analyse ni structuration, on pouvait à l'aide de "ficelle" ajouter, comme et où on le pouvait, les modifs et rectifications nécessaires à son fonctionnement.

Moralité, par la 'planification' (entendre analyse, structuration, projection etc.) on aurait écrit 50 lignes alors que là on en a 400.

Et les génies de la ligne de code vous disent "non non on a tout en tête... laissez nous bosser, laissez nous nous organiser"

OK, pourquoi pas ?

J'ai été un de ces pisse-ligne de code génial et un extraordinaire analyste. Çà c'était avant... Et un jour un collègue me dit "tient, voilà un sujet à traiter, de suite".
Ok, je prends.
Ce que j'ignorai, comme toutes les grosses têtes vides d'humilité, c'est qu'il a fait de même avec une équipe complète à côté.

Quand j'ai rendu ma copie (environs 8.000 lignes, et pas en Basic cette fois) au bout de quelques temps, le collègue m'a dit : "regarde". Il me tend un petit dossier rendu trois jours après la réception du petit travail. Je l'ouvre et c'était le travail de l'équipe, analysé, dispatché, structuré, projeté, récursifié, etc.

Je vous dis pas la tête que j'ai fait ni la claque humiliante que j'ai reçu. Mais là au moins j'ai compris que l'organisation du travail, son analyse, son déminage, son organisation, sa projection et je passe tout un tas d'étapes de planification, était une nécessité que seul les petit génies pisse ligne et remplis de vanité ne pouvaient accepter.

Depuis, ayant changé ma façon de faire, je suis honoré de ma carrière.

Et pour conclure regardez comment l'un des MMORPG de cette année est en train de se couper les jambes faute d'une véritable planification... Faute d'une véritable étude des taches, des risques quand aux serveurs, etc...

La planification n'est jamais zappée que pour des raisons d'égo et de gros sous. Le client final ne devrait jamais pâtir de ce genre de manquement.

Salutation

[RedGuff]

Bonjour.
La programmation agile (pas de planifications, changements continuels, pas de traces, déresponsabilisations de la hiérarchie, vues à très court terme uniquement...) a fortement baissé la qualité produite.
:beurk:

[patrickdeveloppe]

Tout dépend du plis qu'on se donne. Et entre un amateur et un professionnel la différence est vite faite. Un professionnel prend en compte les exigences de son métier. Et quand l'objectif est d'avoir un truc qui marche, les exigences sont vite battue en brèche puisque mille chemins mènent à rome dit-on. A mon humble avis je pense que pour un projet, il faut toujours une feuille de route ne serait-ce que pour le noyau.