Discussion :

[Alp]

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

[Issam_Lahlali]

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 .

[koala01]

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

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

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

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

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

Et la boucle est bouclée

[Issam_Lahlali]

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.

[Matthieu Brucher]

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é.

[Mac LAK]

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 ???

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 !

[white_tentacle]

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 ?

[Invité]

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"?

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

[Issam_Lahlali]

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é.

[Issam_Lahlali]

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.

[Issam_Lahlali]

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 ?

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.

[Mac LAK]

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".

[Matthieu Brucher]

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 !!

[Invité]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Matthieu Brucher]

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.

[Issam_Lahlali]

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.

[Matthieu Brucher]

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

[Issam_Lahlali]

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?

[Mac LAK]

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...

[Matthieu Brucher]

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.