Dans tous les (bons) livres sur java on nous apprend de grands principes=20
de programmation et leur concr=E9tisation dans ce langage: encapsulation,=
=20
abstraction, modularit=E9, factorisation du code, etc...
N'ayant jamais fait de programmation java en =E9quipe, ni sur un gros=20
projet, je me pose la question suivante: que reste-t-il de ces grands=20
principes quand on fait de la programmation java dans une entreprise ?=20
Par exemple:=20
- est-ce que le code obtenu par copier-coller est si peu fr=E9quent ?=20
- est-ce qu'on r=E9utilise tant que =E7a ?=20
- est-ce qu'on cr=E9e ou manipule beaucoup de classes abstraites (en=20
dehors de celles des API standard) ?=20
- est-ce qu'on redefinit vraiment souvent equals et clone ? etc...
Pour ne pas que l'on se m=E9prenne, le sens general de ces questions n'est=
=20
pas: "=E0 quoi servent toutes ces c....ries abstraites ?", mais plutot:=20
"que deviennent toutes ces r=E8gles de bonne programmation lorsqu'on est=20
amen=E9 =E0 travailler sur un projet complexe, avec des contraintes=20
importantes de temps et d'efficacit=E9 ?"=20
J'aimerais avoir les temoignages de gens parmi vous qui sont dans cette=20
situation. Bien s=FBr je realise que "faire de la programmation java dans=
=20
une entreprise" recouvre des r=E9alit=E9s tr=E8s diff=E9rentes...
Merci (et bravo =E0 tous les participants de ce newsgroup tr=E8s=20
enrichissant)
Faible cohésion et couplage fort égalent la situation trop connue du "plat de spaghetti". Nous savons tous ce qu'il en est sur les temps de développement dans ce scénario: on va vite pendant quelques temps, et ensuite on se retrouve avec du code non-maintenable et à dire au client furibard "qu'il faut tout refaire de zéro".
La recette du vite fait mal fait aussi. Mon premier boss m'avait dit... Le bon développeur fait les choses vites et bien, du premier coup. L'éternel trio coût-délai-qualité, applicable à tous les domaines, donc même le code.
Sinon merci Laurent tes messages sont bons comme un gros plat de spaghettis à l'italienne :)
Laurent Bossavit wrote:
Faible cohésion et couplage fort égalent la situation trop connue du
"plat de spaghetti". Nous savons tous ce qu'il en est sur les temps de
développement dans ce scénario: on va vite pendant quelques temps, et
ensuite on se retrouve avec du code non-maintenable et à dire au
client furibard "qu'il faut tout refaire de zéro".
La recette du vite fait mal fait aussi. Mon premier boss m'avait dit... Le
bon développeur fait les choses vites et bien, du premier coup. L'éternel
trio coût-délai-qualité, applicable à tous les domaines, donc même le code.
Sinon merci Laurent tes messages sont bons comme un gros plat de spaghettis
à l'italienne :)
Faible cohésion et couplage fort égalent la situation trop connue du "plat de spaghetti". Nous savons tous ce qu'il en est sur les temps de développement dans ce scénario: on va vite pendant quelques temps, et ensuite on se retrouve avec du code non-maintenable et à dire au client furibard "qu'il faut tout refaire de zéro".
La recette du vite fait mal fait aussi. Mon premier boss m'avait dit... Le bon développeur fait les choses vites et bien, du premier coup. L'éternel trio coût-délai-qualité, applicable à tous les domaines, donc même le code.
Sinon merci Laurent tes messages sont bons comme un gros plat de spaghettis à l'italienne :)
Jean-Marc Molina
dymezac wrote:
je suis moi aussi débutant en java (étudiant) et je voulais savoir ce qu'était le : - mapping OO-relationnel
En anglais on parle de Object Relational Mapping (ORM), quelques références : - Article Mapping de Wikipédia : http://fr.wikipedia.org/wiki/Mapping - Article Persistance de Wikipédia : http://fr.wikipedia.org/wiki/Persistance - Article "An Introduction to Java Persistence for Client-Side Developers" de java.net : http://today.java.net/pub/a/today/2006/05/23/ejb3-persistence-api-for-client-side-developer.html - Article "More Persistence for Client-Side Developers" de java.net : http://today.java.net/pub/a/today/2006/06/08/more-ejb3-persistence-api-for-client-side-developer.html
JM.
dymezac wrote:
je suis moi aussi débutant en java (étudiant) et je voulais savoir ce
qu'était le :
- mapping OO-relationnel
En anglais on parle de Object Relational Mapping (ORM), quelques références
:
- Article Mapping de Wikipédia : http://fr.wikipedia.org/wiki/Mapping
- Article Persistance de Wikipédia :
http://fr.wikipedia.org/wiki/Persistance
- Article "An Introduction to Java Persistence for Client-Side Developers"
de java.net :
http://today.java.net/pub/a/today/2006/05/23/ejb3-persistence-api-for-client-side-developer.html
- Article "More Persistence for Client-Side Developers" de java.net :
http://today.java.net/pub/a/today/2006/06/08/more-ejb3-persistence-api-for-client-side-developer.html
je suis moi aussi débutant en java (étudiant) et je voulais savoir ce qu'était le : - mapping OO-relationnel
En anglais on parle de Object Relational Mapping (ORM), quelques références : - Article Mapping de Wikipédia : http://fr.wikipedia.org/wiki/Mapping - Article Persistance de Wikipédia : http://fr.wikipedia.org/wiki/Persistance - Article "An Introduction to Java Persistence for Client-Side Developers" de java.net : http://today.java.net/pub/a/today/2006/05/23/ejb3-persistence-api-for-client-side-developer.html - Article "More Persistence for Client-Side Developers" de java.net : http://today.java.net/pub/a/today/2006/06/08/more-ejb3-persistence-api-for-client-side-developer.html
JM.
ToOmS
Sans vouloir déclencher une guerre, ni vexer personne, je dirais que les grand principes, c'est pour les bons programmeurs. Un bon programmeur, c'est quelqu'un qui a fait des études d'informatique et connait l'algorithmique de base ; c'est aussi, obligatoirement, quelqu'un qui a de l'EXPERIENCE.
Surtout en Java, la plupart du temps on démarre sur Java parce que les composants UI intégrés c'est vraiment la classe et qu'on croit que c'est toujours un plus que le programme soit portable (à vérifier, selon moi).
Je pense que tout le mon de sera d'accord pour dire qu'il est insupportable de relire son propre code après quelques années : on pourrait réécrire l'application pour qu'elle soit plus robuste, élégante et puissante parce qu'on a accumulé du savoir faire. C'est à ce moment là de sa vie professionnelle qu'on commence à comprendre réelelment les design patterns et l'intérêt irréfutable des "grands principes". Ca ne fait que commencer avec Java, qui reste un langage jeune de ce point de vue là (APIs éprouvées, langage approfondi).
Personnellement, c'est en portant mes applications en Java 5 que j'ai vraiment commencé à être content de moi. Mais, en entreprise, qui a le temps de revenir sur du code ? Personne. La vérité, c'est qu'on fait toujorus (hum) mieux la fois d'après.
Thomas.
Sans vouloir déclencher une guerre, ni vexer personne, je dirais que
les grand principes, c'est pour les bons programmeurs.
Un bon programmeur, c'est quelqu'un qui a fait des études
d'informatique et connait l'algorithmique de base ; c'est aussi,
obligatoirement, quelqu'un qui a de l'EXPERIENCE.
Surtout en Java, la plupart du temps on démarre sur Java parce que les
composants UI intégrés c'est vraiment la classe et qu'on croit que
c'est toujours un plus que le programme soit portable (à vérifier,
selon moi).
Je pense que tout le mon de sera d'accord pour dire qu'il est
insupportable de relire son propre code après quelques années : on
pourrait réécrire l'application pour qu'elle soit plus robuste,
élégante et puissante parce qu'on a accumulé du savoir faire.
C'est à ce moment là de sa vie professionnelle qu'on commence à
comprendre réelelment les design patterns et l'intérêt irréfutable
des "grands principes". Ca ne fait que commencer avec Java, qui reste
un langage jeune de ce point de vue là (APIs éprouvées, langage
approfondi).
Personnellement, c'est en portant mes applications en Java 5 que j'ai
vraiment commencé à être content de moi. Mais, en entreprise, qui a
le temps de revenir sur du code ? Personne. La vérité, c'est qu'on
fait toujorus (hum) mieux la fois d'après.
Sans vouloir déclencher une guerre, ni vexer personne, je dirais que les grand principes, c'est pour les bons programmeurs. Un bon programmeur, c'est quelqu'un qui a fait des études d'informatique et connait l'algorithmique de base ; c'est aussi, obligatoirement, quelqu'un qui a de l'EXPERIENCE.
Surtout en Java, la plupart du temps on démarre sur Java parce que les composants UI intégrés c'est vraiment la classe et qu'on croit que c'est toujours un plus que le programme soit portable (à vérifier, selon moi).
Je pense que tout le mon de sera d'accord pour dire qu'il est insupportable de relire son propre code après quelques années : on pourrait réécrire l'application pour qu'elle soit plus robuste, élégante et puissante parce qu'on a accumulé du savoir faire. C'est à ce moment là de sa vie professionnelle qu'on commence à comprendre réelelment les design patterns et l'intérêt irréfutable des "grands principes". Ca ne fait que commencer avec Java, qui reste un langage jeune de ce point de vue là (APIs éprouvées, langage approfondi).
Personnellement, c'est en portant mes applications en Java 5 que j'ai vraiment commencé à être content de moi. Mais, en entreprise, qui a le temps de revenir sur du code ? Personne. La vérité, c'est qu'on fait toujorus (hum) mieux la fois d'après.
Thomas.
ToOmS
Pour taquiner (cette fois), je dirais que la référence devrait obligatoirement être dans la classe enfant. Un lien "externe" permettrait d'avoir plusieurs pères... Cela dit, de nos jours, avec la technologie transgénique, on peut l'imaginer :-)
Raphael Tagliani wrote:
Par ailleurs il n'est pas forcément indiqué de placer le lien "enfant s" dans la classe père. Il pourrait être placé dans une classe "Lien de Par enté", par exemple. D'ailleurs, dans la base de données telle que tu la propos e, le lien lui même ne semble pas être placé dans la table père, qui ne comporte qu'une clé étrangère, dis-tu. (un lien de lien ? )...
Pour taquiner (cette fois), je dirais que la référence devrait
obligatoirement être dans la classe enfant. Un lien "externe"
permettrait d'avoir plusieurs pères... Cela dit, de nos jours, avec la
technologie transgénique, on peut l'imaginer :-)
Raphael Tagliani wrote:
Par ailleurs il n'est pas forcément indiqué de placer le lien "enfant s" dans
la classe père. Il pourrait être placé dans une classe "Lien de Par enté",
par exemple. D'ailleurs, dans la base de données telle que tu la propos e,
le lien lui même ne semble pas être placé dans la table père, qui ne
comporte qu'une clé étrangère, dis-tu. (un lien de lien ? )...
Pour taquiner (cette fois), je dirais que la référence devrait obligatoirement être dans la classe enfant. Un lien "externe" permettrait d'avoir plusieurs pères... Cela dit, de nos jours, avec la technologie transgénique, on peut l'imaginer :-)
Raphael Tagliani wrote:
Par ailleurs il n'est pas forcément indiqué de placer le lien "enfant s" dans la classe père. Il pourrait être placé dans une classe "Lien de Par enté", par exemple. D'ailleurs, dans la base de données telle que tu la propos e, le lien lui même ne semble pas être placé dans la table père, qui ne comporte qu'une clé étrangère, dis-tu. (un lien de lien ? )...
alexandre cartapanis
Sans vouloir déclencher une guerre, ni vexer personne, je dirais que les grand principes, c'est pour les bons programmeurs. Un bon programmeur, c'est quelqu'un qui a fait des études d'informatique et connait l'algorithmique de base ; c'est aussi, obligatoirement, quelqu'un qui a de l'EXPERIENCE.
Je suis entièrement d'accord SAUF sur les études. Ici, l'expérience vaut BEAUCOUP plus que les études. Les technologies se renouvellent quasi complimentent tout les 10-15 ans environ. Par contre, les principes de base (l'algorithmique de base entre autre) sont eux parfaitement nécessaire. Et c'est vrai que très rare sont le s autodidactes qui ont pris le temps d'ingurgiter ces outils la. Nombreux sont les experts en PHP incapable de faire de l'ASP ou du JSP pour cette raison.
Surtout en Java, la plupart du temps on démarre sur Java parce que le s composants UI intégrés c'est vraiment la classe et qu'on croit que c'est toujours un plus que le programme soit portable (à vérifier, selon moi).
Je pense que tout le mon de sera d'accord pour dire qu'il est insupportable de relire son propre code après quelques années : on pourrait réécrire l'application pour qu'elle soit plus robuste, élégante et puissante parce qu'on a accumulé du savoir faire. C'est à ce moment là de sa vie professionnelle qu'on commence à comprendre réelelment les design patterns et l'intérêt irréfuta ble des "grands principes". Ca ne fait que commencer avec Java, qui reste un langage jeune de ce point de vue là (APIs éprouvées, langage approfondi).
Personnellement, c'est en portant mes applications en Java 5 que j'ai vraiment commencé à être content de moi. Mais, en entreprise, qui a le temps de revenir sur du code ? Personne. La vérité, c'est qu'on fait toujorus (hum) mieux la fois d'après.
Thomas.
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
Sans vouloir déclencher une guerre, ni vexer personne, je dirais que
les grand principes, c'est pour les bons programmeurs.
Un bon programmeur, c'est quelqu'un qui a fait des études
d'informatique et connait l'algorithmique de base ; c'est aussi,
obligatoirement, quelqu'un qui a de l'EXPERIENCE.
Je suis entièrement d'accord SAUF sur les études. Ici, l'expérience vaut
BEAUCOUP plus que les études. Les technologies se renouvellent quasi
complimentent tout les 10-15 ans environ.
Par contre, les principes de base (l'algorithmique de base entre autre)
sont eux parfaitement nécessaire. Et c'est vrai que très rare sont le s
autodidactes qui ont pris le temps d'ingurgiter ces outils la. Nombreux
sont les experts en PHP incapable de faire de l'ASP ou du JSP pour cette
raison.
Surtout en Java, la plupart du temps on démarre sur Java parce que le s
composants UI intégrés c'est vraiment la classe et qu'on croit que
c'est toujours un plus que le programme soit portable (à vérifier,
selon moi).
Je pense que tout le mon de sera d'accord pour dire qu'il est
insupportable de relire son propre code après quelques années : on
pourrait réécrire l'application pour qu'elle soit plus robuste,
élégante et puissante parce qu'on a accumulé du savoir faire.
C'est à ce moment là de sa vie professionnelle qu'on commence à
comprendre réelelment les design patterns et l'intérêt irréfuta ble
des "grands principes". Ca ne fait que commencer avec Java, qui reste
un langage jeune de ce point de vue là (APIs éprouvées, langage
approfondi).
Personnellement, c'est en portant mes applications en Java 5 que j'ai
vraiment commencé à être content de moi. Mais, en entreprise, qui a
le temps de revenir sur du code ? Personne. La vérité, c'est qu'on
fait toujorus (hum) mieux la fois d'après.
Thomas.
--
Alexandre CARTAPANIS - Responsable Système et Réseau
Email alexandre.cartapanis@macymed.fr
Gsm. 06 72 07 51 55
Sans vouloir déclencher une guerre, ni vexer personne, je dirais que les grand principes, c'est pour les bons programmeurs. Un bon programmeur, c'est quelqu'un qui a fait des études d'informatique et connait l'algorithmique de base ; c'est aussi, obligatoirement, quelqu'un qui a de l'EXPERIENCE.
Je suis entièrement d'accord SAUF sur les études. Ici, l'expérience vaut BEAUCOUP plus que les études. Les technologies se renouvellent quasi complimentent tout les 10-15 ans environ. Par contre, les principes de base (l'algorithmique de base entre autre) sont eux parfaitement nécessaire. Et c'est vrai que très rare sont le s autodidactes qui ont pris le temps d'ingurgiter ces outils la. Nombreux sont les experts en PHP incapable de faire de l'ASP ou du JSP pour cette raison.
Surtout en Java, la plupart du temps on démarre sur Java parce que le s composants UI intégrés c'est vraiment la classe et qu'on croit que c'est toujours un plus que le programme soit portable (à vérifier, selon moi).
Je pense que tout le mon de sera d'accord pour dire qu'il est insupportable de relire son propre code après quelques années : on pourrait réécrire l'application pour qu'elle soit plus robuste, élégante et puissante parce qu'on a accumulé du savoir faire. C'est à ce moment là de sa vie professionnelle qu'on commence à comprendre réelelment les design patterns et l'intérêt irréfuta ble des "grands principes". Ca ne fait que commencer avec Java, qui reste un langage jeune de ce point de vue là (APIs éprouvées, langage approfondi).
Personnellement, c'est en portant mes applications en Java 5 que j'ai vraiment commencé à être content de moi. Mais, en entreprise, qui a le temps de revenir sur du code ? Personne. La vérité, c'est qu'on fait toujorus (hum) mieux la fois d'après.
Thomas.
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
