Pourquoi la communauté C++ s'intéresse plus à la technique et ignore la conception?

Citation:

---

Envoyé par Issam_Lahlali

a chaque fois je parle de mettre dans le framework technique ce qui est répétitif et ce qu'on juge utile mais il y avait dés le départ une résistance contre le framework technique , et si t'a t'est pas contre je crois que d'autres ils sont toujours contre :)

---

OK, je crois comprendre d'où vient cette incompréhension.

Le "ce que l'on juge utile", n'apparaît que dans un de tes derniers messages.

Les autres remarques portent sur le fait d'encapsuler ce qui est répété ou les
bibliothèques qui ne correspondent à 100% au niveau de granularité dont tu as besoin dans la partie "métier" du code, ce n'est pas de ça que je parlais en disant qu'il faut prendre la décision au cas par cas. Tu te focalises uniquement sur deux axes, qui bien qu'importants (et je ne remet pas en cause leur utilité, en particulier concernant la duplication de code) ne sont pas uniques, il existe de nombreux paramètres à prendre en compte. Même dans ces deux cas là, la décision d'encapsuler ou non n'est forcément systématique, même dans ces cas là il faut le faire si on le juge utile au regard des différents paramètres (sachant que la décision ne va pas satisfaire tous ses paramètres mais représenter un compromis acceptable).

Bref c'est réellement à voir au cas par cas et non en fonction de simplement deux critères.
Si tu travailles toujours dans un contexte équivalent et que dans ce contexte, ces deux axes représentent les deux seuls critères de choix, alors oui la décision doit toujours être prise en fonction de ces deux seuls critères. Mais il ne faut pas généraliser ton expérience, tout le monde ne travaille pas dans le même contexte et tout le monde n'a pas les mêmes contraintes.

Citation:

---

Envoyé par gl

Juste une petite précision, POCO ne se limite pas au côté système, elle propose également des choses intéressante côté database et XML (respectivement module Data et XML) et également réseau (module NET), même si dans ce domaine elle semble moins riche que ICE (je ne connais pas vraiment ICE, donc je ne saurais être totalement affirmatif).
En outre Applied informatics propose également différents modules (commerciaux ceux-ci) axés réseau par dessus POCO qui, d'après les échos que j'ai eu, sont de bonne qualité.

---

Tout à fait. J'ai juste mis cette "étiquette" système dessus (sous-entendu, non-réseau) parce que ses fonctions réseau, toutes méritantes qu'elles soient, sont inférieures à celles de ICE. Réciproquement, les fonctions d'abstraction système de ICE (gestion des threads notamment) sont très lights par rapport à celles de POCO... ;)
Pour le reste (et les visiteurs du topic), se reporter aux docs de ces librairies, c'est un peu trop vaste pour être résumé en trois lignes... ;)

Citation:

---

Envoyé par Issam_Lahlali

juste une question est ce que tout les développeurs qui ont besoin d'utiliser le distribué dans ta boite sont censé connaitre ICE et ces subtilités?

---

Bon, donc, tu n'as effectivement JAMAIS utilisé cette librairie, ni vu ce qu'elle faisait.
Pour un utilisateur d'un système ICE, ça se résume à (pseudo-code) :

Code:

---

1 2 3 4

endpoint=ICE::createObjectAdapter("NomSymboliqueDuServeur","AdresseIceGrid"); endpoint.DoAction1(...); endpoint.DoAction2(...); endpoint.DoComplexAction(...........);

---

Si besoin, tu peux aussi faire un helper sur la création de l'endpoint, mais bon, ça devient pire que de l'assistanat à ce niveau.
La tripaille, c'est les développeurs des API en question qui s'en occupent (et même eux ne touchent pas une seule fois une socket), le code client n'a jamais besoin d'être écrit explicitement (uniquement le code serveur, c'est à dire le remplissage des méthodes générées automatiquement par Slice), et l'administration IceGrid est plus que simplissime : il suffit de donner l'adresse du serveur IceGrid et c'est tout.

ICE fonctionne certes en distribué, mais aussi en flux (=sockets) plus ou moins typés, et en boucle locale en communication inter ou intra processus !

Donc, re-question : tu parles de devoir faire des frameworks, mais quand il en existe des bons déjà tout prêts, et répondant à tes besoins, tu sembles réchigner à les utiliser... Ne serait-ce pas incohérent ??

Citation:

---

Envoyé par gl

C'est réellement la seule différence ?

J'avais compris que la différence était plus dans l'intention :

• Le premier était à utiliser lorsque le client attendait une interface et que la classe en fournissait une autre.
• Le second permettait de masquer une ou plusieurs classes derrière une interface unifiée.

Ce qui laisse certains "cas limites" (normalisation d'interface à priori par exemple) dans une zone de flou.
Avec la différence que tu cites, il est effectivement plus de simple de cataloguer les constructions dans une catégorie ou dans l'autre, mais ça me semble assez artificielle comme différenciation.

---

En fait, tu viens de redire ce que j'ai dit sous une autre forme ;)
Les catégories, ce sont :
- creational patterns (abstract factory, builder, factory method, prototype, singleton)
- structural patterns (adapter, bridge, composite, decorator, facade, flyweight, proxy)
- behavorial patterns (chain of responsibility, command, interpret, iterator, mediator, memento, observer, state, strategy, template method, visitor)
Certain sont effectivement très proches, comme state et strategy où la seule différence est réellement l'intention : est-ce qu'on change d'état/stratégie en cours d'exécution ?

Citation:

---

Envoyé par Issam_Lahlali

juste une question est ce que tout les développeurs qui ont besoin d'utiliser le distribué dans ta boite sont censé connaitre ICE et ces subtilités?

si oui c'est un choix a respecter mais sérieusement pourquoi ajouter une complexité en plus pour tout les développeurs,tu me dira c'est trop facile mais peut être c'est facile pour toi , en général on a du mal a bien maitriser la technologie distribué et en plus pour moi tout ce qui touche au distribué n'est qu'un adaptateur , un développeur doit s'en foutre que ça soit distribué ou pas il doit y avoir une parfaite abstraction par rapport a ça et surtout un couplage très faible par rapport a cette couche.

---

C'est là aussi où tu n'as pas l'habitude de ces outils. Si tu avais un peu regardé l'opinion des gourous du multithreading/multiprocessing, tu te serais rendu compte que le découplage est quasiment impossible. Il y a un couplage fort et il y a une nécessité de réfléchir complètement différemment de ce que tu ferais en séquentiel.

Citation:

---

Envoyé par Issam_Lahlali

si je reviens a l'exemple de boost.asio ou on dans les exemples de Boost eux même on fait des wrappers pour simplifier.

---

wrappers qui servent juste pour exemple, et encore, je ne vois pas vraiment où il y a deswrappers dans l'histoire :koi: Ce n'est pas parce qu'il y a un wrap* que c'est un wrapper. J'ai utilisé ASIO pour faire un moteur TCP/HTTP SOAP RPC, et il n'y a pas besoind 'autre chose que les outils ASIO de base. Je regarde ce que les gens ont aussi fait du même style à côté, et c'est la même chose, pas de wrappers.

Citation:

---

Envoyé par gl

Enfin.

C'est ce que tout le monde essaie de te dire depuis je ne sais combien de page.

---

Il le dit depuis longtemps mais n'a pas encore compris ce que cela impliquait, par exemple au niveau du choix des bibliothèques, des méthodologies, ...

Citation:

---

Envoyé par Mac LAK

Bon, donc, tu n'as effectivement JAMAIS utilisé cette librairie, ni vu ce qu'elle faisait.
Pour un utilisateur d'un système ICE, ça se résume à (pseudo-code) :

Code:

---

1 2 3 4

endpoint=ICE::createObjectAdapter("NomSymboliqueDuServeur","AdresseIceGrid"); endpoint.DoAction1(...); endpoint.DoAction2(...); endpoint.DoComplexAction(...........);

---

Si besoin, tu peux aussi faire un helper sur la création de l'endpoint, mais bon, ça devient pire que de l'assistanat à ce niveau.

---

de notre coté on laisse jamais trainer un code comme ca dans tout le projet, on propose une facade qui cache le fait qu'on travaille avec ICE , c'est pas un choix d'implementation c'est un choix de conception et c'est la diference entre nos 2 points de vue.

c'est pas le fait qu'elle est trés trés simple a utiliser qu'on va la laisser trainer dans tout le projet, et d'ailleurs c'etait bénéfique puisqu'on avait essayer plusieurs brockers et imagine si a chaque fois la librairie traine dans tout le projet.

c'est le principe de couplage faible qui te protège aussi des changements futurs insoupçonnés que j'ai répéter plusieurs fois.

mais ca reste je répète un choix de conception, c'est pas trop couteux et finalement si on pense bien c'est comme le principe de l'assurance ou on paye un montant par mois ( pas trop couteux) et lorsqu'il y a un probléme on trouve notre assurance :)

Vous ne pourrez jamais vous mettre d'accord tant que vous parlerez de choses différentes qui ne sont pas généralisables...

Si on prend un cas de figure un peu plus précis, celui de l'utilisation d'une balance électronique depuis l'application pour peser des objets.

Cela nécessite :
1) Ouverture si nécessaire du port série et application des paramètres spécifiques (baudrate, parité etc..)
2) Envoi d'une requête sous forme de chaine ASCII par le port série.
3) Attendre la stabilisation de la masse pendant X millis
4) Récupérer la masse de l'objet dans le port série
5) Parser tout ça pour obtenir la masse en double

Si quelqu'un dit que ce processus doit faire l'objet d'une fonction de haut niveau qui serait du genre

Code:

---

double peserObjet(int timeoutInMs)

---

Je suis entièrement d'accord pour la plupart des cas, on ne va pas commencer à copier coller toute cette séquence à travers l'application, refaire la gestion d'erreur entre les différents phases etc...

Par contre dans le corps de cette méthode peserObject, si on utilise Boost pour la gestion du port série et qu'on me dit qu'il faut wrapper boost afin de pouvoir mettre autre chose à la place. Là je suis nettement moins d'accord.

Alors? :aie:

Citation:

---

Envoyé par Matthieu Brucher

Il le dit depuis longtemps mais n'a pas encore compris ce que cela impliquait, par exemple au niveau du choix des bibliothèques, des méthodologies, ...

---

pour être clair au sujet de ces bibliothèques on va parler d'un cas concret d'une entreprise qui commence un projet en C++:

imaginant qu'une Boite SB a une équipe de 50 développeurs C++ et utilise N librairies et on suppose que le choix est très judicieux fait par des experts comme toi qui maitrise très très bien le choix de librairie.

on commence l'implémentation et on se rend compte qu'on a besoin de fonctions techniques qu'on fait souvent non existantes dans nos librairies, et pour être concret disant le StartWith pour std::string , soit on laisse les 50 développeurs faire le StartWith a leur sauce soit avoir un framework technique au niveau de l'entreprise qui le fait.

moi je préfère avoir dés le départ du projet un framework technique ou je mettrais tout ce qui simplifiera la vie aux développeurs quelque soit les librairies techniques utilisés.

et crois moi tu fais l'expérience tu verra ce framework grandir rapidement parce que tu decouvrera que dans le code il y a pas mal de choses répétitifs avec les Copier/Coller.

d'autre part si t'est adepte du couplage faible comme assurance et protection au changement futur tu ne laissera jamais trainer les librairies pour le distribué par exemple trainer dans ton code, tu proposera a partir de ton framework une facade trés simple d'utilisation, et le but n'étant pas que simplifier mais avoir une assurance au cas d'un changement d'une techno.

et le réflexe de résistance contre le couplage faible et a mon avis comme le réflexe d'un conducteur qui dit je ne vais jamais faire d'accident je suis trés fort et j'ai pas besoin de payer l'assurance mais encore une fois ca ne dépend pas que toi, il y a plusieurs facteurs autour et tout peut changer a un moment donc autant se protéger depuis le départ.

Citation:

---

Envoyé par Issam_Lahlali

de notre coté on laisse jamais trainer un code comme ca dans tout le projet, on propose une facade qui cache le fait qu'on travaille avec ICE , c'est pas un choix d'implementation c'est un choix de conception et c'est la diference entre nos 2 points de vue.

---

Dans ce cas, tu fais un helper pour l'ouverture et tu rends le type de "endpoint" défini par macro (laid), ou héritage (bof...), ou template (admettons).
Ce qui revient toujours au même point : tu ne peux pas te passer des appels de fonction eux-mêmes, étant donné que ce sont, justement, les fonctions de haut niveau que tu souhaitais avoir.
Le fait que l'objet "endpoint" soit de type "ICE::Endpoint" ou "FrameworkMaison.Module2" a-t'il une importance quelconque, tant que les méthodes restent les mêmes ??

Citation:

---

Envoyé par Issam_Lahlali

c'est pas le fait qu'elle est trés trés simple a utiliser qu'on va la laisser trainer dans tout le projet, et d'ailleurs c'etait bénéfique puisqu'on avait essayer plusieurs brockers et imagine si a chaque fois la librairie traine dans tout le projet.

---

Ça, c'est plutôt un problème d'étude de faisabilité mal faite que de conception et/ou d'adéquation des librairies... Et de conception aussi : si tu démarres bille en tête dans le code à essayer des librairies de façon empirique (plutôt que d'en mesurer objectivement les performances), c'est également la méthodologie qui est en cause et non pas, finalement, le code lui-même...

Citation:

---

Envoyé par Issam_Lahlali

c'est le principe de couplage faible qui te protège aussi des changements futurs insoupçonnés que j'ai répéter plusieurs fois.

---

Sauf qu'à un moment, il faut aussi s'arrêter : si tu colles une couche abstraite et générique à chaque fois que tu fais le moindre truc, tu vas passer deux fois plus de temps à faire ces interfaces qu'à casser le code en cas de changement !!
Il faut savoir réfléchir en termes de coût horaire d'une modification, mais surtout en terme de probabilité de modification...

Citation:

---

Envoyé par Issam_Lahlali

mais ca reste je répète un choix de conception, c'est pas trop couteux et finalement si on pense bien c'est comme le principe de l'assurance ou on paye un montant par mois ( pas trop couteux) et lorsqu'il y a un probléme on trouve notre assurance :)

---

Pas trop coûteux ??? Tu plaisantes, là... Si ce n'est pas fait de façon générale et universelle, c'est AUSSI qu'il y a une bonne raison, et pas l'incompétence des concepteurs contrairement à ce que tu sembles penser. A partir d'un certain stade, tout wrapper / encapsuler coûte bien trop cher (perfs et/ou temps de dév), tout simplement !

Comme dans beaucoup de domaines, et l'informatique n'échappe pas à la règle, jouer les "intégristes" est bien plus nuisible que profitable. Il faut savoir s'arrêter à un moment donné, mais tu ne veux pas écouter cet argument.

Citation:

---

Envoyé par _skip

Par contre dans le corps de cette méthode peserObject, si on utilise Boost pour la gestion du port série et qu'on me dit qu'il faut wrapper boost afin de pouvoir mettre autre chose à la place. Là je suis nettement moins d'accord.

Alors? :aie:

---

certainement pas le but n'est pas wrapper Boost c'est aberrant, par contre on peut simplifier des fonctionalités de Boost si c'est necessaire.

par exemple j'ai donner l'exemple de StartWith qui n'existe pas pour std::string, on va pas laisser chaque developpeur faire sa version, mais on proposera une méthode qui le fait pour tout le monde.

ce que je dis c'est que dés le départ il faut avoir le réflexe d'avoir un framework technique ou on mettra tout ce qui facilitera le dev a tout le monde qui servira d'une part :

- simplifier et mettre en commun tout ce qu'on juge utile
- faire un couplage faible par rapport aux technos utilisés ,par exemple pour le distribué je ne laisse jamais trainer la librairie réel dans le code, je fais une façade et le developpeur ne sais même pas quelle techno distribué il utilise.

Citation:

---

Envoyé par Issam_Lahlali

pour être clair au sujet de ces bibliothèques on va parler d'un cas concret d'une entreprise qui commence un projet en C++:

imaginant qu'une Boite SB a une équipe de 50 développeurs C++

---

J'arrête de lire là, car déjà à ce niveau, tu as imaginé un cas concret qui est clairement faux. On ne commence JAMAIS avec une équipe de 50 développeurs, dans n'importe quel projet.

Tu démontres, à mon sens, ta méconnaissance de la gestion de projets SI par cet exemple irréel, et c'est pour cette raison qu'on te dit qu'il te manque de l'expérience, car clairement dans ces dernières réponses, c'est le cas. On ne part jamais bille en tête et on ne fait jamais d'over-engineering comme tu veux en faire en encapsulant tout au cas où (et ça, ça vient du monde Java C# où ce sont des règles de base chez eux).

Citation:

---

Envoyé par Mac LAK

Dans ce cas, tu fais un helper pour l'ouverture et tu rends le type de "endpoint" défini par macro (laid), ou héritage (bof...), ou template (admettons).

---

je répète c'est un choix de conception pas d'implémentation, et pour l'implémentation c'est pas ca le probléme il y a plusieurs façons de donner une façade simple a utiliser.

et pour le cout de faire ce couplage faible, ce n'est pas des mois mais quelques jours, le but est de ne pas faire abstraction a tout ce que propose ICE , mais de faire abstraction de ce qu'on utilise de ICE et c'est pas du tout la même chose, chaque librairie est générique dans le sens ou elle propose énormément de fonctionnalités pour s'adapter a tout les besoins , ca veut pas dire que lorsque j'utilise ICE j'utilise tout ce qui est fourni.

et pour le fait que t'est sur que rien ne changera, juste pour une anecdote dans la boite ou j'étais on était obliger de changer pour une histoire de license, bref pour le produit qu'on utiliser il y avait un mal entendu dans le contrat quelque part et la boite qui détient le produit a demander une somme colossale si on voulait toujours utiliser leur solution, donc rien a voir ni avec la technique, ni calcul de performance ni autre.

et c'est ca le monde réel on peut avoir une surprise n'importe quand et fort heureusement on avait notre assurance qui était le couplage fable :)

finalement dire qu'on peut maitriser tout dés le départ c'est faux , on ne sait jamais ce qui peux se passer, et cette technique de conception de couplage faible on va pas la faire bien sur a tord et a travers , mais pour le distribué je suis pour le faire.

Citation:

---

Envoyé par Issam_Lahlali

et pour le fait que t'est sur que rien ne changera, juste pour une anecdote dans la boite ou j'étais on était obliger de changer pour une histoire de license, bref pour le produit qu'on utiliser il y avait un mal entendu dans le contrat quelque part et la boite qui détient le produit a demander une somme colossale si on voulait toujours utiliser leur solution, donc rien a voir ni avec la technique, ni calcul de performance ni autre.

---

Et ? C'est un risque qui a un coût, une probabilité d'apparition et un coût de couverture.

Bon, là, on voit bien que tu essaies de te sortir de la situation dans laquelle tu t'es mis tout seul, on est à 100 lieues de ce que tu défends puisque maintenant tu ne veux plus de couplage faible partout, mais dans le distribué oui, alors que tu n'as, à nouveau, aucune connaissance dans ce domaine.

Citation:

---

Envoyé par Matthieu Brucher

J'arrête de lire là, car déjà à ce niveau, tu as imaginé un cas concret qui est clairement faux. On ne commence JAMAIS avec une équipe de 50 développeurs, dans n'importe quel projet.

.

---

tu me montre que tu ne veux rien comprendre , ou t'a bien compris le message lorsque tu l'a lu jusqu'à la fin et tu me poste une réponse ridicule genre on commence jamais par une équipe de 50 développeurs et c'est pas ca qui va influencer sur le reste du message.

essaye de relire le poste et vire on commence et met a la place "pour un projet ou on a 50 developpeurs"

et essaye de me répondre sur le reste du message .

Citation:

---

Envoyé par Matthieu Brucher

Et ? C'est un risque qui a un coût, une probabilité d'apparition et un coût de couverture.

Bon, là, on voit bien que tu essaies de te sortir de la situation dans laquelle tu t'es mis tout seul, on est à 100 lieues de ce que tu défends puisque maintenant tu ne veux plus de couplage faible partout, mais dans le distribué oui, alors que tu n'as, à nouveau, aucune connaissance dans ce domaine.

---

encore une fois ça montre l'utilité de la discussion " on ignore complètement la conception", si un expert comme toi ignore le principe de couplage faible, alors j'ai eu la réponse a ma question de départ :)

Citation:

---

Envoyé par Issam_Lahlali

tu me montre que tu ne veux rien comprendre , ou t'a bien compris le message lorsque tu l'a lu jusqu'à la fin et tu me poste une réponse ridicule genre on commence jamais par une équipe de 50 développeurs et c'est pas ca qui va influencer sur le reste du message.

---

Eh si, ça influence, car tu pars sur un cas qui n'existe pas ! Tu veux nous faire des démonstrations alors que tu es complètement à côté de la plaque !
Toute ta méthodologie, tout ce que tu racontes par du principe qu'on prend 50 développeurs et qu'on y va, on code. Je comprends maintenant pourquoi tu posais ta question au départ sur la conception ! C'est que tu n'utilises aucune méthodologie de développement, c'est de l'arrache pure ! C'est claire que dans ces conditions, la technique est primordiale, mais quand on fait les choses correctement, avec une méthodologie éprouvée de développement, bizarrement, la technique (et c'est ce que TOUT LE MONDE ici t'a dit), c'est accessoire.

Citation:

---

Envoyé par Issam_Lahlali

encore une fois ça montre l'utilité de la discussion " on ignore complètement la conception", si un expert comme toi ignore le principe de couplage faible, alors j'ai eu la réponse a ma question de départ :)

---

Où est-ce que j'ai dit que j'ignorai ce principe ? Où est-ce que j'ai dit que j'étais un expert ? C'est toi qui ne sais pas à quoi il sert et qui change d'avis tout le temps, pas moi.

Citation:

---

Envoyé par Matthieu Brucher

Eh si, ça influence, car tu pars sur un cas qui n'existe pas ! Tu veux nous faire des démonstrations alors que tu es complètement à côté de la plaque !
Toute ta méthodologie, tout ce que tu racontes par du principe qu'on prend 50 développeurs et qu'on y va, on code. Je comprends maintenant pourquoi tu posais ta question au départ sur la conception ! C'est que tu n'utilises aucune méthodologie de développement, c'est de l'arrache pure ! C'est claire que dans ces conditions, la technique est primordiale, mais quand on fait les choses correctement, avec une méthodologie éprouvée de développement, bizarrement, la technique (et c'est ce que TOUT LE MONDE ici t'a dit), c'est accessoire.

---

une question simple et je veux une réponse simple mais pas philosophique comme dab:

est ce que t'est pour ou contre un framework technique au niveau de l'entreprise?

Mais pour faire quoi ton framework ? Chez moi, je suis désolé, mais c'est impossible d'avoir un seul framework technique pour la chimie, la sismique, la paie, ... Ce sont des technologies complètement différentes, aucun point commun, ...
C'est pour ça que je n'arrête pas de te dire que tu ne connais qu'une infime partie de ce que regroupe l'informatique !

Citation:

---

Envoyé par Matthieu Brucher

Mais pour faire quoi ton framework ? Chez moi, je suis désolé, mais c'est impossible d'avoir un seul framework technique pour la chimie, la sismique, la paie, ... Ce sont des technologies complètement différentes, aucun point commun, ...
C'est pour ça que je n'arrête pas de te dire que tu ne connais qu'une infime partie de ce que regroupe l'informatique !

---

restant dans le concret , pour une fonction comme StartWith qu'on veut ajouter pour std::string , tu la mettra ou?

Citation:

---

Envoyé par Issam_Lahlali

et pour le cout de faire ce couplage faible, ce n'est pas des mois mais quelques jours, le but est de ne pas faire abstraction a tout ce que propose ICE , mais de faire abstraction de ce qu'on utilise de ICE et c'est pas du tout la même chose, chaque librairie est générique dans le sens ou elle propose énormément de fonctionnalités pour s'adapter a tout les besoins , ca veut pas dire que lorsque j'utilise ICE j'utilise tout ce qui est fourni.

---

C'est ce que je me tue (enfin, "nous nous tuons") à t'expliquer : ne confonds pas "couplage fort" et "mésutilisation d'une librairie"... Cf. mon post précédent, où je te montre pourtant que c'est bien ce que permet ICE, ou toute librairie correctement construite d'ailleurs...

Citation:

---

Envoyé par Issam_Lahlali

et pour le fait que t'est sur que rien ne changera, juste pour une anecdote dans la boite ou j'étais on était obliger de changer pour une histoire de license, bref pour le produit qu'on utiliser il y avait un mal entendu dans le contrat quelque part et la boite qui détient le produit a demander une somme colossale si on voulait toujours utiliser leur solution, donc rien a voir ni avec la technique, ni calcul de performance ni autre.

---

Tu sais, Issam, en dix ans d'expérience, et dans le bas niveau (où le code "en dur" est plus la règle que l'exception), des changements radicaux de librairies, j'en ai fait plus d'un... Y compris des changements de plate-forme matérielle, de compilateur, de gamme de code (16 bits à 32 bits, 64 bits bientôt), alors je connais bien le sujet du "ça ne changera jamais" qui n'est jamais vrai.

Je sais très bien que ça n'existe pas, par contre, je sais évaluer si une techno/librairie quelconque pourra perdurer au moins le temps de vie du module en question, avant que sa refonte intégrale ne devienne nécessaire de par les simples évolutions requises par le client (entre 5 et 10 ans dans mon domaine)... Et c'est au moment de la refonte que l'on change la "base", technologique ou logicielle, qui sous-tend le module devenu obsolète.

Mais ça, c'est l'expérience qui te l'apprends, ainsi que la connaissance du métier. C'est aussi savoir faire une étude de faisabilité, savoir "sentir" si une techno est pérenne ou juste un gadget à la mode, savoir poser les BONNES abstractions aux BONS endroits, savoir raisonner non plus en framework mais en flux de données, etc.
Comme te l'a dit aussi Matthieu, c'est une analyse de risque, avec probabilité d'occurrence et coût en cas de problème.

Citation:

---

Envoyé par Issam_Lahlali

et c'est ca le monde réel on peut avoir une surprise n'importe quand et fort heureusement on avait notre assurance qui était le couplage fable :)

---

Toi, t'es du genre à prendre une assurance auto tout-risques (couvrant aussi le risque de chute de station spatiale, la guerre nucléaire et les attaques d'aliens), alors que tu conduis un tas de boue de 20 ans qui roule à peine ?
Moi, non... J'assure en fonction de la valeur des choses, et du coût de remplacement. On ne mets pas dans une assurance le prix de l'objet neuf, c'est tout simplement un non-sens ! Dans le cas d'une voiture, si en trois ans tu mets dedans le prix d'une voiture neuve (36 mois, soit 280€ / mois pour une voiture à 10.000€), c'est idiot, il vaut bien mieux la prendre en leasing avec assurance incluse !! Et cela reste valable même en arrivant à "seulement" la moitié du prix de la voiture, d'ailleurs !

C'est pareil en logiciel : tu dis "ça ne prends que quelques jours"... OK, mais combien ? Et surtout, combien coûterait le fait de modifier les sources et tous les appels, SI la librairie de support venait à changer ??
La modification des sources, avec un bon éditeur de texte et une bonne expression régulière, ça peut aller extrêmement vite... Quelques HEURES à peine !! Dans un tel cas, ton couplage faible est tout simplement une perte sèche, il faudrait que tu t'en rendes compte...

Mais tu ne veux pas entendre ces arguments, ni même y répondre, à se demander à quoi cela sert-il de tenter de t'expliquer...

Citation:

---

Envoyé par Issam_Lahlali

finalement dire qu'on peut maitriser tout dés le départ c'est faux , on ne sait jamais ce qui peux se passer, et cette technique de conception de couplage faible on va pas la faire bien sur a tord et a travers , mais pour le distribué je suis pour le faire.

---

On peut maîtriser 90% dès le départ, en évitant de commencer à coder AVANT d'avoir fini la conception générale ET les études de faisabilité... C'est ça aussi, le métier et l'expérience.

starts_with, ça ne serait pas compare(0, str2.size(), str2) == 0 ?

Il y a vraiment besoin de wrapper ça ?

Citation:

---

Envoyé par white_tentacle

starts_with, ça ne serait pas compare(0, str2.size(), str2) == 0 ?

Il y a vraiment besoin de wrapper ça ?

---

Ah oui oui oui, *abstraction* et *encapsulation* à tout prix :mrgreen:

Citation:

---

Envoyé par Mac LAK

Je sais très bien que ça n'existe pas, par contre, je sais évaluer si une techno/librairie quelconque pourra perdurer au moins le temps de vie du module en question, avant que sa refonte intégrale ne devienne nécessaire de par les simples évolutions requises par le client (entre 5 et 10 ans dans mon domaine)... Et c'est au moment de la refonte que l'on change la "base", technologique ou logicielle, qui sous-tend le module devenu obsolète.

Mais ça, c'est l'expérience qui te l'apprends, ainsi que la connaissance du métier. C'est aussi savoir faire une étude de faisabilité, savoir "sentir" si une techno est pérenne ou juste un gadget à la mode, savoir poser les BONNES abstractions aux BONS endroits, savoir raisonner non plus en framework mais en flux de données, etc.

On peut maîtriser 90% dès le départ, en évitant de commencer à coder AVANT d'avoir fini la conception générale ET les études de faisabilité... C'est ça aussi, le métier et l'expérience.

---

a mon avis t'est très très fort pour avoir une telle confiance en toi, je ne suis pas assez doué que toi ni la majorité non plus, c'est pour cela que je préfère avoir une assurance puisque je ne suis pas doué et je sais qu'un truc peut me dépasser a un moment.

et si tout le monde était comme toi, même cette discussion n'aura pas lieu mais la réalité c'est autre chose on est pas tous très très fort et je dis a ceux comme moi ne tomber jamais dans le piège des gurus qui savent en général les implications de la moindre chose qu'il font mais rester zen et utiliser des méthodes pour se couvrir on ne sait jamais :).

Tu mélanges les styles, et c'est à mon sens une position très instable, pour ne pas dire intenable...

Citation:

---

Envoyé par Issam_Lahlali

on commence l'implémentation et on se rend compte qu'on a besoin de fonctions techniques qu'on fait souvent non existantes dans nos librairies, et pour être concret disant le StartWith pour std::string , soit on laisse les 50 développeurs faire le StartWith a leur sauce soit avoir un framework technique au niveau de l'entreprise qui le fait.

moi je préfère avoir dés le départ du projet un framework technique ou je mettrais tout ce qui simplifiera la vie aux développeurs quelque soit les librairies techniques utilisés.

et crois moi tu fais l'expérience tu verra ce framework grandir rapidement parce que tu decouvrera que dans le code il y a pas mal de choses répétitifs avec les Copier/Coller.

---

Pour ce qui est d'éviter une pléthore d'implémentations différentes et / ou les copier / coller dans tous les coins, ta position n'est pas mauvaise et même admise par tous: il faut, au sein de l'équipe ou de l'entreprise, un minimum d'homogénéité pour ce qui est suffisamment indépendant des technologie ou des bibliothèques externes.

Par contre, lorsque tu écris

Citation:

---

d'autre part si t'est adepte du couplage faible comme assurance et protection au changement futur tu ne laissera jamais trainer les librairies pour le distribué par exemple trainer dans ton code, tu proposera a partir de ton framework une facade trés simple d'utilisation, et le but n'étant pas que simplifier mais avoir une assurance au cas d'un changement d'une techno.

---

J'ai beaucoup plus de mal à être d'accord avec toi:

1. Au mieux, tu ne fais que déplacer le problème: si tu change de techno ou de bibliothèque, tu sera, quoi qu'il arrive, obliger de "casser du code", en tout ou en partie pour que ton framework puisse réellement travailler avec la nouvelle techno, même si, de fait, on peut estimer que tu devra travailler sur une portion de code moins importante
2. Si tu en viens à changer la techno ou la bibliothèque exposée par ton framework maison, c'est soit:
   
   • que l'étude des besoins / de faisabilité a été mal menée
   • que la bibliothèque originellement choisie était en inadéquation avec les besoins réels
   • que tu as surestimé "l'universalité" des besoins d'un projet particulier par rapport aux projets que tu as à gérer
   
   et, quoi qu'il en soit, le changement (qui ne s'effectuera pas techniquement avant d'avoir été murement réfléchi) coutera certainement "un pont" en terme d'heures de conception afin de garder l'interface de ton framework
   (sans compter le coup de l'implémentation qui sera lui aussi faramineux), cout que tu ne peux décemment pas envisager de faire supporter par un client unique, ce qui t'oblige d'autant plus à t'assurer que le nouveau choix sera globalement plus adapté et "universel" (comprend: opportun pour les projets à venir) que l'existant

Citation:

---

et le réflexe de résistance contre le couplage faible et a mon avis comme le réflexe d'un conducteur qui dit je ne vais jamais faire d'accident je suis trés fort et j'ai pas besoin de payer l'assurance mais encore une fois ca ne dépend pas que toi, il y a plusieurs facteurs autour et tout peut changer a un moment donc autant se protéger depuis le départ.

---

C'est un peu le serpent qui se mord la queue...

Un couplage faible est intéressant, nous n'en disconvenons absolument pas...

Par contre, dans l'optique de permettre de changer "facilement" de technologie ou de bibliothèque, nous sommes face à un problème Kafkaien:

Soit, nous ne changerons jamais de technologie ou de bibliothèque, et, dans ce cas, à quoi peut servir le couplage faible :question:

Soit nous souhaitons garder en permanence l'opportunité de le faire, mais... le cout du changement est tel qu'il faudra prévoir de le rentabiliser "sur le long terme", ce qui nous fait naturellement nous poser la question de l'opportunité de ce changement sur le long terme...

Peut être même jusqu'à décider de reporter la décision de changer jusqu'aux calendes grecques :aie:

Et la boucle est bouclée ;)

Citation:

---

Envoyé par white_tentacle

starts_with, ça ne serait pas compare(0, str2.size(), str2) == 0 ?

Il y a vraiment besoin de wrapper ça ?

---

c'est le probléme a mon avis de la communauté C++ ou on veut laisser trainer des lignes de codes pas lisible, tu remarque que t'a deux 0 dans ta ligne chose qu'il faut éviter dans les règles de base d'implémentation, il ne faut jamais laisser de numéros qui traine :)

et au niveau lisibilité du code lorsqu'on a un StratWith c'est nettement mieux que cette ligne et si on dit c'est pas grave et on accumule les détails comme ça , on a un code illisible a la fin.

et tu fait quoi avec EndWith alors?

je prefere avoir les choses clairs qu'un code avec des numeros qui trainent partout et pas lisible, c'est un choix.

et ca changera pas a la problématique de départ du fait qu'il faut avoir un framework technique ou on met tout ce qu'on Copier/Coller dans notre code concernant la couche technique.

Citation:

---

Envoyé par Issam_Lahlali

et ca changera pas a la problématique de départ du fait qu'il faut avoir un framework technique ou on met tout ce qu'on Copier/Coller dans notre code concernant la couche technique.

---

J'aime bien la facilité avec laquelle tu as occulté ma réponse, la preuve que tu ne maîtrises pas du tout ce dont tu parles actuellement.

L'assurance, tu NE PEUX PAS la payer à chaque fois. C'est impossible, demande à ton management. A nouveau, tu n'as pas d'expérience professionnelle à ce niveau, donc s'il te plaît arrête de croire que ce que tu crois être la vérité est la vérité.

Citation:

---

Envoyé par Issam_Lahlali

a mon avis t'est très très fort pour avoir une telle confiance en toi, je ne suis pas assez doué que toi ni la majorité non plus, c'est pour cela que je préfère avoir une assurance puisque je ne suis pas doué et je sais qu'un truc peut me dépasser a un moment.

---

Tu ne réponds toujours pas aux points que j'ai soulevés précédemment, et c'est justement ce que l'on tente de t'expliquer quand on te dit qu'il te manque de l'expérience...

Sérieux, je suis le seul à trouver que c'est un faux problème de conception, et un vrai problème de méthodologie / inexpérience ???

Citation:

---

Envoyé par vdaanen

et si tout le monde était comme toi, même cette discussion n'aura pas lieu mais la réalité c'est autre chose on est pas tous très très fort et je dis a ceux comme moi ne tomber jamais dans le piège des gurus qui savent en général les implications de la moindre chose qu'il font mais rester zen et utiliser des méthodes pour se couvrir on ne sait jamais :).

---

C'est le rôle du chef de projet (ou du responsable technique) de demander les coûts de développement, d'évolutions, les risques et tout et tout aux ingénieurs, notamment à l'archi du projet. En tant qu'ingé, tu dois donc savoir donner ces chiffres, et c'est tout.

La décision est entre les mains du CP et du RT ensuite, mais s'ils ne savent pas mesurer objectivement de tels risques, il vaudrait mieux leur laisser faire des choses moins risquées pour la société, comme balayer le sol... C'est "juste" leur boulot de trouver le compromis entre de la sur-qualité (ce que tu voudrais faire) et de la sous-qualité (où ce sera le client qui viendra t'expliquer les termes du contrat), tout en restant dans les clous des heures vendues au client (rentabilité du projet, donc).

Et désolé, mais perdre 4 JOURS de dév pour une interface de couplage faible alors que le "cassage" d'un couplage "fort" coûte quatre HEURES de dév tous les deux ans, ce n'est pas rentable économiquement parlant !! Cela ne le deviendrait que dans seize ans, et ton projet ne vaudrait plus un clou de toutes façons dans un futur aussi "lointain", il faudrait intégralement le refondre !

En fait, je pense que tu fais trop de starts_with, c'est pour ça que tu veux que ça soit écrit de manière simple. Moi, comme je n'en fais (pratiquement) jamais, ça ne me pose pas de problème que ça soit compliqué à écrire.

Mais ça ne te choque pas de devoir faire des starts_with tout le temps ? N'y aurait-il pas un problème de conception quelque part (genre, représenter par des chaînes des choses qui ne devraient pas l'être), qui amènerait à cette situation ? :mrgreen:

Citation:

---

Envoyé par Issam_Lahlali

tu remarque que t'a deux 0 dans ta ligne chose qu'il faut éviter dans les règles de base d'implémentation, il ne faut jamais laisser de numéros qui traine :)

---

C'est exactement ce qu'on appelle de l'intégrisme... Le second zéro, c'est la valeur retour de compare(), c'est parfait, car une recherche dans la doc (ou ta mémoire si tu es un programmeur sérieux) t'explique pourquoi. Tu voudrais faire quoi, redéfinir le nombre zéro en une constante appelée "zéro"?

Citation:

---

Envoyé par Issam_Lahlali

je prefere avoir les choses clairs qu'un code avec des numeros qui trainent partout et pas lisible, c'est un choix.

---

La lisibilité c'est complètement relatif. Le code doit être lisible pour les mainteneurs, dont on peut espérer qu'ils soient informaticiens et connaissent les paramètres d'appel et les valeurs de retour des fonctions de base. Si ce n'est pas le cas, il faut virer le DRH...

La lisibilité pour le mec du controle qualité, le commercial ou le "chef de projet" qui n'a jamais écrit une ligne de code, c'est une perte de temps. Si le client veut la payer, pourquoi pas, sinon, ... ben faut virer le DRH (et le chef de projet aussi, d'ailleurs)

Ouais, pas facile d'être DRH...

Francois

Citation:

---

Envoyé par koala01

toi:
Au mieux, tu ne fais que déplacer le problème: si tu change de techno ou de bibliothèque, tu sera, quoi qu'il arrive, obliger de "casser du code", en tout ou en partie pour que ton framework puisse réellement travailler avec la nouvelle techno, même si, de fait, on peut estimer que tu devra travailler sur une portion de code moins importante[*]Si tu en viens à changer la techno ou la bibliothèque exposée par ton framework maison, c'est soit:

• que l'étude des besoins / de faisabilité a été mal menée
• que la bibliothèque originellement choisie était en inadéquation avec les besoins réels
• que tu as surestimé "l'universalité" des besoins d'un projet particulier par rapport aux projets que tu as à gérer

---

pour l'impact de changement de librairie comme t'a dis c'est isoler dans le framework et c'est pas rien, un code qui contient des millions de lignes je t'assure c'est pas rigolo de faire le changement , j'ai vu des projets ou les types Corba traine dans tout le projet et lorsque tes clients te demande on veut plus Corba mais WCF , si t'a pas un couplage faible le mieux est de te suicider pour un très grand projet, en tout cas pour mon expérience c'était très très bénéfique, et j'ai vu l'utilité réel.

et pour le fait qu'on peut maitriser tout dés le départ pour le bon choix dés le départ , mon expérience me dis le contraire, combien de fois j'ai vu devant mes yeux le changement de librairie.

il ya le monde idéale ou tout se passe bien , on maitrise tout a 100% et le monde réel ou a tout moment il peut y avoir un changement, et bien sur il ne faut pas passer un temps fou sur la protection de ces changement, et une façade par expérience c'est pas couteux en tout cas pour le distribué.

Citation:

---

Envoyé par fcharton

C'est exactement ce qu'on appelle de l'intégrisme... Le second zéro, c'est la valeur retour de compare(), c'est parfait, car une recherche dans la doc (ou ta mémoire si tu es un programmeur sérieux) t'explique pourquoi. Tu voudrais faire quoi, redéfinir le nombre zéro en une constante appelée "zéro"?

---

et tu pense quoi du premier ?

et si on veut faire un EndWith on fait quoi, en gros tôt ou tard on a besoin d'un endroit qui représentera une boite a outil simple et clair.

Citation:

---

Envoyé par white_tentacle

Mais ça ne te choque pas de devoir faire des starts_with tout le temps ? N'y aurait-il pas un problème de conception quelque part (genre, représenter par des chaînes des choses qui ne devraient pas l'être), qui amènerait à cette situation ? :mrgreen:

---

en fait je te parle pas de mon cas mais en général si on a besoin de cette méthode, et on peut pas dire que si on a besoin de cette méthode c'est qu'il ya un probléme de conception, rien a voir a mon avis.

et il ne faut pas se borner sur le StartWith, il faut voir le probléme d'une manière globale:

comment faire si on a un code technique répétitif dans le projet?

est ce qu'on laisse les copier/coller ou on le met en commun , c'est tout simplement le but avec cet exemple, et le but est de ne pas savoir qui va donner la meilleur implémentation ou discuter de l'inutilité de cette méthode.

Citation:

---

Envoyé par Issam_Lahlali

il ya le monde idéale ou tout se passe bien , on maitrise tout a 100% et le monde réel ou a tout moment il peut y avoir un changement, et bien sur il ne faut pas passer un temps fou sur la protection de ces changement, et une façade par expérience c'est pas couteux en tout cas pour le distribué.

---

D'où intégrisme, parce que tu cherches le 100% (qui est de toutes façons IMPOSSIBLE).

Vises le 90%, de façon rapide, efficace et avec des risques minimum : tu vas diviser par deux tes temps de développement et/ou d'évolution, et sans nuire à la qualité du code final en plus... C'est l'expérience qui te permet d'avoir 90% de "bonnes décisions", et souvent en évitant que les 10% restants soient des "situations catastrophiques", mais uniquement des "retards légers".

Citation:

---

Envoyé par Mac LAK

Sérieux, je suis le seul à trouver que c'est un faux problème de conception, et un vrai problème de méthodologie / inexpérience ???

---

Ah non, tu n'es pas le seul !!

Citation:

---

Envoyé par Issam_Lahlali

et tu pense quoi du premier ?

et si on veut faire un EndWith on fait quoi, en gros tôt ou tard on a besoin d'un endroit qui représentera une boite a outil simple et clair.

---

Le premier, je n'ai pas regardé... Mon opinion sur les "boites à outil", c'est la même que sur le commentaire. Dans un grand nombre de cas, les commentaires c'est un truc comme ca:

Code:

---

1 2 3 4 5 6 7 8

// ouvre le fichier, filename est le nom du fichier void open_file(string filename) { // le fichier ifstream file; ... }

---

Pour les wrappers, c'est pareil, sauf qu'à la différence des commentaires débiles, ca a un impact à l'exécution. C'est peut être utile pour le mec du marketing qui ne sait pas très bien ce que veulent dire les mots, open, file ou handle... Mais ca ne sert qu'à lui.

Le destinataire des commentaires, ou des interfaces, c'est le programmeur, on a un start() mais pas de end(); parce qu'on n'en a pas besoin, ca me va bien, moi... Et je pense que la plupart des programmeurs seront d'accord.

Ca va, en revanche, atrocement déstabiliser le consultant qui est payé à vérifier que chaque start a un end. Personnellement, cette situation me convient: ces consultants conseillent généralement mes concurrents, plus il y en aura...

Francois

Citation:

---

Envoyé par Issam_Lahlali

pour l'impact de changement de librairie comme t'a dis c'est isoler dans le framework et c'est pas rien, un code qui contient des millions de lignes je t'assure c'est pas rigolo de faire le changement , j'ai vu des projets ou les types Corba traine dans tout le projet et lorsque tes clients te demande on veut plus Corba mais WCF , si t'a pas un couplage faible le mieux est de te suicider pour un très grand projet, en tout cas pour mon expérience c'était très très bénéfique, et j'ai vu l'utilité réel.

---

Inexpérience : ton client a payé pour une interface Corba, ce n'est pas à toi de prévoir qu'il va devoir changer l'outil. S'il y a des évolutions qui le nécessitent, c'est à lui de payer. si tu commences à gérer ce genre de cas, tu vas vite te retrouver à la porte.

Citation:

---

Envoyé par Mac LAK

Et désolé, mais perdre 4 JOURS de dév pour une interface de couplage faible alors que le "cassage" d'un couplage "fort" coûte quatre HEURES de dév tous les deux ans, ce n'est pas rentable économiquement parlant !! !

---

sincèrement on parle pas des mêmes grandeurs , et pas de la même taille de projet, si tu me dis que le cassage d'un couplage fort se fait en 4 heures, moi j'en ai assister a un cassage qui a couter des mois pour CORBA ou les types Corba trainer partout dans le projet et ça concerne des millions de lignes de codes.

et effectivement si tu juge que le cassage prend 4 heures t'a raison pas besoin de couplage faible mais il faut faire gaffe même si toi tu maitrise bien ce qu'il faut faire , crois moi avec les développeurs tu découvre qu'il traine des types de la librairie spécifique au fin fond du projet, puisqu'il y a une méconnaissance d'adaptateur ou de pont.

et dans ce cas t'est obliger de faire un audit régulier , ce qui va te couter des jours, autant faire un couplage faible dés le départ.

Aller, tu veux savoir comment je ferai pour start_with et end_with ? Je prendrai... Boost.
http://www.boost.org/doc/libs/1_40_0....predicate_hpp

Citation:

---

Envoyé par Matthieu Brucher

Inexpérience : ton client a payé pour une interface Corba, ce n'est pas à toi de prévoir qu'il va devoir changer l'outil. S'il y a des évolutions qui le nécessitent, c'est à lui de payer. si tu commences à gérer ce genre de cas, tu vas vite te retrouver à la porte.

---

e si t'est un éditeur de logiciel et ton client paye toujours le meme prix de la license, mais en faisant l'étude de marché et en écoutant tes clients tu te rends compte qu'ils ne veulent plus de Corba et pour etre compétitif et avoir d'autres marchés t'investit dans WCF, tu fais quoi alors?

Citation:

---

Envoyé par Issam_Lahlali

sincèrement on parle pas des mêmes grandeurs , et pas de la même taille de projet, si tu me dis que le cassage d'un couplage fort se fait en 4 heures, moi j'en ai assister a un cassage qui a couter des mois pour CORBA ou les types Corba trainer partout dans le projet et ça concerne des millions de lignes de codes.

---

Le problème à ce stade, ce n'est même plus une notion de couplage fort ou faible, mais de code tentaculaire. Qui se règle à un tout autre étage de la conception, d'ailleurs, mais passons... Et sinon, oui, je bosse sur des projets de très grosse taille justement : je te répète que je sais de quoi je parle, c'est souvent moi qui suis en charge de tels travaux, justement... Ou qui prévoit en amont comment découpler les modules entre eux, et ça ne fait "que" dix ans que je fais ça.

Ton "audit", ça se règle à coup de graphes de dépendances (Doxygen en fait de très beaux, tu devrais essayer), de métrique (calcul automatique à la génération nocturne le plus souvent), et d'analyse statique du code (outil que tout projet de cette taille DOIT avoir). C'est le boulot de l'ingé en qualité logicielle, et/ou du CP/RT en fonction des casquettes de chacun dans ta boîte.
C'est quelque chose qui devrait être fait en process continu, tout au long du développement, et non pas une fois tous les six mois (et trop tard !!) lors d'un audit.


Dans le cas que tu donnes, il faut simplement abattre le CP et les dévs précédents pour avoir fait des tentacules partout, et si possible très rapidement avant qu'ils ne contaminent le reste de l'équipe...
Mesure sanitaire basique, quoi, tu n'as qu'à dire qu'ils ont la grippe... :twisted:

Citation:

---

Envoyé par Issam_Lahlali

e si t'est un éditeur de logiciel et ton client paye toujours le meme prix de la license, mais en faisant l'étude de marché et en écoutant tes clients tu te rends compte qu'ils ne veulent plus de Corba et pour etre compétitif et avoir d'autres marchés t'investit dans WCF, tu fais quoi alors?

---

Tu avais fait une étude des risques auparavant, tu regardes, tu vois si le jeu en vaut la chandelle, quand il faudra le mettre en place (normalement, tu as de l'avance à ce niveau, donc pas de stress), et tu fais ton planning. Tu remets à jour ton étude des risques a posteriori, et tu prends les décisions en conséquence.
Je ne vois pas le problème. Sauf si code Mac LAK le dit, ton code est tellement tentaculaire/spaghetti, que c'est limite trop tard, il y a un effort permanent qui devait être fait qui n'a pas été fait. C'est valable, à nouveau, pour tout langage et technologie. La dernière fois que j'ai eu affaire à ce problème, on a repris tout le front-end et conservé les algos.