Discussion :

[Invité]

D'accord pour les dialectes. Néanmoins, il semblerait qu'il arrive qu'une simple utilisation proche du fameux exemple d'une classe Stack soit proscrit. Pour des raisons idéologiques, je ne vois pas autrement. La lisibilité du code c'est une chose, mais la pertinence des solutions exprimées au travers du code en est une autre. J'ai bien peur qu'au nom d'un "style commun", ce soit tout une application et sa maintenance qui soient affectées négativement. Et ça serait quand même dommage d'en arriver là

Je suis d'accord. Dans pas mal de cas, l'idéologie joue un role important.

Sur la pénalisation de la maintenance, il faut néanmoins se méfier.

Dans un logiciel, le cout d'une évolution (pour les développeurs) est formé de deux parts :

- le cout de l'écriture des fonctionnalités nouvelles
- le cout de l'adaptation du logiciel à l'évolution (souvent, en fait, le cout lié au débogage des régressions que l'évolution provoque)

Un dialecte riche et puissant réduit le cout d'écriture, mais un dialecte simpliste réduira le cout d'adaptation... En général, le cout d'adaptation est plus faible que le cout d'écriture (sauf si le logiciel est déjà en très mauvais état), mais le risque commercial associé à une régression (même rare) est plus élevé que le gain associé à une fonctionnalité nouvelle (une nouvelle fonctionnalité te gagnera peut être un client, une régression qui affecte tout le monde, risque de t'en faire perdre 10, une fonctionnalité tu as une semaine pour l'écrire, une régression tu as quelques heures pour la trouver...) Et bien sur, c'est dans ces moments la qu'on voudrait avoir le code le plus simpliste possible, et qu'on apprend à hair l'intelligence du gars qui a écrit le code super malin qu'on essaye de débuguer dans l'urgence...

Francois

[Klaim]

Issam_Lahlali> Je ne comprends pas du tout ta réponse, elle me semble hors sujet. Je ne sais pas si j'ai mal lu ou autre.

Je n'ai fait que répondre a ta remarque sur la prise de risque qui serait itérative. A mon sens, l'experience permet de résoudre la première itération si tu préfère et c'est l'expérience nécessaire pour ça ça dont les autres disent que tu manques. (je suis d'accord avec eux)

edit> Au passage, les "attaques" que tu ressens sont souvent juste des avis ou des conseils. En posant la question initiale tu te doutes bien que tu aurais obtenu des réponses. Donc prends les pour ce qu'elles sont, non?

[koala01]

Ok pour les exceptions, ça a du sens. Je rajouterais d'ailleurs le fait que certaines libs ou composants ne sont pas forcément très solides quant aux 3 safety guarantees (basic, strong, no-throw).

D'accord pour les temps de compilation ou les messages d'erreurs pour les templates. Mais de là à ce que se soit porté en tant que règle générale au détriment de la pertinence du code...

Dans un monde idéal, la pertinence du code serait la fondation même du développement

Vous (c.a.d. beaucoup de monde ici) n'avez pas l'air de porter les chefs de projets dans votre coeur

Mais si, on les adore...

Surtout grillés à point, avec un peu de beurre à l'ail

Bon, plus sérieusement, on trouve du bon et du moins bon partout...

Mais il faut dire ce qui est: ce n'est pas *forcément* par compétence que les gens le deviennent...

Ce sont encore souvent ceux qui caressent le patron dans le sens du poil, qui, bien souvent, en sont restés bloqués à une époque où même la STL n'était pas stable... S'ils connaissent réellement C++

Maintenant, il y a des exceptions partout, et tu connais le principe: pour dix gusses qui font leur travail correctement, il en suffit d'un qui fait des conneries pour que l'on ne parle que de celui-là

D'accord pour les dialectes. Néanmoins, il semblerait qu'il arrive qu'une simple utilisation proche du fameux exemple d'une classe Stack soit proscrit. Pour des raisons idéologiques, je ne vois pas autrement. La lisibilité du code c'est une chose, mais la pertinence des solutions exprimées au travers du code en est une autre. J'ai bien peur qu'au nom d'un "style commun", ce soit tout une application et sa maintenance qui soient affectées négativement. Et ça serait quand même dommage d'en arriver là

Une raison bien plus fréquente que tu ne pourrais le croire est simplement la connerie du type qui émet ce genre de restriction...

Si ton chef de projet part du principe qu'il sait mieux que toi comment faire, alors qu'il n'a pas évolué depuis la fin des années 80 dans sa connaissance (acquise sur le tas) du C et qu'il se pique de savoir programmer en C++, sans jamais avoir ouvert un bouquin qui en parle... il est facile d'en arriver à de telles extrémités

Bon, un type qui cumule vraiment toutes ces tares serait sans doute le pire des mauvais, mais, ce n'est, malheureusement, pas qu'une caricature

Et encore une fois, pour un gars de ce type, tu en a peut être 10 qui seront réellement géniaux mais dont on ne parlera jamais ici

[Issam_Lahlali]

Issam_Lahlali> Je ne comprends pas du tout ta réponse, elle me semble hors sujet. Je ne sais pas si j'ai mal lu ou autre.

Je n'ai fait que répondre a ta remarque sur la prise de risque qui serait itérative. A mon sens, l'experience permet de résoudre la première itération si tu préfère et c'est l'expérience nécessaire pour ça ça dont les autres disent que tu manques. (je suis d'accord avec eux)

justement je t'est répondu a ca avec une expérience reussi avec cette demarche je ne sais pas si ta lu tout le message.

et autre chose je trouve que la réponse "manque d'expérience" est devenu a la mode dans beaucoup de forums et un passe partout ou on utilise a tord et a travers.

surtout lorsque c'est une réponse a une citation genre:

il faut simplifier la couche technique, va comprendre la relation

peut être qu'il fallait que je dise qu'il faut se compliquer la vie et peut être la je serais plus expérimenté

[Klaim]

et autre chose je trouve que la réponse "manque d'expérience" est devenu a la mode dans beaucoup de forums et un passe partout ou on utilise a tord et a travers.

Personellement je ne l'ai vu que dans cette discussion (mais je ne parcours que peu les forums hors C++). La plupart du temps les gens viennent ici pour trouver des réponses, en toute humilité, parcequ'ils savent qu'ils manqueront toujours d'expérience un jour par rapport a une tache ou un challenge ou que sais-je. On sent l'experience rien qu'a lire les messages de ceux qui en ont. Moi je considère que la miène est bien mineure. Ca m'empeche pas de reconnaitre le manque d'expérience quand je le vois. Et manquer d'experience n'est pas un mal, l'accepter c'est le premier pas pour combler le manque.

Enfin, peu importe j'imagine. Je digresse.

surtout lorsque c'est une réponse a une citation genre:

il faut simplifier la couche technique, va comprendre la relation

Ce n'est pas ce que j'ai lu moi, c'est une interprétation pour le moins déformée.

[Mac LAK]

Ok pour les exceptions, ça a du sens. Je rajouterais d'ailleurs le fait que certaines libs ou composants ne sont pas forcément très solides quant aux 3 safety guarantees (basic, strong, no-throw).

Ce qui est encore un autre problème, mais important aussi. Je te promets qu'une exception non gérée qui claque dans un module critique temps réel, c'est un coup à te prendre un coup de fusil de la part du client...
Dans ce genre de code, il est soit nécessaire de continuer "au mieux" (tolérance de panne), soit d'assurer un repli propre (sûreté de fonctionnement). Dans les deux cas, les exceptions ne sont pas vraiment une bonne solution.
Ce qui ne retire rien à leur utilité dans d'autres niveaux/types de code, bien entendu !

Côté temps de compilation... Disons que là, tout dépend du projet bien sûr. Quand il arrive à une taille telle que tu n'es pas certain de pouvoir le générer pendant la nuit, ce genre de considération est prise en compte très très sérieusement.

Mais de là à ce que se soit porté en tant que règle générale au détriment de la pertinence du code...

C'est la fameuse règle des 80/20 : dans 80% du code, ces règles "drastiques" sont non seulement utiles, mais même nécessaires.
Et pour les 20% restants, ce n'est pas forcément optimal, mais au moins ça ne perturbe personne quand on passe dessus.

Après, il faut voir aussi que toute règle possède ses exceptions : jusqu'à présent, j'ai toujours pu écrire mon code comme je le voulais, parce qu'il était correctement encapsulé / exporté / commenté, n'impactait pas le reste, et surtout qu'il marchait nickel et/ou que chaque correction/évolution était apportée dans des délais courts.
Ces règles ne sont réellement incontournables que si tu dois coder en suivant une norme particulière (genre DO178, SIL, etc.), car là il y a d'autres raisons qui entrent en jeu.

Vous (c.a.d. beaucoup de monde ici) n'avez pas l'air de porter les chefs de projets dans votre coeur

Disons que tu as deux sortes de CP : le "technique", ancien ingénieur devenu CP, qui est en général accessible à la raison et effectue correctement son boulot d'isolation entre les dévs et les financiers. Ce genre de CP te permet en général de te concentrer au maximum possible sur ton boulot.
L'autre sorte, c'est le "financier", qui est tombé par accident dans le soft, que l'on a bombardé CP parce qu'il ne fallait surtout pas le laisser toucher au code, qui n'effectue AUCUN travail d'isolation entre les dévs et les financiers et qui passe son temps à t'en faire perdre.

Inutile de te dire que le premier est en général respecté, ne serait-ce que parce qu'il serait largement capable d'écrire le code à ta place s'il en avait le temps, et qu'il te fiche la paix tant que tu n'exploses pas tes délais de façon injustifiée.
Pour le second, disons que l'on risque de devenir très grossiers si l'on dit ce que l'on pense réellement...

et surtout si on parle d'éditeurs les français n'arrive pas a s'exporter comme d'autres pays donc il y a un probléme dans la démarche suivi et lorsqu'on parle d'expérience il faut voir aussi ce qu'on fait sur les projets qui ont très bien marcher.

Tout dépend des branches... Je bosse dans une petite PME, et on vend partout dans le monde, Chine et USA inclus, au travers de plusieurs grands comptes français.

Contrairement à une idée répandue, les produits français sont souvent technologiquement supérieurs aux autres (cf. Airbus vs. Boeing pour le plus connu), et les "cerveaux" français sont souvent recherchés un peu partout.
C'est le caractère général des français (en tant qu'individus) qui est souvent peu apprécié, et non pas leurs réalisations techniques.

[Issam_Lahlali]

Ce n'est pas ce que j'ai lu moi, c'est une interprétation pour le moins déformée.

c'est pour cela que je ne vois pas la relation avec le manque d'expérience, ca veut pas dire que je j'ai une grande expérience, d'ailleurs a plusieurs reprises j'ai dis que ne suis pas expert mais je vois pas le rapport.

depuis le debut je parle de simplifier la couche technique la ou on juge utile , et on me répond par manque d'expérience , si toi tu comprends quelque chose a cette relation peux tu m'éclairer parce que je comprends rien de rien a cette association d'où ma réponse ou je parlais de mon expérience réussi avec la démarche de simplification de la couche technique,pour montrer que c'est justement mon expérience réel sur un très grand projet que j'ai appris a avoir ce réflexe et cette démarche.

[Mac LAK]

depuis le debut je parle de simplifier la couche technique la ou on juge utile , et on me répond par manque d'expérience , si toi tu comprends quelque chose a cette relation peux tu m'éclairer parce que je comprends rien de rien a cette association d'où ma réponse ou je parlais de mon expérience réussi avec la démarche de simplification de la couche technique.

C'est simplement que tu as assez d'expérience pour voir que le codage "à la geek" n'est pas bien en soi, mais pas encore assez pour voir que l'excès inverse n'est pas non plus une bonne chose.

Il te reste à apprendre l'art du compromis dans ce domaine... T'inquiètes pas, on a tous des domaines où l'on doit encore apprendre plein de choses, que ce soit sur un plan technique, humain ou relationnel.

[Klaim]

depuis le debut je parle de simplifier la couche technique la ou on juge utile , et on me répond par manque d'expérience , si toi tu comprends quelque chose a cette relation peux tu m'éclairer parce que je comprends rien de rien a cette association d'où ma réponse ou je parlais de mon expérience réussi avec la démarche de simplification de la couche technique.

D'accord: ce qui a été dit c'est que a la fois le probleme (toutefois vague mais admétons qu'ils soit compris ici) que tu exposes n'a pas de solution (ou n'est pas un vrai probleme) comme tu semble le penser et que tes réponses face aux arguments qui expliquent le pourquoi démontrent (je suis pas sur que ce soit le bon mot) que ta vision des choses est un poil limitée - caractéristique du manque d'expérience. Le manque d'expérience ici n'est pas signe d'amateurisme mais peut être de manque de diversité des situations vécues, des types de développement, de management, de technologies etc.
Donc en gros, ce que tu suggères et sur lequel tu demandes une reflexion est soit absurde, soit utopiste (encore une fois pas sur que ce soit le bon mot) soit ne prends pas en compte des aspect de developpements auxquels tu n'as certainement pas été confronté. Et les exemples tirés des autres languages est juste sans poids (rapport a la conception/technique).
On revient a l'experience parceque c'est l'experience qui permet d'arriver a cette constatation, notamment par la distance que l'on prends avec l'experience quand aux différentes façons de penser, et qui permet de voir ces façons de penser comme des outils d'abord.

Beaucoup de réponses synthétiques t'ont été données sans que cela semble réellement avoir un poids dans tes réponses, d'où la répétition je présume.

Enfin, ya pas mal de choses a dire pour résumer tout ce qui a été suggéré ici...

Maintenant je dois aller dormir

[Klaim]

C'est simplement que tu as assez d'expérience pour voir que le codage "à la geek" n'est pas bien en soi, mais pas encore assez pour voir que l'excès inverse n'est pas non plus une bonne chose.

Il te reste à apprendre l'art du compromis dans ce domaine... T'inquiètes pas, on a tous des domaines où l'on doit encore apprendre plein de choses, que ce soit sur un plan technique, humain ou relationnel.

Et moi faut vraiment que j'aprenne la synthèse des idées en français
Merci c'est bien plus clair que ce que je dis.

[Issam_Lahlali]

C'est simplement que tu as assez d'expérience pour voir que le codage "à la geek" n'est pas bien en soi, mais pas encore assez pour voir que l'excès inverse n'est pas non plus une bonne chose.

Il te reste à apprendre l'art du compromis dans ce domaine... T'inquiètes pas, on a tous des domaines où l'on doit encore apprendre plein de choses, que ce soit sur un plan technique, humain ou relationnel.

bien dit mais a mon avis répondre par manque d'expérience tout court n'a pas trop de sens en général , c'est très vaste et il faut des précisions comme maintenant ou tu me dis qu'il faut pas trop en faire non plus au niveau abstraction et c'est pour cela que je disait a chaque fois "lorsqu'on juge utile" et la c'est un tout un process a suivre pour valide si on le fait ou pas.

et t'inquiette en informatique je me considère tout le temps comme débutant , on a toujours des choses a apprendre même des débutants

juste le fait d'avoir des reponses passe partout que j'aime pas trop, genre :
t'a pas d'experience, tu comprends rien et autre similaire.

[koala01]

pour montrer que c'est justement mon expérience réel sur un très grand projet que j'ai appris a avoir ce réflexe et cette démarche.

Mais c'est justement là le problème:

Tu pars d'une expérience qui n'est pas remise en question, mais basée sur un fait particulier, et tu essaye d'en tirer des règles d'application générale, sans te rendre compte que tout ce que tu peux dire sera, au mieux, uniquement adapté à ton cas particulier, au pire la plus mauvaise des bonnes idées dans des cas différents.

C'est un peu comme si tu te basais (pour prendre un exemple concret) sur ce que permet (ou ne permet pas) un compilateur connu pour son non respect de la norme (tel que VC6 ou BCB6) pour essayer de tirer des conclusions sur la norme elle-même.

Nous respectons l'expérience que tu as pu acquérir au cours de ce projet, nous comprenons qu'elle ait un aspect particulièrement valorisant à tes yeux, mais ce qui nous énerve quelque peu, c'est le fait que, tu considère que cette expérience est significative de l'ensemble des problèmes auxquels il faut réfléchir.

Récemment, je lisais dans une autre discussion (même si je ne me souviens plus de laquelle) un rappel de ce que disait un guru il y a déjà bien des années:

Tout programmeur système devrait avoir au moins programmé trois système d'exploitation avant de s'estimer compétant:
Le premier sera fait n'importe comment
Le second sera fait en respectant trop scrupuleusement les règles
Le troisième et les suivants seront fait en trouvant les meilleurs compromis entre les deux

(citation très approximative)

La gestion de projet suit, en définitive, et pour autant que tu reste ouvert à une éventuelle remise en question, une logique comparable:

1. Tu gérera ton premier projet, disons le sans fard, "comme un manche" (et quand je dis "tu", je parle de n'importe qui )
2. Tu gérera ton deuxième projet en imposant des règles beaucoup trop strictes et, bien qu'il puisse arriver à un résultat correct, tu versera dans la "sur qualité" déjà évoquée
3. Ce n'est qu'après le troisième projet que tu arrivera à faire la part de ce qui est important, chronophage et inutile ou financièrement et techniquement intéressant

Ce n'est pas une attaque, c'est, simplement, une évolution normale par laquelle nous passons tous (d'ailleurs, il y en a pas mal qui n'atteignent réellement le juste milieu qu'après un nombre autrement plus importants de projets ) et par laquelle les gens continueront de passer dans tous les domaines, y compris n'ayant rien à voir avec l'informatique.

Le manque d'expérience n'est pas une tare, à la condition expresse d'accepter de rester suffisamment ouvert pour profiter de l'expérience des autres ainsi que des erreurs que l'on commet.

C'est peut être beaucoup plus ton manque d'ouverture d'esprit et ton coté "tout ou rien" qui échauffent réellement les oreilles de certains d'entre nous.

[Issam_Lahlali]

C'est peut être beaucoup plus ton manque d'ouverture d'esprit et ton coté "tout ou rien" qui échauffent réellement les oreilles de certains d'entre nous.

je vais me répéter une dernière fois , lorsque je parle de simplifier a plusieurs reprises je disais "lorsqu'on juge utile" et le tout ou rien je l'est déjà évoqué avant lorsque je disait qu'on veut rien toucher tout marche nikel et ma position justement était au milieu avec le mot clé "lorsqu'on juge utile"

et pour l'expérience personne ne peut prétendre une expérience absolu, chaque projet est unique et la je parle plutot d'un reflexe qu'il faut avoir quelque soit le projet qui est celui de simplifier et aprés on va voir si c'est utile de le faire ou pas c'est juste un principe.

mais si on me dit que ce principe ne marche pas pour tous les projets ,la je reste perplexe

[metagoto]

Un dialecte riche et puissant réduit le cout d'écriture, mais un dialecte simpliste réduira le cout d'adaptation... En général, le cout d'adaptation est plus faible que le cout d'écriture (sauf si le logiciel est déjà en très mauvais état), mais le risque commercial associé à une régression (même rare) est plus élevé que le gain associé à une fonctionnalité nouvelle (une nouvelle fonctionnalité te gagnera peut être un client, une régression qui affecte tout le monde, risque de t'en faire perdre 10, une fonctionnalité tu as une semaine pour l'écrire, une régression tu as quelques heures pour la trouver...) Et bien sur, c'est dans ces moments la qu'on voudrait avoir le code le plus simpliste possible, et qu'on apprend à hair l'intelligence du gars qui a écrit le code super malin qu'on essaye de débuguer dans l'urgence...

C'est une analyse très pertinente. Cependant, simpliste dans ce contexte, si je suis bien, ça sous entend coder dans le dialecte du C (en exagérant un peu). Je n'ai personnellement pas l'impression que ça facilite le debugging ou la simple compréhension du code lorsque l'on est dans la démarche d'adaptation que tu as décrit. Néanmoins, je peux comprendre que l'on en arrive là.

Dans un monde idéal, la pertinence du code serait la fondation même du développement

Oui c'est sûr que ça serait idéal
Au nom d'une certaine lisibilité du code, on va se priver d'une syntaxe particulière qui aurait pu générer un dialecte qui à son tour aurait pu générer des possibilités de résolutions de problèmes (la raison d'être du code). Une caractéristique symptomatique du C++ -je pense.

jusqu'à présent, j'ai toujours pu écrire mon code comme je le voulais, parce qu'il était correctement encapsulé / exporté / commenté, n'impactait pas le reste, et surtout qu'il marchait nickel et/ou que chaque correction/évolution était apportée dans des délais courts.

Eh bien, c'est impressionnant!

[Invité]

C'est une analyse très pertinente. Cependant, simpliste dans ce contexte, si je suis bien, ça sous entend coder dans le dialecte du C (en exagérant un peu).

C'est de moins en moins le cas, car même chez les "vieux" programmeurs C++, il commence à y en avoir beaucoup qui n'ont jamais fait de C à titre professionnel...

Simpliste, ça veut généralement dire deux choses

- un seul paradigme
- un sous ensemble réduit du langage et des librairies

Sur un C++ moderne, ca pourrait vouloir dire
1- juste la STL, pas de boost
2- seulement des vector, pas de map, de set, ou autres
3- pas (ou pas trop) de foncteurs, et des templates réduits au minimu
4- pas trop d'objet (par exemple pas de hiérarchie de classe autre que celles de base fournies par le framework utilisé s'il y en a un

Tu te retrouves alors avec un code utilisant peu la POO, et gravitant autour de la STL

Pour d'autres on verra (cette version est très courante)
1- de la POO (mais pas d'héritage multiple, ni de hiérarchies trop longues)
2- pas trop de générique (voire pas du tout)
3- une librairie algo maison (éventuellement dérivée de la STL)

L'idée générale derrière le "simplisme", c'est qu'on réduit au maximum ce qu'un programmeur est censé maitriser pour lire le code et le débuguer. Le C est effectivement une solution attrayante (parce que c'est un petit langage, du point de vue de la syntaxe), mais il est notoirement difficile à débuguer. En fait, les tenants du C compileront tout en C, de nos jours (je connais au moins une boite francaise de développement, assez connue, où le C est la norme et où le C++ est interdit).

A mon avis, la forme la plus classique du C++ simplifié, actuellement c'est POO basique, + iostreams, et presque pas de STL (vector et algos de tri et de recherche).

Francois

[metagoto]

Sur un C++ moderne, ca pourrait vouloir dire
1- juste la STL, pas de boost
2- seulement des vector, pas de map, de set, ou autres
3- pas (ou pas trop) de foncteurs, et des templates réduits au minimu
4- pas trop d'objet (par exemple pas de hiérarchie de classe autre que celles de base fournies par le framework utilisé s'il y en a un

Je comprends tout à fait ça, et les argumentations des autres dans cette thread d'ailleurs.

Il n'empêche que je trouve scandaleux () le fait qu'une solution imaginée, implémentée et qui fonctionnerait bien puisse être oubliée et remplacée par quelque chose de moins "bon" (dans toutes les dimensions possibles) simplement parce qu'elle ne respecte pas une certaine notion de "simplicité". Bon, là c'est un exemple, mais le choix entre vector et map ne devrait pas être dicté par des règles préalables, mais par des considérations rationnelles d'algorithmie et de modélisation.

Y a quand même une sacrée différence entre la littérature et la réalité dans le monde du C++

Du coup j'ai une idée, ne faudrait-il pas systématiquement avoir un framework pour la couche technique ? Vous en pensez quoi ?

[koala01]

mais si on me dit que ce principe ne marche pas pour tous les projets ,la je reste perplexe

Hé bien, je vais te donner un exemple précis tiré de "la vie de tous les jours" de toute personne disposant d'un ordianteur: les interfaces graphiques...

Nous sommes, à part quelques irréductibles, tous d'accord pour estimer que le "cliquodrôme" facilite grandement la vie par rapport à une application fonctionnant en mode "console" pure, et ce, malgré que les interfaces se fassent de plus en plus complexes.

Et, pour bien enfoncer le clou, je vais même prendre une interface qui est généralement la plus basique qui soit: un installateur quelconque (qu'il s'agisse de l'interface d'installation de windows ou de celle de l'installation d'un service pack).

L'utilisation de telles interfaces est des plus simple: clique, clique, cocher, un tout petit peu de texte, clique, clique, attendre, fini.

Un enfant sachant lire serait capable de le faire.

Et, dans une majorité des cas, c'est très bien comme cela.

Sauf que, voilà... un jour, en tant qu'informaticien, tu dois effectuer une mise à jour du windows des 150 pc's (passer de XP à vista, par exemple) de ta boite, en veillant à introduire le dernier SP (qui, comme de juste, est sorti juste après que tu aie acheté le DVD original), en veillant, tant qu'à faire, à intégrer une suite bureautique quelconque et, cela va de soi, certains programmes propres à l'entreprise.

Si tu dois n'utiliser que le seul DVD original des programmes à installer (parce qu'il est possible d'avoir plusieurs licences différentes mais un seul DVD) tu commence en septembre pour terminer en décembre, tellement chaque installation va prendre longtemps et tellement tu as d'ordinateurs à mettre à niveau, et, surtout, parce que tu ne peux pour ainsi dire pas quitter chaque ordinateur des yeux parce que tu as des licences à accepter ou des manipulation physiques à faire (introduire le cd d'office, par exemple ?)

La solution "de bon sens" sera de créer un système d'installation automatisé, incluant directement le dernier SP et les logiciels nécessaire, mais tu pourra chercher partout dans le système de windows, si tu trouvera "assez facilement" une interface graphique te permettant de créer un dvd d'installation automatisée, tu aura le plus grand mal à y intégrer le service pack en n'utilisant que le cliquodrôme.

Et le constat est strictement le même pour les différents programmes que tu pourrais souhaiter installer de manière automatique...

Par contre, si tu ressort l'antique ligne de commande, il en va tout autrement:

• une commande pour extraire le contenu du SP dans un dossier prévu pour
• une commande pour copier le contenu du DVD dans un autre dossier prévu pour
• une troisième commande pour intégrer le contenu du SP au contenu du répertoire qui contient la copie du DVD
• une commande pour lancer l'interface graphique qui te permettra de créer un DVD d'installation automatisée
• Quelques commandes pour copier le contenu des cd des logiciels à installer (voire, pour créer un système d'acceptation de licences / introduction de numéro de série automatisé)
• Gravure à X exemplaires, si tu n'a pas la possibilité de profiter du réseau pour l'installation, et roulez jeunesse: en cinq heures de temps (la copie des fichiers, l'intégration des programmes et du service pack et la gravure des dvd risque, effectivement, de prendre du temps), tu peux en arriver à avoir installer le tout sur tous les PC d'un étage, là où la méthode manuelle t'aurait demandé trois jours 24 heures sur 24.

Ici, je te présente, il est vrai, un cas particulier dans lequel le principe général de base n'est pas applicable.

Mais il te montre bien que le soucis de "simplification" d'un processus est souvent synonyme d'abandon de possibilités.

Dans d'autres cas, nous pourrions en trouver, on en arrive même à l'effet contraire: une simplification mal faite ou mal étudiée où la simplification s'avérera réellement contre productive, tous points de vue confondus, parce que ce que tu auras assimilé, sans doute hâtivement, au cas général n'est en réalité que le cas particulier d'une exception elle-même fort rare.

Il n'y a rien à faire, la simplification a un cout qui s'évalue selon une série de critères qui va bien au delà du fait de permettre à un développeur de faire en une ligne ce qui lui en aurait demandé trois s'il ne profitait pas de la simplification.

Les critères d'évaluation de ce cout vont de la conception à la mise en oeuvre en passant par la facilité avec laquelle nous pourrons faire évoluer le projet voire, dans les cas les plus tendus, la facilité avec laquelle nous pourrons "casser" le code afin de repartir sur des bases toutes différentes.

Et force est de constater que, parfois, le bénéfice qu'il peut y avoir à permettre "ponctuellement" à quelqu'un de gagner en productivité sera perdu très largement à long terme si, pour une raison ou une autre, on en vient à devoir casser le code

[Issam_Lahlali]

merci pour cette réponse détaille et je suis d'accord avec ce raisonnement c'est pour cela que je répète tout le temps "lorsqu'on juge utile" et je ne sais pas pourquoi on zappe toujours cette phrase pourtant je l'écris toujours en gras

[Matthieu Brucher]

merci pour cette réponse détaille et je suis d'accord avec ce raisonnement c'est pour cela que je répète tout le temps "lorsqu'on juge utile" et je ne sais pas pourquoi on zappe toujours cette phrase pourtant je l'écris toujours en gras

Parce que ça ne veut rien dire. Le souci, c'est que notre "lorsqu'on juge utile" n'est pas le même que le tien. Et ça se voit dans les discussions.

Autre détail qui a son importance. Tu disais qu'en Ruby et en Python, la couche technique était formalisée. Il y a une bibliothèque standard plus étoffée, disons comme C++ + Boost. Mais au niveau graphique, rien n'est formalisé par exemple. wxPython et PyQt n'ont rien à voir entre eux et rien à voir avec tkinter. Rien n'est réutilisable pour les UI. Ca pourrait être utile de créer une couche technique pour eux, et il y a des outils qui font des sous-ensembles de wxPython et PyQt, mais dans les faits, on ne peut pas faire la même chose avec les deux, il y a des hacks et du monkey-patching pour modifier le comportement, ... C'est utile, mais ce n'est pas gérable de faire une couche commune.

[Mac LAK]

Cependant, simpliste dans ce contexte, si je suis bien, ça sous entend coder dans le dialecte du C (en exagérant un peu). Je n'ai personnellement pas l'impression que ça facilite le debugging ou la simple compréhension du code lorsque l'on est dans la démarche d'adaptation que tu as décrit. Néanmoins, je peux comprendre que l'on en arrive là.

Mon interprétation : c'est plutôt "simpliste" dans le sens où il y a peu de concepts utilisés... Les concepts en question peuvent par contre être particulièrement velus suivant les domaines, mais leur nombre est faible.

Eh bien, c'est impressionnant!

Cela a un prix : si je devais compter les heures que j'ai pu passer à bosser à la maison ou le week-end, ça te ferait peur... Parce que tu te doutes bien que je n'ai jamais eu de temps supplémentaire par rapport aux autres juste pour mes beaux yeux ! De plus, dans un tel cas de figure, tu n'as pas le droit de faire simplement "aussi bien" que les autres : tu dois faire bien mieux... Cela coûte du temps supplémentaire, qu'il te faudra bien sûr mesurer et conserver quelque part : c'est un argument si, un jour, tu cherches à faire évoluer les règles de ta boîte en faveur de "ta" manière de concevoir/coder. Et le seul moyen de la faire accepter, c'est de prouver que le temps "perdu" à l'écriture initiale a été rentabilisé en accélérant (ou en supprimant !!) les interventions de maintenance sur ton code, très coûteuses car "gratuites" pour le client le plus souvent... Comme d'hab, les chiffres, les chiffres et encore les chiffres, toujours tout tracer et tout quantifier !

Donc, le temps "perdu" à chercher des conceptions intéressantes, ou à tester certaines implémentations, il fallait bien le rattraper d'une manière ou d'une autre, donc en dehors du boulot en général.
Ceci étant dit, et sans pousser non plus les dévs à devenir des bourreaux de travail, c'est très formateur côté expérience... Sur les premières années de travail, cela peut être un pari intéressant si l'on n'a pas trop de contraintes familiales.

Mais c'est un contre-exemple à l'idée reçue "on casse le code qui ne respecte pas la règle, même s'il fonctionne très bien". Crois-moi, en entreprise, on ne casse pas quelque chose qui marche, surtout si ça marche très bien... Pour que cela arrive, il faut absolument des contraintes autres, souvent provenant du client lui-même et/ou d'une certification quelconque (genre norme DO178) ! Et dans un tel cas de figure, coder autrement que "dans la norme" est une faute professionnelle, donc personne ne s'y amuse.

Tu n'as le loisir de coder "à ta guise" que sous deux conditions :

• Pas de norme imposée, dont le non-respect pourrait invalider le produit complet.
• Tu n'as pas intérêt à te louper, ton travail doit être plus qu'irréprochable, sinon on te sortira que c'est le non-respect des règles qui est la cause des erreurs (et ça va être dur à infirmer, que ce soit vrai ou non...).

Mais au moins, ça te permet le cas échéant de pouvoir faire évoluer les règles dans ta société, en prouvant que ta manière de faire est meilleure (=moins chère)... Le gain se situe soit à l'écriture initiale, soit lors des évolutions/corrections, c'est à toi de pouvoir expliquer objectivement en quoi ta manière est meilleure que la règle en cours.

Et, bien sûr, les arguments "c'est plus dans l'esprit du langage" ou "c'est plus beau ainsi" ne sont pas recevables, faut parler pognon pour se faire écouter !