Faut-il simplifier la programmation et revoir ses fondements ? Un journaliste s'essaye au développement

Citation:

---

Envoyé par deadalnix

Je te laisse faire la conclusion.

---

Sauf que tout le paragraphe est intéressant. Pas uniquement les deux passages surlignés !

[edit]
Souviron, il faut bien débuter. developpez.com est un forum d'entraide c'est normal d'y trouver des débutants qui auront des question ou des croyances qui pourront te surprendre.

Mais, je suis d'accord avec vous, utilisez un outil en se disant : "Comme ça je n'ai pas besoin de savoir ce qu'il se passe en dessous", c'est souvent aller droit dans le mur. La magie c'est pour les sorciers pas pour les informaticiens (qui est un métier logique).

Si je prend l'exemple de la génération de code, aujourd'hui il est possible de :
- maitriser le code généré
- modifier le code généré (pour remplir les parties qu'on n'arrive pas à générer
- faire de la génération incrémentale (ou itérative) (en gros, ce n'est plus du one shot) tout en gardant le code écrit à la main.
- garder la traçabilité code généré <-> modèle (et même code généré <-> template de génération).

Par contre, dans mon cas d'utilisation, ça demande des compétences en ingénierie des modèles ce qui n'est pas gratuit ! Pour autant, je pense que le jeu en vaut bien la chandelle.

J'illustre avec un exemple que je connais bien. J'utilise la génération de code au quotidien sur mes projets professionnels depuis 5 ans. Et, oui, pour le "sur mesure" ce n'est pas forcément adapté.
[/edit]

Rassurez-vous, on ne sera pas tout de suite au chômage, car cela fait plus de 50 ans (depuis les travaux fondateurs de Noam Chomsky) que la recherche en IA achoppe sur un point fondamental qui nous sépare de la génération totalement automatique de programmes: les spécifications rédigées en langage naturel.

Le langage naturel est cette chose ambiguë et protéiforme pour laquelle notre cerveau est si doué et les ordinateurs sont si mauvais, malgré les progrès spectaculaires accomplis ces dernières années, notamment sous l'impulsion de Google, de Microsoft et d'IBM. Tant que cet écueil ne sera pas surmonté, aucun risque de voir un jour un logiciel prendre la place d'un développeur. Les systèmes experts sont ce qui a approché le plus de cette utopie, mais, en plus d'être généralement cantonné à un domaine spécifique, le formalisme qu'ils emploient est complexe et il faut un informaticien pour rentrer dans le système les règles énoncées par l'expert du domaine, on est donc loin de l'outil universel accessible au profane...

Ca ne veut pas pour autant dire que le développement échappe à toute tentative de rationalisation, d'automatisation, de normalisation et de gestion du risque. Si ça n'avait pas été le cas, on aurait pas assisté à l'explosion de l'économie numérique (et de ce qui en dérive) des vingt dernières années, et on ne formerait pas d'ingénieurs à ces méthodes et techniques. C'est pour cela que les inévitables diatribes sur les méfaits supposés des frameworks, IDE et autres outils de modélisation me font bien sourire. A part enfoncer des portes ouvertes (un outil mal utilisé donne un mauvais résultat, quel scoop !), il faudra un jour expliquer pourquoi le développement serait la seule discipline à demeurer ad vitam aeternam artisanale...

Ou alors il faut renommer les écoles d'ingénieurs en autre chose. ;)

Citation:

---

Envoyé par GrandFather

(.../...)Ca ne veut pas pour autant dire que le développement échappe à toute tentative de rationalisation, d'automatisation, de normalisation et de gestion du risque. Si ça n'avait pas été le cas, on aurait pas assisté à l'explosion de l'économie numérique (et de ce qui en dérive) des vingt dernières années, et on ne formerait pas d'ingénieurs à ces méthodes et techniques. C'est pour cela que les inévitables diatribes sur les méfaits supposés des frameworks, IDE et autres outils de modélisation me font bien sourire. A part enfoncer des portes ouvertes (un outil mal utilisé donne un mauvais résultat, quel scoop !), il faudra un jour expliquer pourquoi le développement serait la seule discipline à demeurer ad vitam aeternam artisanale...

Ou alors il faut renommer les écoles d'ingénieurs en autre chose. ;)

---

J'ai mis +1 à tes deux premiers paragraphes, mais je suis moins d'accord avec le troisième. On ne forme pas un ingénieur à des techniques, mais à des concepts. Les techniques ne sont que des supports de ces concepts.

Quand j'étais en école d'ingénieur, on m'a appris le "changement rapide d'outil". C'est un concept. Les techniques associées(interfaces de connection des tuyaux de refroidissement, blocage magnétique du moule, stockage informatisé des moules de remplacement) ne me sont d'aucune utilité aujourd'hui, en informatique(je suis rarement amené à mouler mon propre clavier). Le concept, lui, m'a sauvé les fesses deux ou trois fois(en informatique, on appelle ça modularité du code, avec interfaces standards).

Les diatribes contre les "outils modernes" viennent - en tout cas de ma part - du fait qu'on aveugle les "ingénieurs" avec les techniques, sans leur permettre de comprendre les concepts sous-jacents.

Les outils de modélisation, par exemple, sont formidables, mais ne permettent pas d'exprimer la totalité de la conception. Seul le code le peut. A partir du moment ou la modélisation n'est pas le code, il y a des informations de conception qui échappent à l'outil de modélisation. Souvent de bas niveau(par exemple l'implémentation d'une boucle), mais avec parfois un impact important sur le fonctionnement global de l'application.

Et quand on bourre le crâne des étudiants avec des outils de modélisation, sans leur rappeller que ceux-ci ne représentent pas l'intégralité de la solution, on rend lesdits outils - par ailleurs formidables - contreproductifs.

quand à

Citation:

---

il faudra un jour expliquer pourquoi le développement serait la seule discipline à demeurer ad vitam aeternam artisanale...

---

la réponse à ce point précis est à un autre niveau. Par "artisanal", on entend généralement "imprévisible". Et je ne vois pas comment éviter une dose d'imprévisibilité. Pourquoi? Parceque ce qui est prévisible, c'est ce qui existe déjà. Si les hollandais ont construit un pont suspendu de 350 mètres, alors je peux construire un pont de 350 mètres pour le même prix dans les mêmes délais, si j'utilise les mêmes techniques. Si par contre je change de technique, ou si je veux faire un pont de 700 mètres(et que personne n'en a fait avant moi), je vais dans l'inconnu, et j'affronterais des difficultés imprévues.

En logiciel, ce qui existe déjà n'a pas à être refait : il suffit de le copier-coller. Donc on est toujours dans le cas ou soit on change de technique(on va refaire ce vieux nanard inmaintenable en assembleur dans un langage moderne), soit on fait quelque-chose de nouveau. Donc, on est dans l'expérimental. Toujours.

Citation:

---

Envoyé par el_slapper

En logiciel, ce qui existe déjà n'a pas à être refait : il suffit de le copier-coller. Donc on est toujours dans le cas ou soit on change de technique(on va refaire ce vieux nanard inmaintenable en assembleur dans un langage moderne), soit on fait quelque-chose de nouveau. Donc, on est dans l'expérimental. Toujours.

---

Et je te soutiens totalement :)

C'est la raison fondamentale pour laquelle les "normes" appliquées à la lettre et la division taylorienne du travail en info est une aberration conceptuelle : elle est calquée sur une chaîne de production, or la production d'un logiciel est l'équivalent de ce qui se passe dans le bureau d'études, pas sur la chaîne de montage..

De là découle tout..


Car on n'a jamais encore trouvé comment automatiser les Bureaux d'Etudes ..

Citation:

---

Envoyé par el_slapper

Les diatribes contre les "outils modernes" viennent - en tout cas de ma part - du fait qu'on aveugle les "ingénieurs" avec les techniques, sans leur permettre de comprendre les concepts sous-jacents.

---

N'étant plus tout jeune (mais moins vieux que Souviron ;) ), je me souviens qu'au tournant des années 1990/2000 c'était l'inverse qui était reproché aux cursus d'ingénieurs en développement : trop d'enseignement fondamental, et pas assez d'apprentissage aux techniques et outils employés en entreprise (et donc formant des ingénieurs pas assez productifs en début de carrière). On est peut-être tombé dans l'excès inverse, mais le reprocher aux outils et méthodes concernés c'est balancer le bébé avec l'eau du bain.

Mais quel que soit l'enseignement, il faut de toutes façons du temps pour faire un bon développeur. A part pour une fraction infinitésimale de gens naturellement doués (et encore, comme disait Brassens « le talent sans travail n'est rien d'autre qu'une sale manie »), il faut au développeur moyen des années d'effort, d'erreurs et de remise en question pour se considérer vraiment à l'aise dans sa discipline.

Citation:

---

Envoyé par el_slapper

Par "artisanal", on entend généralement "imprévisible". Et je ne vois pas comment éviter une dose d'imprévisibilité. Pourquoi? Parceque ce qui est prévisible, c'est ce qui existe déjà.

---

On commence à disposer maintenant de suffisamment de recul sur l'activité de développement et la gestion de projet pour dégager quand même quelques tendances sur ce qui fonctionne ou pas. Donc, à moins de travailler dans le secteur de la recherche, tout nouveau projet repasse dans les traces d'un ancien dans le même domaine fonctionnel. Changement d'échelle, adoption des conventions en vigueur pour les IHM et les interfaces, tout cela ajoute des difficultés parfois très importantes, mais on revient sur des problèmatiques déjà traitées. Le risque (ou imprévisibilité) en développement porte désormais davantage sur le respect des coûts et des délais, on n'est plus à l'ère des pionniers où tout était à inventer. ;)

Citation:

---

Envoyé par souviron34

C'est la raison fondamentale pour laquelle les "normes" appliquées à la lettre et la division taylorienne du travail en info est une aberration conceptuelle : elle est calquée sur une chaîne de production, or la production d'un logiciel est l'équivalent de ce qui se passe dans le bureau d'études, pas sur la chaîne de montage..

---

Personnellement, je pense que le développement moderne se situe entre ces deux extrêmes : une production basée exclusivment sur des process et l'aggrégation de composants, et une activité intellectuelle totalement « éthérée » et « magique » affranchie de toute méthode. Pas besoin d'un bureau d'études pour générer un module CRUD générique dans une application lambda, mais il faudra toujours un développeur pour y ajouter ce qui ne peut pas être inféré.

Citation:

---

Envoyé par GrandFather

N'étant plus tout jeune (mais moins vieux que Souviron ;) ), je me souviens qu'au tournant des années 1990/2000 c'était l'inverse qui était reproché aux cursus d'ingénieurs en développement : trop d'enseignement fondamental, et pas assez d'apprentissage aux techniques et outils employés en entreprise (et donc formant des ingénieurs pas assez productifs en début de carrière). On est peut-être tombé dans l'excès inverse, mais le reprocher aux outils et méthodes concernés c'est balancer le bébé avec l'eau du bain.

---

Je pense qu'on est presque d'accord, en fait : l'enseignement est loin d'avoir la maturié qu'il peut avoir dans d'autres domaines(en plasturgie, je pense avoir eu le bon équilibre théorie-pratique).

N'en reste pas moins que le culte de l'outil est dramatique : "il suffit d'utiliser UML, et tout est facile" fait des dégats énormes. Alors même que UML est un outil formidable. Dans son domaine d'application.

Citation:

---

Envoyé par GrandFather

Mais quel que soit l'enseignement, il faut de toutes façons du temps pour faire un bon développeur. A part pour une fraction infinitésimale de gens naturellement doués (et encore, comme disait Brassens « le talent sans travail n'est rien d'autre qu'une sale manie »), il faut au développeur moyen des années d'effort, d'erreurs et de remise en question pour se considérer vraiment à l'aise dans sa discipline.

---

Avec une subtilité supplémentaire : certains développent bien avant d'en faire leur sujet d'études. Eux, à 20 ans, ils sont déjà parfaitement opérationnels. Et pas par talent pur.

Citation:

---

Envoyé par GrandFather

On commence à disposer maintenant de suffisamment de recul sur l'activité de développement et la gestion de projet pour dégager quand même quelques tendances sur ce qui fonctionne ou pas. Donc, à moins de travailler dans le secteur de la recherche, tout nouveau projet repasse dans les traces d'un ancien dans le même domaine fonctionnel. Changement d'échelle, adoption des conventions en vigueur pour les IHM et les interfaces, tout cela ajoute des difficultés parfois très importantes, mais on revient sur des problèmatiques déjà traitées. Le risque (ou imprévisibilité) en développement porte désormais davantage sur le respect des coûts et des délais, on n'est plus à l'ère des pionniers où tout était à inventer. ;)

---

Pas d'accord : ce qui devient prévisible(par exemple les standards UI) devient automatisable. On créée des templates, ou n'importe quoi d'autre, et en trois clics on a l'UI - ou tout autre élément standard. Même si l'imprévisible représente de moins en moins d'éléments du produit final, il représente toujours autant de la part d'effort accompli.

Citation:

---

Envoyé par GrandFather

Personnellement, je pense que le développement moderne se situe entre ces deux extrêmes : une production basée exclusivment sur des process et l'aggrégation de composants, et une activité intellectuelle totalement « éthérée » et « magique » affranchie de toute méthode. Pas besoin d'un bureau d'études pour générer un module CRUD générique dans une application lambda, mais il faudra toujours un développeur pour y ajouter ce qui ne peut pas être inféré.

---

Ton CRUD, tu as assez vite un outil pour te le générer, si tu est proprement industrialisé. Parceque c'est standard. C'est la partie inférée(joli mot, j'aime bien) qui va bouffer l'essentiel de ton temps.

Citation:

---

Envoyé par Idelways

Chris Tompkins est un consultant journaliste qui vient de vivre l'une de ces expériences qui poussent certains à remettre en question leurs capacités intellectuelles et prédispositions naturelles pour un domaine qui leur est étranger, tout en scellant dans l'oubli le souvenir de cette tentative.

Mais pas lui !

Chris Tompkins rejette plutôt la faute sur les concepteurs des langages de programmation et remet en question tout le fondement du domaine tel qu'on les connaît.

---

bonjour pas le temps de lire tous les messages..
les journalistes ce sont des catastrophes ambulantes ces personnes !
Ils se permettent d'avoir la Science infuse et de donner des leçons alors qu'ils ne connaissent qu'une partie du problème.

Sinon concernant le sujet , la simplification à tout va en informatique c'est une très mauvaise direction !
J'écris cela parce qu'il y a quelques années on parlait de "RAD" outils de développement rapides
Or le développement d'un projet informatique ça ne se fait pas en 5minutes.
Il ne faut pas que les "décideurs" s'imaginent réaliser un projet info en quelques jours de presta facturées à un client.
Un projet info c'est le développement en lui-même mais aussi tout une phase de test, une assurance qualité etc..

Citation:

---

Envoyé par GrandFather

On commence à disposer maintenant de suffisamment de recul sur l'activité de développement et la gestion de projet pour dégager quand même quelques tendances sur ce qui fonctionne ou pas. Donc, à moins de travailler dans le secteur de la recherche, tout nouveau projet repasse dans les traces d'un ancien dans le même domaine fonctionnel.

---

tout à fait d'accord ; quand on pense que le métier de développeur informatique n'existait pas il y a 30ans ou à peine..maintenant comme tu l'écris on a ce recul pour juger les choses

Bonjour

Donc en fait si je vous suis bien (pas tous mais, la plupart des gens qui s'expriment ici) : les CMS, par exemple, sont des jouets qu'il ne faut pas utiliser ? Voilà, je prends un exemple à l'extrême cette fois-ci.

Non ? Je dois utiliser le bloc note et écrire du HTML/Javascript/CSS ? Même si un CMS pourra répondre à mon besoin et de manière bien plus conviviale ?

D'ailleurs, la simplification ne se limite pas qu'aux outils. Les langages eux même évoluent. Je vais prendre HTML5 en exemple parce que je trouve que les efforts réalisés autour de cette technologie très appréciables ! Lorsque l'on fait une application client/serveur avec un client web, nous sommes amené à avoir des pages Web. Ces pages web comportent des formulaires permettant à l'utilisateur d'entrer des valeurs. Et bien saviez vous que c'était, à nous, pauvre développeurs de vérifier qu'un champs requis était bien renseigné ? C'est à dire qu'il fallait faire un code javascript côté client (je mets de côté la validation côté serveur qui devrait également être faite, bien entendu) pour vérifier que le champs est bien renseigné. Comme, déduit de certains discours, je ne vais pas utiliser un framework proposant une libraire solide pour la validation de formulaire, je vais bien entendu développer la mienne ! Donc problème de départ :
- développer un front end web
Nouveau problème :
- développer un framework de validation de formulaires

On s'éparpille messieurs !

Maintenant, l'utilisateur doit pouvoir saisir une date. Hmmm il y a plein de frameworks proposant un tel composant mais, non, sur dvp.com ils ont dit : les frameworks c'est pour les feignasses. Je vais développer mon propre composant pour afficher un calendrier... (avec i18n et tout le touin touin).

Nouveau problème :
- développer un composant de calendrier en javascript.

Je continue ? Dîtes moi que vous réécrivez tout ! Je ne sais pas combien de temps ça prend de développer un calendrier en javascript (quelque chose de beau et solide, hein ! Avec une bonne gestion de l'i18n... ça doit fonctionner en Chine). En tout cas, je sais combien de temps ça prend d'en réutiliser un éprouvé.

Donc, déjà avant le HTML5, n'importe quel développeur ayant un peu de bon sens aurait réutiliser un composant parce que son métier du jour c'est de développer une application pas de faire des librairies. Heureusement pour nous, le HTML 5 permet de faire ces deux choses banales, et qu'on rencontre dans 99% des applications web, nativement (plus besoin de javascript). Bon... d'un côté je ne pourrai pas certifier que c'est supporté par tous les navigateurs :mouarf:

Voilà, c'est encore un exemple très simple qui montre que le développeur doit pouvoir se concentrer sur le fonctionnel de son application. D'ailleurs cela à beaucoup de valeur pour le client. Vous aurez beau avoir pondu une pépite technique tout le monde s'en moque ! C'est tout juste bon à se faire mousser devant la machine à café.

Donc, je pense que vous devriez mettre de l'eau dans votre vin et espère que personne ne vous prendra au pied de la lettre !

Bon sinon... RAD ça veut dire Rapid Application Development. Il existe une méthode RAD et des outils RAD.

Développer une application rapidement peut être primordial pour le client ! Il y a plein de raisons pour lesquelles il peut avoir besoin d'une application informatique dans des délais très serrés. La première pour, par exemple, ne pas être dépassé par les concurrents (rester compétitif). Je n'ai jamais pratiqué la méthode RAD ni utilisé d'outils RAD pour juger de leurs avantages/inconvénients mais, un client qui veut une application pour hier, ça, je peux le comprendre. Et, d'ailleurs, c'est aussi une des raisons pour laquelle je trouve qu'il est important de simplifier la programmation. Si on peut, dans le même temps, gagner en productivité alors c'est tout bénef !

Quoiqu'il en soit les outils RAD ne sont pas les seuls à promouvoir la simplification du développement. Vous dîtes :
- Les outils RAD simplifient le développement
- Les outils RAD ne sont pas bons parce que <votre retour sur expérience>
=> Donc la simplification du développement n'est pas une bonne direction

Ça s'appelle un paralogisme.


Yann

Citation:

---

Envoyé par Mat.M

tout à fait d'accord ; quand on pense que le métier de développeur informatique n'existait pas il y a 30ans ou à peine..maintenant comme tu l'écris on a ce recul pour juger les choses

---

Les premiers ordinateurs se programmaient tout seul 8O ? je l'ignorais ....

@Yann : Il y a aussi le principe de coeur de métier : si c'est ton coeur de métier, alors fais-le toi-même. Si je suis un importateur de pare-chocs pour 4*4, alors je prends un CMS et je fais au plus vite mon site web. Si je suis Facebook, par contre, je me fais moi-même mon propre outillage. Parceque le site web est mon coeur de métier, et que je dois faire mieux que les autres pour survivre.

Une banque bien gérée crééra ex nihilo sa gestion comptable, mais achetera sa gestion de cafétéria. Une chaine de cafés bien gérée achetera sa gestion comptable, mais développera en interne sa gestion de distribution des cafés. Parceque dans son cas, c'est stratégique. C'est un facteur stratégique qui permet de conquérir des avantages concurrentiels durablement défendables.

Pour revenir à l'exemple de la gestion de dates, dans une banque, on a plein de dates différentes, qui ne sont pas forcément gérées par les modules présents dans les frameworks publics. On peut s'amuser à regérer ça à la main à chaque fois. Ou on peut définir, dans le framework maison, une gestion des dates spécifiques an métier bancaire, qui sera l'alpha et l'oméga de toute gestion de date dans le SI. C'est ça, industrialiser un SI. Et c'est peu prévisible : se dépatouiller avec les dates Target, ça peut amener des surprises...

Et au développement suivant, si on a une date à la noix, pas de souci, on utilise le composant qui va bien. C'est répétitif. Donc c'est industrialisé. Donc ça coutera trois fois rien. C'est la nouveauté qui va couter cher - et qui va être imprévisible.

Citation:

---

Envoyé par el_slapper

@Yann : Il y a aussi le principe de coeur de métier : si c'est ton coeur de métier, alors fais-le toi-même. Si je suis un importateur de pare-chocs pour 4*4, alors je prends un CMS et je fais au plus vite mon site web. Si je suis Facebook, par contre, je me fais moi-même mon propre outillage. Parceque le site web est mon coeur de métier, et que je dois faire mieux que les autres pour survivre.

---

Oui, je suis d'accord avec ça. Je nuance un peu quand même. l'importateur de 4*4 n'utilisera pas le CMS parce qu'il ne comprend rien au Web. Il s'adressera à une "Web Agency" et ce sont les informaticiens de cette "Web Agency" qui choisiront d'utiliser un CMS parce que ça répondra parfaitement au besoin de notre importateur. Si j'insiste sur ce point c'est bien pour dire que le choix de l'outil doit être réalisé par quelqu'un qui s'y connait. Parce que j'ai l'impression, dans cette discussion, qu'il y a un amalgame de fait entre la personne incompétente (pas au sens péjoratif du terme, hein) et l'outil mauvais. Si notre importateur ne connait rien au Web il y a de fortes chances qu'il fasse n'importe quoi avec le CMS.

Citation:

---

Envoyé par el_slapper

Une banque bien gérée crééra ex nihilo sa gestion comptable, mais achetera sa gestion de cafétéria. Une chaine de cafés bien gérée achetera sa gestion comptable, mais développera en interne sa gestion de distribution des cafés. Parceque dans son cas, c'est stratégique. C'est un facteur stratégique qui permet de conquérir des avantages concurrentiels durablement défendables.

Pour revenir à l'exemple de la gestion de dates, dans une banque, on a plein de dates différentes, qui ne sont pas forcément gérées par les modules présents dans les frameworks publics. On peut s'amuser à regérer ça à la main à chaque fois. Ou on peut définir, dans le framework maison, une gestion des dates spécifiques an métier bancaire, qui sera l'alpha et l'oméga de toute gestion de date dans le SI. C'est ça, industrialiser un SI. Et c'est peu prévisible : se dépatouiller avec les dates Target, ça peut amener des surprises...

Et au développement suivant, si on a une date à la noix, pas de souci, on utilise le composant qui va bien. C'est répétitif. Donc c'est industrialisé. Donc ça coutera trois fois rien. C'est la nouveauté qui va couter cher - et qui va être imprévisible.

---

Je ne comprend pas bien le concept de dates différentes mais, je peux tout à fait comprendre le besoin du "sur mesure". J'ai l'impression que c'est cela que tu évoques. Donc, oui, je suis aussi d'accord avec toi, c'est un cas en marge qui mérite le travail d'un développeur.

Par définition, une "industrialisation" du "sur mesure" n'est pas rentable.

ps: industrialisation entre guillemets parce que dans ton exemple vous avez bien industrialisé en créant un framework maison. Mais il s'agit d'un travail interne. Aucune société n'a d'intérêt à sortir un outil industrialisant votre "sur mesure" (pfiou c'est compliqué d'écrire une phrase comme celle ci :) ).

Citation:

---

Envoyé par Bluedeep

Les premiers ordinateurs se programmaient tout seul 8O ? je l'ignorais ....

---

oui d'accord mais ne pas être de mauvaise foi il n'y avait pas autant de salariés que maintenant et pas autant de SSII.
Il y a 30ans l'informatique c'était des gros systèmes qui tenaient sur plusieurs m3 dans une pièce ventilée..

Citation:

---

Envoyé par yann2

Quoiqu'il en soit les outils RAD ne sont pas les seuls à promouvoir la simplification du développement. Vous dîtes :
- Les outils RAD simplifient le développement
- Les outils RAD ne sont pas bons parce que <votre retour sur expérience>
=> Donc la simplification du développement n'est pas une bonne direction

---

je suppose que ces remarques me sont adressées...
oui les outils RAD simplifient le développement ; mais pour les gens qui "décident" et conçoivent les projets informatiques le danger est de croire qu'on puisse réaliser et mener à bien un projet avec un claquement de doigts...un projet informatique c'est pas seulement faire du développement c'est aussi faire des tests fonctionnels, s'assurer de la qualité du code..

Bonjour

Citation:

---

Envoyé par Mat.M

je suppose que ces remarques me sont adressées...
oui les outils RAD simplifient le développement ; mais pour les gens qui "décident" et conçoivent les projets informatiques le danger est de croire qu'on puisse réaliser et mener à bien un projet avec un claquement de doigts...un projet informatique c'est pas seulement faire du développement c'est aussi faire des tests fonctionnels, s'assurer de la qualité du code..

---

D'accord mais dans ce cas je pense que c'est une mauvaise compréhension de la méthode RAD par ces décideurs. En effet, j'ai jeté un coup d'oeil, trop rapide je l'avoue, sur cette méthode et il apparaît que la qualité y tient une place importance.

On peut y lire :

Citation:

---

Le projet est piloté selon un suivi rigoureux des contraintes, des risques et de la qualité technique.
[...]
Le projet est piloté selon un suivi rigoureux de la qualité fonctionnelle (rapport de Focus, suivis des divergences).

---

Je ne peux pas faire une critique de cette méthode mais, visiblement il ne s'agit pas de pondre une application rapidement au détriment de la qualité.

Ou alors cela viendrait plutôt d'une confusion de ces décideurs qui pensent qu'on peut utiliser un outil RAD pour pondre une application sans penser à toutes les activités autres que la réalisation (recueil des besoins, spécifications fonctionnelles, qualités (recettes, tests, ...), ...). Et, cela rejoint ce qu'on disait plus tôt, et que GrandFather a très bien exprimé : "un outil mal utilisé donne un mauvais résultat".

Yann

Citation:

---

Envoyé par Mat.M

oui d'accord mais ne pas être de mauvaise foi il n'y avait pas autant de salariés que maintenant et pas autant de SSII.

---

Pas autant de salariés, c'est sur.
Pas autant de SSII, je ne sais pas car tu avais finalement assez peu de "grosses" et un tas de SSII de moins de 10 personnes.

Citation:

---

Il y a 30ans l'informatique c'était des gros systèmes qui tenaient sur plusieurs m3 dans une pièce ventilée..

---

Là, tu confonds les époques.

Dans les années 70, oui, c'est vrai.

Au debut des années 80, tu avais les premiers micro qui arrivaient (je ne parle pas que des PC), qui ne nécessitaient pas de clim, qui fonctionnaient en réseau, (avec des systèmes comme Xenix, MPM 86, CTOS, etc ... )et certains "mainframe" du début des années 80 (Burroughs B95 par exemple) tenaient sur une table.(avec de gros pieds ....)

Alors pour l'exploitation dans les grosses boites, bien sur tu avais les mainframes qui nécessitaient un salle dédiée, mais aussi des versions "mini" de ces mainframe pour les PME ou pour le développement.

[QUOTE=yann2;6915518(.../...)

Je ne comprend pas bien le concept de dates différentes mais, je peux tout à fait comprendre le besoin du "sur mesure". J'ai l'impression que c'est cela que tu évoques. Donc, oui, je suis aussi d'accord avec toi, c'est un cas en marge qui mérite le travail d'un développeur.

Par définition, une "industrialisation" du "sur mesure" n'est pas rentable.

ps: industrialisation entre guillemets parce que dans ton exemple vous avez bien industrialisé en créant un framework maison. Mais il s'agit d'un travail interne. Aucune société n'a d'intérêt à sortir un outil industrialisant votre "sur mesure" (pfiou c'est compliqué d'écrire une phrase comme celle ci :) ).[/QUOTE]

Pour les dates, c'est normal, tant qu'on a pas mis son nez dedans, on ne voit pas. Mais il y a bel et bien besoin de gestion de date sur mesure.

En fait, il y a deux types d'outils : extérieurs, et intérieurs. Dans les deux cas, il permettent de simplifier des opérations répétitives. Si je créée un simulateur du moyen âge, je prend un composant extérieur de gestion de dates, et basta. On industrialise. Sinon, si ça ne suffit pas, on fait en interne.

Mais là ou on diverge vraiment, c'est quand tu dis "c'est un cas en marge". En fait, 90% de notre boulot, c'est de la marge. Prenons l'exemple d'une banque. Bon, on va dire que la compta et 2-3 autres trucs marchent bien. Maintenant, de temps en temps, un chef a besoin de savoir ou il en est de ses ventes de prêts subprime. Alors il demande à l'informaticien de faire quelques requêtes. Si la demande devient régulière, l'informaticien va lui mettre en place un mécanisme automatique. C'est une industrialisation, qui demande pas mal de boulot(même si on utilise des produits tiers comme BO).

Puis le chef veut contacter des clients. Au début, il le fait à la main. Puis il en a marre, et l'informaticien lui met en place une automatisation. Etc.....

Ce que je veux dire par là, c'est que nous passons notre temps à industrialiser les choses. Soit le boulot de notre client(du banquier au wargamer), soit le notre, en mettant en place des systèmes qui nous permettrons d'avancer plus vite. Mais pas de faire le boulot automatiquement. Si j'ai un nouveau projet qui a besoin de mon module de date Target, certes je n'ai pas à m'embêter avec ces dates, mais tous le reste est nouveau, et il faut le coder. Et, si il est susceptible d'être réutilisé, l'industrialiser. Mais au final, nous allons faire 90% d’expérimental. Si nous faisons moins, nous nous répétons, et donc nous n'avons pas correctement industrialisé là ou c'était pertinent. Notre boulot, c'est d'industrialiser, pas d'utiliser à longueur de journée nos industrialisations. Si ça nous prend la journée, c'est que c'est mal industrialisé.

Citation:

---

Envoyé par Bluedeep

Là, tu confonds les époques.

Dans les années 70, oui, c'est vrai.

---

ok mais je ne voulais pas parler d'une époque précise je voulais dire de manière vague..c.a.d. il y a quelques temps.
Est-ce que du temps de l'homme de Néandertal l'informatique existait ?
Sinon ok tu as parfaitement raison je suis dans l'erreur totale..

Citation:

---

Envoyé par yann2

Je ne peux pas faire une critique de cette méthode mais, visiblement il ne s'agit pas de pondre une application rapidement au détriment de la qualité.

Ou alors cela viendrait plutôt d'une confusion de ces décideurs qui pensent qu'on peut utiliser un outil RAD pour pondre une application sans penser à toutes les activités autres que la réalisation (recueil des besoins, spécifications fonctionnelles, qualités (recettes, tests, ...), ...). Et, cela rejoint ce qu'on disait plus tôt, et que GrandFather a très bien exprimé : "un outil mal utilisé donne un mauvais résultat".

Yann

---

c'est précisément ce que je voulais signifier :D

Citation:

---

Envoyé par Mat.M

ok mais je ne voulais pas parler d'une époque précise je voulais dire de manière vague..c.a.d. il y a quelques temps.

---

Ok, mais quand on écrit :

Citation:

---

quand on pense que le métier de développeur informatique n'existait pas il y a 30ans ou à peine..

---

Ca désigne quand même une époque précise, non ? surtout quand on parle d'une technique qui n'a guère plus de 60 ans (si on exclut les calculateurs analogiques du périmètre), 10 ans en plus ou en moins ça compte.

Il y a 50 ans, je t'accorde que le métier de développeur n'existait quasiment pas; il y a trente ans, en revanche, on avait des SSII(on disait plutôt SSCI),des développeurs (on utilisait pas non plus ce terme, et on stratifiait entre programmeurs, analystes programmeurs, programmeur systèmes, analyste, etc ... sur mon premier bulletin de salaire en 85, c'était marqué "analyste stagiaire" - pourtant c'était un CDI, pas un stage).

Alors que dans un autre domaine, par exemple la verrerie, une erreur de cent ans n'a pas le même impact descriptif.

Citation:

---

Est-ce que du temps de l'homme de Néandertal l'informatique existait ?

---

Je ne sais pas, on a perdu les données.:aie: