Discussion :

[cladsam]

Quelque chose que je considère comme vitale pour les projets que je fait, est de ne SURTOUT PAS se contenter de répondre simplement au besoin comme il est si simple de faire : il faut préparer le programme à son évolution.

Alors au risque de surprendre je ne suis que partiellement d'accord avec cette assertion. Je m'explique : soit une fonction qui renvoit des infos sur un forunisseur à partir de son ID. Une piste potentielle d'évolution de cette fonction pourrait être : la même fonction qui renvoit les infos de N-forunisseurs.

En ce sens, on peut se dire que faire N appels à une fonction qui renvoit 1 forunisseur est plus gourmand que faire appel 1 fois à la fonction qui renvoit N fournisseurs.

[MODE HS ON]
(selon le concept bien connu du "on peut tromper 1 fois 1 personne, on peut tromper 1000 fois une personne ...)

[MODE HS OFF]

partant de la on prévoit tout de suite de mettre une liste en entrée de la fonction et dans le cas du besoin d'un seul forunisseur, on mettra un seul élément dans la liste en entrée.

Pourtant, c'est bien connu, le grand problème de notre époque ce sont les budgets. On a jamais le temsp de faire une conception parfaite, un truc super souple et optimisé. En clair, ce qu'on perd en temps à vouloir bien préparer les choses pour l'avenirse traduit souvent en temps qu'on a pas pour terminer correctement les choses du présent.
bref, le mieux étant l'ennemi du bien, à vouloir être trop altruiste on fini par en être la victime.

je dirais donc pour ma part que :

"Bien qu'une conception idéale soit faite de telle sorte que le produit soit le plus adaptable possible, les impératifs de délai empêche d'atteindre la conception idéale. Il faut donc s'inspirer de ces idéaux de conception tout en ne perdant pas plus de temps que nécessaire et en ne cherchant pas forcément le perfection".

[mogwai162]

Il est évident qu'un programme parfait n'existe pas et le mieux etant l'ennemi du bien, vous allez droit dans le mur si vous voulez atteindre la perfection.

Cependant il existe des solutions : soit un compromis, soit des chemins de traverses.

Je prend souvent comme exemple le tableau les iris de van gogh : un champs d'iris blanc avec au milieu un iris bleu. Vous pouvez batir vos programmes de la meme manière Les utilisateurs adorent ça !

[CinePhil]

soit une fonction qui renvoie des infos sur un forunisseur à partir de son ID. Une piste potentielle d'évolution de cette fonction pourrait être : la même fonction qui renvoie les infos de N-fournisseurs.

L'exemple est bien choisi.
Ce qui m'a intéressé aussi dans mes cours CNAM, c'est le concept de boîte noire associé au concept objet.
Si je reprends l'exemple ci-dessus, cette fonction accepte en entrée par exemple une chaîne de caractères : le nom du fournisseur.
Si je veux que cette fonction me retourne N fournisseurs je dois lui fournir un tableau en entrée donc la fonction ne fonctionne pas.
Chercher une liste de fournisseurs, c'est une autre fonction qui accepte des entrées différentes et qui donnera des sorties différentes.

Si on veut généraliser la fonction qui retourne 1 fournisseur, c'est peut-être assez facilement faisable en ajoutant en entrée le type d'info demandée. On peut alors utiliser la fonction pour retourner les caractéristiques (toutes les propriétés de l'objet) d'1 fournisseur, d'1 client, d'1 employé, d'1 contact, d'1 produit...

[nanomag]

Un autre point qui peut devenir courant dans les moyennes entreprises :
Un nouveau produit est lancé, le responsable/chef de projet veut gagner du temps sur certains points déjà existants dans d'autres produits, on prend quelques fichiers ou quelques classes d'un produit plus vieux et là où ça bloque c'est qu'en général, pour que ça fonctionne on ajoute une librairie/un autre fichier lié etc... mais on n'a pas le temps d'épurer le code !
ce qui contribue à rendre le code compliqué avec des blocs de code inutiles.
On peut réutiliser du code à condition que ce que l'on réutilise soit modulaire/autonome/composant, ce qui en soit est toujours une bonne chose.

le pair-programming (XP) pour intégrer un nouveau developpeur sur le projet (surtout s'il sort de l'école) permettra de le faire rapidement monter en compétences.

Une bonne communication entre les développeurs et chef de projet, par exemple un point par semaine qui a fait quoi la semaine dernière, qui va faire quoi la semaine à venir.. (scrum)

Déterminer un interlocuteur (chez le client) unique (pour le projet ou par module si ceux là ne sont pas trop interdépendants) pour éviter que les demandes ne varient pas d'une personne à l'autre. Qui prend les décisions chez le client ?

[moutey]

Salut,
Je pense qu'une approche modulaire serait bienvenue.
La plupart du temps on se lance dans des projets herculéens qui mettent beaucoup de temps à être complètement fini.
Un projet segmenté en module bienfait auquel on ajoute au fur et à mesure les différentes spécificités serait plus efficace.

[el_slapper]

Salut,
Je pense qu'une approche modulaire serait bienvenue.
La plupart du temps on se lance dans des projets herculéens qui mettent beaucoup de temps à être complètement fini.
Un projet segmenté en module bienfait auquel on ajoute au fur et à mesure les différentes spécificités serait plus efficace.

Pas forcément. Souvent, les modules ont été pensés dans une certaine optique, avec certaines contraintes, et plus tard, ils deviennent des boulets. Qu'il faut contourner ou refondre. L'approche modulaire est efficace sur un laps de temps restreint(moins de 5 ans). Au delà, elle devient aussi inextricable que les autres. Parceque les besoins ont changé, parceque le monde extérieur a changé, parceque les autres applications ont changé.

sur un programme seul et indépendant, tu as évidemment raison. Sur des S.I. monstrueux, c'est plus compliqué

[souviron34]

Pas forcément. Souvent, les modules ont été pensés dans une certaine optique, avec certaines contraintes, et plus tard, ils deviennent des boulets. Qu'il faut contourner ou refondre. L'approche modulaire est efficace sur un laps de temps restreint(moins de 5 ans). Au delà, elle devient aussi inextricable que les autres. Parceque les besoins ont changé, parceque le monde extérieur a changé, parceque les autres applications ont changé.

sur un programme seul et indépendant, tu as évidemment raison. Sur des S.I. monstrueux, c'est plus compliqué

pas d'accord du tout...

L'approche modulaire (et d'ailleurs je me demande dans le fond ce qu'on entend par là) est essentielle surtout pour les SI monstrueux à durée de vie longue....

Et une des sources de problèmes est qu'à mon avis justement soit 1) les "modules" n'ont pas été correctement analysés au départ, soit 2) les nouveaux développeurs/mainteneurs n'ont pas compris la philosophie d'architecture initale (ce que je rencontre actuellement sur une très grosse et très vieiille application...)

[el_slapper]

(.../...)Et une des sources de problèmes est qu'à mon avis justement soit 1) les "modules" n'ont pas été correctement analysés au départ, soit 2) les nouveaux développeurs/mainteneurs n'ont pas compris la philosophie d'architecture initale (ce que je rencontre actuellement sur une très grosse et très vieiille application...)

En fait, on est quasiment d'accord; on le dis juste de manière différente.

Sauf que si je reprends tes points :

1)les modules au départ sont conçus dans un cadre donné. Il est très difficille d'anticiper certains changements d'architecture. Si la signature d'appel à un module change, et que ce module est appelé par un autre appelé par un autre appelé par un autre........ alors tu recompiles la moitié du SI, avec les soucis de gestion de conflit avec les autres évolutions en cours que celà comporte.
2)On vit dans un monde réel, avec des couts élevés et des budgets faibles. Les nouveaux n'ont pas forcément le temps de s"imprégner de l'ensemble d'une philosophie quand ils commencent. Un urbanisme bien léché, hyper-efficace quand il est utilisé par des gens qui connaissent, peut être aussi contre-productif quand des gens débarquent pour des interventions courtes. Tu en fais l'expérience, si j'ai bien compris.

Après, oui, il faut modulariser. Un monstre Cobol de 35 000 lignes(dont 5 000 de gestion d'erreurs) et qui appelle 72 modules d'accès bases, c'est un poil beaucoup(et encore, les accès bases n'étaient pas codés en natif).

Mais ce que je veux dire, c'est que le mieux est l'ennemi du bien. Si tu as un module chapeau qui appelle un module d'aggrégation qui apelle des modules métiers qui appellent des modules accesseurs fonctionnels(qui appellent des modules accesseurs techniques) et des modules de gestion d'erreurs métiers qui eux-mêmes..........alors je ne suis pas sur que tu aie gagné en maintenabilité.

quand j'ai commençé, j'encapsulais tout comme une brute. Tout ce qui dépassais 10 lignes, hop! externalisé. j'ai mis de l'eau dans mon vin. je suis toujours l'ennemi des monstres hyperlinéaires, mais à force de faire de la maintenance, j'ai appris à moins saucissoner..... Le déclic, c'est le jour ou un de mes modules a buggé, et que j'ai passé 2 jours à remonter chaque appel pour comprendre ce que la doc du module que j'appelais ne disait pas. Parcequ'evidemment, il y avait 5 modules consécutifs codés par 5 personnes différentes(j'étais n°6 dans la chaine alimentaire).

[souviron34]

quand j'ai commençé, j'encapsulais tout comme une brute. Tout ce qui dépassais 10 lignes, hop! externalisé. j'ai mis de l'eau dans mon vin. je suis toujours l'ennemi des monstres hyperlinéaires, mais à force de faire de la maintenance, j'ai appris à moins saucissoner.....

Absolument....

Une des raisons pour lesquelles je ne suis pas favorable aux langages OO en tant que tels....

Par contre, je ne parle pas de projets de 35000 lignes, pour moi c'est petit.. Je parle de projets de 700 000 a 2 a 3 millions de lignes...


Et ce dont tu parles est "teinte" par un langage, ou un "paradigme", si tu veux (les mots que tu emploies : "signature", "urbanisme", "aggregation", "possesseur"....).

Quand je parle modularite, je parle modularite conceptuelle... Celle-la devrait etre persistente... et independante des concepts du moment... Purement logique.

La modularite "code", est essentielle aussi, et, meme si certaines interfaces ou structures changent, les impacts devraient etre minimes si la modularite a ete bien concue... (et suivie )

[el_slapper]

(.../...)
Par contre, je ne parle pas de projets de 35000 lignes, pour moi c'est petit.. Je parle de projets de 700 000 a 2 a 3 millions de lignes...

je parle juste d'un module unique; le projet, lui, approchait le million de lignes(mais avec du Cobol, du RdJ, du MQ series et plein d'autres, c'est difficille de faire un total qui aie un sens)

Et ce dont tu parles est "teinte" par un langage, ou un "paradigme", si tu veux (les mots que tu emploies : "signature", "urbanisme", "aggregation", "possesseur"....).

Mouais. Mais ça ne change pas les réalités qui sont derrière; tu peux nommer "signature", "paramètres d'appel" ou "données en entrée", ça recouvre toujours la même réalité.....

Quand je parle modularite, je parle modularite conceptuelle... Celle-la devrait etre persistente... et independante des concepts du moment... Purement logique.

Je comprends bien ça. Pour tout un tas de raisons, en COBOL, on ne peut pas découper à l'infini en programmes appelés; un bon programme disposera donc d'une modularité interne(enfin, il vaut mieux quand même couper en morceaux, hein.....). Je comprends donc parfaitement ton raisonnement. Mais j'insiste : à trop saucissoner, on rend le code aussi illisible et spaghetti qu'à ne pas le saucissoner du tout.

La modularite "code", est essentielle aussi, et, meme si certaines interfaces ou structures changent, les impacts devraient etre minimes si la modularite a ete bien concue... (et suivie )

Bien conçue, et bien suivie; voilà les deux choses qui me posent problème :

_bien conçue : une conception correspond toujours à un besoin. Exemple, une appli gère un référentiel carte Bleue; Bien conçu, il présuppose(alors que ça n'est pas demandé) qu'un seul client peut avoir plusieurs comptes, et que chaque compte peut supporter plusieurs cartes. Dix ans plus tard, on s'aperçoit qu'en fait, une carte devrait AUSSI pouvoir pointer sur plusieurs comptes, pas seulement l'inverse. Moralité, il faut une refonte majeure de l'application. Qui pourtant était bien conçue, et avait anticiper plusieurs axes d'évolution. Mais il est impossible de les prévoir tous.

_bien suivie. Là, on entre plus dans des questionnements organisationnels. Quand la majorité des programmeurs sont des prestataires jugés sur délais et résultats, et pas sur leur manière de coder, l'exigence sur ce point là est souvent oubliée. Sans compter que si les sachants sont partis, leurs remplaçants n'ont souvent pas les billes pour saisir l'esprit de l'architecture qui leur est proposée.

[Monstros Velu]

Exemple, une appli gère un référentiel carte Bleue; Bien conçu, il présuppose(alors que ça n'est pas demandé) qu'un seul client peut avoir plusieurs comptes, et que chaque compte peut supporter plusieurs cartes. Dix ans plus tard, on s'aperçoit qu'en fait, une carte devrait AUSSI pouvoir pointer sur plusieurs comptes, pas seulement l'inverse. Moralité, il faut une refonte majeure de l'application. Qui pourtant était bien conçue, et avait anticiper plusieurs axes d'évolution. Mais il est impossible de les prévoir tous.

J'en déduirai qu'une des bonnes pratiques serait : "il faut mettre toutes les relations en N-N, juste au cas où". J'avoue que des fois, je le fais : on me dit que pour tout T il n'y aura qu'un seul S. Mais juste au cas où, je prévois qu'il y en ait plusieur. Ca prend peu de temps à ce moment là, ça en prendrai beaucoup plus plus tard.

[cchatelain]

Cela n'alourdit pas un peu trop les perfs ? La charge de la base de données n'est pas la même dans ce cas, car ça ajoute pas mal de jointures.

[gl]

J'en déduirai qu'une des bonnes pratiques serait : "il faut mettre toutes les relations en N-N, juste au cas où". J'avoue que des fois, je le fais : on me dit que pour tout T il n'y aura qu'un seul S. Mais juste au cas où, je prévois qu'il y en ait plusieur. Ca prend peu de temps à ce moment là, ça en prendrai beaucoup plus plus tard.

Dans le principe, je suis entièrement d'accord qu'il faut faire le minimum de supposition et privilégier les relations N-N mais de là à n'avoir que des relations N-N ca me parait utopique, en effet il y a généralement un moment ou il faut obtenir une relation unique.

Pour reprendre l'exemple de el_slapper sur les comptes et cartes bancaires, il faut au final débiter (ou créditer) le compte en fonction des données entrantes. Si toutes les relations sont N-N comment déterminer le compte a débiter ?
On débite tout les comptes ? Un compte au hasard ?
Pour résoudre le problème il faut bien a un moment obtenir une relation unique, certes elle ne sera pas ici entre deux données simples (le numéro de carte et le compte ici) mais entre deux ensembles de données (un ensemble de données carte et le compte bancaire) mais elle existe bien au final.

[Monstros Velu]

Plusieurs cartes peuvent appartenir à un compte, et un compte peut avoir plusieurs cartes, il s'agit bien q'une relation N-N. Et quand on veut débiter, il ne s'agit plus de débiter une carte ou un compte, mais de débiter sur l'ensemble formé par la paire {carte, compte}. Ce n'était pas possible il y a quelques années, donc pas prévu par les modèles, mais désormais, c'est possible.

De même, il y a un homme au brésil qui est "tombé enceint". Le modèle objet qui voit les classes [homme] et [femme] dériver de la classe [humain] tombent à l'eau ! 8o)

Celà étant, les relations N-N alourdissent en effet la base. Il y a donc une balance à trouver entre évolutivité et performance.

[gl]

Plusieurs cartes peuvent appartenir à un compte, et un compte peut avoir plusieurs cartes, il s'agit bien q'une relation N-N. Et quand on veut débiter, il ne s'agit plus de débiter une carte ou un compte, mais de débiter sur l'ensemble formé par la paire {carte, compte}. Ce n'était pas possible il y a quelques années, donc pas prévu par les modèles, mais désormais, c'est possible.

Il s'agit bien maintenant d'une relation N-N, je ne discute pas ce point.

Le problème d'utiliser la paire {carte, compte} c'est justement qu'il faut arriver à la trouver cette fameuse paire.
Pour rester dans l'exemple, lorsque tu fais une transaction, le numéro de compte n'est pas connu, on a seulement le numéro de la carte et différents autres éléments de la carte (et de la transaction mais qui n'ont pas d'utilité ici).
Lorsque vient le moment de débiter la transaction, il faut déterminer de manière unique le compte à débiter à partir de ces informations. Il faut donc bien avoir une relation unique entre les données de la carte (dont le numéro) et le numéro du compte.
La seule différence, c'est qu'avant le numéro de la carte était suffisant pour déterminer le numéro de compte et maintenant il faut utiliser également d'autres données (et si le problème rencontré par el_slapper est bien celui auquel je pense, ces données n'existait pas auparavant).

On en reste bien à ma conclusion précédente : il faut certes privilégier les relations N-N et ne pas faire trop d'hypothèse sur l'utilisation qui sera faite dans les données. Mais il arrive un moment où une relation N-N n'est plus possible.

Note bien que mon propos n'est pas de rejeter ta conclusion "il faut mettre toutes les relations en N-N, juste au cas où" mais juste d'y apporter un bémol : ce n'est pas toujours possible.

[Monstros Velu]

Ma conclusion était fortement exagérée, de toutes façons 8o)

[souviron34]

Ma conclusion était fortement exagérée, de toutes façons 8o)

oui et non

je suis d'accord avec toi..

Mas pour garder la souplesse, il suffit des les avoir en dynamique... Mais donc dans les structures on pourrait arriver à N*N..

Juste ne pas le coder en dur est mieux..

[Monstros Velu]

Un modèle en métadonnée peut être une solution, question souplesse.

[dba01]

Bonjour.

Juste un petit commentaire : mettez-en toujours (des commentaires) dans votre code. Dernièrement, on a hérité de 3 applis sans aucune doc. "Non, on n' a rien, c'est peut-être le mec qui les a emporté, on sait pas".
On a donc commencé par aller voir l'utilisateur pour savoir à quoi servait ces applis. On n'avait pas l'air cons ! Ensuite, c'est mon informateux qui s'est collé à l'écran pour déchiffrer le truc et trouver comment on chargeait, comment on lançait, etc... Heureusement, mon informateux, c'est un doué qui lit pratiquement tous les langages comme moi je lis une bande dessinée.
Mais quand même, si on avait eu des commentaires ! Ne serait-ce qu'une explication simple en tête de chaque module pour en décrire l'utilité.
Personnellement, il m'est arrivé qu'on me demande la mise à jour d'une petite moulinette que j'avais écrite en CLIPPER ... 5 ans après. Ben pour me rappeler ce que j'avais fait et pourquoi, c'était pas de la tarte. Pour la peine, j'ai fait l'inverse : j'en ai foutu partout. Finalement, ça ne consomme par d'air et ça peut toujours servir. Bien sûr, les passages habituels, les écrans de saisie, les sorties papier, on les reconnaît de loin. Mais les traitements internes à plusieurs étages, avec des fonctions tordues, et des appels en cascade, ça fait mal à la tête.
Mais vous parlez aussi de la définition des développements. Ca c'est le travail du maître d'ouvrage. C'est à lui de dire ce qu'il veut, et de s'expliquer de manière à être compris. Il doit alors être du côté client, mais avoir de bonnes notions de programmation, afin de faire des descriptions utilisables et de préciser suffisamment les bornes et résultats souhaités. Sinon, il ne reste plus à l'informateux qu'à apprendre le métier du client, comme on faisait dans le temps. C'est peut-être pourquoi mon informateux aime bien mes définitions : c'est dans l'ordre du général au détaillé, avec des tableaux, et aussi des modèles d'écrans en BMP. J'ajoute même des passages en SQL quand je n'arrive pas à le dire en bon Français.
Le poste d'analyste est déteminant pour la réussite. Ensuite vous pouvez utiliser l'outil de modélisation que vous voulez, ou que vous connaissez. Si les idées sont claires et dans l'ordre, ça ira. Sinon...
On m'a reproché le temps passé à l'analyse. Mais putain le développement a été super turbo et tout a marché du premier coup. Alors que mon informateux s'attaquait au JAVA sans préparation. Même les évolutions sont rentrées là dedans comme dans du beurre. Faut pas hésiter à perdre du temps sur l'analyse, se faire confirmer par le client, lui faire des images des résultats, lui poser des question idiotes. Et on ne commence pas tant qu'on n'a pas l'image entière de tout le fourbis dans la tête, vu d'avion ou vu à la loupe. Faut pas dessiner des wagons, faut dessiner un train, mais sans omettre les poignées de portes. Tout dans la tête, au point de pouvoir réécrire la doc entièrement de mémoire. Vous avez le droit à l'aspirine si vous voulez.
Si l'étude est bien finie ça marchera sûrement, à moins d'avoir un développeur...sous développé !
Bonne soirée.
db

[_vince_]

Pour eviter d'avoir du code qu'on ne sait pas a quoi il sert, une bonne pratique consiste a ecrire les references des exigences dans le code source (tracabilite verticale).

Je ne suis pas fan de mettre des commentaires partout. Pour la bonne raison que le code doit etre se lire facilement. C'est a dire qu'on doit pouvoir comprendre l'intention de l'auteur (le pourquoi). Les details de l'implementation (le comment) doivent rester caches ou au moins ne pas vous sauter a la figure. Les commentaires ne devraient servir qu'a faire reference aux documents applicables, utilises pour construire le logiciel.

Pour finir, un petit exemple... On voit souvent des tests du genre:
if (ret1 == 64 && ret2 != ret1) {...}

Ca pourrait etre remplace par (au minimum) :
isOk = (ret1 == 64 && ret2 != ret1)
if(isOk) {..}