Discussion :

[Idelways]

Java est-il un choix coûteux pour les entreprises ?
Oui, d'après un expert qui recommande de capitaliser à bon escient sur les briques open-source




Quinze ans après l’émergence de Java, David Duquenne, Directeur Génétal du groupe Open Wide Technologies (spécialiste de l'intégration et des l'exploitation des logiciels en France) fait un bilan du langage, qu'il trouve plutôt mitigé.
Un avis plutôt polémique.

Selon lui, Java n'aurait pas tenu ses promesses. Les projets réalisés à l'aide de ce langage auraient la réputation d'être « trop subtils pour les développeurs (sic), coûteux à réaliser et complexes à maintenir».

Le point de vue des Directions des Systèmes d'Information (DSI) serait, pour David Duquenne, sans appel : « prise en main longue et compliquée », « des compétences et une expertise coûteuses », des « architectes apprentis sorciers », un « écosystème technologique étourdissant ».

Bref, un constat qui ferait d'après lui regretter aux DSI les « bons vieux langages [...] complètement dépassés dans certains domaines, mais tellement plus productifs » et les pousserait à expérimenter des langages plus récents ou à explorer de nouveaux paradigmes tels que l'approche par modélisation (MDA) ou la programmation fonctionnelle dédiée.

Des solutions cependant pas suffisamment matures, toujours selon l'analyste, pour être industrialisées sur des projets stratégiques.

Sa solution ? Capitaliser sur des briques open-source proposant des réponses aux problématiques les plus courantes dans le développement d'applications.

« À condition toutefois d'éviter certains écueils » met en garde Duquenne, qui propose des conseils pour faire face aux défis de l'intégration Java comme la gestion du foisonnement de l'Open Source, la versatilité des composants, l'exploitation de la richesse ou l'évacuation de la complexité.

Les DSI qui préfèrent miser sur l'existant plutôt que d'investir dans leur propre « framework maison » seront ainsi confrontés à l’embarras du choix entre les milliers frameworks techniques Java et les dizaines de milliers de modules fonctionnels open source.

Leur but serait d'aboutir à un socle applicatif de qualité industrielle.

Ce socle souhaité par David Duquenne peut être créé avec des composants sélectionnés et être l'assemblage des interactions d'interfaces de programmation hétérogènes. Une phase coûteuse qui risque de durer entre 3 à 18 mois pour le développements techniques et nécessiter une équipe de 3 à 10 experts.

Autre solution, les entreprises peuvent s'essayer aux socles applicatifs fournis clef en main, qui peuvent être adaptés au contexte spécifique des projets de l'entreprise. Ces socles sont des distributions de composants Open Source intégrées dans une architecture applicative couvrant un périmètre plus ou moins important.

Les DSI doivent selon David Duquenne s'assurer de l'existence d'un support professionnel sur la totalité du socle applicatif afin de sécuriser la réalisation, la maintenance et l'exploitation des applications les plus critiques.

Le coût de ce support, mutualisé entre les entreprises utilisatrices du socle « restera plus économique que la maintenance d’un socle applicatif maison », affirme-t-il.

Le deuxième challenge serait de maintenir ce socle pour les 5, 10 ou 15 prochaines années au milieu d'un écosystème Java en constante évolution.

Cette évolution permet aux composants de devenir constamment plus pertinents et plus robustes et motiver l'apparition de nouveaux composants encore plus performants et innovants. Mais mal gérée, cette évolution peut aussi générer une versatilité désastreuses pour les systèmes d'information.

De plus, le rythme de ces évolutions est imprévisible et diffère pour chaque composant du socle applicatif.

Un composant peut aussi être abandonné, mais rester accessible sur Internet, devenant une sorte de bombe à retardement pour les applications. Ces composants doivent être en permanence remplacés ou maintenus par la société elle-même.

Duquenne met également en garde contre les ruptures technologiques introduites par une évolution majeure ou par le changement brutal d'une licence.

Pour se prémunir, le seul moyen serait d'anticiper ces risques par une veille technologique permanente et sensibiliser les directions sur les coûts (souvent mal vécus) de cette activité de veille sans rapport avec les enrichissements fonctionnels et métiers attendus par l’entreprise.

Un autre challenge, encore plus délicat selon Duquenne, est de survivre au départ de l'architecte, souvent un prestataire de haut vol intervenant de façon limitée, le temps de stabiliser ce socle applicatif.

Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.

Ce départ doit donc être anticipé en organisant un transfert de compétences au sein d’un contrat de maintien en condition opérationnel pour éviter la perte de la maîtrise du socle, ou pire encore, le désengagement technique des partenaires qui ne voudront plus travailler sur une plate-forme obsolète ou non supportée

La verbosité qui fait de Java un langage très structurant (garantissant la qualité et la portabilité des applications) rebute souvent les développeurs expérimentés sur d'autres langages et complique le recrutement et les budgets.

Duquenne recommande des solutions qui peuvent évacuer la complexité du Java et de son environnement comme le cadrage structurant les méthodes de développement, l’utilisation de Frameworks, l'intégration continue ou encore le recours aux approches agiles de gestion de projet favorisant les échanges d'informations et limitant la dépendance aux personnes clefs du projet.

Pour se faire, des socles applicatifs communautaires peuvent compléter les plates-formes avec une surcouche simplifiant le codage des applications, des générateurs de code et un cadre méthodologique.



Le discours de David Duquenne n'est cependant pas un plaidoyer anti-Java, au contraire :

« La complexité du monde Java est réelle mais ses qualités, son ouverture et sa standardisation poussent à son adoption malgré les difficultés à bâtir et à maintenir son environnement technologique », conclue-t-il. « Pour bénéficier des avantages de cet environnement, particulièrement bien adapté aux technologies de l'information, il est indispensable de capitaliser sur le savoir-faire et les retours d’expérience des composants Open Source qui le peuplent. Au delà de l’économie d’échelle induite par l’approche communautaire, celle-ci vous permet de bénéficier d’une constante évolution gage de fiabilité, d’interopérabilité et de respect des derniers standards […] L'émergence d'éditeurs Open Source dans ce domaine est un signe encourageant de la maturité des socles applicatifs et une réponse adaptée aux DSI qui souhaitent investir sur leur métier plutôt que sur la technologie qui les sous-tend ».

Source : Communiqué de presse : Open Wide Technologies

Et vous ?

Qu'en pensez-vous ?

[CAML]

C'est pas parce que des personnes n'utilisent pas les "bonnes méthodes" que l'outil est mauvais.
Cet article revient à dire : y a pas de mauvais language, mais des mauvais programmeurs/analyste/etc...

[Gog077]

De toute manière le langage parfait adapté à toutes les situations n'existe pas. Je ne pense pas que ce soit un problème de Java ou pas. On pourrait faire le même discours sur le C# ou d'autres langages encore.

[willard]

Java couteux ? Je ne dirais pas ça .. c'est peut etre un langage trop verbeux mais je trouve que c'est ce qui fait sa force. Investir la dedans est clairement plus rentable que d'investir dans un langage bas niveau ou pire dans un autee paradigme.

[Rei Ichido]

Ce socle souhaité par David Duquenne peut être créé avec des composants sélectionnés et être l'assemblage des interactions d'interfaces de programmation hétérogènes. Une phase coûteuse qui risque de durer entre 3 à 18 mois pour le développements techniques et nécessiter une équipe de 3 à 10 experts.

Il faudrait détailler le "souhaité". L'émergence de beaucoup de frameworks est due aussi à la multiplicité des besoins ; est-ce qu'il propose une solution unique ?

Un autre challenge, encore plus délicat selon Duquenne, est de survivre au départ de l'architecte, souvent un prestataire de haut vol intervenant de façon limitée, le temps de stabiliser ce socle applicatif.

Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.

Honnêtement, quel techno ne subit pas ce problème récurrent du départ de celui-qui-sait ?

La question réside souvent dans le passage de connaissance, en effet, qui peut être singulièrement allégé si on produit une doc explicite en amont (comprenant aussi des commentaires dans le code). Les basiques, quoi. Et ce n'est pas comme si c'était spécifique à Java.

[BugFactory]

Je ne vois pas ce que l'article de M. Duquenne apporte de neuf. Les atouts et travers de Java qu'il dénonce sont bien connus.

On va m'accuser de manquer d'impartialité étant donné mon investissement personnel dans Java. Néanmoins, ce même investissement me permet d'affirmer qu'aucune entreprise aujourd'hui ne se lance dans Java sans choisir soigneusement les frameworks à utiliser. Ces frameworks deviennent par la suite le standard de l'entreprise.

Si la majeur partie du texte me semble relever de l'évidence, d'autres me font bondir. Notamment ce qu'il dit sur les socles applicatifs.

Pour réaliser un socle applicatif de qualité industrielle (c-à-d complété par des générateurs de code, une approche méthodologique et un processus structurant de développement), il est raisonnable de prévoir une phase d'une durée de 3 à 18 mois de développements techniques avec une équipe de 3 à 10 experts selon vos besoins : niveau d'intégration dans votre système d'information, simplicité de prise en main par vos développeurs, productivité et qualité attendue pour la réalisation de vos projets, criticité des applications pour votre entreprise…

Très exagéré. A en croire cet extrait, créer un socle applicatif prendrait de 9 à 180 mois hommes! Le pire des cas reviendrait à 15 ans de travail avant même de commencer à programmer l'application elle-même. Hors on peut avoir un socle applicatif décent en assemblant Struts + Swing + Hibernate en quelques jours.

Une fois le socle applicatif terminé et livré, se pose alors la question de sa maintenance pour les 5, 10 ou 15 prochaines années (soit la durée des applications de votre SI).

Manque de clarté. Maintenir les applications réalisées aujourd'hui à l'aide de ce socle applicatif pendant quinze ans : bien sûr. Mais je doute que dans quinze ans, on souhaite commencer de nouvelles applications avec ce même socle.

En revanche, là où je suis entièrement d'accord, c'est sur la nécessité de ne pas devenir trop dépendant de son architecte. Ceci d'une façon très simple : prévoir deux jours pour que l'architecte forme l'équipe, et écrire un dossier d'architecture. Dans la pratique, même dans le cas où l'architecte est encore dans l'entreprise, je constate que l'équipe ne connaît pas l'architecture!

EDIT:
Le paragraphe précédent a été écrit avant même que Rei Ichido n'écrive :

La question réside souvent dans le passage de connaissance, en effet, qui peut être singulièrement allégé si on produit une doc explicite en amont (comprenant aussi des commentaires dans le code). Les basiques, quoi. Et ce n'est pas comme si c'était spécifique à Java.

Comme quoi...

[Traroth2]

Bonjour les évidences ! Miser sur les briques open-source ? Il était temps qu'il découvre ça, en 2011, le gars ! IDE le plus populaire : Eclipse. Conteneur de servlet : Tomcat. Conteneur d'EJB : JBoss. Sans parler de Spring, Hibernate, etc. Et juste après, il parle du problème posé par le foisonnement de briques open-source, justement. Un peu contradictoire, non ?

Personnellement, je pense que ce foisonnement est justement une des très grandes forces de Java, ce qui en fait un langage avec lequel on peut (presque) tout faire ! Et c'est ce qui le rend aussi difficile à remplacer, aussi, comme on le voit maintenant avec les problèmes posés par l'arrivée d'Oracle aux manettes...

[Killing Joke]

Je suis plutôt d'accord sur certains constats que ce Monsieur fait, mais pas sur le fond.
Pour les constats, oui, l'écosystème Java est parfois devenu un peu trop riche, trop verbeux, trop redondant (tant de librairies pour un même sujet mais pas une seule bien finie jusqu'au bout, etc.), même si çà dénote une forte implication de beaucoups d'acteurs.

Par contre dire que Java n'est pas productif en entreprise, là je suis scié. Il y a peu, dans ma boîte, on maintenait encore de vieilles applications en C, remplacées aujourd'hui par du J2EE. En terme de maintenance et de déploiement, il n'y a pas photo : les applications en C étaient une plaie niveau compilations, dépendances inter-modules, divergences entre plateformes, links avec les .so système ... tout un tas de sujet sur lesquels on a bien galéré (il y a encore pas si longtemps !), alors qu'on était quand même équipé, et qui ont totalement disparu avec Java (ouf).

[B.AF]

En même temps tout ça c'est bien vrai. Mais c'est valable pour toutes les technologies.

Le problème de l'architecture, ce sont les profils. Moi quand je lis une personne qui me dit qu'une architecture technique c'est quelques jours en spring/hibernate/strut, je me dis surtout que si Java à introduit une notion, c'est le dogme architectural.
Spring, c'est une des librairies les plus crades du marché, hibernate c'est probablement le framework le plus mal employé de la planéte et qui pose le plus de problèmes de perfs, et strut je ne commente même pas.
Je ne compte plus le nombre de développeur que j'ai vu se prendre les pieds dans le tapis avec la session hibernate, les select n+1, les mappings, les locks de thread sur les singleton spring, les transactions,les jar hell, les fichiers xml partout, ou la submission multiple en strut, la config de strut....

Oui une archi technique même en Java peut prendre du temps et couter cher.
Et il n'y a ni évidence, ni facilité. La plus grande erreur étant celle de prendre des composants open source (pour ne pas payer les outils) en se disant qu'ils font, sans maitriser le sujet qu'ils traitent (pour ne pas payer la formation)

Si les frameworks open source étaient si faciles à mettre en oeuvre et répondaient tant aux besoins fonctionnels, alors beaucoup de boites, dont spring et dont jboss ne gagneraient pas leur vie.

[DarkVenoM]

Et dire que ce monsieur a une "solide" experience Java...
Ils nous conseille quoi au juste ? De faire les SI en ASP 3 ? En Ruby ? En PHP ? En C++ ? Et pourquoi pas en LISP ?

Je ne vois aujourd'hui quel langage de programmation permet de développer un SI avec plus de productivité que Java. C# rivalise mais c'est au prix d'un tarif salé et d'un choix de frameworks plus restreint. Justement, les choix des frameworks parlons en... Ils trouvent que le nombre de cadriciels en Java est étourdissant, et bien moi je me réjouit d'avoir du choix, je préfère passer du temps a choisir un bon framework plutôt que de me voir imposer une mauvaise solution sous prétexte qu'elle est unique. Ainsi en Java (pour faire la comparaison avec .NET, mais on pourrait le faire avec d'autres plateformes) , j'ai plus de choix en terme de serveurs, d'orm, de framework IHM, de framework d'IOC etc.... Java est peut être un choix coûteux pour les entreprises, mais ses alternatives le sont bien plus encore, et bien souvent elles laissent moins de latitudes aux dévelopeurs pour leurs propres choix techniques. Cette latitude permet aux développeurs d'avoir plus de chance de coller aux attentes du client en terme de coûts, de sécurité et de qualité.

[bugsan]

Spring, c'est une des librairies les plus crades du marché

Wow...

[panda31]

Dans un cadre d'efforts d'industrialisation constants par les DSI, le choix de Java est remis en question. Oui, .NET limite délibérement le nombre de frameworks. Mais quelle suite applicative ! Excusez le troll mais je ne comprends pas qu'on passe encore autant de temps à parler d'Eclipse alors que j'ai l'impresson de perdre le mien à chasser à travers tous ses projets de plugins, à gérer des dépendances hasardeuses parfois et une prise en main toute relative par les équipes. Je demande un bon outil de modélisation uml ou merise et je ne trouve rien dans le catalogue cet IDE qui soit probant. Je me tourne alors vers un outil tiers... sans interop ! super... Eclipse open source, certes mais où est le ROI ? je suis entièrement d'accord avec Duquenne sur les autres points.

[B.AF]

Et dire que ce monsieur a une "solide" experience Java...
Ils nous conseille quoi au juste ? De faire les SI en ASP 3 ? En Ruby ? En PHP ? En C++ ? Et pourquoi pas en LISP ?

Je ne vois aujourd'hui quel langage de programmation permet de développer un SI avec plus de productivité que Java. C# rivalise mais c'est au prix d'un tarif salé et d'un choix de frameworks plus restreint.

C'est vraiment un commentaire inutile. Java est de fait non productif. La comparaison avec certains L4G, beaucoup de projets de migration ont mis le doigt dessus : on ne peut pas empiler framework, technologies et principes et améliorer la productivité. La qualité, oui clairement, mais pas la vitesse.
Il suffit de regarder le code à déployer juste pour faire une application de CRUD en JSF pour comprendre que le principe de Java n'est pas la productivité. Et au final, .Net coûte moins (en dehors de la souscription MSDN; le RAD est meilleur en productivité). Faut parler de ce que l'on connait. Des projets de migration j'en ai vécu plusieurs et oui Java n'est pas une technologie productive. Et ce n'est pas un mal; tant qu'elle est fiable et permet de faire des architectures testables (ce qui est un gain plus important dans le temps que de faire des économies de jours de dev).

Quant à Spring, je n'invente rien, la plupart des orateurs Spring trouvaient drôle de dire au début de leur meeting "Ca fonctionne, mais ne regardez pas le code source". Là encore, avoir du succès et des fonctionnalités n'a jamais signifié exemplarité du code source et de la qualité. Et oui ! C'est aussi ça l'histoire. Et ce n'est pas mieux pour ceux qui se souviennent des releases JBoss qui pouvaient prendre un peu de temps avant de se "stabiliser".

[bugsan]

Faut parler de ce que l'on connait.

puis

"Ca fonctionne, mais ne regardez pas le code source". Là encore, avoir du succès et des fonctionnalités n'a jamais signifié exemplarité du code source et de la qualité.

Je ne sais pas où tu as été sortir ça, d'une brochure marketing .NET ?
Applique tes propos à toi même et avoue nous que 1) Tu n'as jamais vraiment utilisé Spring et 2) Tu n'as jamais été voir le code source.


C'est un des codes sources les plus clean/lisible que j'ai pu voir dans le monde Java, tout projet Apache, Jboss, Codehaus compris.
Et franchement c'est vraiment n'importe quoi de lire ça, et sur developpez.com en plus de la part "d'Experts". Affligeant.

[damien.charpentier]

C'est vraiment un commentaire inutile. Java est de fait non productif. La comparaison avec certains L4G, beaucoup de projets de migration ont mis le doigt dessus : on ne peut pas empiler framework, technologies et principes et améliorer la productivité. La qualité, oui clairement, mais pas la vitesse.
Il suffit de regarder le code à déployer juste pour faire une application de CRUD en JSF pour comprendre que le principe de Java n'est pas la productivité. Et au final, .Net coûte moins (en dehors de la souscription MSDN; le RAD est meilleur en productivité). Faut parler de ce que l'on connait. Des projets de migration j'en ai vécu plusieurs et oui Java n'est pas une technologie productive. Et ce n'est pas un mal; tant qu'elle est fiable et permet de faire des architectures testables (ce qui est un gain plus important dans le temps que de faire des économies de jours de dev).

Quant à Spring, je n'invente rien, la plupart des orateurs Spring trouvaient drôle de dire au début de leur meeting "Ca fonctionne, mais ne regardez pas le code source". Là encore, avoir du succès et des fonctionnalités n'a jamais signifié exemplarité du code source et de la qualité. Et oui ! C'est aussi ça l'histoire. Et ce n'est pas mieux pour ceux qui se souviennent des releases JBoss qui pouvaient prendre un peu de temps avant de se "stabiliser".

Tu ne fais pas du JSF 2 pour un simple CRUD (a part pour un prototype), le but est bien d'ameliorer la productivite sur le long terme. Je ne vois pas pourquoi tu opposes qualite et productivite, pour moi ces deux concepts sont lies.
Ensuite si les applications qui consistent en un simple empilement de frameworks ne marchent pas, c'est peut etre a cause du developpeur, pas de l'outil.

[B.AF]

1 - J'utilise Spring
2 - J'ai plus que regardé le code source.

C'est loin d'être un exemple. Un exemple de code source super clean; c'est quantlib. Pas Spring.

Mais peu importe, de toutes façons, il y a tellement peu de mesure ici que critiquer un framework java me transforme en fanboy microsoft. Et peut être simplement que nous n'avons pas la même notion de propre.

Pour les projets Apache, là encore, va jeter un oeil dans le code de Velocity et dis moi que c'est clean, voir dans Strut.

Du code clean : Guice est clean.

Bref, dans le fonds, je ne suis pas d'intérêt à partir dans les critiques personnelles, je n'ai pas grand chose à prouver.
J'écris ce que je pense : dire que pour faire une archi java il faut juste quelques jours, et spring, hibernate et strut, c'est faux.

Typiquement, la surabondance de Framework ORM (même si là encore il y a des merveilles et de la créativité) à obfusqué la qualité même de Jdbc et de sa conception.

Moi ce qui me dérange, c'est que Java meurt de tous ces poncifs, et si pour faire du java il faut obligatoirement utiliser Spring, hibernate et strut, ben ça rendra Java juste chiant et lourd.

C'est mon avis, et ce n'est pas une comparaison avec .Net.

Je ne suis pas d'accord avec cet article : avoir des frameworks techniques n'a jamais amélioré le SI.

[ALCINA]

L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,
DAL => entity, couche de communication => WCF, validation => dataannoration, presentation => xaml/asp/mvc, analyse => reporting services, repository => TFS.
Et c'est tout, du coup n'importe quel archi utilise les même outil ce qui n'est pas vrai pour java.
Et dotnet n'est au final pas plus cher, maintenance plus facile, dev moins cher cf prix du marché.
Les couts d'infrastructure son identique, aucune grossr entreprise prends une distribution linux gratuite, trop de risque.
Les couts d'infra de windows ou de ibm, sun, red hat, sont relativement identique.
Au final un projet dotnet coutera moins cher qu'il soit de 1500/10000/100000 jour/homme.
En dessous les entreprises prennent php.

[B.AF]

L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,
DAL => entity, couche de communication => WCF, validation => dataannoration, presentation => xaml/asp/mvc, analyse => reporting services, repository => TFS.
Et c'est tout, du coup n'importe quel archi utilise les même outil ce qui n'est pas vrai pour java.
Et dotnet n'est au final pas plus cher, maintenance plus facile, dev moins cher cf prix du marché.
Au final un projet dotnet coutera moins cher qu'il soit de 1500/10000/100000 jour/homme.

C'est pareil sur la trinité S/H/S en Java, il y a beaucoup d'idées reçues là dedans.
EF ne permet pas aujourd'hui de tout faire, WCF demandent de la plomberie plus qu'on ne le croit (notamment en conjonction avec un ORM, la sérialisation, la sécurité, la performance), pour la présentation chaque techno a ses spécificités et ses contraintes (ah le thread ui en winforms), TFS est excellent soit, mais est très long à faire fonctionner correctement, ou du moins autrement qu'en dépot de source. Si tu prends la gestion du messaging, .Net est beaucoup moins outillé que Java.
Et n'importe quelle archi .Net n'utilise pas les mêmes outils. Il suffit de compter le nombre de projet Codeplex.
La seule partie sur laquelle .Net a pour moi un avantage non discutable de productivité c'est la partie client lourd (Forms vs Swing).

[Jitou]

Enfin en 10 ans d'expérience sur la conception et le développement de projets Java, c'est la première fois que j'entends quelqu'un avouer ce qui est peu avouable, les projets Java coûtent très très chers aux clients mais aussi aux prestataires.

Et ce n'est pas au moment du développement du projet que cela coute mais bien après ! C'est à dire lorsque l'application va vivre sa vie, va devoir être maintenue et donc subir des opérations de maintenance mais aussi des évolutions voir des refontes radicales.

Pourtant j'adore ce langage et j'apprécie toute la "Java Sphere" qui l'entoure sa grande force par rapport à d'autres langages plus pauvres et plus fermés de ce point de vue là. Mais je dois dire que même après 10 ans passé dans ce monde captivant on n'en fini toujours pas de réinventer la roue et cette pratique est très pénalisante pour les projets. On aboutie inévitablement à du code plus où moins fiable, plus ou moins performant et surtout plus où moins lisible et évolutif surtout lorsqu'il est implémenté dans 95% des cas par de jeunes ingénieurs fraîchement sorti de l'école et qui ont appris le langage sur le tas au moment de la réalisation du projet !

Dans les 10 euros du coût d'un projet Java, 50 centimes sont généreusement investi dans le développement initial et 9.50 euros seront encore investi pour tenter d'assurer sa maintenance tant bien que mal jusqu'au moment où 6 mois après une nouvelle direction décide de faire table rase pour arrêter la surchauffe des coûts et tout recommencer ... et ce dans les mêmes conditions.

Merci panda31 pour cette citation très à propos:

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
John F. Woods

Source: http://groups.google.com/group/comp....b64e464aed84a0

[ManusDei]

En gros l'article se résume à : "Y a plein de gens qui codent en Java comme des gros porcs, donc c'est le bordel de maintenir une appli Java."