Discussion :

[_Xavier_]

Nous sommes actuellement trois à travailler sur un projet informatique qu'on a divisé en trois modules. Mon plus grand défi pour le moment est de faire de sorte à ce que chaque module soit "indépendant" des autres. Toutefois il y a des classes que l'on se partage et ça ajoute un peu de complexité dans le problème. Pour rester fidèle à mon objectif j'ai opté pour mettre des interfaces et laisser chacun en faire l'implémentation qui lui convient. Comme c'est une première expérience je voudrais savoir si l'approche que j'ai du problème est pertinente et s'il y a d'autres contraintes que l'on peut rencontrer dans des projets informatiques où l'on est appelé à travailler à plusieurs.

[deadalnix]

D'abords il te faut une bonne modélisation.

Ensuite, il te faut un outils type svn pour travailler sur la même base de code et éviter les surprises.

Il te faut des batteries de tests pour chacune des specs, afin de pouvoir identifier l'origine des problèmes et de savoir qui doit les fixer. Les test doivent être écris en même temps que le code à tester, pas après.

Utilisez un outils de gestion de projet. À 3, un truc simple type trac suffit. Faites des tikets pour les fonctionnalité à faire, des bugs pour les bugs, etc . . .

Pour le SVN, commitez ce qui passe tous les tests dans le tronc. Ne faite pas de grosse modif massive, sans quoi on ne pourra plus suivre le travail.

Si un bout de code nécessite de toucher à un large base de code, faites un branche, et ainsi, on pourra voir ce qui se passe dans la branche. Si la fonctionnalité est simple, commitez dans le tronc un fois que cela marche et passe tous les tests.

Essayez d'avoir des choses testables et utilisable très tôt. Cela permet de savoir ou vous allez et de ne pas vous planter.

Voila, je suis sur que tout ça va s'affiner avec les posts des autres.

[_Xavier_]

Le serveur SVN a été mis en place, le projet a été en trois modules. Mon blocage se situe au niveau de la modélisation, exactement au niveau des classes qui seront utilisés dans tous les modules. Comment les concevoir sans porter préjudice à l'autonomie des modules, et minimiser l'impact d'une modification.

PS : le projet est en java (même si le problème peut être traité dans un cadre plus général)

[_skip]

le projet a été en trois modules. Mon blocage se situe au niveau de la modélisation, exactement au niveau des classes qui seront utilisés dans tous les modules. Comment les concevoir sans porter préjudice à l'autonomie des modules, et minimiser l'impact d'une modification.

La vrai question est plutôt : est-ce que cette séparation a du sens?
Qu'est-ce qu'elle apporte concrètement et qu'est-ce qu'elle coûte?

Parce que si elle te demande de faire des choses du style écrire un tas d'interface pour obtenir de l'abstraction qui ne sert à rien parce que les modules ne peuvent pas réellement évoluer ou être réutilisés séparément hormis dans d'hypothétiques scénarios, tu vas complexifier ton projet pour des prunes et finalement ça va faire l'effet contraire de celui qui était recherché sur la maintenance.

A titre d'exemple, le super 3 tiers ou chaque couche doit être totalement séparée et indépendante au point de pouvoir être remplacée individuellement sans adaptation, hors milieu académique j'ai vu plus de projets se vautrer à cause de ça qu'être efficace grâce à ça.

Alors réfléchis bien.

[Nebulix]

des classes qui seront utilisés dans tous les modules... sans porter préjudice à l'autonomie des modules..

Oublie un moment ton ordinateur,
prends un papier et un crayon.
Ecris quelles données tu veux traiter
et quels traitements.
La struture de données commune et le découpage en modules risquent fort d'apparaitre spontanément.

[_Xavier_]

@Nebulix Le modèle est déjà fait, avec tous les diagrammes nécessaires.

La vrai question est plutôt : est-ce que cette séparation a du sens?

C'est ça l'origine de mon thread, étant donné que c'est une première expérience pour dans ce genre de projet. J'utilise des modules qui seront implémentés par les autres je me suis dis que la meilleure manière de leur imposer d'avoir la même signature pour ces modules c'est de contraindre chacun d'implémenter les interfaces.

Qu'est-ce qu'elle apporte concrètement et qu'est-ce qu'elle coûte

Concrètement ça peut apporter plus d'indépendance pour les groupes, un niveau d'abstraction qui diminuerait les impacts d'une modification, ...

[deadalnix]

Ça nécessite que tu mettes en place une procédure pour modifier ces interfaces.

Car malheureusement, dans la pratique, on a rarement tout bon du premier coup :/

[Nebulix]

Mon blocage se situe au niveau de la modélisation,

@Nebulix Le modèle est déjà, et tous les diagrammes nécessaires.

[Mac LAK]

En général, je règle le problème en confiant à une personne la responsabilité des interfaces en question, ce qui crée dans ton cas un quatrième module.

Il est alors le seul habilité à modifier lesdites interfaces, les autres ne faisant qu'utiliser une "librairie" (en pratique, un ensemble d'entêtes le plus souvent) d'interfaces. A noter que j'utilise "interface" dans le sens le plus large du terme : si par exemple deux modules communiquent entre eux via une connexion réseau, alors l'intégralité du code client/serveur nécessaire à cette communication EST une interface à part entière. Même chose pour les FIFO, les structures de données partagées, les objets de synchronisation, etc. Si tu es en multithread, alors le module d'interface doit également contenir le code de création / gestion des threads de façon à uniformiser tout ça au sein des divers modules. Bref, "interface" est à prendre dans le sens "modules entre eux", mais AUSSI "module et système". Du moment qu'un machin sort d'un module, il DOIT passer par le module d'interface.

Dans mon cas particulier, qui est de s'appuyer en général sur une librairie d'abstraction C/C++, ces interfaces sont les encapsulations "haut niveau" (ou "hautes performances" suivant le cas) de fonctions plus primitives, le but étant simplement de rendre des opérations complexes et/ou difficiles à mettre au point plus accessibles au développeur lambda, inclus débutants, AT et stagiaires qui n'ont pas forcément la connaissance du système dans sa globalité.

Bien entendu, ce développeur-charnière doit être à l'écoute des besoins de chacun, mais c'est lui qui vérifie que les modifications n'introduisent pas de régressions (tests unitaires et fonctionnels impératifs, de préférence automatiques). Si tu es dans une optique de programmation par contrat, il est également en charge du respect des invariants et de la définition des pré et post conditions.

En général, je donne cette casquette à la personne ayant le module le plus "central", car il est rarissime qu'un tel module d'interface occupe une personne à temps plein sur toute la durée d'un projet. De par sa position "centrale", le développeur est souvent plus à même de déterminer l'impact d'une modification sur tous les modules, par rapport à quelqu'un qui serait à une "extrémité".
En cas de conflit et/ou de choix d'implémentation à faire, la décision finale revient conjointement au chef de projet et au responsable d'interface, le CP ayant le dernier mot si besoin.

[Jimmy_]

Plus que le découpage c'est surtout une communication efficace qui importe le plus dans ce type d'équipe.
La factorisation du code commun est la clé. Cela evitera que chacun fasse sa sauce dans son coin. Après le contenu à l'interieur de chaque module a moins d'importance.

[ZeRevo]

Une application peut être découpée en plusieurs couches :
- dao : accès aux données
- beans : classe composée uniquement de propriété privées et d'accesseurs
- service : appels aux dao + code métier.

Ensuite, on peut ajouter une couche de vue

Une règle simple lors du travail en équipe est d'avoir des commits fréquents et que la head fonctionne correctement. Il y a des outils comme hudson qui permettent de faire un checkout d'un projet et de lancer les tests. Les commits fréquents sont obligatoires afin d'éviter les merges difficiles.

Il va de soit que personne ne doit supprimer ou "refactoriser" du code d'un autre membre de l'équipe, si celui ci code encore dessus.

Pour le découpage du travail, je dirais que ça n'a pas d'importance, ce qui est important c'est de bien définir le scope des frameworks utilisées et que chaque nouveau framework doit être débattu en équipe. Un point également à prendre en considération c'est que personne n'est dépendant du code qu'il produit. En clair, il faut laisser son égo de côté et éviter de critiquer le code des autres, au risque de se retrouver à tout coder tout seul, ce qui n'est pas le but.
Un jour j'espère qu'un écrivain s'attardera à présenter ce que représente l'égo du programmeur. C'est l'un de ses vices les plus marquants...

[Nebulix]

Une règle simple lors du travail en équipe est d'avoir des commits fréquents et que la head fonctionne correctement. Il y a des outils comme hudson qui permettent de faire un checkout d'un projet et de lancer les tests. Les commits fréquents sont obligatoires afin d'éviter les merges difficiles.
... ce qui est important c'est de bien définir le scope des frameworks utilisées ...

Quand je veux qu'une collaboration réussisse, j'essaie de bien me faire comprendre en parlant français ( ou anglais). L'usage de jargon permet de se donner de l'importance, mais comme chacun le comprend à sa façon, le mur n'est pas loin.

Un jour j'espère qu'un écrivain s'attardera à présenter ce que représente l'égo du programmeur. C'est l'un de ses vices les plus marquants...

J'avais remarqué qu'il y a de plus en plus de "managers" et de moins en moins de programmeurs.
Merci d'avoir révélé que ce sont eux, avec leur ego surdimensionné qui plombent les projets.
Arrivera-tu à les éliminer complètement ?

[chaplin]

J'avais remarqué qu'il y a de plus en plus de "managers" et de moins en moins de programmeurs.
Merci d'avoir révélé que ce sont eux, avec leur ego surdimensionné qui plombent les projets.
Arrivera-tu à les éliminer complètement ?

Une petite blague :

Les chroniques racontent qu'en 1994 aurait eu lieu un challenge d'aviron
entre l'équipe de rameurs de l'ENA et ceux d'une université Province.
Les rameurs de l'Université brillèrent dès le départ, et arrivèrent avec
une heure d'avance sur l'équipe Enarque...

De retour dans les locaux de l'ENA, le Comité de Consultation se réunit
pour analyser les raisons d'un résultat si imprévu et déconcertant.

Leurs conclusions furent les suivantes :

1) L'équipe universitaire était formée d'un chef d'équipe et de 10
rameurs...
2) L'équipe de l'ENA était, elle, constituée d'1 rameur et de 10 chefs
d'équipe.

La décision fût porté à la sphère de planification stratégique pour
l'année suivante, avec une réforme dont les répercussions se feraient
ressentir à tous les niveaux de la délégation.

En 1995, lors du départ du nouveau challenge, l'équipe universitaire
reprenait une fulgurante avance. Cette fois-là, l'équipe Enarque
arrivait avec 2 heures de retard...

La nouvelle analyse du Comité de Consultation rendait les constatations
suivantes :

1) Dans l'équipe Universitaire, il y avait 1 chef et 10 rameurs.
2) L'équipe de l'ENA, suite aux réformes décidées par le Comité de
Consultation et approuvées par la haute sphère de planification,
comprenait :

* Un chef d'équipe
* Deux assistants au chef d'équipe
* Sept chefs de section
* Un rameur

La conclusion du Comité fut unanime et lapidaire: "Ce rameur est un bon
à rien".

En 1996 se pressentait une nouvelle opportunité pour l'équipe Enarque.
En effet, le Département du Haut Management d l'ENA, en collaboration
avec le Département de Recherche sur les Ressources Humaines de cette
même école, avait mis au point une stratégie novatrice qui améliorerait
sans aucun doute possible le rendement et la productivité, grâce à
l'introduction de substantielles modifications dans la structure.
C'était la clef de voûte du succès, l'aboutissement ultime d'une
méthodologie qui ferait pâlir d'envie même les meilleurs managers au
monde...

Le résultat fût catastrophique. L'équipe Universitaire arrivait cette
fois avec 3 heures d'avance sur l'équipe énarque. Les conclusions fûrent
effroyables :

1) Dans un évident but de déstabilisation spéculative, l'équipe
universitaire avait opté pour la formation traditionnelle : 1 chef
d'équipe et 10 rameurs.
2) L'équipe Enarque avait introduit une formation avant-gardiste:

* Un chef d'équipe
* Deux consultants Qualité
* Un auditeur en empowerment
* Un superviseur de downsizing
* Un analyste de procédures
* Un technologue
* Un contrôleur
* Un chef de section
* Un technicien chronomètre
* Un rameur

Après plusieurs jours d'épuisantes réunions et autant de séances de
Brainstorming, le Comité décidait de punir le rameur en lui supprimant
ses bourses d'étude et en le radiant de l'école, dont la Grandeur et la
Réputation risquait de se voir ternie par une telle incompétence.

Lors de la réunion de clôture, le Comité, appuyé par le corps
enseignant, statuait :

"Pour le prochain challenge, nous engagerons un nouveau rameur, mais par
le biais d'un contrat d'Outsourcing, de manière a éviter toute friction
syndicale et d'esquiver tout contrat de travail et charges sociales qui
en découlent, éléments qui, sans aucun doute, ont jusque là dégradé
l'efficacité et la productivité de nos ressources humaines".

Ndlr : "Toute ressemblance avec des organisations actuelles ou passées...."

[Jimmy_]

J'avais remarqué qu'il y a de plus en plus de "managers" et de moins en moins de programmeurs.
Merci d'avoir révélé que ce sont eux, avec leur ego surdimensionné qui plombent les projets.
Arrivera-tu à les éliminer complètement ?

En fait il y a beaucoup plus de programmeur, mais on ne les vois plus. Car en Inde ou dans les pays de l'est ...

[_Xavier_]

Merci encore Mac LAK, ta contribution m'a beaucoup servi.

Le découpage du projet a été bien fait, les modules sont transparents et autonomes. C'était aussi une opportunité de découvrir, dans d'autres sujets du forum, certains concepts de JAVA (de la POO en général ? ) que j'utilisais n'importe comment, les Interfaces.

On a été moins rigoureux sur les tests et on a constaté les conséquences à la fin du projet. Mais pour un premier projet c'était pas mal.

Quand je veux qu'une collaboration réussisse, j'essaie de bien me faire comprendre en parlant français ( ou anglais). L'usage de jargon permet de se donner de l'importance, mais comme chacun le comprend à sa façon, le mur n'est pas loin

J'ai résolu le problème du "langage de communication" (français ou anglais et non du langage geek) depuis le début pour l'avoir expérimenté dans d'autres domaines de la vie. Je n'ignore pas qu'il y a des termes techniques propres à l'informatique mais l'usage qu'en font certains leur fait perdre leur sens originel. Devant un client ou un recruteur cette stratégie peut rendre service mais avec des co-épiquiers je ne vois pas vraiment à quoi ça sert.

[deadalnix]

Ha les tests !

C'est une des choses qui font que j'aime D : on peut coder les tests en même temps que le reste et dans le même fichier.

Et c'est vraiment l'erreur n°1 qui est souvent faite. Quand je code, je teste tout, même les truc les plus bêtes. J'avais un collègue (et ami) qui me disait régulièrement que j'en faisais un peu trop avec les tests. Jusqu'au jour ou il a perdu une semaine car il y avait une erreur dans la spec d'une lib qu'il utilisait. Après cette mésaventure, qui lui a causé beaucoup d'heures sup', il est venu se renseigner sur ma méthode de travail, et a modifié la sienne en conséquence.

Pour info, c'était un projet pro ?

[_Xavier_]

Ha les tests !

C'est une des choses qui font que j'aime D : on peut coder les tests en même temps que le reste et dans le même fichier.

Et c'est vraiment l'erreur n°1 qui est souvent faite. Quand je code, je teste tout, même les truc les plus bêtes. J'avais un collègue (et ami) qui me disait régulièrement que j'en faisais un peu trop avec les tests. Jusqu'au jour ou il a perdu une semaine car il y avait une erreur dans la spec d'une lib qu'il utilisait. Après cette mésaventure, qui lui a causé beaucoup d'heures sup', il est venu se renseigner sur ma méthode de travail, et a modifié la sienne en conséquence.

Oui c'est une partie que l'on néglige en général, "tant que ça compile c'est bon". Mais au fur et à mesure que l'on avance on est hanté par la peur de tester, par crainte d'avoir de mauvaises surprises. C'est comme avec les tests de VIH.

Pour info, c'était un projet pro ?

Non c'est un projet d'école.