La Pierre de Tear fait peau neuve ! L'aventure continue sur www.pierredetear.fr !
L'ancien site est a présent archivé pour la postérité et en mode "lecture seule". Vous pouvez consulter l'ensemble du contenu et des anciennes discussions du forum,
mais plus créer de nouveaux topics ni écrire de nouvelles réponses.
N'hésitez pas à rejoindre le Discord de la Pierre de Tear en cliquant ici: Discord Pierre de Tear
- L'équipe des Admins: Klian, Owyn et DS
Révolution Informatique !!!
(Sujet créé par Caramon Bornhald l 24/03/04 à 19:00)
Il y a eu les langages web les plus simples. Puis le langage Java modernisé a pris la place dans le monde de l'entreprise. Au lieu de se tourner vers des solutions PHP gratuites et efficaces, on se tourne vers du Java gourmand mais structuré. On parle de propreté de code, de maintenabilité. Les informaticiens sont devenus avec de tels langages des gens capables de maîtriser des couches et des surcouches, et des surcouches de validation de celles-ci, à un tel point que les équipes nécessaires ont grossies, les erreurs augmenté, les besoins également, alors que la demande elle..... est restée la même !
Je viens ici exposer, aux informaticiens mais aussi aux autres qui s'y intéressent, mon opinion très originale sur la question... n'hésitez pas à réagir.
Moi il y a un aspect de l informatique qui "m amuse", c est le fait que la programmation est devenu une langue en soit.
Et elle influence les autres languages du quotidien.
Ainsi on communique en simplifiant toujours plus.
Une autre consequence par rapport au chinois. Le language informatique est structure autour de codes. Et on code selon l alphabet... DOnc les informatitiens chinois codent en Anglais. A long terme cela peut amener a des changements dans le chinois? la mise en place d un alphabet?
Je tiens à rappeler, pour compléter le sujet, que je parlerai ici d'applications de gestion. Oui, et encore un post avec des allures de roman mais j'espère que certains apprécieront ce petit moment de détente, malgré les points techniques.
Je dirai aussi carrément que je vais aborder un sujet qui me révolte dans le monde de l'entreprise, que je parlerai carrément de choses qui me font poser de sérieuses questions sur de nombreux experts informatiques. Comme ils ont les compétences et connaissances, j'espère que l'un d'entre eux viendra, et sera capable de prendre du recul pour discuter de ce sujet.
L'informatique a toujours été, de tous temps :
- La présentation de l'information
- Le traitement de l'information
- Et dans le monde des applications de gestion, un excellent moyen d'appliquer des règles de gestion sur ces informations.
Depuis 20 - 30 ans, dans les applications de gestion, les règles de gestion n'ont absolument pas changé. Les informations elles-mêmes non plus, ni de forme ni de contenu. Pour preuve, les bases SQL sont restées rigoureusement les mêmes (je ne parlerai pas des exceptions).
Elles répondent déjà aux besoins des gestionnaires.
Les traitements appliqués à ces informations (ceux incontournables, nécessaires à l'implémentation des règles de gestion) sont eux aussi restés rigoureusement, exactement les mêmes.
La présentation des informations elle a beaucoup évolué. Mais en soit, cela reste un moyen de présenter les informations et faciliter leur exploitation. Le langage web a apporté beaucoup pour s'affranchir des limites de vieux langages poussiéreux comme 4GL et COBOL, etc.
Les vieux langages...
Je ne parlerai pas ici pour défendre ces vieux langages : ce qui est insupportable avec eux n'est pas tant un problème de performance, de lourdeur de programmation ou même de présentation : le principal problème est l'impossibilité qu'ils ont à gérer bien des situations. C'est à la limite du :
"ah désolé votre texte ne peut être écrit que par lignes de 80 caractères maximum", ou de répondre à la maîtrise d'ouvrage (celle qui passe commande des applications) :
"non faire ça est impossible !"
Le mot impossible devrait être à bannir de bien des situations. Malcommode, peu performant, non recommandé, voilà qui est normal. Mais en 4GL par exemple, bien des choses sont impossibles. C'est pourquoi je tiens à préciser que non, malgré ce que je vais exposer plus bas, je ne défends pas ces vieux langages.
Le langage Java et l'Architecture n-tiers
Je ne vous ferai pas un exposé technique car ce serait encore plus sortir du sujet même du débat. Mais je vais quand même être obligé d'expliquer un peu, peut-être d'ailleurs que cela aidera certains futurs informaticiens.
En gros, le principe du Java a des qualités que je n'expliquerai pas : émulation d'une machine virtuelle, organisation, etc. Je dirai cependant que l'émulation d'une machine virtuelle est devenue non nécessaire dans le monde web, qui s'affranchit déjà de ces limites. Et l'organisation, on peut se l'imposer. C'est juste que le Java en impose déjà une par lui-même. Pourquoi pas. Donc, on résumera Java à un langage imposant une organisation démesurée (si cela choque certains connaisseurs, je leur lance une HumourException ) .
L'Architecture n-tiers elle pourrait s'appliquer à d'autres langages que le Java. L'un de ses exemples, dans le développement d'applications, consiste à appliquer un design pattern (schéma de conception, une organisation). Ici dans mon exemple le modèle MVC. En gros, on distingue plusieurs parties dans une application : la partie Vue (écran), la partie contrôleur (qui effectue les contrôles, et envoie vers un écran dans le cas valide par exemple et à d'autres dans d'autres cas) et la partie Modèle (dite partie métier), qui gère les accès et traitements avec la base de données.
Donc trois parties.
Et du coup, l'équipe de développement se trouve scindée en trois.
Trois expertises.
- Une équipe d'analyse, qui en gros contiendra des gens incapables de développer des programmes (je fais de l'humour ici, c'est parfois vrai, mais ce qui est certain c'est qu'à mon travail c'est à 90 % le cas - même si j'en ai fait - pas grave, c'est l'objectif en analyse, de ne pas avoir à connaître le reste), mais qui s'estiment capables d'analyser les demandes de la maîtrise d'ouvrage pour réaliser des documents de présentation des informations. C'est leur mission, entre autres choses. Le chef de projet appartient bien sûr à cette catégorie. A noter que dans l'architecture n-tiers l'analyse n'apparaît pas, il s'agit évidemment d'une notion par-delà l'application.
L'analyse s'occupe de traduire les règles de gestion en documents, et de présenter l'application et ses règles en documents. Ils font aussi des choix. En fait, on estime que ce sont les seuls ici à avoir un véritable cerveau.
- Une équipe s'occupera du développement de la partie communiquant avec la base de données. En langage Java, ce sera l'équipe EJB. Ils utiliseront des objets complexes mais optimisés pour utiliser les mêmes requêtes somme toutes qu'il y a 20 ans.
- Une équipe s'occupera de l'assemblage, c'est-à-dire du développement des écrans et des contrôleurs.
Je n'ai pas ici parlé de l'équipe de maquettage qui s'occupe de faire des écrans de présentation. Des écrans, c'est beaucoup plus parlant pour nos clients, ça se comprends.
On reprends. Plein d'équipes, et une seule avec un vrai cerveau.
A la rigueur, c'est un principe qui marche bien si les personnes mises en analyse ont une bonne expérience, de bonnes idées, et un bon sens de la communication.
Ils l'ont appliqué à mon service dans le public.
Ils ont recruté en express des gens du privé, les ont même souvent titularisé "ingénieurs de recherche" pour cela - pour qu'ils puissent encadrer les autres informaticiens, qui sont déjà ingénieurs d'études - et les ont placé chefs de projet. Des personnes pourtant totalement étrangères à la boîte et à son fonctionnement. Et même, des personnes totalement étrangères aux moindres notions de la nouvelle architecture, mais qui s'estimaient capables de tout car "elles avaient déjà programmé du Java", et étaient très compétentes selon elles.
Gens du privé qui par contre n'ont aucune qualité humaine (ce qui n'est pas forcé, je connais plein de types bien dans le privé !), aucun bon sens, qui sont comme l'exemple que je donnais dans "la vie de tous les jours".
Donc, du coup, l'analyse (le cerveau) n'a plus aucune capacité de communication ou de remise en question. Les gens s'y engueulent à longueur de temps, claquent les portes, font bande à part, puise une personne (la chef de projet) décide des choses.
Ensuite, les autres équipes doivent développer les décisions prises.
On programme.
Des problèmes humains et techniques : les java-merveilles !
Le Java rajoute des couches et des surcouches au-dessus de ce qui est incontournable. On perd du temps. On développe des expertises, on acquiert des compétences.
On devient des développeurs qui sont de moins en moins utiles aux gestionnaires, qui n'ont que faire de ces règles et surcouches. On devient de plus en plus des 'experts'. Donc, de moins en moins un cerveau décideur.
Et pourtant, on a pas changé. On voit les erreurs d'analyse.
On les signale. Mais non, ce n'est pas nous qui décidons, ce n'est à la rigueur même pas nous qui parlons. C'est le chef. Les erreurs d'analyse créent ensuite des problèmes aux développements ; on peut facilement tourner les choses pour dire, ce sont des problèmes de développeurs !!!
Résultat, comme le grand patron appuie la chef de projet (le grand patron aussi, n'a plus à avoir besoin de comprendre ; seul est besoin de décider) des gens sont virés, d'autres dégoûtés, les compétences et qualités humaines disparaissent.
On pense faire bien. On se fait engueuler pour des problèmes de performances. Somme toutes, quelque soit le processeur de votre serveur, le Java en utilisera 100 %. C'est que c'est compliqué, la machine virtuelle qui ne sert plus vraiment. Mais le Java, c'est une décision ministérielle. On ne peut pas dire du mal des décisions ministérielles, comme toutes les décisions, elles sont BIEN parce qu'elles ont été DECIDEES. Point. Et les seuls à pouvoir contester leurs décisions sont ceux qui les ont prises, ou les gens au-dessus d'eux. POINT.
Ces mêmes gens sont définis comme incapables de comprendre les impacts techniques de leurs décisions : ce n'est pas leur rôle. Tout ce qu'ils veulent, en cas de problème, c'est une réponse peu importe s'il s'agit de la bonne.
Un problème survient ; il est forcément technique ; il vient donc forcément des développeurs.
Ne dites pas à l'analyse que si l'application allait connaître des milliers d'utilisateurs simultanés, c'était un point qui impliquait beaucoup de contraintes, de penser l'application très différemment. D'ailleurs, c'est même un point qui n'a pas été signalé aux développeurs pendant les six mois de développement de l'application, où on leur avait dit qu'il y aurait dix utilisateurs simultanés ; à quoi bon leur dire la vérité ? ils n'ont pas d'intelligence, ils ne portent aucune décision. Ma chef de projet elle-même appelle ça "pisser des lignes de code".
Inutile que je poursuive là-dessus. Vous avez compris l'essentiel de ce point.
Tout est communication et qualité humaine. Avec un chef sans ça, vous allez dans un mur. Je dois vous avouer qu'on s'est pris pas mal de murs dans ma boîte, pour voir à chaque fois les nouvelles décisions être pires que les anciennes.
Des notions plus utiles !
Maintenant je vais prendre plus de recul par rapport à tout ça. Plus de recul, et moins de hargne ; ma situation personnelle n'est pas celles de tous et il doit y en avoir qui profitent à fond des nouvelles règles et organisations.
Avant, on avait une petite équipe : trois fois moins de personnes, car trois fois moins de pôles et d'expertises. On avait plus des gens à tout faire.
La notion d'expertise (on fait une équipe dédiée à une partie) est censée assurer une notion de qualité.
Le langage Java permet de s'assurer du respect de normes et d'organisation, et permet justement de faire des choses dites 'propres'.
Tout cela ayant pour objectif de faire des applications plus propres, plus performantes, plus maintenables.
Maintenabilité augmentée grâce aux normes et à l'organisation. Propreté augmentée par ces mêmes choses, et performance assurée par cela également.
Oui, parce que sans ça, un programmeur fera les choses à sa façon, un autre à la sienne, sans savoir que telle procédure plante avec telle situation, ou en écrivant ses programmes de façon illisible, inexploitable, inmaintenable.
Voilà pour la partie visible de l'iceberg !!!
Parlons maintenant de la partie moins visible.
Je ne conteste pas l'intérêt des normes et de l'organisation : c'est indéniable, c'est le point fort.
Mais définir des expertises, qu'est-ce que ça implique ?
Que votre code programme sera meilleur ?
Non, car la nécessité de l'expertise vient du langage Java et justement de ses complexités. D'autres langages sont moins complexes. Le PHP reste idéal. Que le langage soit complexe implique que même un expert pourra se planter. Avec Java, ce qui est merveilleux, c'est qu'on aura des experts, des super-experts, etc.
Que l'application sera plus maintenable ?
Allez, tout le monde dira oui, l'application a été faite de façon normalisée. Mais en fait non, ABSOLUMENT PAS MAINTENABLE, pour deux raisons :
1 - quand vous aurez besoin de la faire évoluer ou de la corriger, vous devrez faire appel à quelqu'un disposant de la bonne expertise. Vous devrez faire appel à une partie spécifique de l'assemblage, et lui ne pourra corriger le problème s'il s'aperçoit que ça vient de la partie métier (l'autre partie, celle de l'interface avec la base de données) . Et vice versa. Bien sûr, le problème vient aussi parfois de l'analyse, mais ça seule l'analyse est à même de le décider.
Alors du coup, en cas de bug, soit vous faites appel à trois personnes (une de chaque expertise) pour en assurer la correction, soit vous faites appel - et c'est plus souvent le cas - à quelqu'un de vraiment compétent, capable de voir et corriger le problème quelqu'en soit l'origine. Bref, quelqu'un qui sait tout faire.
Bref, comme auparavant, une seule personne pour ces trois notions.
2 - La visibilité de l'erreur elle-même disparaît complètement. Elle disparaît dans les couches et surcouches Java, disparaît car coupée en trois parties. Il y a trois parties, autant de parties supplémentaires à tester, et parmi ces trois parties une séparation. En gros, si l'erreur vient de l'interface avec la base de données, je serai incapable de le voir avant d'avoir tester tout le reste. Et comme moi, qui fait de l'assemblage, ignore tout de ce qui se passe là-bas - c'est le principe ! - je serai ensuite obligé de faire appel à quelqu'un de cette expertise pour vérifier sa partie.
Lui vérifiera, ne trouvera peut-être pas, me demandera de vérifier la mienne, c'est merveilleux, on perd 5 fois plus de temps !
Pour la petite info, avant, on avait participé à la réalisation de toutes les parties, du coup la visibilité était totale (pour peu qu'on ait tout bien codé).
Les conclusions !
Oui, enfin !
Je parle trop moi !
Les conclusions sont :
Le langage Java, l'architecture n-tiers, les expertises, les séparations de compétences dans une application, sont tout un monde merveilleux, mais pas si merveilleux.
Les applications ont les mêmes besoins qu'avant. Les réponses à ces besoins ont changé : pendant un temps, le web améliorait tout, puis à mon travail, on implique désormais des solutions plus coûteuses en temps, en compétences, en personnes.
J'ai vu une solution à tout cela.
L'organisation est une chose à prendre.
Distinguer les parties dans une application est également à adopter. Mettre les requêtes et accès base à un endroit, les écrans avec leur fonctionnel à un autre, l'intelligence de navigation entre les écrans à un troisième. C'est idéal pour organiser les choses, programmer des évolutions, ou même comprendre ce qu'à écrit un autre.
Les normes d'écriture des programmes, c'est à prendre aussi.
Mais le langage Java ? Ca ne sert à rien. Le PHP est plus rapide et n'ajoute pas des couches et des surcouches qui ne seraient que de l'auto-masturbation informatique.
Son problème (au PHP) est qu'il est également plus libre. On peut tout faire avec du PHP, y comprit des choses complètement pas propres et non structurées. Alors c'est simple, on définit une architecture appliquée au PHP, des normes, une organisation, des façons performantes d'appliquer tout cela.
Et je peux vous le dire, ça fonctionne !!!
Du coup, n'importe qui peut reprendre les programmes PHP et le comprendre. Tout est transparent. Même l'architecture est transparente, alors qu'en JAva cela nécessite des semaines d'étues. Meilleure maintenabilité. Meilleure évolutivité des traitements. Meilleures performances car le PHP est plus rapide et consomme moins de mémoire. On le dit peu sécurisé, mais il existe des moyens sécurisés de programmer en PHP.
Alors la question est : pourquoi ??? pourquoi le monde de l'entreprise prône l'utilisation de Java ? pourquoi n'y a-t-il que lui ? alors que le PHP est gratuit ?
J'ai même compris, alors qu'il y a des années ce n'était pas le cas, que même la programmation objet ne sert à rien (ou pas grand chose) pour les applications informatiques de gestion (et de gestion uniquement, évidemment !).
Bon, reprenez votre souffle.
Désolé d'avoir écrit tout ça. Je supprimerai bien le tout, mais maintenant que c'est écrit...
Caramon >>> Ce qui m'amuse le plus c'est que le langage Java est devenu un langage au sens propre.
Même littérairement parlant : c'est une langue qui parlée par quelqu'un, n'est absolument pas comprise par quelqu'un d'autre ne l'ayant pas apprise. Et c'est même une langue totalement hermétique, car l'apprendre est complexe.
Là où d'autres langages sont en fait des moyens de simplifier l'écriture des programmes tout en offrant la liberté, le langage Java est très près de n'offrir aucun des deux.
(bing ! voilà que Méliane se dira : lui sur un CV, je le mets anarcho-informaticien ! )
Voici le post en version censurée des choses inutiles :
L'informatique a toujours été, de tous temps :
- La présentation de l'information
- Le traitement de l'information
- Et dans le monde des applications de gestion, un excellent moyen d'appliquer des règles de gestion sur ces informations.
Depuis 20 - 30 ans, dans les applications de gestion, les règles de gestion n'ont absolument pas changé. Les informations elles-mêmes non plus, ni de forme ni de contenu. Pour preuve, les bases SQL sont restées rigoureusement les mêmes (je ne parlerai pas des exceptions).
Elles répondent déjà aux besoins des gestionnaires.
Les traitements appliqués à ces informations (ceux incontournables, nécessaires à l'implémentation des règles de gestion) sont eux aussi restés rigoureusement, exactement les mêmes.
La présentation des informations elle a beaucoup évolué. Mais en soit, cela reste un moyen de présenter les informations et faciliter leur exploitation. Le langage web a apporté beaucoup pour s'affranchir des limites de vieux langages poussiéreux comme 4GL et COBOL, etc.
___________________________
Il fut un temps où tout a été beau : des applications légères en client / serveur, des applications comme tout un chacun peut faire et comprendre.
Mais depuis pas mal de temps, dans le monde de l'entreprise, on parle surtout du langage Java. Un truc super coûteux, super lourd, que pourtant j'utilise depuis longtemps maintenant.
Le Java rajoute des couches et des surcouches au-dessus de ce qui est incontournable. On perd du temps. On développe des expertises, on acquiert des compétences, mais qui en fait ne servent au final qu'au Java. Si, on gagne quelque chose : quand on ne fait plus de Java, on trouve le reste beaucoup plus simple.
Moins structuré aussi, mais plus simple.
Le PHP est plus rapide et n'ajoute pas des couches et des surcouches qui ne seraient que de l'auto-masturbation informatique.
Son problème (au PHP) est qu'il est également plus libre. On peut tout faire avec du PHP, y comprit des choses complètement pas propres et non structurées. Alors c'est simple, on définit une architecture appliquée au PHP, des normes, une organisation, des façons performantes d'appliquer tout cela.
Et je peux vous le dire, ça fonctionne !!!
Alors la question est : pourquoi ??? pourquoi le monde de l'entreprise prône l'utilisation de Java ? pourquoi n'y a-t-il que lui ? alors que le PHP est gratuit ?
Moi ce que j'ai compris, c'est que le macro-monde des entreprises fonctionne un peu comme celui de la politique. Il est rempli de mensonges, de mensonges qui sont devenus vérité parce que c'est "quelqu'un d'expert qui le dit !". L'expert n'y est pour rien, il y a du vrai dans ce qu'il dit, et de l'invisible qu'il ne voit pas. Les exemples concrets sont nombreux dans ma boîte...
Mais pourquoi ne pas se tourner vers les solutions vraiment efficaces ? celles qu'on voit efficaces quand on est là tout en bas, et qu'on voit comment ça marche...
Le PHP est gratuit, donc il entraîne un groupe de personnes sympas... mais pas une entreprise capable d'appuyer avec de l'argent des formations (ce qui implique qu'il y en a besoin) et des produits (moins performants que les libres d'ailleurs) et des magazines d'expertise remplis de mensonges. Le Java, c'est payant (enfin en tout cas l'éditeur JBuilder - pour faire du JAva, fait par ceux faisant le Java - l'est à 300 %), et l'argent, ça a ce pouvoir. Le pouvoir de transformer un mensonge en nécessité absolue, et d'appliquer des instruments de torture informatique là où il n'en était pas besoin.
Donc, on résumera Java à un langage imposant une organisation démesurée (si cela choque certains connaisseurs, je leur lance une HumourException )
Non non aucun pb.
Alors je vais apporter mon grain de sel (de sable dans l'engrenage ?) sur Java.
1) Mettre une classe complètement définie par fichier :
C'est débile ! C'est inutile du point de vue organisation, ça empêche d'avoir une vue synthétique de la classe si on veut pas l'implémentation (regardez un .h en C++ ...). En plus, les exemples Sun fourmillent de classes imbriquées voire de classes imbriquées anonymes pour compenser cette erreur de conception du langage !
2) Pas de pointeurs sur fonctions :
Dommage on éviterait des centaines (sur un petit projet) voire des milliers (sur une application d'entreprise) de lignes de code inutiles.
3) La JVM, révolutionnaire :
Oui bien sûr le concept a été inventé à la fin des années 70 pour le Pascal.
4) La librairie de classes :
Super idée ! Pourquoi il y a des modules à part ? (Java3D ...)
J'arrête ! Je déteste le Java. C'est lourd, inélégant, inefficace.
Sinon anecdote vécue la semaine dernière, à propos des magies de la détection de bug.
Je bosse en binôme sur un projet (applet Boïds). Bon j'ai d'abord fait un moteur Java2D pour afficher des triangles en guise de poissons. Je développe ensuite un moteur Java3D (pouah !) pour mieux afficher mes pitits poissons. Bon. Ensuite je veux connecter l'un et l'autre : l'applet déjà programmée, et mon code Java3D. D'abord rien d'affiché. OK c normal. Ensuite j'ajoute mes poissons. Oh j'ai plein de cones qui s'affichent. Mais pourquoi ils bougent pas ? Ah oui je ne mets pas à jour le moteur. OK je mets à jour. POURQUOI CA BOUGE TOUJOURS PAS ? Merde c'est mon code 3D qui n'est pas bon ? SI je fais ça comme ça, que je recharge 3 fois, que je ferme, rouvre et recharge plutôt (sinon il recharge pas l'applet IE comme FF) ça fait une exception parce que je ne mets pas mon objet au bon endroit dans la scène. Bon je rectifie, je tente de trouver la cause du non-rafraîchissement en mettant un gentil throw new ArrayIndexOutOfBoundsException(); pour qu'il me dise si il passe dans mes fonctions, et là rien ! Dingue. Bref !
Au bout de 4h de boulot cet après midi là, j'ai constaté, par hasard, en cliquant sur Java Console, que mes exceptions étaient bien déclenchées, mais pas affichée par le plug-in Java ! J'ai mis ensuite 5 minutes à corriger le pb, oh c'est tout con : 50 poissons 1 requin, je créais correctement les 50 poissons, mais j'avais pas créé le requin.
Conclusion : si j'avais eu un outil (Java en l'occurence) qui fonctionnait, j'aurai bossé 4h cet après midi là. Mais non, j'ai perdu 3h45 pour une connerie.
Je n'aurai qu'un mot ... VIVE BORLAND ! (pour Delphi et C++ Builder, accessoirement pour Turbo C++ et Turbo Pascal)
mais j'espère que certains apprécieront ce petit moment de détente, malgré les points techniques.
) .
