super bus...
Avant d'avancer certaines choses comme des faits fondés, n'oublies pas d'argumenter.
Tu dis que le Java est inadapté pour ce genre de travail.
De quel travail parles-tu? La banque n'est pas un travail pour moi.
Pour quelles raisons est-il inadapté?
Encore une fois, on a jamais dit que les nouveaux langages avaient apporté des tonnes de nouveautés...
Tu as lu des stats sur la durée de vie des programmes, c'est très bien, mais c'est sans tenir compte que:
- Pour avoir un gros système, il faut généralement des moyens, et donc c'est pas n'importe qui, ni n'importe quel projet, qui utilise une application mainframe
- Un micro est à la portée de tous. Si on considère toutes les applications faites par des particuliers, des petites PME, des startup, il me semble tout a fait normal que les statistiques de durée de vie baissent. Et oui, si la startup se plante, bah l'application est morte... Une banque c'est quand même plus stable.
Dans les sociétés sérieuses et stables, tu peux me croire, les applications Java ont une durée de vie plus importante
Tu n'as jamais vu de système unix vieux de 20 ans. Cool, moi non plus. Et qu'est ce que ça à a voir par rapport à la durée de vie d'une application? Avec Java et la JVM, tu peux faire tourner ton application sur presque n'importe quel micro. On change l'infrastructure de temps en temps, mais l'application reste.
Tu ne t'es pas posé la question pourquoi on trouve des gros systèmes de plus de 20 ans? Tu ne penses pas que si l'infrastructure évolue peu, c'est plutôt parce qu'elle est plus difficile à faire évoluer sur du gros système???
Changer de matériel en Java ne nécessite bien souvent pas de migration.
Pourquoi y-a-t-il beaucoup de bidouilleurs dans le web? Tout simplement parce que le web est aujourd'hui à la portée de tous, tandis que les gens qui font du cobol ont été formés, on leur a dit à l'entrée de la banque: "pas de bac+x en informatique, pas de boulot en cobol". Regarde combien d'autodidactes font du web avec du PHP, dont une grande majorité qui codent en effet n'importe comment...
Tu peux me croire, ça n'est pas pour autant qu'il n'y a pas des gens très compétents en développement web.
Au cas ou tu n'aurais pas encore compris, je ne prends absolument pas parti contre les seniors. Au contraire, je serais le premier à embaucher un mec avec de l'expérience comme toi, pour peu que tu sois opérationnel dans les technologies nécessaires à mon projet!
Et si il y a encore de la passion aujourd'hui. En Java, ça s'appelle les Java User Group, les présentations, les coding Dojo, les journées d'échange... Ou des passionnés de réunissent, investissent sur leur temps personnel pour se former...
Pour ta reflection sur la qualité (cf MACIF), cela existe encore aujourd'hui. Pour ce qui est des normes de développement, nous avons aujourd'hui la chance d'avoir:
- Des plugins paramétrables dans notre environnement de développement, qui permettent d'appliquer automatiquement les règles basiques.
- Des plugins dans l'env de dev qui permettent d'analyser le style du code produit.
- Des plugins dans les outils de versionning des sources, qui permettent de refuser les changements de code qui ne suivent pas ces règles.
- Des plugins en environnement d'intégration continue, qui permettent de passer des tests unitaire, et visualiser le % de code couvert par les tests.
- Des outils qui permettent de simuler l'activité d'un browser et contrôler le bon fonctionnement d'un site.
Tu parles de te faire contrôler pour la qualité. Saches que cela se fait encore aujourd'hui sur les projets sérieux qui ont un minimum de moyens.
Alors oui, on a la possibilité d'avoir de la liberté sur le dev micro, mais justement, le rôle des architectes sur les projets sérieux est de restreindre un peu cette liberté pour que justement les normes et préconisations soient respectées.
Rien avoir avec des ateliers de génie logiciel. Il s'agit de la façon de découper les programmes, et de la façon de gérer tout ce qui est problématique comme les accès à un fichier. Par exemple en COBOL, nous regroupons dans un module sous-programme tous les accès à une table DB2, quelque soit les programmes qui ont accès à cette table. Si pour une raison inconnue la structure de la table change, on modifie que ce sous-programme et non la totalité des programmes qui accède à cette table via ce sous-programme. C'est un plus pour la maintenance, mais ca nécessite des contraintes.
Aujourd'hui, on appelle ça un design pattern. C'est le principe même du DAO (Data Access Object). C'est très fréquemment utilisé: pour te dire, depuis ma sortie d'étude, je n'ai jamais travaillé sur un seul projet qui n'utilisait pas une couche DAO... Ce concept est très très largement connu, on nous l'apprend même à l'école...
Et puis pour revenir un peu sur le sujet, on parle beaucoup des seniors mais ça ne commence pas qu'a 50 ans...
Déjà, pourquoi appelle-t-on un développeur de 28 ans, avec 5 ans d'expérience, un développeur senior???
Pourquoi les SSII nous font comprendre que si on est encore développeur à 30 ans, on a raté notre carrière? On nous pousse à faire de la gestion de projet, ce qui n'a rien a voir, alors qu'on veut rester dans la technique!
Voir les nombreux posts qu'on retrouve sur les blogs français:
http://www.touilleur-express.fr/2009/07/27/senior/Il faut peut-être prendre le problème à la base! Pourquoi dans informatique, en France, on est vieux a 30 ans, et papy a 50?
5 |
1 |
Pensez-vous que la situation soit la même en France ?
Envoyé par super_bus
