java: les "grands principes" et la "vraie vie"
Le
Freddy
salut à tous,
Dans tous les (bons) livres sur java on nous apprend de grands principes
de programmation et leur concrétisation dans ce langage: encapsulation,=
abstraction, modularité, factorisation du code, etc
N'ayant jamais fait de programmation java en équipe, ni sur un gros
projet, je me pose la question suivante: que reste-t-il de ces grands
principes quand on fait de la programmation java dans une entreprise ?
Par exemple:
- est-ce que le code obtenu par copier-coller est si peu fréquent ?
- est-ce qu'on réutilise tant que ça ?
- est-ce qu'on crée ou manipule beaucoup de classes abstraites (en
dehors de celles des API standard) ?
- est-ce qu'on redefinit vraiment souvent equals et clone ? etc
Pour ne pas que l'on se méprenne, le sens general de ces questions n'est=
pas: "à quoi servent toutes ces c.ries abstraites ?", mais plutot:
"que deviennent toutes ces règles de bonne programmation lorsqu'on est
amené à travailler sur un projet complexe, avec des contraintes
importantes de temps et d'efficacité ?"
J'aimerais avoir les temoignages de gens parmi vous qui sont dans cette
situation. Bien sûr je realise que "faire de la programmation java dans=
une entreprise" recouvre des réalités très différentes
Merci (et bravo à tous les participants de ce newsgroup très
enrichissant)
Fred
Dans tous les (bons) livres sur java on nous apprend de grands principes
de programmation et leur concrétisation dans ce langage: encapsulation,=
abstraction, modularité, factorisation du code, etc
N'ayant jamais fait de programmation java en équipe, ni sur un gros
projet, je me pose la question suivante: que reste-t-il de ces grands
principes quand on fait de la programmation java dans une entreprise ?
Par exemple:
- est-ce que le code obtenu par copier-coller est si peu fréquent ?
- est-ce qu'on réutilise tant que ça ?
- est-ce qu'on crée ou manipule beaucoup de classes abstraites (en
dehors de celles des API standard) ?
- est-ce qu'on redefinit vraiment souvent equals et clone ? etc
Pour ne pas que l'on se méprenne, le sens general de ces questions n'est=
pas: "à quoi servent toutes ces c.ries abstraites ?", mais plutot:
"que deviennent toutes ces règles de bonne programmation lorsqu'on est
amené à travailler sur un projet complexe, avec des contraintes
importantes de temps et d'efficacité ?"
J'aimerais avoir les temoignages de gens parmi vous qui sont dans cette
situation. Bien sûr je realise que "faire de la programmation java dans=
une entreprise" recouvre des réalités très différentes
Merci (et bravo à tous les participants de ce newsgroup très
enrichissant)
Fred
Poser une question
développements dont la durée de vie excède 6 mois (finances, webapp,
comptabilité, gestion), par opposition aux applis kleenex (un jeu en
ligne par exemple), pour lequel on utilisera les technos LAMP (et pour
lesquelles on externalisera les développement au forfait et en mode
"boite noire").
Pour les dev java, par contre, on est en boite blanche, et on est très
rigoureux sur la rationalisation et la qualité du code, car les
différents modules (éditorial, finance, mais aussi des modules plus
techniques : swing, web) sont massivement réutilisés entre les
différentes applis. On doit donc garantir la compatibilité ascendante
et s'assurer que les différentes couches applicatives sont bien
"découplées". Une mise en production d'un code instable pourrait
déstabiliser d'autres applications !
transversal ne peut pas évoluer "facilement" et de manière uniforme.
douleur (il faudrait penser à n'oublier aucune appli). ^_^
pour lequel il existera différentes spécialisations), mais aussi pour
les services et pour certaines IHM (une boite de recherche dont la
méthode de validation doit être redéfinie en fonction du contexte
applicatif par exemple)...
Et le reste pour pouvoir bénéficier des fonctionnalités de l'api
java (sorting, unicité, ...)
En bref, on essaie de faire "au mieux", mais on vit quand même dans le
monde réel et il faut souvent jouer sur les curseurs "qualité" et
"délais" pour pouvoir annoncer (et tenir !) des plannings qui tiennent
la route.
C'est parfois dur à faire comprendre aux dirigeants, mais sur le long
terme, cette approche transversale nous permet d'assurer une
évolutivité efficace et uniforme des grandes fonctions métiers sur
le moyen / long terme (que ce soit techniquement ou fonctionnellement).
Après, les expériences doivent varier d'une boite à une autre ...
j'avais toujours bossé dans des PME/TPE avant de rejoindre la grosse
boite pour laquelle je travaille aujourd'hui depuis un peu plus de 4
ans.
Symon
Freddy wrote:
Comme tu dis Freddy, chacun doit vivre une réalité différente, voire
différentes réalités succéssivement ou simultanément...
Je pense que tout ça dépend de beaucoup de paramètres:
- la volonté de la hiérarchie (et les moyens associé, le "propre"
c'est un investissement).
- la volonté des équipes.
- les connaissances et (surtout) l'expérience des équipes.
- le rapport à l'éxistant.
Personnellement, j'ai évolué, et le code de ma boite avec puisque je
suis maintenant le seul développeur java.
Au départ, j'ai tatonné une appli basique à base de FTP et décodage
XML, et déjà comprendre les mécanismes de XML et la programmation
FTP java pour un débutant total en Java et dans le monde des applis
réseaux sérieuses, c'était pas si mal.
Ensuite on m'a donné un client (au sens client-serveur) à traduire de
C/C++ (très peu "objet") à Java. Je l'ai fait, mais j'ai surtout
copier/coller et changé ce qui ne marchait pas (#define par exemple).
Et pour cause, je ne comprenait pas la version native avant de la
traduire. Donc, difficile de la réarchitecturer!!! De plus, personne
ne "parlant" java, on ne risquait pas de me montrer le chemin pour
programmer pour Java...
C'est dans ces conditions que j'ai attaqué la réalisation d'une appli
graphique. La raison du choix de java c'était:
- les compétences des ressources disponibles (hum! hum!).
- la "beauté" de Java (même le LNF de l'époque était mieux que
les MFC basiques).
- la perspective d'un éventuel portage (on excluait de fait VB
donc).
J'ai fait un proto semi-fonctionnel (fonctions principale OK, mais peu
de contrôle de cohérence des commandes dispos par exemple) pour
permettre au marketing de valider l'utilisation de Java. Ce proto à
été validé et le délai de finition imposé ne laissait pas de place
à d'autres choix que de modifier le proto pour en faire une appli
décente.
J'ai passé un certain temps à me débattre dans un code qui gonflait
à vue d'oeil. Une beaucoup trop grande partie du code était
directement lié à la partie graphique. A force de tenter de masquer
les défauts de départ (un proto graphique n'est pas conçu pour être
fiabilisé et ensuite maintenu).
A tel point qu'au plus fort de la tempête, j'avais une classe qui
devait faire environ 5000 lignes de code. Et encore, j'avais qq
principe en tête, je suis un convaincu de la programmation objet
"propre". Mais bon, dans la pratique, sans expérience de la
programmation objet (en particulier graphique, je trouve que c'est la
moins intuitive à rendre propre) et dans de telle conditions, on
subit!!!
En parralèle j'ai fait un essai d'implémentation de l'API Java
Speech. Cet exercice, même si on me l'a aussi fait bâcler, a été
salutaire. J'ai pu (enfin) intégrer la manière dont doivent dialoguer
les objets en java (et en général au passage).
Aujourd'hui, mes nouveaux composants sont de plus en plus propre et je
consacre du temps à rénover le code fait à mes débuts (ça apprend
l'humilité, lol). Les stagiaires que je prends sont invités à coder
selon les même principes, j'essaye de leur faire sauter qq étapes que
j'ai du faire ne rampant... Mais bon, faut pas rêver, les livres de
principes, les design patterns, les excellents profs ça ne remplace
pas l'expérience personnelle et la confrontation avec les collègues,
surtout si ils sont plus compétents!
Aujourd'hui, je crois qu'il est temps que j'aille me frotter à d'autre
developpeurs Java, JEE de préférence, pour évoluer.
Voilà une tranche de vie (4 ans) de développeur Java (notamment).
J'espère que ça répond un peu à ta question...
Vincent
C'est marrant mais j'ai un parcours trés ressemblant à celui de Vincent
qui a répondu. Moi aussi je suis dans une petite boite. Je gère tout le
développement et j'ai un developpeur et souvent quelque stagiaires à ma
charge.
Pour faire court, je vais dire que les grands principes je les applique
quand j'ai le temps. J'essaye de faire le meilleure compromis entre
délais et qualité, robustesse du code.
Je vais peut être en faire bondir plus d'un mais sur environ 70% de mes
projets, les tests unitaires sont passé à la trappe. Et mes projets
fonctionnent trés bien. Mais je gère presque tout de A à Z donc, je suis
capable d'être trés réactif en cas de Bug. Il est vrai que mes
developpements et mes architectures sont de plus en plus propres aussi
avec l'expérience.
En fait il faut savoir s'adapter suivant le contexte. Aprés faut savoir
imposer certain choix à la hiérarchie. Mais ce n'est pas facile.
Il doit avoir tout un monde entre gérer tout seul un projet de taille
moyenne (pas besoin de EJB en application WEB par exemple) en TPE et
travailler sur un projet énorme en SSII.
Et pour répondre à Vincent, moi j'ai fini par franchir le pas, et me
suis mis en recherche active d'un nouveau poste la semaine dernière.
En effet, je pense que je m'enchirai encore plus vite au contact d'autre
développeurs vraiment confirmé.
Jérôme
La différence entre TPE et grosse SSII ne se trouve pas forcément dans le
code.
J'ai un client qui m'a demandé de "récupérer" un gros projet codé par une
grosse SSII.
J'avais jamais vu un code aussi pourri, peu performant, buggé de toute ma
vie.
Et pourtant il y avait des tests unitaires.
Je n'ai eu qu'une seule expérience dans une équipe de 40 dév (dont certains
étaient très compétents), j'y ai constaté que plus le nombre de développeur
croit, plus la qualité globale et la maintenabilité du code diminue.
Ce n'est je l'espère pas systématique, mais probablement difficile à éviter
sans un très très bon management des équipes.
plus.
Quelle est la meilleure façon de bien séparer les différentes parties
d'un programme en java?
En effet, il me semble que la meilleure pratique de développement
consiste à rendre 1 ou 2 personnes responsables d'un petit programme qui
sera très bien défini au niveau de son service model, de façon à pouvoir
l'intégrer dans un plus gros programme par la suite (en gros de l'Xtreme
prog...).
Donc, spécifiquement en java, comment feriez-vous?
- un package séparé pour le sous-programme, avec un package de stubs
pour les tests et une façade par sous-programme
- un programme totalement séparé, sous forme de jar, standalone pour les
tests et ayant sa propre doc/javadoc
- une meilleure idée?
et aussi, quel est l'impact de ces choix sur temps de développement
(réutilisation prise en compte)?
Merci, je me réjouis d'entendre votre expérience parler!