Le 18/06/2011 14:46, JKB a écrit :Et après, on récupère du code moisi.
Non, le code suit la procédure normale de QA : relecture de code
hebdomadaire, suivi des métriques via Sonar et Jenkins, normes de
codage, couverture de code…
Je ne vois pas comment
assimiler en trois semaines tout ce qu'il faut pour utiliser
correctement un bloatware comme java associé à un autre bloatware
comme Netbeans ou Eclipse.
Seul Maven est une réelle barrière.
Eclipse n'est au final qu'un éditeur de texte enrichi, le reste des
plugins tournant en arrière-plan sans intervention de l'utilisateur.
Le reste des concepts (3 tiers, MVC, IoC) vient avec le temps,
l'architecte JEE ayant déjà fait son travail, le nouveau dev ne sera
qu'« utilisateur » de l'architecture mise en place au début.Si on y arrive en trois
semaine, on a déjà de solides notions de POO. Sinon, c'est
parfaitement impossible (sauf à ne pas comprendre ce qu'on fait et à
utiliser des recettes toutes faites).
Notions de POO oui, notion de Java non.
Le dernier formé dans mon équipe est venu du monde .Net.
Le 18/06/2011 14:46, JKB a écrit :
Et après, on récupère du code moisi.
Non, le code suit la procédure normale de QA : relecture de code
hebdomadaire, suivi des métriques via Sonar et Jenkins, normes de
codage, couverture de code…
Je ne vois pas comment
assimiler en trois semaines tout ce qu'il faut pour utiliser
correctement un bloatware comme java associé à un autre bloatware
comme Netbeans ou Eclipse.
Seul Maven est une réelle barrière.
Eclipse n'est au final qu'un éditeur de texte enrichi, le reste des
plugins tournant en arrière-plan sans intervention de l'utilisateur.
Le reste des concepts (3 tiers, MVC, IoC) vient avec le temps,
l'architecte JEE ayant déjà fait son travail, le nouveau dev ne sera
qu'« utilisateur » de l'architecture mise en place au début.
Si on y arrive en trois
semaine, on a déjà de solides notions de POO. Sinon, c'est
parfaitement impossible (sauf à ne pas comprendre ce qu'on fait et à
utiliser des recettes toutes faites).
Notions de POO oui, notion de Java non.
Le dernier formé dans mon équipe est venu du monde .Net.
Le 18/06/2011 14:46, JKB a écrit :Et après, on récupère du code moisi.
Non, le code suit la procédure normale de QA : relecture de code
hebdomadaire, suivi des métriques via Sonar et Jenkins, normes de
codage, couverture de code…
Je ne vois pas comment
assimiler en trois semaines tout ce qu'il faut pour utiliser
correctement un bloatware comme java associé à un autre bloatware
comme Netbeans ou Eclipse.
Seul Maven est une réelle barrière.
Eclipse n'est au final qu'un éditeur de texte enrichi, le reste des
plugins tournant en arrière-plan sans intervention de l'utilisateur.
Le reste des concepts (3 tiers, MVC, IoC) vient avec le temps,
l'architecte JEE ayant déjà fait son travail, le nouveau dev ne sera
qu'« utilisateur » de l'architecture mise en place au début.Si on y arrive en trois
semaine, on a déjà de solides notions de POO. Sinon, c'est
parfaitement impossible (sauf à ne pas comprendre ce qu'on fait et à
utiliser des recettes toutes faites).
Notions de POO oui, notion de Java non.
Le dernier formé dans mon équipe est venu du monde .Net.
Le 18/06/2011 15:20, JKB a écrit :Mon
expérience me dit qu'il faut souvent oublier le code de la version
1 et repartir d'une page blanche (c'est même assez souvent vrai
lorsqu'on code en C++)
En tout cas sur mes applis Java, je n'ai jamais vu ça.
Le code est suffisamment propre et découplé pour pouvoir intervenir en
profondeur et sans effet de bord notable.
Le 18/06/2011 15:20, JKB a écrit :
Mon
expérience me dit qu'il faut souvent oublier le code de la version
1 et repartir d'une page blanche (c'est même assez souvent vrai
lorsqu'on code en C++)
En tout cas sur mes applis Java, je n'ai jamais vu ça.
Le code est suffisamment propre et découplé pour pouvoir intervenir en
profondeur et sans effet de bord notable.
Le 18/06/2011 15:20, JKB a écrit :Mon
expérience me dit qu'il faut souvent oublier le code de la version
1 et repartir d'une page blanche (c'est même assez souvent vrai
lorsqu'on code en C++)
En tout cas sur mes applis Java, je n'ai jamais vu ça.
Le code est suffisamment propre et découplé pour pouvoir intervenir en
profondeur et sans effet de bord notable.
Ça, c'est juste factuellement faux.
Ça, c'est juste factuellement faux.
Ça, c'est juste factuellement faux.
Je t'aide : le XL n'a jamais été prévu pour être humainement
lisible.
Encore faut-il avoir accès à /opt/repo
et ne pas casser les
bibliothèques du voisin qui nécessite telle version et pas telle
autre. J'ai des tas de bouts de code Java qui demandent une version
bien spécifique d'un 'import' et qui refusent de fonctionner avec
une version plus récente.
Non, pas plus. J'ai le droit d'avoir un org.com.truc.bidule qui est
strictement identique celui utilisé par quelqu'un d'autre à l'autre
bout du monde.
Et encore une fois c'est un faux problème. Si tu
utilises un namespace en C++ qui s'appelle lib, le problème vient de
toi et non du langage.
Que _tu_ ne considères pas comme propre ou maintenable.
Ne pas avoir de collision de symbole en C et surtout ne pas avoir à
corriger à la main tout un tas de nom de fonctions.
Déjà rien que les trucs de la fondation Apache,
Parlons-en. Il y a des trucs très bons et des vériables merdes
complètement inabouties.
Je t'aide : le XL n'a jamais été prévu pour être humainement
lisible.
Encore faut-il avoir accès à /opt/repo
et ne pas casser les
bibliothèques du voisin qui nécessite telle version et pas telle
autre. J'ai des tas de bouts de code Java qui demandent une version
bien spécifique d'un 'import' et qui refusent de fonctionner avec
une version plus récente.
Non, pas plus. J'ai le droit d'avoir un org.com.truc.bidule qui est
strictement identique celui utilisé par quelqu'un d'autre à l'autre
bout du monde.
Et encore une fois c'est un faux problème. Si tu
utilises un namespace en C++ qui s'appelle lib, le problème vient de
toi et non du langage.
Que _tu_ ne considères pas comme propre ou maintenable.
Ne pas avoir de collision de symbole en C et surtout ne pas avoir à
corriger à la main tout un tas de nom de fonctions.
Déjà rien que les trucs de la fondation Apache,
Parlons-en. Il y a des trucs très bons et des vériables merdes
complètement inabouties.
Je t'aide : le XL n'a jamais été prévu pour être humainement
lisible.
Encore faut-il avoir accès à /opt/repo
et ne pas casser les
bibliothèques du voisin qui nécessite telle version et pas telle
autre. J'ai des tas de bouts de code Java qui demandent une version
bien spécifique d'un 'import' et qui refusent de fonctionner avec
une version plus récente.
Non, pas plus. J'ai le droit d'avoir un org.com.truc.bidule qui est
strictement identique celui utilisé par quelqu'un d'autre à l'autre
bout du monde.
Et encore une fois c'est un faux problème. Si tu
utilises un namespace en C++ qui s'appelle lib, le problème vient de
toi et non du langage.
Que _tu_ ne considères pas comme propre ou maintenable.
Ne pas avoir de collision de symbole en C et surtout ne pas avoir à
corriger à la main tout un tas de nom de fonctions.
Déjà rien que les trucs de la fondation Apache,
Parlons-en. Il y a des trucs très bons et des vériables merdes
complètement inabouties.
et sans effet de bord notable.
J'aime assez le _notable_.
et sans effet de bord notable.
J'aime assez le _notable_.
et sans effet de bord notable.
J'aime assez le _notable_.
Non, pas plus. J'ai le droit d'avoir un org.com.truc.bidule qui est
strictement identique celui utilisé par quelqu'un d'autre à l'autre
bout du monde.
Le droit oui, le devoir non.
La propreté du code n'est qu'une histoire de convention communément
admises par une communauté, pas une chose intrinsèquement sûre.
Et encore une fois c'est un faux problème. Si tu
utilises un namespace en C++ qui s'appelle lib, le problème vient de
toi et non du langage.
Oui, mais que le nommage à utiliser soit conventionnée par l'ensemble de
la communauté, C⁺⁺ ne propose pas ça.
Que _tu_ ne considères pas comme propre ou maintenable.
Que beaucoup de développeurs considèrent comme non propre et non
maintenable. Pour n'en citer qu'un, Linux Torvald, qui ne se gène pas
pour gueuler sur les macros et les define (cf différentes flame wars sur
la kernel list) même s'il n'a souvent d'autre choix que de s'en servir.
Ne pas avoir de collision de symbole en C et surtout ne pas avoir à
corriger à la main tout un tas de nom de fonctions.
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Déjà rien que les trucs de la fondation Apache,
Parlons-en. Il y a des trucs très bons et des vériables merdes
complètement inabouties.
Qui ne se retrouvent pas dans le dépôt central de Maven ou en tout cas
pas dans l'état « stable ».
Non, pas plus. J'ai le droit d'avoir un org.com.truc.bidule qui est
strictement identique celui utilisé par quelqu'un d'autre à l'autre
bout du monde.
Le droit oui, le devoir non.
La propreté du code n'est qu'une histoire de convention communément
admises par une communauté, pas une chose intrinsèquement sûre.
Et encore une fois c'est un faux problème. Si tu
utilises un namespace en C++ qui s'appelle lib, le problème vient de
toi et non du langage.
Oui, mais que le nommage à utiliser soit conventionnée par l'ensemble de
la communauté, C⁺⁺ ne propose pas ça.
Que _tu_ ne considères pas comme propre ou maintenable.
Que beaucoup de développeurs considèrent comme non propre et non
maintenable. Pour n'en citer qu'un, Linux Torvald, qui ne se gène pas
pour gueuler sur les macros et les define (cf différentes flame wars sur
la kernel list) même s'il n'a souvent d'autre choix que de s'en servir.
Ne pas avoir de collision de symbole en C et surtout ne pas avoir à
corriger à la main tout un tas de nom de fonctions.
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Déjà rien que les trucs de la fondation Apache,
Parlons-en. Il y a des trucs très bons et des vériables merdes
complètement inabouties.
Qui ne se retrouvent pas dans le dépôt central de Maven ou en tout cas
pas dans l'état « stable ».
Non, pas plus. J'ai le droit d'avoir un org.com.truc.bidule qui est
strictement identique celui utilisé par quelqu'un d'autre à l'autre
bout du monde.
Le droit oui, le devoir non.
La propreté du code n'est qu'une histoire de convention communément
admises par une communauté, pas une chose intrinsèquement sûre.
Et encore une fois c'est un faux problème. Si tu
utilises un namespace en C++ qui s'appelle lib, le problème vient de
toi et non du langage.
Oui, mais que le nommage à utiliser soit conventionnée par l'ensemble de
la communauté, C⁺⁺ ne propose pas ça.
Que _tu_ ne considères pas comme propre ou maintenable.
Que beaucoup de développeurs considèrent comme non propre et non
maintenable. Pour n'en citer qu'un, Linux Torvald, qui ne se gène pas
pour gueuler sur les macros et les define (cf différentes flame wars sur
la kernel list) même s'il n'a souvent d'autre choix que de s'en servir.
Ne pas avoir de collision de symbole en C et surtout ne pas avoir à
corriger à la main tout un tas de nom de fonctions.
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Déjà rien que les trucs de la fondation Apache,
Parlons-en. Il y a des trucs très bons et des vériables merdes
complètement inabouties.
Qui ne se retrouvent pas dans le dépôt central de Maven ou en tout cas
pas dans l'état « stable ».
Le 18/06/2011 16:04, JKB a écrit :et sans effet de bord notable.
J'aime assez le _notable_.
Par notable, j'entend qu'ils ne dépassent pas la couche où ils se
déclenchent (la couche suivante étant protégée des erreurs par
conception), qu'ils sont immédiatement détectés par les tests U ou la CI
et que la correction relève de moins de 1h.
Le 18/06/2011 16:04, JKB a écrit :
et sans effet de bord notable.
J'aime assez le _notable_.
Par notable, j'entend qu'ils ne dépassent pas la couche où ils se
déclenchent (la couche suivante étant protégée des erreurs par
conception), qu'ils sont immédiatement détectés par les tests U ou la CI
et que la correction relève de moins de 1h.
Le 18/06/2011 16:04, JKB a écrit :et sans effet de bord notable.
J'aime assez le _notable_.
Par notable, j'entend qu'ils ne dépassent pas la couche où ils se
déclenchent (la couche suivante étant protégée des erreurs par
conception), qu'ils sont immédiatement détectés par les tests U ou la CI
et que la correction relève de moins de 1h.
Java ne l'impose pas non plus.
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Ni plus ni moins qu'en C++.
Java ne l'impose pas non plus.
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Ni plus ni moins qu'en C++.
Java ne l'impose pas non plus.
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Ni plus ni moins qu'en C++.
Le 18/06/2011 17:22, JKB a écrit :Java ne l'impose pas non plus.
Rien n'est jamais imposé en développement.
Juste que le nommage des projets et des classes est réellement
MONDIALEMENT normalisé et communément admis et MONDIALEMENT appliqué sur
l'ensemble des projets Java, à de très rares exceptions près.
Extrait de la doc :
groupId: This is generally unique amongst an organization or a project.
*Note that the dot-notated groupId does not have to correspond to the
package structure that the project contains. _It is, however, a good
practice to follow._*
artifactId: The artifactId is generally the name that the project is
known by.
*It, along with the groupId, create a key that separates this project
from every other project in the world (_at least, it should_ :) ).*
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Ni plus ni moins qu'en C++.
Trouve-moi 2 projets C⁺⁺ de 2 équipes différentes qui utilisent :
— La même arborescence et structure de fichiers
— Le même Makefile
— La même convention de nommage de classes et surtout de namespace
et en allant plus loin
— Le même découpage architectural
— Le même cycle de vie de développement
et en allant encore plus loin
— La même structure de site web
— La même structure de doc
— La même convention de versionning
— La même gestion de dépendance
— La même manière d'intégrer leur travail dans ton propre travail
Le 18/06/2011 17:22, JKB a écrit :
Java ne l'impose pas non plus.
Rien n'est jamais imposé en développement.
Juste que le nommage des projets et des classes est réellement
MONDIALEMENT normalisé et communément admis et MONDIALEMENT appliqué sur
l'ensemble des projets Java, à de très rares exceptions près.
Extrait de la doc :
groupId: This is generally unique amongst an organization or a project.
*Note that the dot-notated groupId does not have to correspond to the
package structure that the project contains. _It is, however, a good
practice to follow._*
artifactId: The artifactId is generally the name that the project is
known by.
*It, along with the groupId, create a key that separates this project
from every other project in the world (_at least, it should_ :) ).*
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Ni plus ni moins qu'en C++.
Trouve-moi 2 projets C⁺⁺ de 2 équipes différentes qui utilisent :
— La même arborescence et structure de fichiers
— Le même Makefile
— La même convention de nommage de classes et surtout de namespace
et en allant plus loin
— Le même découpage architectural
— Le même cycle de vie de développement
et en allant encore plus loin
— La même structure de site web
— La même structure de doc
— La même convention de versionning
— La même gestion de dépendance
— La même manière d'intégrer leur travail dans ton propre travail
Le 18/06/2011 17:22, JKB a écrit :Java ne l'impose pas non plus.
Rien n'est jamais imposé en développement.
Juste que le nommage des projets et des classes est réellement
MONDIALEMENT normalisé et communément admis et MONDIALEMENT appliqué sur
l'ensemble des projets Java, à de très rares exceptions près.
Extrait de la doc :
groupId: This is generally unique amongst an organization or a project.
*Note that the dot-notated groupId does not have to correspond to the
package structure that the project contains. _It is, however, a good
practice to follow._*
artifactId: The artifactId is generally the name that the project is
known by.
*It, along with the groupId, create a key that separates this project
from every other project in the world (_at least, it should_ :) ).*
Chose que nous n'avons même pas à appliquer à Java car tout le monde
suit les mêmes conventions.
Ni plus ni moins qu'en C++.
Trouve-moi 2 projets C⁺⁺ de 2 équipes différentes qui utilisent :
— La même arborescence et structure de fichiers
— Le même Makefile
— La même convention de nommage de classes et surtout de namespace
et en allant plus loin
— Le même découpage architectural
— Le même cycle de vie de développement
et en allant encore plus loin
— La même structure de site web
— La même structure de doc
— La même convention de versionning
— La même gestion de dépendance
— La même manière d'intégrer leur travail dans ton propre travail
Un code est bon ou n'est pas bon. Il n'est pas notablement bon.
D'autant que la gestion des erreurs par exception est une aberration
née dans le cerveau dément d'un analyste fou.
C'est le pire des
systèmes lorsqu'on veut récupérer une erreur efficacement et de
façon propre. Le principe à la C d'une fonction qui renvoie un code
d'erreur est bien mieux pensé car plus simple et en testant les
retours des fonctions, on laisse toujours le programme dans un état
cohérent.
En C++ ou en Java, on peut rapidement avoir des surprises
amusantes.
Un code est bon ou n'est pas bon. Il n'est pas notablement bon.
D'autant que la gestion des erreurs par exception est une aberration
née dans le cerveau dément d'un analyste fou.
C'est le pire des
systèmes lorsqu'on veut récupérer une erreur efficacement et de
façon propre. Le principe à la C d'une fonction qui renvoie un code
d'erreur est bien mieux pensé car plus simple et en testant les
retours des fonctions, on laisse toujours le programme dans un état
cohérent.
En C++ ou en Java, on peut rapidement avoir des surprises
amusantes.
Un code est bon ou n'est pas bon. Il n'est pas notablement bon.
D'autant que la gestion des erreurs par exception est une aberration
née dans le cerveau dément d'un analyste fou.
C'est le pire des
systèmes lorsqu'on veut récupérer une erreur efficacement et de
façon propre. Le principe à la C d'une fonction qui renvoie un code
d'erreur est bien mieux pensé car plus simple et en testant les
retours des fonctions, on laisse toujours le programme dans un état
cohérent.
En C++ ou en Java, on peut rapidement avoir des surprises
amusantes.
