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 :
en fait tu m'a pas encore repondu su l'endroit ou mettre le StratWith si on veut l'ajouter pour std::string.Envoyé par Matthieu Brucher
et voici ma reponse dans ton cas: on aura un FrameworkCore ou on mettera tout ce qui transversal a tous les metiers que t'a evoqués qui contient des classes et fonctions uilitaires pour les besoins generiques.
et pour chaque fonctionnalité spécifique a un métier j'aurais sismiqueFramework,BiologieFrmework ainsi de suite.
+1, c'est du simple boulot normal et habituel en gestion de projet...
Mac LAK.
___________________________________________________
Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.
Sources et composants Delphi sur mon site, L'antre du Lak.
Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.
Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO
Je vais répondre juste à cette partie, sinon, je vais trollercomment faire si on a un code technique répétitif dans le projet?.
Si tu as un code technique répétitif, alors oui, il y a des chances que tu aies intérêt à le factoriser d'une manière ou d'une autre.
Ca ne veut pas dire non plus wrapper toute la classe std::string, parce que ça coûte inutilement. Mais rajouter un namespace ma_societe::string_utils avec une fonction libre starts_with(std::string const &chaine, std::string const &prefixe), pourquoi pas... (mais je maintiens ce que j'ai dit, si tu passes ton temps à faire des starts_with dans tout le projet, c'est un problème de conception, il y a toutes les chances que ce starts_with soit factorisable en quelque chose du genre (je vais prendre l'exemple d'une commande reçue par réseau) EstOrdreArret(chaine), qui gagnerait à être factorisée de la sorte plutôt qu'en chaine_recue.starts_with("ORDRE_ARRET"))
Et je ne crois pas que quelqu'un ait dit le contraire. Juste, qu'il faut faire preuve de modération quand on fait ça, parce que ça a aussi des défauts.
@Matthieu : boost_regex pour un starts_with, c'est pas un peu l'enclume pour enfoncer un clou, quand même ?
mais c'est ca le probléme en realité, on ne peux pas maitriser a 100% ce que font les développeurs, et si pour vous tout est nikel, CP , développeurs, décideurs je vous comprends très bien.
mais en réalité c'est pas le cas et je veux juste savoir combien de boites en france ont des profils d'architectes et de concepteurs?
en général comme plusieurs l'ont signaler avant on a tendance après a avoir un code pourri et dans n'importe quel langage d'ailleurs, et je préfère quand je le peux avoir une protection des dérives de ceux impliqués dans le projet.
?? Boost, c'est installé sur tout bon PC, il n'y a pas à l'ajouter à std::string, juste à l'utiliser.
Donc tu as répondu toi-même à ta question : il n'est pas possible de faire un framework générique. Maintenant, réfléchis à ce que tu viens de dire et à tes précédentes interventions.
C'est pas du regex@Matthieu : boost_regex pour un starts_with, c'est pas un peu l'enclume pour enfoncer un clou, quand même ?
Non, c'est simplement l'échelle de valeur à envisager:
Si ton framework est prévu pour tourner avec cobra et que tu décide de le faire passer à WCF, tu devra, de toutes façons, reprendre l'ensemble du projet "framework", qui se sera étoffé sans même que tu ne t'en rende compte au fil des années et qui, par définition (et pour des raisons essentiellement budgétaires), tu peux estimer qu'il sans doute "est mal conçu" et très certainement mal documenté.
Reprendre un tel framework à partir de rien en assumant la compatibilité de l'interface te prendra un temps très largement supérieur (et le le coefficient *8 sous entendu par MAK LAK me semble sous estimé) à celui qui, pour le projet à fournir au client pourrait se traiter à coup de chercher / remplacer si les type Cobra sont effectivement partout dans le code:
Une "simple" "table de conversion" pourrait, à l'extrême limite, suffire là où, dans ton framework maison, tu subirais des contraintes bien plus importantes
A méditer: La solution la plus simple est toujours la moins compliquée
bien sur on va pas tout mélanger, et d'ailleurs le framework se compose de plusieurs modules et plusierus namespaces pour bien isoler les fonctionalités.
et tout ce qui est générique on mettra dans FrameworkCore pour eviter de le dupliquer partout.
jusqu'à ce point on a jamais parler comment le concevoir mais juste de son utilité, ou il y avait une résistance que je ne comprends pas toujours
c'est nettement plus compliqué que ca, si c'était qu'une simple table de conversion je te conseil de bosser dans le domaine de MDA ou tu crée des convertisseurs pour passer d'un PSM a un autre, et crois moi tu sera rapidement millionnaire
qui a parler de wrapper std::string.
et d'un autre coté ne te focalise pas sur start_with mais raisonne d'une manière générale ou on a un code technique répétitif.
Je ne vois pas trop le rapport entre start_with() et un code orienté métier.
start_with(), c'est vraiment le début d'une redéfinition de la librairie standard à la sauce de l'entreprise. Personnellement je n'en ai jamais eu besoin, je préfère justement m'orienter vers des fonctions qui ont un sens métier.
On entre dans le cas où on recherche une fonction qui existe dans une librairie d'un langage dans un autre langage qui n'a pas de rapport. En C++ on pourrait faire un std::find() par exemple et tester si la valeur renvoyée est le début de la string.
Après je sais que beaucoup d'entreprises aiment faire ces "librairies maisons" ( il y a peut être un terme pour ça ) qui pour moi ne sont pas vraiment orientés métiers. Il y a sûrement de bonnes raisons, ça permet peut être de développer rapidement des choses simples à des développeurs ayant peu d'expériences dans le langage. Ca a aussi l'effet pervers de ne pas apprendre le langage aux développeurs. C'est mon opinion.
Mais une librairie métier, comme dit plus haut, ce sera autre chose, pas une suite de fonctions libres ou pires une encapsulation d'une std::string en MyCompanyNameString.
Effectivement, pour faire ces librairies, on créera un namespace comme std:: et MyCompanyName::Myframework:: contiendra les classes/fonctions
nécessaires.
Mais le cheminement avant de factoriser ce code répétif devrait être:
- est-ce que je peux le faire avec le standard?
- est-ce que je peux le faire avec boost?
- est-ce que je peux le faire avec mon framework du moment?
- est-ce utile?
c'est justement l'étude de risque qui m'impose des fois a faire un couplage faible pour éviter un risque de modification ,si je le juge important ce risque.
Mais si tu as un code technique répétitif, c'est soit que :raisonne d'une manière générale ou on a un code technique répétitif
- ta librairie est mal conçue/inadaptée à ton besoin
- tu l'utilises mal
Tu as beaucoup plus à gagner à isoler et factoriser ces aspects techniques répétitifs derrière une façade qui a un sens du point de vue de ton application, que dans un framework technique qui va juste faire 4 opérations répétitives en un appel de fonction.
c'est justement le cas , c'est pas orienté du tout métier c'est du pure technique et ça doit être dans un framework pure technique.
et encore une fois start_with est juste un exemple d'un cas ou on fais du copier/coller du code purement technique, il faut ne pas rester focaliser sur cette méthode mais toute fonctionnalité technique répétitif.
je dis pas le contraire et cette facade pour moi est isoler dans un module a part que j'appelle framework technique.
C'est bien pour cela que j'ai dit "à l'extrême limite" et que j'ai encadré les mots simples et tables de conversion de guillemets ...c'est nettement plus compliqué que ca, si c'était qu'une simple table de conversion je te conseil de bosser dans le domaine de MDA ou tu crée des convertisseurs pour passer d'un PSM a un autre, et crois moi tu sera rapidement millionnaire
Et pourtant, dés le moment où tu a pu constater qu'une séquence donnée peut / doit être remplacée par une autre, même s'il faut sans doute jouer avec les expressions régulières, tu peux à l'extrême limite t'en sortir avec une recherche dans l'ensemble du code du projet...
Alors que ce n'est pas du tout le cas lorsqu'il s'agit de prévoir la modification d'un framework complet.
A titre d'exemple, je me suis présenté, il y a maintenant près de deux ans, dans une boite dont le projet principal était codé essentiellement en C, fonctionnait dans un mode console, et avait été lancé depuis dix ans sous la forme d'une start up.
Le responsable voulait passer à une application Qt écrite en C++.
A l'époque, il m'a fait comprendre qu'il était déjà occupé à la conception depuis plus de 6 mois et qu'il n'envisageait pas de l'avoir terminée avant encore trois.
Bien sur, cela correspond à un changement radical dans l'optique du projet, mais le changement occasionné par le passage d'un framework basé sur cobra à un autre basé sur WCF ne sera pas moins radical
Comme il a été dit, factoriser des opérations afin d'éviter la duplication de code, c'est nécessaire et pas qu'en C++. C'est même peut être bien un peu à cela que servent les fonctions.
Par contre, pour ce qui est du couplage faible, je sais pas expérience qu'il faut être extrêmement prudent de ne pas rajouter de la plomberie juste pour avoir de l'abstraction et faire face à des situations de changement invraisemblables!
De la même façon que tu vas pas t'embêter à sortir de chez toi avec un casque tous les jours de peur d'éventuellement te ramasser une météorite sur la tête, tu ne vas pas doubler le volume de ton code si la menace d'un changement n'est pas considérable.
Et sur ce point, particulièrement en langages managés (.Net et Java) les théories à la mode sur le 3 tiers et l'indépendance totale des couches, c'est TRES dangereux pour un projet lorsqu'on se force à les appliquer à la lettre.
Vouloir être indépendant du stockage depuis les couches supérieurs, que ce soit des fichiers XML, des BDD, ou des WebServices quelconque C'est la porte ouverte à l'over-engineering et aux gros retards de délais de livraison.
Et si le changement se produit, cela remet de toutes façons en cause trop de choses pour ne devoir que simplement modifier que la couche incriminée
C'est là que t'as pas compris ce que j'ai dit.
Pour reprendre mon exemple, on ne va pas isoler starts_with, mais on va fournir une fonction EstOrdreArret. Et ça, ça ne s'isole pas dans un framework technique, vu que c'est spécifique à ton appli/librairie. C'est un niveau d'abstraction supplémentaire, contrairement à starts_with qui n'est jamais qu'une simplification d'écriture.
Tu saisis la différence ?
t'a entièrement raison si le code est bien fait et n'est pas spaghetti,dans le cas réel dont je te parle , il fallait faire 2 etapes, la premiére est de virer tout ce qui est corba du code et le remonter juste au niveau stub et squeleton et la 2 eme est de remplacer par WCF, et crois moi la deuxième étape était trés rapide, la première prenais quelques mois pour un projet avec des millions de ligne de codes.Bien sur, cela correspond à un changement radical dans l'optique du projet, mais le changement occasionné par le passage d'un framework basé sur cobra à un autre basé sur WCF ne sera pas moins radical
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
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?
je ne suis pas avec le principe de tout ou rien, je dis qu'il faut faire abstraction lorsqu'on le juge utile et rassure toi je ne fais pas de plomberie pour tout et n'importe quoi mais dans la situation adéquate a ce choix.
Répondre avec citation
Partager