Discussion :

[el_slapper]

Tu regrettes de ne pas avoir fait de Cobol ? moi j'en ai fait pendant mes études et c'était un vrai cauchemar ce langage archaïque par ailleurs j'en vois des offres où on te demande de connaître le Cobol pour aider les dev à virer vers le Java donc Cobol langage d'avenir j'y crois vraiment pas.

Chacun ses gouts, mais des projets de migration COBOL vers JAVA qui se plantent, j'en ai vu un paquet. Dont un à 100M€. COBOL est peut-être horrible en dehors de sa niche(les batches de gestion, en gros), mais dans sa niche, il est très puissant, efficace, et lisible.

Après, on peut préférer JAVA quand même, il y a clairement un vaste marché pour ce genre de compétences. Comme je l'ai dit, chacun ses gouts. Et les salaires sont à peu près similaires.

[Us and them]

Je te le redis : Bienvenue dans le monde de l'informatique.

Les codes de "porc" tu vas en trouver à tir-larigot. Les codes tout beau tout propre tu n'en auras pas souvent (sauf si c'est toi qui le fait, mais le code propre de l'un est un code de porc pour d'autres)

Sans vouloir être méchant, je pense que tu t'es fait des films sur le monde de l'informatique, Et que la tu te prends la totale désillusion en pleine face.

Je ne me suis pas fait de film : c'est le discours des profs de l'AFPA !
Commenter, écrire du code réutilisable, factoriser les taches répétitives... Les trucs élémentaires.

Là, reprendre du code de 1000 lignes sans aucun commentaire, des variables mal nommées, des demi-pages de html dans des ECHO, des trucs copié-collé 10 fois s'il y en a besoin 10 fois, et recollé pareil sur toutes les pages du site, bonjour quand il faut changer un élément...

Je ne demande pas un code parfait, ça n'existe pas. Mais au moins un truc écrit avec un minimum de logique... Là, la boite perd du fric parce qu'à la moindre modif, il faut chercher 3 plombes et bricoler une rustine à répercuter sur un tas d'autres fichiers.
Et ne parlons même pas des bases de données créées sans la moindre réflexion, avec dans une table la date qui est un timestamp, et dans la table d'à coté la date est une chaine...

[el_slapper]

(.../...)Je ne demande pas un code parfait, ça n'existe pas. Mais au moins un truc écrit avec un minimum de logique... Là, la boite perd du fric parce qu'à la moindre modif, il faut chercher 3 plombes et bricoler une rustine à répercuter sur un tas d'autres fichiers.
Et ne parlons même pas des bases de données créées sans la moindre réflexion, avec dans une table la date qui est un timestamp, et dans la table d'à coté la date est une chaine...

Standard. Hélas.

[Zirak]

Je ne me suis pas fait de film : c'est le discours des profs de l'AFPA !
Commenter, écrire du code réutilisable, factoriser les taches répétitives... Les trucs élémentaires.

Là, reprendre du code de 1000 lignes sans aucun commentaire, des variables mal nommées, des demi-pages de html dans des ECHO, des trucs copié-collé 10 fois s'il y en a besoin 10 fois, et recollé pareil sur toutes les pages du site, bonjour quand il faut changer un élément...

C'est la que si, tu t'es fais un film, si tu as cru à ce discours de l'AFPA


Bien sûr que tout le monde apprends ces notions, sauf qu'une fois dans la réalité du monde du travail, cela ne se passe pas comme dans le monde des bisounours....

Quand un commercial (ou ton chef, si tu n'es pas en SSII) :
- vend X jours pour réaliser ton prog, alors qu'il en faudrait X + 15
- que tu n'as pas de cahier des charges mais les seules informations que tu as pu soutirer (ou que l'on t'a fait parvenir) du service métier, qui bien entendu n'en dit que le moitié sans penser aux "cas spécifiques", ce qui t'oblige à reprendre Y fois le développement...
- Etc. Etc.

Au final, avoir un code pratiquement parfait, factorisé, commenté et lisible, c'est mission impossible dans la plupart des boîtes, pas forcement par volonté du dev, mais par manque de temps / moyens / informations / Etc. Etc. Du coup, bah tu ne commente pas forcément tout, tu fais du copier-coller pour gagner du temps sur le moment et livrer dans les temps...

Si tu fais perdre du fric à ta boite car tu veux prendre le temps de faire un code parfait, alors qu'elle n'en a pas vendu autant à son client, tu as plus de chance d'être viré que d'avoir des remerciements du mec qui reprendra ton code derrière (pour qui cela sera "normal" d'avoir un bon code)..

Et puis c'est un peu le principe de notre société individualo-libérale, des gains rapides (on propose donc au client un temps de dev très court, quitte à ce que celui-ci ne soit pas parfait mais histoire d'être sûr de récupérer l'affaire), et puis plus tard, au niveau maintenance, c'est le pauvre quidam qui reprendra le code qui sera dans la mouise, on s'en fou, on ne sera plus là, ou dans le pire des cas, on revendra X jours de maintenance au client donc du bénef en plus....

Hélas, il ne faut jamais oublier que pour tes patrons : gain > qualité du code

[Mat.M]

Je ne demande pas un code parfait, ça n'existe pas. Mais au moins un truc écrit avec un minimum de logique... Là, la boite perd du fric parce qu'à la moindre modif, il faut chercher 3 plombes et bricoler une rustine à répercuter sur un tas d'autres fichiers.
Et ne parlons même pas des bases de données créées sans la moindre réflexion, avec dans une table la date qui est un timestamp, et dans la table d'à coté la date est une chaine...

c'est exact.
Le problème en France dans les équipes de développement c'est , j'ai l'impression, d'un manque cruel de personnes sachant structurer et architecture convenablement un projet.
Facile à écrire ou à dire, difficile à faire mais si un projet est un minimum structuré eh bien l'entreprise ne dépense pas autant d'argent comme tu l'écris

Quand un commercial (ou ton chef, si tu n'es pas en SSII) :
- vend X jours pour réaliser ton prog, alors qu'il en faudrait X + 15
- que tu n'as pas de cahier des charges mais les seules informations que tu as pu soutirer (ou que l'on t'a fait parvenir) du service métier, qui bien entendu n'en dit que le moitié sans penser aux "cas spécifiques", ce qui t'oblige à reprendre Y fois le développement...
- Etc. Etc.

Au final, avoir un code pratiquement parfait, factorisé, commenté et lisible, c'est mission impossible dans la plupart des boîtes, pas forcement par volonté du dev, mais par manque de temps / moyens / informations / Etc. Etc. Du coup, bah tu ne commente pas forcément tout, tu fais du copier-coller pour gagner du temps sur le moment et livrer dans les temps...

tu as parfaitement raison
Ceci dit sur le long terme les entreprises qui font ça risquent de couler face à celles qui seront capables de se structurer véritablement

Et puis c'est un peu le principe de notre société individualo-libérale, des gains rapides (on propose donc au client un temps de dev très court, quitte à ce que celui-ci ne soit pas parfait mais histoire d'être sûr de récupérer l'affaire), et puis plus tard, au niveau maintenance, c'est le pauvre quidam qui reprendra le code qui sera dans la mouise, on s'en fou, on ne sera plus là, ou dans le pire des cas, on revendra X jours de maintenance au client donc du bénef en plus....

oui c'est exact
Ceci dit le développement de projets informatique dépend étroitement de la philosophie et culture anglo-saxonne.
Je m'explique:
aux USA les équipes qui gèrent des projets de développement sont assez "urbanisées" : on a un rédacteur technique, des personnes qui font des tests, un architecte, des programmeurs.
Mais ils en ont les moyens techniques et financiers.
En France rien de tout ça souvent il y a souvent un manque d'organisation en entreprise et la seule logique qui prévaut c'est faire des dev le plus rapidement possible pour le client

[Invité]

Ceci dit le développement de projets informatique dépend étroitement de la philosophie et culture anglo-saxonne.
Je m'explique:
aux USA les équipes qui gèrent des projets de développement sont assez "urbanisées" : on a un rédacteur technique, des personnes qui font des tests, un architecte, des programmeurs.
Mais ils en ont les moyens techniques et financiers.
En France rien de tout ça souvent il y a souvent un manque d'organisation en entreprise et la seule logique qui prévaut c'est faire des dev le plus rapidement possible pour le client

Ah ah ah ah !!!!
J'ai failli me pisser dessus !
Effectivement, l'herbe est toujours plus verte ailleurs...
Comme j'aimerais que tu aies raison. Mais dans la vraie vie, non !
C'est sûr que l'organisation américaine est différente. Mais pour ce qui est du résultat final, ce n'est pas systématiquement mieux.
Au final, je n'ai jamais senti une différence qualitative notable du code entre les 2 cultures.
Par contre, le recours au « ça marche plus et on patche en urgence comme des porc » me semble un peu plus fréquent de ce bord-ci de l'Atlantique.

[GuillaumeJ]

Au final, je n'ai jamais senti une différence qualitative notable du code entre les 2 cultures.
Par contre, le recours au « ça marche plus et on patche en urgence comme des porc » me semble un peu plus fréquent de ce bord-ci de l'Atlantique.

Je pense que franchement, sur la qualité du code, ca dépend uniquement de la structure dans laquelle on travaille. Et qu'il serait bien difficile d'en tirer des conclusions générales...

Ce qui par contre est vrai, c'est que le code est très dévalorisé (comme choix de carrière a moyen terme, ou niveau reconnaissance salariale) en France. En Amérique du Nord, c'est nettement moins le cas (même si on n'échappe pas à un certain jeunisme).

[Invité]

Je pense que franchement, sur la qualité du code, ca dépend uniquement de la structure dans laquelle on travaille. Et qu'il serait bien difficile d'en tirer des conclusions générales...

Disons qu'après 7 ans d'expérience des deux côtés de l'Atlantique, avec du code tiré de banque à la TPE, avoir trempé dans du privé et du public, j'ai la prétention de me permettre de tirer une conclusion générale, que voici :
La structure de travail est bien différente mais la qualité finale est pas mal équivalente.

[GuillaumeJ]

La structure de travail est bien différente mais la qualité finale est pas mal équivalente.

On est d'accord

[Mat.M]

C'est sûr que l'organisation américaine est différente. Mais pour ce qui est du résultat final, ce n'est pas systématiquement mieux.
.

attention tu nous parles du pays au nord des USA pas des USA eux-mêmes
As-tu déjà travaillé dans une véritable entreprise américaine en immersion totale en anglais et non avec une entreprise à Montréal ?
Ensuite la différence entre les américains et les canadiens surtout le Québec c'est que les moyens financiers ne sont pas du tout les mêmes.
Pour ce qui est de la philosophie américaine qui caractèrise la Hi Tech il y a tonne d'inventions qui proviennent des USA comme les méthodologies, les outils en eux-même.

[Mr_Exal]

!
Je trouve assez osé d'appeler ça des "formations professionnalisantes", alors qu'en sortant de là, il va falloir se farcir quelques mois ou années d'autoformation pour espérer pouvoir postuler à la moindre offre.

Comme tout un chacun en informatique, auto formation, tous les jours, tout le temps.

[Invité]

attention tu nous parles du pays au nord des USA pas des USA eux-mêmes
As-tu déjà travaillé dans une véritable entreprise américaine en immersion totale en anglais et non avec une entreprise à Montréal ?
Ensuite la différence entre les américains et les canadiens surtout le Québec c'est que les moyens financiers ne sont pas du tout les mêmes.
Pour ce qui est de la philosophie américaine qui caractèrise la Hi Tech il y a tonne d'inventions qui proviennent des USA comme les méthodologies, les outils en eux-même.

D'accord, je n'ai pas d'expérience direct aux USA, mais je travaille directement avec des collègues américains depuis plus de 10 ans depuis la France ou Montréal.
Et donc je peux comparer les méthodes de travail et le résultat.

Un gros exemple tout frais : La boîte pour laquelle je travaille actuellement a été rachetée par une boîte américaine et je bénéficie de la vision de code US de première main. Je peux te décrire parfaitement la méthodologie employée : La Rache, du tout dernier cri...
D'ailleurs quand on parle de documentations, mes interlocuteurs se braquent et s'offusquent devant tant de grossièreté !
Quand je parle de versionage, je vois des yeux ronds...
Les outils ? MS SQL server 2000, la fine pointe...
Je continue ?

Ok, Apple et Micorosoft sont américains, mais tous ne sont pas des innovateurs de premiers plans, loin de là.

[GuillaumeJ]

Ok, Apple et Micorosoft sont américains, mais tous ne sont pas des innovateurs de premiers plans, loin de là.

Oui, et puis bon :

http://odetocode.com/blogs/scott/arc...word-1-1a.aspx

(enfin, pour le cas de Microsoft, on parle de code qui a 30 ans cependant..)

[Mr_Exal]

Pour Apple ce qui me fait énormément rire c'est qu'ils utilisent du 2IS pour leurs serveurs (du moins pour leurs sites webs).

@Domi2 : Désolé l'habitude

[Us and them]

Si tu fais perdre du fric à ta boite car tu veux prendre le temps de faire un code parfait, alors qu'elle n'en a pas vendu autant à son client, tu as plus de chance d'être viré que d'avoir des remerciements du mec qui reprendra ton code derrière (pour qui cela sera "normal" d'avoir un bon code)..

Et puis c'est un peu le principe de notre société individualo-libérale, des gains rapides (on propose donc au client un temps de dev très court, quitte à ce que celui-ci ne soit pas parfait mais histoire d'être sûr de récupérer l'affaire), et puis plus tard, au niveau maintenance, c'est le pauvre quidam qui reprendra le code qui sera dans la mouise, on s'en fou, on ne sera plus là, ou dans le pire des cas, on revendra X jours de maintenance au client donc du bénef en plus....

Hélas, il ne faut jamais oublier que pour tes patrons : gain > qualité du code

Ton exemple vaut pour les boites de dev qui vendent du code à la chaine à d'autres boites.
Dans mon cas, la boite s'est montée y'a 1 an, a fait développé l'ossature du site en 2 mois par des gros branlos pisseurs de code, et depuis ça été aggrémenté/maintenu/tricoté/patché/bidouillé par un mec qui restait dans le même style. Et bien le mec n'a pas été gardé, et aujourd'hui le site est à refaire de zéro tellement il n'est plus maintenable et disfonctionnel (il ne rapporte pas un rond).
Et évidemment on ne fera pas appel à la boite de branlos qui a pondu le site à l'origine.

Tout le monde y est perdant avec ce modèle :
- la boite qui a chié le site s'est fait 2 mois de paie mais elle ne rebossera plus jamais pour nous, et avec le bouche-à-oreille très négatif elle ne risque pas de se faire une grosse clientèle
- le dev qui a repris le truc en faisant pareil n'a pas été gardé, au mieux il ira pisser du code moisi dans une SSII sur des projets sans intéret
- nous le site est tellement mal foutu que l'expérience utilisateur est nulle et donc les rentrées d'argent aussi, et il va falloir refaire une v2 du site rapidement tout en devant rester compatible avec la base de donnée merdique, ce qui représente un gros coût et une énorme perte de temps

Alors peut-être que moi je me fais des films, mais ton modèle, c'est un peu le modèle du "made in China" : on développe le plus vite possible de la merde pas chère qui va engendrer plein de problème par la suite pour lesquels il faudra payer... Et au final ça coutera plus cher et rapportera moins que si on avait fait les choses correctement.

[Mat.M]

Ok, Apple et Micorosoft sont américains, mais tous ne sont pas des innovateurs de premiers plans, loin de là.

je ne voudrais pas dériver du sujet principal et faire du HS mais l'innovation c'est pas forcément le but premier des entreprises anglo-saxonnes.
Je vous laisse deviner lequel est..
dans ce que tu as écris tu as parfaitement raison cf American Airlines qui ne veut pas changer ses antiques MacDonnell Douglas md80 et DC9 qui consomment 20 à 30 % de plus qu'un Airbus A320...( dans cette logique c'est pour ça que ces avions ont volé sans peinture parce que la peinture ça coûte également cher..)

ensuite lorsque je voulais parler d'inventions c'est des inventions qui sont issues d'une certaine "pilosophie" de l'informatique, d'une "vision globale" ( ce dont je parlais dans un autre fil de discussion) :les méthodologies comme UML,les outils de développement..