Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Vouaip. En plus, comme la lib standard est pas trop mal fichue, ça ne prend qu'une ligne à écrire, donc ce n'est pas trop compliqué à dupliquer aux quelques endroits où j'en aurais besoin.c'est bien ce que tu fais la, mais imagine que t'a besoin de start_with dans une autre méthode métier, tu fais comment, tu duplique le code de start_with?
Et si j'en ai besoin vraiment partout dans mon code, alors j'ai sûrement merdé un truc quelque part.
Et puis, c'est pas comme si ton framework technique n'était pas Boost/Qt/...
Pourtant, tu parlais bien de framework métier pour cela pas plus tard qu'il y a quelques pages. Maintenant, le framework métier, c'est autre chose?
Pour un chef de projet, ça fait beaucoup de changements, de mauvaises estimations, ...
qui a deja parler de framework metier , je parle de métier lorsque je dis a chaque fois qui faut faciliter la couche technique aux développeurs en proposant un framework technique qui facilite ce qui est compliqué ou repetitif pour ce focaliser plus sur le métier qui est la vrai valeur ajoutée du projet.Envoyé par Matthieu Brucher
en gros le message est simple.
Visiblement, tu n'as pas compris le sens de ma phrase (ou qu'à moitié)..
Je disais que le passage de cobra à WFC était également un travail de titan.
Et c'est bien sur encore plus vrai s'il s'agit d'un code spagetti
Raison de plus pour prendre en compte ce fait dans l'évaluation du cout occasionné par le passage d'une techno à une autre au sein d'un framework "maison"...finalement t'a certainement raison si tout est bien fait a un instant T avant le changement mais sincèrement c'est pas toujours le bonheur dans notre métier
Le plus souvent, c'est un cout qui est propre à "exploser" un budget et qui ne peut pas être répercuté vers le client
A méditer: La solution la plus simple est toujours la moins compliquée
c'est la ou je vois pas le rapport, entre avoir besoin plusieurs fois d'une fonction technique et le fait que t'a merder quelque part?
oups desolé mais je vois que t'a tomber dans le même piège ou je dis que l'étape de virer les types Corba était a l'ordre des mois et celle de remplacer était a l'ordre de jours, ce qui prouve la pertinence d'un couplage faible dans ce cas
Le rapport se situe simplement dans le fait que tu as visiblement mal évalué la portée d'un module particulier, et que tu n'a très certainement pas suivi correctement demeter
si je comprends bien si j'ai besoin d'utiliser plusieurs fois find de sd::string j'ai un probléme quelque part?Le rapport se situe simplement dans le fait que tu as visiblement mal évalué la portée d'un module particulier, et que tu n'a très certainement pas suivi correctement demeter
mais certainement il ya un malentendu
C'est à se demander si tu le fais exprès ou si tu es complètement buté...si je comprends bien si j'ai besoin d'utiliser plusieurs fois find de sd::string j'ai un probléme quelque part?
mais certainement il ya un malentendu
Il est clair qu'il y a toujours "une base" que tu ne peut pas cantonner à un module particulier, et cette base recouvre, en gros, la S(T)L et les types primitifs.
Mais, entre les modules et les classes, c'est exactement le même combat:
Tout comme une classe ne vaut que par les classes qui la manipule, un module (comprend: un groupement donné de classes, que l'on pourrait assimiler à un espace de noms ou à ce que l'on trouve dans une dll) ne vaut que par les modules qui le manipulent.
Et, tout comme il n'est pas normal qu'une classe A qui manipule une classe B connaisse la classe C qui est manipulée par la classe B, il n'est pas normal qu'un module A qui manipule un module B connaisse le module C qui est manipulé par le module C.
Que ce soit pour une classe ou un module, en arriver à des dépendances directes avec des classes ou des modules gérés par ailleurs (comme le premier dessin vite fait) est le symptôme classique d'une mauvaise conception.
La "bonne conception" devant être strictement linéaire (comme le deuxième dessin présenté)
(d'ailleurs, les dépendances devraient, autant que faire se peut, être unidirectionnelles
donc j'avais raison on parle pas de la meme chose, je te parle d'une fonctionalité purement technique repetitif qu'il faut encapsuler pour eviter les copier/coller , ce qui ne va rien toucher a la conception lineaire puisque ce framework ne va etre cabler qu'avec les couches techniques plus bas que lui genre STL.C'est à se demander si tu le fais exprès ou si tu es complètement buté...
La "bonne conception" devant être strictement linéaire (comme le deuxième dessin présenté)
(d'ailleurs, les dépendances devraient, autant que faire se peut, être unidirectionnelles
Plus ou moins.En fait, tu viens de redire ce que j'ai dit sous une autre forme
En fait, avec la vision que j'avais rien n'empêche d'avoir des adaptateurs qui encapsulent plusieurs classes et certains cas sont flous et ne rentrent pas clairement dans une case ou dans l'autre.
Alors qu'avec la définition sur le nombre de classes que tu encapsulent, il n'y a plus de doute.
Mais bon dans la très grande majorité des cas ça revient strictement au même et ça reste de l'ordre du détail.
Dans tous les cas, merci pour ces compléments d'information.
Justement, je pensais qu'il avait enfin compris ce que cela impliquait vraiment. Visiblement j'avais tort.
effectivement je ne comprends rien de rien ni aux choix de librairies , ni au fait qu'il n y a rien de compliqué lors de l'utilisation de bons librairies de C++, tout ça n'est qu'un mythe puisque tout est facile
et pour le couplage faible, il n y a aucun probléme tout le monde fait le bon choix depuis le départ et ne court aucun risque, il y a que de bons architectes, concepteurs et développeurs et tout ceux la maitrise très bien leur domaine.
bref c'est le paradis de l'informatique
Qu'est-ce que c'est que ce post, Caliméro?
En fait les gens sur le forum n'ont fait que de te prouver qu'ils n'étaient pas des geeks que ça amuse d'écrire du code abstrait "r00t l33t" en mettant la technique au détriment du fonctionnel.
Car c'est bien ce que tu as dit à l'origine dans ce débat, genre les programmeurs C++ s'intéresseraient plus de savoir si une multiplication par 2 est plus performante qu'un décalage de bit plutôt que de se concentrer sur les besoins métier de leur application.
Comme tu as pu le voir, des noms de librairies sont sortis (boost notamment) face aux exemples que tu as mentionnés, ce qui montre bien que les programmeurs de ce forum c++ savent très bien qu'il n'est pas intéressant de réinventer la roue et de rester sur une API ultra bas niveau si on peut se contenter des fonctionnalités offertes par des surcouches beaucoup plus commodes.
Par ailleurs les réflexions concernant le couplage faible vont dans une direction de productivité, ne pas plomber son code, ne pas chercher une abstraction qui n'apporte rien. En gros se méfier de l'over engineering que l'on peut amener si les efforts à fournir pour se prémunir d'une situation embarrassante ne contrebalancent pas ceux qui seraient nécessaires pour "affronter" ladite situation.
La problématique économique est donc omniprésente dans ce threads, ce qui devrait te montrer que tous ces gens sont très regardant des problèmes de productivité et de maintenance et qu'ils ne s'amuseront pas de s'enfoncer dans la technique si le besoin derrière ne l'exige pas.
Exactement,
D'ailleurs, les esprits un minimum ouvert feront beaucoup d'analogie entre le développement et d'autres métiers.
Pour moi, c'est comme en math. Tu apprends des formules (les biblothèques, la techno) ainsi que des méthodes (les techniques conceptuelles) et à toi de choisir les bons outils et les bonnes méthodes pour résoudre un problème métier.
Beaucoup ne s'intéresse pas à cette partie du développement, ils veulent juste faire du "code". C'est comme si un écrivain était dingue de l'écriture, mais il s'en fou de son plan, son contenu, lui y veut juste écrire.
Je suis pas d'accord avec le fait qu'en C++ on ignore la conception et je dirait même bien au contraire !
En C++ il faut décider pour tout, il faut stratégier pour tout (le choix de la bibliothèque pour l'IHM, le réseau, le threading etc.) par conséquent on travail avec des pincettes.
J'ai déjà travaillé en .NET et en Java et j'ai constaté que le fait d'avoir tout à dispo par la techno, d'être "conditionné" et même assisté par celle-ci empêchait les développeurs de se poser des questions en général, y compris sur le plan conceptuel.
ce que t'arrive pas a comprendre c'est que je propose un niveau plus haut de simplification pour se concentrer plus sur le métier.Qu'est-ce que c'est que ce post, Caliméro?
En fait les gens sur le forum n'ont fait que de te prouver qu'ils n'étaient pas des geeks que ça amuse d'écrire du code abstrait "r00t l33t" en mettant la technique au détriment du fonctionnel.
Car c'est bien ce que tu as dit à l'origine dans ce débat, genre les programmeurs C++ s'intéresseraient plus de savoir si une multiplication par 2 est plus performante qu'un décalage de bit plutôt que de se concentrer sur les besoins métier de leur application.
Comme tu as pu le voir, des noms de librairies sont sortis (boost notamment) face aux exemples que tu as mentionnés, ce qui montre bien que les programmeurs de ce forum c++ savent très bien qu'il n'est pas intéressant de réinventer la roue et de rester sur une API ultra bas niveau si on peut se contenter des fonctionnalités offertes par des surcouches beaucoup plus commodes.
Boost,STL,Qt c'est bien et on va pas les réinventer, mais il faut aller plus que ca , si dans ton code t'utilise une séquence répétitif de lignes pour un besoin technique qui est spécifique a ce que tu fais, il faut avoir le reflexe de la mettre en commun et cet endroit commun je l'appelle Framework technique et tu peux l'appeler comme tu veux.
et je ne sais pas si t'a fait Corba ou pas mais essaye de travailler directement avec les librairies existantes genre Tao,Orbacus ou autre et tu va voir la galère et la tu comprends qu'il faut que tu simplifie l'utilisation de ces librairies aux développeurs pour leur donner une façade simple a utiliser.
on va me dire il y a une librairie X très facile pour Corba mais en réalité il n y a pas que la librairie X utilisé mais chacun choisit sa librairie, et si on me réponds que c'était un mauvais choix dés le départ certes mais la réalité est la on utilise dans les boites qui développent avec C++ des librairies qui peuvent être compliqués a utiliser.
si on raisonne dans un monde idéale ou on utilise que des librairies faciles , Ok pas besoin de simplifier, mais imaginant que t'intègre une boite qui utilise une librairie compliqué en utilisation, soit tu va leur dire qu'il faut la changer avec toutes les implications derrière , soit il faut que tu t'adapte avec cette librairie et tu va vite te rendre compte qu'on impose la deuxième solution, et la t'a encore 2 solutions
encore une fois le monde réel est loin de ce qu'on suppose, tu n'a qu'a lancer un topic pour discuter des aberrations dans les projets et tu va rigoler et pas d'ailleurs qu'on C++.
Vous supposez qu'il nya aucun maillon faible dans la chaine de développement ou on choisit très bien les librairies , on gère bien le projet , on fait un audit régulier ainsi de suite, dans ces conditions j'ai complètement tord mais ce qui se passe réellement c'est autre chose ou tu peux avoir un code ou tu ne comprends rien du tout avec des copier/coller partout et une programmation proche de C.
et d'ailleurs il ny a qu'a voir le succès des templates dans les boites francaises, ou on veut même pas entendre, c'est pour cela lorsque je lis cette résistance je me demande si on parle bien de qui se passe en france ou ailleurs.
soyant réaliste en france juste le mot refactoring on a du mal a l'avaler, par contre j'entends toujours une phrase du genre "ça marche on laisse comme tel", donc comment tu veux convaincre pour changer de librairie, tu n'a qu'a t'adapter et pour cela essaye de faire des adaptateurs
Bravo ! Encore une fois, par un mécanisme de compréhension qui t'es personnel, tu as réussi à interpréter mon message de manière complétement erronée et tu me prêtes des intentions qui ne sont pas les miennes.effectivement je ne comprends rien de rien ni aux choix de librairies , ni au fait qu'il n y a rien de compliqué lors de l'utilisation de bons librairies de C++, tout ça n'est qu'un mythe puisque tout est facile
et pour le couplage faible, il n y a aucun probléme tout le monde fait le bon choix depuis le départ et ne court aucun risque, il y a que de bons architectes, concepteurs et développeurs et tout ceux la maitrise très bien leur domaine.
bref c'est le paradis de l'informatique
Je vais tenter une dernière fois de t'expliquer les choses clairement.
Entre la position que tu prônes qui est de systématiquement (ou presque) encapsuler les bibliothèques pour simplifier l'interface ou obtenir un couplage plus faible et celle de ne jamais le faire que tu prêtes, à tort, à ceux qui essaie de te montrer que ton raisonnement est faux, il existe une multitude de position intermédiaire bien plus réalistes et acceptables.
Pour reprendre ton exemple de wrapper une bibliothèque pour pouvoir la remplacer facilement par une autre : l'intention est louable et c'est parfois utile ou nécessaire mais il existe bien des questions à se poser avant de prendre une décision (la liste suivante n'est pas exhaustive, certaines questions se recoupent en partie et il n'est pas toujours évident d'avoir la réponse) :
- Quelle est la probabilité que l'on change un jour de lib ?
- Sous quel échéance ?
- Quel degré de confiance a-t-on dans cette lib ?
- Quelle est la durée de vie prévisionnelle de l'application concernée ?
- Quel délai prévisionnel avant une ré-architecture importante ?
- Qu'est-ce ça coute (aussi bien en terme financier qu'en terme de délai) ?
- Qu'est-ce ça coute si on ne le fait pas ?
- Qui va assumer le surcoût ?
- De quels délais dispose-t-on avant de livrer ?
- Quels sont les impacts en terme de performance, mémoire, taille du binaire, etc. de la modification ?
- A quel point les bibliothèques concurrentes sont différentes ?
- L'utilisation de cette bibliothèque est-elle localisée dans le code ?
- Si non, pourquoi ?
- Est-elle utilisée dans un contexte unique ou de manière plus variée ?
- Est-elle connue et maitrisée par les participants au projet ?
- Est-elle répandue et massivement utilisée en dehors de ce projet ?
- L'abstraction sera-t-elle réutilisable dans d'autres projets ?
- L'application doit-elle être portable ? Si oui sur quoi ?
- La lib est-elle portable ? Si oui sur quoi ?
- Sous quel délai un changement de lib devra-t-il être fait si cela s'avère nécessaire ?
- Et bien d'autre.
C'est avec ces réponses et en fonction de l'importance que l'on accorde aux différents critères que l'on peut faire un choix à peu prés pertinent.
Et les choix possibles sont divers :
- On écrit le wrapper maintenant.
- On planifie son écriture à une date ultérieure.
- On planifie son écriture pour le jour où on changera de lib, si cela arrive.
- On ne fait rien et on se reposera la question lorsqu'un changement de lib sera nécessaire.
- On en fait rien, un changement de lib passera par l'écriture d'un adaptateur.
- On ne fait rien, un changement de lib passera par la réécriture du code concerné.
- Et j'en oublie probablement.
Bref, il ne faut pas appliqué bêtement et à la lettre tel ou tel mécanisme ou principe. Mais réfléchir à ce qui est pertinent de faire, quand, comment et pourquoi.
t'inquiète c'était juste pour détendre l'atmosphère , j'ai vu venir les attaques partout
merci pour ton message très détaillé et t'a raison sur tout ce que t'a dis et en aucun moment j'étais contre tout ca, je ne cesse de répéter qu'il faut simplifier la ou c'est nécessaire, ce que t'a bien préciser.
et comme l'exemple que j'ai mentionner avant ou t'intègre une boite qui n'utilise pas de librairie simple il faut avoir le reflexe de simplifier c'est tout ce que je dis, et même si on utilise STL ou Boost si a un moment on découvre qu'on répète une séquence de ligne faisant appel a Boost ou STL je dis qu'il faut la mettre en commun, et la je ne vois pas ou je suis différent de ce que t'a mentionné.
dés que je poste un message concernant ça on me dit pourquoi tu veux réinventer la roue? chose que je n'est jamais dis.
donc finalement mon message est :
ayez le réflexe de simplifier tout ce qu'on peut simplifier pour la couche technique, et crois moi en réalité ou le choix des librairies n'est pas toujours judicieux on a beaucoup besoin de ce réflexe.
Juste pour rajouter à l'ambiance qui est terrible dans cette discussion ... d'ailleurs je ne sais même pas ou on en est arrivé ...
J'ai déjà vu des gros geek se battre sur ce sujet dans un projet industrielle.
sinon quelqu'un a-t-il de bon référence bibliographique sur la conception logiciel ?
La rubrique Conception de DVP a de bonnes références à ce niveau
C'est justement parce que nous avons conscience de l'existence potentielle de maillons faibles que nous ne sommes pas d'accord avec toi...
Tu nous présente les choses comme si le fait de simplifier tout ce qui peut l'être était le gage d'arriver à quelque chose de stable, de cohérent et de solide... En un mot, la panacée.
Sauf que... là où tu arrête ta réflexion beaucoup trop tôt, c'est dans le fait que, une fois le "super framework de la mort qui tue" doit, pour une raison ou une autre, se découpler d'une technologie ou d'une bibliothèque quelconque, soit, tu en arrivera à un framework tellement compliqué (fatalement, s'il doit s'appliquer à trente six techno différentes) qu'il deviendra fatalement inutilisable soit que le temps qu'il te faudra pour effectuer les modifications sera à peut de choses près égal au temps... passé à développer ce framework...
Du coup, ce qui peut passer pour la panacée du point de vue de la productivité (et encore, quand tu débarque dans la boite qui utilise un tel framework, tu dois quand même bien t'y habituer... ce qui "plombe" ta productivité immédiate le temps que tu le fasse) s'avère être un mal sans doute bien pis lorsqu'il faut en arriver à la décision de le modifier en profondeur...
Tu mélanges de nouveau des choses qui n'ont rien à voir...et d'ailleurs il ny a qu'a voir le succès des templates dans les boites francaises, ou on veut même pas entendre, c'est pour cela lorsque je lis cette résistance je me demande si on parle bien de qui se passe en france ou ailleurs.
Oui, nous sommes tous bien d'accord sur le fait que la programmation générique a de quoi effrayer ceux qui n'ont jamais têté qu'au biberon de l'OO...
Oui, tout le monde l'admet sans honte, il faut s'accrocher pour acquérir la "mentalité générique" lorsque l'on débarque
Et oui, on rencontre régulièrement des gens butés au point de refuser de se remettre en question.
Mais bien que ce soit une technique que certains n'hésiteraient pas à la qualifier "d'extra terrestre", c'est une technique qui présente de très sérieux avantages.
Ne t'en fais pas, ce n'est pas le cas qu'en France, ni même qu'en Europe...soyant réaliste en france juste le mot refactoring on a du mal a l'avaler,
Malgré la publicité faite par microsoft, tu serait sans doute surpris du nombre de lignes de (parfois mauvais) code que windows XP traine qui viennent de versions 95 ou 98.
Le fait est que, passé un certain niveau de refactoring à envisager, on se heurte à la logique purement financière pour laquelle passer plus de XX heure à refaire quelque chose qui marche, même si c'est pour que ca "marche mieux" ou que ca "soit plus productif", est quelque chose de non financièrement inrentable.par contre j'entends toujours une phrase du genre "ça marche on laisse comme tel",
Parce que, justement, tu oublie un facteur important: Si tu décide de changer de bibliothèque, cela implique:donc comment tu veux convaincre pour changer de librairie, tu n'a qu'a t'adapter et pour cela essaye de faire des adaptateurs
- que l'équipe devra apprendre à manipuler la nouvelle (ce qui représente une perte de temps que l'on ne peut à nouveau pas facturer)
- Qu'il faudra, au minimum, adapter le framework pour qu'il puisse utiliser la nouvelle bibliothèque... ce qui représente, encore une fois, une dépense que (ne serait-ce qu'en salaire) l'on ne peut pas répercuter chez le client
- Eventuellement que tu aura justement renouvelé ta licence annuelle pour la bibliothèque que tu utilise actuellement pour rien... C'est encore une fois une dépense impossible à répercuter chez le client.
- la liste des objections n'est surement pas finie
Et, quand ce n'est pas le financier qui parle, c'est le chef de projet qui est resté bloqué sur ce qu'il a pu apprendre à l'époque des dinosaures et qui n'a pas voulu (et ne voudra sans doute jamais) évoluer...
Je trace, effectivement, un tableau bien noir de la situation, mais il est, malheureusement, fort proche de la vérité.
Mais tu peux me croire sur parole lorsque j'écris que nous regrettons tous cette situation
Répondre avec citation
Partager