Discussion :

[F.Saad]

la programmation modulaire ? jamais vu dans les tutos

[Mac LAK]

la programmation modulaire ? jamais vu dans les tutos

Pas les bons tutos, ou ... pas les bons langages, peut-être ?
Turbo Pascal (par Hugo Etievant), chapitre XIV.
Turbo Pascal (par Jean-Michel Bernabotto), chapitre 5

Tous sur DVP, hein, bien entendu...

(Oui, je sais, j'suis méchant toussa toussa...)

[chaplin]

Ceci dit, en .NET, le découpage en module (assembly) est bien foutu, c'est même un plaisir, je dirais nativement transparant.

[Mac LAK]

Ceci dit, en .NET, le découpage en module (assembly) est bien foutu, c'est même un plaisir, je dirais nativement transparant.

Oui, mais ça n'apprends pas forcément à faire de BONS modules, c'est à dire autonomes et sans tentacules... Ni même à forcément penser à en faire soi-même, en dehors des modules "imposés" par le langage.

[ZoinX]

Euh je peux me tromper, mais un module autonome ce serait pas tout simplement un projet ? (ou une bibliothèque)

Sinon je suis d'accord qu'il faut éviter d'avoir des modules trop tentaculaires, ceci dit l'important dans les modules n'est pas tant de limiter les interactions entre modules que surtout de faire des regroupements logiques, correspondant à tes différents composants tels que définis dans la spec. S'il doit y avoir de nombreuses ramifications entre les modules, tant pis.

[jabbounet]

Euh je peux me tromper, mais un module autonome ce serait pas tout simplement un projet ? (ou une bibliothèque)

Sinon je suis d'accord qu'il faut éviter d'avoir des modules trop tentaculaires, ceci dit l'important dans les modules n'est pas tant de limiter les interactions entre modules que surtout de faire des regroupements logiques, correspondant à tes différents composants tels que définis dans la spec. S'il doit y avoir de nombreuses ramifications entre les modules, tant pis.

C'est surtout un analyse cartésienne des problèmes que tu peux avoir a résoudre en informatique .

* l'analyse :

« Le second, de diviser chacune des difficultés que j'examinerais, en autant de parcelles qu'il se pourrait, et qu'il serait requis pour les mieux résoudre. »

si ton problème est trop compliqué pour être résolu d'un coup tu le découpe en petit morceaux que tu sais résoudre.

A croire que l'on a rien inventé en informatique

[Mac LAK]

Euh je peux me tromper, mais un module autonome ce serait pas tout simplement un projet ? (ou une bibliothèque)

Cela peut aller d'une simple fonction de deux lignes à un projet monumental, en fait, tout dépend du niveau de raffinage que tu es en train de considérer pour ton approche modulaire.

Sinon je suis d'accord qu'il faut éviter d'avoir des modules trop tentaculaires, ceci dit l'important dans les modules n'est pas tant de limiter les interactions entre modules que surtout de faire des regroupements logiques, correspondant à tes différents composants tels que définis dans la spec.

Non : le plus important dans un module, c'est qu'il soit autonome. S'il est bien conçu, tu initialise ses dépendances à l'exécution, sachant qu'une dépendance non renseignée doit impérativement être remplacée par un stub neutre.

S'il doit y avoir de nombreuses ramifications entre les modules, tant pis.

Surtout pas : ça, c'est la méthode "crassos", qui rend un projet totalement impossible à maintenir au bout de deux ou trois évolutions. Si ton module est bien fait, tu dois pouvoir le retirer du projet et garder ce dernier fonctionnel, aux fonctions assurées par le module supprimé près bien entendu, d'où le stub.
Si ton projet ne compile plus après avoir retiré un module (sauf initialisation / connexions évidemment), c'est que tu as merdé dans son implémentation.

si ton problème est trop compliqué pour être résolu d'un coup tu le découpe en petit morceaux que tu sais résoudre.

Et ainsi de suite jusqu'à arriver à des problèmes élémentaires...

[ZoinX]

Je ne suis pas du tout d'accord avec ta vision des modules.

Je ne prétends pas avoir raison, mais pour moi ce n'est pas comme ça qu'on définit quels seront les différents modules d'un projet. Certes dans l'idéal c'est évidemment mieux qu'ils soient au maximum indépendants des autres, mais c'est pas dans cette optique là qu'on les définit.

Dans un projet typique par exemple, tu définis un module bas niveau pour les accès aux données, qui s'occupera par exemple de toutes les interactions avec une base SQL. Ce module là est utilisé par tous les autres modules du projet, et c'est normal, et aucun autre ne pourra fonctionner correctement sans lui.

Tu auras aussi typiquement un module haut niveau qui sert de "main", et qui s'occupe de faire fonctionner tout le reste, il interagira donc avec tous les autres modules (sauf peut-être ceux de plus bas niveau justement).

Entre les deux, tu peux tout à fait définir plein de modules intermédiaires qui interagissent entre eux, l'important est de les distinguer selon leurs rôles. Par exemple on peut imaginer un module pour une interface web, un module pour une API utilisée par l'interface web, un module pour un pool de threads exécutant le principal travail du projet, un module de logging et monitoring, un module pour une tâche précise de traitement, etc...

Tous ces modules peuvent ou non avoir plein d'interactions et d'appels entre eux. L'essentiel est que les interfaces publiques soient clairement définies et relativement simples. Dans tous les cas, il me semble que le découpage des modules doit être fait en fonction des différentes fonctionnalités et/ou types d'exécution de tes modules (ce qui correspond normalement exactement à ton organigramme de haut niveau dans ta spec), et non de manière à minimiser les interactions, même si c'est préférable.

[Mac LAK]

Je ne suis pas du tout d'accord avec ta vision des modules.

Tu as le droit. Tu as tort, mais ce n'est pas encore interdit de se planter lorsque l'on apprends.

Je ne prétends pas avoir raison, mais pour moi ce n'est pas comme ça qu'on définit quels seront les différents modules d'un projet. Certes dans l'idéal c'est évidemment mieux qu'ils soient au maximum indépendants des autres, mais c'est pas dans cette optique là qu'on les définit.

C'est pourtant ce que l'on fait tous les jours. Peut-être te manque-t'il le fait d'avoir travaillé sur un projet de plus de 300 homme-ans, et qui est garanti dix ans pour le client, pour comprendre en quoi tu te trompes lourdement ?

Dans un projet typique par exemple, tu définis un module bas niveau pour les accès aux données, qui s'occupera par exemple de toutes les interactions avec une base SQL. Ce module là est utilisé par tous les autres modules du projet, et c'est normal, et aucun autre ne pourra fonctionner correctement sans lui.

Ah ? Première nouvelle... Je crois qu'il te reste deux ou trois trucs à apprendre en conception, comme les stubs, les interfaces abstraites permettant de les implémenter, les dépendances en amont, les systèmes de plug-ins, etc.

Bref, des façons de séparer les modules entre eux, et de laisser un code tiers (en général, le programme principal) le soin de les accorder entre eux, il y en a plein. Via de belles définitions de macros, tu peux même totalement adapter le code et inclure des modules via quelques directives de préprocesseur... Et adapter le code en conséquence, soit en supprimant toute référence au module, soit en le stubbant.

Tu auras aussi typiquement un module haut niveau qui sert de "main", et qui s'occupe de faire fonctionner tout le reste, il interagira donc avec tous les autres modules (sauf peut-être ceux de plus bas niveau justement).

Je te rappelle qu'en tête de tout bon entête C/C++ bien écrit, tu as un "#define" qui te permet de savoir si le module a été inclus ou pas... Tires-en les conclusions qui s'imposent quand à l'adaptabilité du code principal, surtout si les "#include" principaux sont eux-même conditionnés par des définitions globales au projet du genre "USE_MODULE_X"...
Via un concept un peu plus évolué (type plug-in, ou classes abstraites d'interface), tu peux carrément rendre tout ça réellement dynamique et automatique, sans même recompiler...

Entre les deux, tu peux tout à fait définir plein de modules intermédiaires qui interagissent entre eux, l'important est de les distinguer selon leurs rôles.

Tu as aussi un autre concept, celui de chaînage de modules, qui te permet de formaliser strictement les interfaces des modules et donc d'ajouter (ou retirer) n'importe quelle étape du traitement de façon transparente.

Tous ces modules peuvent ou non avoir plein d'interactions et d'appels entre eux.

Bien sûr. Sauf qu'ils diffusent ces interactions sur les modules que l'on a décidé d'interfacer avec eux, suivant soit un principe de broadcast, soit de chaînage, soit de séquentialité, ou encore de callbacks, tout dépend de l'utilisation du module qui a été décidée. C'est quand même encore le concepteur qui décide des traitements effectués et de la manière de les effectuer, hein...
Ta seule limite est ton ouverture d'esprit, et les limites de la machine. Tant que la première est compatible avec les secondes, tu peux implémenter tout ce que tu peux imaginer.
Il faut simplement pouvoir imaginer, ou, pour utiliser le terme adéquat, concevoir.

Dans tous les cas, il me semble que le découpage des modules doit être fait en fonction des différentes fonctionnalités et/ou types d'exécution de tes modules (ce qui correspond normalement exactement à ton organigramme de haut niveau dans ta spec), et non de manière à minimiser les interactions, même si c'est préférable.

Et à la première modification/évolution majeure du projet, tu vas devoir péter les deux tiers du code pour pouvoir la faire.

Ta manière de voir est peut-être valable pour un (petit) projet one-shot, mais sûrement pas pour un gros projet générique, adaptable et devant rester fonctionnel (et maintenu !!) pendant des dizaines d'années.

Compares ce qui est comparable, on ne fait pas de modules aussi indépendants sur un projet d'école ou une petite appli maison. Mais vu qu'en milieu professionnel, ce sera forcément demandé un jour ou l'autre, autant savoir que c'est une possibilité concrète et comprendre les mécanismes nécessaires à une telle opération. Sinon, tu ne peux pas considérer que tu as "appris" la programmation modulaire...

[ZoinX]

C'est pourtant ce que l'on fait tous les jours. Peut-être te manque-t'il le fait d'avoir travaillé sur un projet de plus de 300 homme-ans, et qui est garanti dix ans pour le client, pour comprendre en quoi tu te trompes lourdement ?

Ben en ce moment je travaille sur un projet sur lequel il y a environ 800 ingénieurs depuis un peu plus de 5 ans, et nos modules dépendent les uns des autres. Pour autant ça va le projet marche de mieux en mieux de version en version, il n'y a eu en 5 ans qu'un seul bug majeur en production et les nombreux clients en sont de plus en plus satisfaits.

Et évidemment l'exemple de modules que je t'ai donné dans mon post précédent faisait référence à ce projet.

Ah ? Première nouvelle... Je crois qu'il te reste deux ou trois trucs à apprendre en conception, comme les stubs, les interfaces abstraites permettant de les implémenter, les dépendances en amont, les systèmes de plug-ins, etc.

J'ai pas dit non plus qu'il fallait faire interagir les modules entre eux n'importe comment hein. Evidemment qu'il faut utiliser des interfaces pour les objets et des API pour le reste, mais si ça sert pas justement à gérer des interactions entre modules tout ça, faudra me dire à quoi ça sert...

Bref, des façons de séparer les modules entre eux, et de laisser un code tiers (en général, le programme principal) le soin de les accorder entre eux, il y en a plein. Via de belles définitions de macros, tu peux même totalement adapter le code et inclure des modules via quelques directives de préprocesseur... Et adapter le code en conséquence, soit en supprimant toute référence au module, soit en le stubbant.

Je te rappelle qu'en tête de tout bon entête C/C++ bien écrit, tu as un "#define" qui te permet de savoir si le module a été inclus ou pas... Tires-en les conclusions qui s'imposent quand à l'adaptabilité du code principal, surtout si les "#include" principaux sont eux-même conditionnés par des définitions globales au projet du genre "USE_MODULE_X"...
Via un concept un peu plus évolué (type plug-in, ou classes abstraites d'interface), tu peux carrément rendre tout ça réellement dynamique et automatique, sans même recompiler...

C'est bien joli tes #define et #include, mais tout le monde ne fait pas que du C++. Et sans avoir besoin d'utiliser du préprocesseur, je vois pas ce qu'il y a de mal à un bon vieux "using myModule;" et faire appel aux interfaces de ce module, dans n'importe quel autre... le nom du module et ses interfaces, c'est quelque chose que tu définis au début et que tu n'es pas censé changer tous les jours !

Et à la première modification/évolution majeure du projet, tu vas devoir péter les deux tiers du code pour pouvoir la faire.

Ah bon. Donc tu es en train de dire qu'à la première évolution majeure du projet, il faut casser toutes les interfaces abstraites ? Je sais pas comment tu les conçois tes évolutions de projet...

De plus, la règle numéro un des évolutions de projet, c'est de n'avoir jamais de régression. On ajoute des features, on n'en enlève jamais. A partir de là, ça implique soit de créer de nouveaux modules, soit d'en modifier/enrichir le contenu et enrichir éventuellement les interfaces. Dans tous les cas, si tes interfaces ont été bien conçues dès le départ, tu n'auras jamais besoin de casser des interfaces existentes, juste de les enrichir ou en ajouter de nouvelles pour faire appel aux nouveaux modules ou aux nouvelles fonctionnalités des anciens modules.

Si tu respectes cette règle fondamentale, aucune nécessité de modifier en profondeur un module parce que tu en as modifié ou créé un autre, à moins d'avoir besoin d'exploiter explicitement les nouvelles fonctionnalités via de nouvelles interfaces.

Ta manière de voir est peut-être valable pour un (petit) projet one-shot, mais sûrement pas pour un gros projet générique, adaptable et devant rester fonctionnel (et maintenu !!) pendant des dizaines d'années.

Merci pour ce commentaire, mais je répète que mon projet actuel dure depuis plus de 5 ans (et ne partait déjà pas de 0 à cette époque) avec 800 ingénieurs dessus, durera encore bien plus longtemps, et qu'il s'agit d'un gros produit pour serveur nécessitant une très haute fiabilité et disponibilité, et devant supporter de très hautes montées en charge.
Il s'enrichit de nombreuses nouvelles fonctionnalités de version en version. La version actuellement en cours de développement repose sur un énorme changement de toute l'infrastructure bas niveau, et ça ne nous empêche pas de maintenir en grande partie les interfaces telles quelles et donc de ne pas avoir à changer quoi que ce soit dans le code haut niveau par rapport à ce changement.

Compares ce qui est comparable, on ne fait pas de modules aussi indépendants sur un projet d'école ou une petite appli maison. Mais vu qu'en milieu professionnel, ce sera forcément demandé un jour ou l'autre, autant savoir que c'est une possibilité concrète et comprendre les mécanismes nécessaires à une telle opération. Sinon, tu ne peux pas considérer que tu as "appris" la programmation modulaire...

Ne pas faire le raccourci "jeune diplômé = noob n'ayant jamais fait autre chose que des projets d'école et petites applis maison", merci. Commence par voir ton projet de liens gigabits saturés embarqués vendu à des milliers d'entreprises avec des centaines de milliers d'utilisateurs l'utilisant tous les jours, et on en reparlera ensuite.

Je n'ai peut-être pas ton expérience, mais je sais ce que c'est qu'un gros projet et comment on gère plusieurs centaines de personnes codant sur le même projet.

[jabbounet]

C'est une impression ou c'etait dans une autre post avant?

[chaplin]

je vois pas ce qu'il y a de mal à un bon vieux "using myModule;" et faire appel aux interfaces de ce module

Peut être aussi que les projets industriels ne veuleut pas s'appuyer sur un éditeur mais davantage sur du standard électronique. C'est un avis, mais comme le dit Mac Lag, le monde embarqué est un monde caché.

La notion d'interface est vraiment générale et n'est pas la propriété unique des langages objets.

[Mac LAK]

Ben en ce moment je travaille sur un projet sur lequel il y a environ 800 ingénieurs depuis un peu plus de 5 ans, et nos modules dépendent les uns des autres.

J'aurais tendance à dire qu'il faudrait aussi voir le niveau (et l'expérience) des ingénieurs en question...

C'est pour ça que je parle aussi en charge plutôt qu'en nombre d'ingénieurs, le boulot abattu par un ingé avec dix ans d'expérience n'a pas grand-chose à voir avec le boulot abattu par un débutant. La charge en question étant bien sûr prévue pour un ingénieur expérimenté.

Pour autant ça va le projet marche de mieux en mieux de version en version, il n'y a eu en 5 ans qu'un seul bug majeur en production et les nombreux clients en sont de plus en plus satisfaits.

Super, content pour vous. Combien de demandes d'évolution spécifiques ? D'ajout de ressources non gérées au départ ? De formats de sortie différents ? Combien de machines impliquées dans le bon fonctionnement de l'application ? Combien de processus en interaction ?
Plus important : Quelle durée de garantie ? De maintenance ? Quelle disponibilité exigée du produit final ?

Au niveau développement : quelles possibilités d'ajout / suppression de ressources / fonctionnalités afin de pouvoir adapter le produit à n'importe quel client ? Peut-on supprimer n'importe quelle fonctionnalité du projet sans conséquences sur les autres ?

J'ai pas dit non plus qu'il fallait faire interagir les modules entre eux n'importe comment hein.

Tentacules = n'importe comment. Si tu ne peux pas séparer un module du projet, c'est mal fait, c'est tout.

C'est bien joli tes #define et #include, mais tout le monde ne fait pas que du C++. Et sans avoir besoin d'utiliser du préprocesseur, je vois pas ce qu'il y a de mal à un bon vieux "using myModule;" et faire appel aux interfaces de ce module, dans n'importe quel autre... le nom du module et ses interfaces, c'est quelque chose que tu définis au début et que tu n'es pas censé changer tous les jours !

Et bien si tu n'as pas accès aux directives de préprocesseur, tu utilises un petit générateur afin de fabriquer le fichier source principal en fonction des modules que tu as décidé d'utiliser... Ou tu passes en plug-ins, ou via des librairies dynamiques / processus autonomes couplés entre eux par enregistrement vers les modules que l'on désire utiliser.
Comme je l'ai dit, des solutions pour séparer réellement les modules, il y en a plein.

Ce qui ne veut pas dire forcément qu'un module totalement coupé des autres est très utile : il est évident qu'un module de construction de requêtes SQL sans un module d'accès à la BD et sans module container pour le retour des données, c'est pas très utile en soi. Toutefois, ça permet au moins les tests (unitaires, non-régression, pré-intégration) de façon totalement automatique, sans aucune interférence possible. La moindre des choses pour tester les cas nominaux, ainsi que les cas dégradés attendus et prévus.

Ah bon. Donc tu es en train de dire qu'à la première évolution majeure du projet, il faut casser toutes les interfaces abstraites ? Je sais pas comment tu les conçois tes évolutions de projet...

Si ton code est tentaculaire ? Oui. Du moins, sur une évolution majeure.
Sur une mineure, c'est souvent pire : ça vire au patch, dans un code tentaculaire...

De plus, la règle numéro un des évolutions de projet, c'est de n'avoir jamais de régression.

J'imagine bien le bronx que ça peut faire... La rétrocompatibilité absolue, c'est très bien, mais c'est rarement un facteur de propreté du code.

Nous, on assure le maintien de la fonction, macroscopiquement parlant, et tout ce que le client a pu faire lui-même (scripts, contenu des BD, fichiers de configuration, etc.). Si une évolution demande un fonctionnement différent sur la nouvelle version, on l'impose.

Dans tous les cas, si tes interfaces ont été bien conçues dès le départ, tu n'auras jamais besoin de casser des interfaces existentes, juste de les enrichir ou en ajouter de nouvelles pour faire appel aux nouveaux modules ou aux nouvelles fonctionnalités des anciens modules.

Bien sûr. Et tu fais comment avec du code tentaculaire, lorsque tu passes au travers de deux ou trois couches abstraites modifiées ?
Ben tu impactes deux ou trois modules sur ta modification, au lieu de simplement changer le "câblage logique" des modules entre eux.

Merci pour ce commentaire, mais je répète que mon projet actuel dure depuis plus de 5 ans (et ne partait déjà pas de 0 à cette époque) avec 800 ingénieurs dessus, durera encore bien plus longtemps, et qu'il s'agit d'un gros produit pour serveur nécessitant une très haute fiabilité et disponibilité, et devant supporter de très hautes montées en charge.

Et ils l'ont fait en Java ? C'est ... courageux, quand on cherche les performances et la montée en charge.

La version actuellement en cours de développement repose sur un énorme changement de toute l'infrastructure bas niveau

Je dois traduire ça en "le projet n'arrivait plus à des performances correctes sur le matos actuel, donc on passe sur des machines de monstre pour tenir les perfos" ?

Ne pas faire le raccourci "jeune diplômé = noob n'ayant jamais fait autre chose que des projets d'école et petites applis maison", merci.

C'est pourtant souvent le cas... Ce sont les exceptions qui sont rares.
Soyons par contre clairs sur un point : je n'ai rien contre les débutants, ni contre le fait de les former. Par contre, le débutant qui croit tout savoir et qui vient tenter de m'expliquer mon métier, j'apprécie moyen.

Commence par voir ton projet de liens gigabits saturés embarqués vendu à des milliers d'entreprises avec des centaines de milliers d'utilisateurs l'utilisant tous les jours, et on en reparlera ensuite.

Oh, j'ai mieux : c'est notamment grâce à nous (et aux industriels dans le même secteur que nous) que les avions volent sans se vautrer au moindre pépin, que les trains ne déraillent pas, et que ta voiture fonctionne sans te péter le jonc.
T'as des centaines de milliers d'utilisateurs ? Super, c'est très bien pour ta boite, et c'est sincère.

Tu m'excuseras si on n'a que des MILLIONS de gens dont la vie dépend directement ou indirectement de notre boulot, à chaque fois qu'ils prennent l'avion, le train ou leur voiture ?

Je n'ai peut-être pas ton expérience, mais je sais ce que c'est qu'un gros projet et comment on gère plusieurs centaines de personnes codant sur le même projet.

Mais tu n'as pas idée des conséquences sur la vie humaine de certains projets, manifestement...

Tu as l'air de prendre de haut le fait d'avoir des liens gigabit saturés : mais as-tu simplement conscience du volume de données qui transite dans un avion, ou un train ? Que notre boulot, c'est de TOUTES les chopper, les traiter, les interpréter et ceci sans avoir droit à la moindre erreur ?

Parce que si tu n'as jamais réussi à mettre un lien gigabit au taquet avec un soi-disant "serveur hautes performances", c'est bien triste... Ou on n'a définitivement pas la même conception de ce qu'est un "gros volume de données". Tout comme on n'a pas la même notion de "disponibilité", de "performances", ou de "sûreté de fonctionnement".

C'est une impression ou c'etait dans une autre post avant?

Ce n'est pas une impression.

Peut être aussi que les projets industriels ne veuleut pas s'appuyer sur un éditeur mais davantage sur du standard électronique. C'est un avis, mais comme le dit Mac Lag, le monde embarqué est un monde caché.

Effectivement caché, et pourtant crucial... Quant à "faire confiance", on commence en général à avoir confiance dans une technologie quand elle a été plus que largement éprouvée et fiabilisée.

Comme je l'ai dit, en embarqué, on a souvent au bout du compte la sécurité des biens et/ou la vie des personnes qui sont en jeu. Cela n'incite pas à faire n'importe quoi n'importe comment.

[simcoin]

Oh, j'ai mieux : c'est notamment grâce à nous (et aux industriels dans le même secteur que nous) que les avions volent sans se vautrer au moindre pépin, que les trains ne déraillent pas, et que ta voiture fonctionne sans te péter le jonc.
T'as des centaines de milliers d'utilisateurs ? Super, c'est très bien pour ta boite, et c'est sincère.

Tu m'excuseras si on n'a que des MILLIONS de gens dont la vie dépend directement ou indirectement de notre boulot, à chaque fois qu'ils prennent l'avion, le train ou leur voiture ?

Mais tu n'as pas idée des conséquences sur la vie humaine de certains projets, manifestement...

Tu as l'air de prendre de haut le fait d'avoir des liens gigabit saturés : mais as-tu simplement conscience du volume de données qui transite dans un avion, ou un train ? Que notre boulot, c'est de TOUTES les chopper, les traiter, les interpréter et ceci sans avoir droit à la moindre erreur ?

Parce que si tu n'as jamais réussi à mettre un lien gigabit au taquet avec un soi-disant "serveur hautes performances", c'est bien triste... Ou on n'a définitivement pas la même conception de ce qu'est un "gros volume de données". Tout comme on n'a pas la même notion de "disponibilité", de "performances", ou de "sûreté de fonctionnement".

Heureusement qu'il existe des vétérans du C/C++ qui maîtrisent à la perfection l'utilisation des macros et l'optimisation des boucles for, sans jamais faire d'erreur, pour permettre aux avions de voler (mais pourquoi un tel débit dans un avion, c'est quel type de réseau qui est embarqué là ?) ou aux trains de rouler, sans quoi le monde serait bien différent...

Le problème reste de trouver des gens assez compétents et expérimentés pour reprendre et maintenir de tels joyaux du code, parce qu'au train où vont les choses tout le monde fait du java ou du C# (j'aime pas spécialement ces langages mais faut accepter les faits) voire du php, donc les futurs génies du C vont se faire très rares...

Après peut-être que certains langages haut niveau permettent de simplifier ce genre de choses,sans impact notable sur les performances, le tout avec une syntaxe plus agréable, mais pourquoi changer ses habitudes ?

[jabbounet]

Heureusement qu'il existe des vétérans du C/C++ qui maîtrisent à la perfection l'utilisation des macros et l'optimisation des boucles for, sans jamais faire d'erreur, pour permettre aux avions de voler (mais pourquoi un tel débit dans un avion, c'est quel type de réseau qui est embarqué là ?) ou aux trains de rouler, sans quoi le monde serait bien différent...

pour les avions je ne sais pas, mais de mémoire pour les train y'avait du FIPS du CAN, et maintenat je crois que c'est du MVB (Multifunction Vehicle Bus)

Le problème reste de trouver des gens assez compétents et expérimentés pour reprendre et maintenir de tels joyaux du code, parce qu'au train où vont les choses tout le monde fait du java ou du C# (j'aime pas spécialement ces langages mais faut accepter les faits) voire du php, donc les futurs génies du C vont se faire très rares...

C'est un peu le même souci avec les compétences cobol/mainframe je pense, ce qui est rare deviendra cher

Après peut-être que certains langages haut niveau permettent de simplifier ce genre de choses,sans impact notable sur les performances, le tout avec une syntaxe plus agréable, mais pourquoi changer ses habitudes ?

pour etre embarqué dans les parties critiques il faut passer tout un tas de certifications tant pour le materiel que pour le logiciel.

exemple:
SIL4
http://www.surete-fonctionnement.cle...-ils/#more-188
DO-178B
http://fr.wikipedia.org/wiki/DO-178B

Ces certificaiton imposent notament d'etre capable de maitriser ce qu'il se passe dans la mémoire (allocation, desallocation). donc on se retrouve souvent avec une interdiction d'utilisation d'allocation dynamique par exemple.

Et sans allocation dynamique cela deviens difficile de faire du java par exemple.

C'est aussi pour cela que tu n'aura jamais le dernier processeur Intel ou AMD dans tes trains car le passage d'une certification pour un processeur prend du temps, il faut connaitre son comportement et ses bug de manière assez précise ce qui implique d'attendre quelques année et d'avoir les retour utilisateur (grand public).

en gros les développeur de nouvelle technos sont potentiellement les bêta testeur des technos embarquée de demain ou après demain (mais pas forcement si la techno est jugée trop bancale pour pouvoir la certifier).

[ZoinX]

J'aurais tendance à dire qu'il faudrait aussi voir le niveau (et l'expérience) des ingénieurs en question...

C'est pour ça que je parle aussi en charge plutôt qu'en nombre d'ingénieurs, le boulot abattu par un ingé avec dix ans d'expérience n'a pas grand-chose à voir avec le boulot abattu par un débutant. La charge en question étant bien sûr prévue pour un ingénieur expérimenté.

Ben peut-être que chez toi il est courant d'embaucher 800 débutants et les mettre tous ensemble sur un projet, mais dans le monde courant il existe la notion de hiérarchie, à savoir qu'il y a un développeur avec 10+ années d'expérience pour 2 ou 3 développeurs moins expérimentés.
Et je te rassure, dans cette boite on n'embauche pas n'importe qui, le processus de recrutement est très très exigent.

Super, content pour vous. Combien de demandes d'évolution spécifiques ? D'ajout de ressources non gérées au départ ? De formats de sortie différents ? Combien de machines impliquées dans le bon fonctionnement de l'application ? Combien de processus en interaction ?
Plus important : Quelle durée de garantie ? De maintenance ? Quelle disponibilité exigée du produit final ?

Les clients sont régulièrement interrogés pour leur demander les évolutions les plus importantes selon eux, et les évolutions les plus demandées pondérées par leur coût en temps de développement sont celles apportées en priorité, tout simplement, que la possibilité d'évolution ait été initialement prévue ou non.

Le produit est vendu avec un support de 7 ans extensible à 12 ans, et la disponibilité du produit final est assurée majoritairement par le hardware, comme c'est toujours le cas pour tous les produits serveur... Le hardware étant beaucoup plus défaillant que le soft dans le cas des serveurs, la disponibilité est bien évidemment assurée par de la réplication et du load balancing.

Le nombre de machines impliquées dans le bon fonctionnement est complètement adaptable selon les besoins du client : ça peut aller d'une seule machine faisant tout tourner (ou seulement une partie, tout n'est pas obligatoire), à des dizaines de sites avec des dizaines de clusters de dizaines de machines assumant les dizaines de rôles différents. Le client choisit le hardware qu'il veut en fonction de la charge qu'il a besoin de supporter. Quant au nombre de processus, tu multiplies le nombre de machines par 5 et on approche du compte.

Au niveau développement : quelles possibilités d'ajout / suppression de ressources / fonctionnalités afin de pouvoir adapter le produit à n'importe quel client ? Peut-on supprimer n'importe quelle fonctionnalité du projet sans conséquences sur les autres ?

Avec le nombre de clients qu'on a, on va sûrement pas s'amuser à adapter le produit à chaque client séparément... on prend en compte la moyenne des demandes de tous.

De plus, un produit bien conçu c'est pas un produit qu'on peut modifier facilement selon les besoins du client, c'est un produit suffisamment large et souple pour pouvoir lui-même convenir aux besoins de nombreux clients.

Supprimer des fonctionnalités, faudra m'expliquer l'intérêt... Un produit bien conçu te propose *évidemment* de choisir de manière suffisamment fine quelles fonctionnalités tu veux installer/activer, à toi de choisir lesquelles t'intéressent. Mais retirer des fonctionnalités du code c'est juste idiot.

Tentacules = n'importe comment. Si tu ne peux pas séparer un module du projet, c'est mal fait, c'est tout.

Si tu peux séparer un module du projet, c'est pas un module mais un projet différent, c'est tout.

Ce qui ne veut pas dire forcément qu'un module totalement coupé des autres est très utile : il est évident qu'un module de construction de requêtes SQL sans un module d'accès à la BD et sans module container pour le retour des données, c'est pas très utile en soi. Toutefois, ça permet au moins les tests (unitaires, non-régression, pré-intégration) de façon totalement automatique, sans aucune interférence possible. La moindre des choses pour tester les cas nominaux, ainsi que les cas dégradés attendus et prévus.

C'est pas parce qu'un module coupé des autres ne pourra pas fonctionner normalement dans les conditions de production qu'il est impossible de le tester seul... c'est justement la définition des tests unitaires !

Si ton code est tentaculaire ? Oui. Du moins, sur une évolution majeure.
Sur une mineure, c'est souvent pire : ça vire au patch, dans un code tentaculaire...

Bah écoute ces derniers mois toute l'architecture de bas niveau pour la gestion des données et des communications entre clusters a été refaite, les changements de code sur la partie haut niveau se comptent seulement en dizaines de lignes, ça va c'est encore gérable !

J'imagine bien le bronx que ça peut faire... La rétrocompatibilité absolue, c'est très bien, mais c'est rarement un facteur de propreté du code.

Nous, on assure le maintien de la fonction, macroscopiquement parlant, et tout ce que le client a pu faire lui-même (scripts, contenu des BD, fichiers de configuration, etc.). Si une évolution demande un fonctionnement différent sur la nouvelle version, on l'impose.

Je vois pas le rapport entre rétrocompatibilité et non-régression, ça n'a juste rien à voir. La rétrocompatibilité c'est par exemple rendre le nouveau serveur compatible avec les anciens clients ou inversement. Et ce n'est pas nécessaire d'assurer une rétrocompatibilité absolue si les évolutions justifient cela.

La non-régression ça n'a rien à voir, c'est ne pas retirer d'anciennes fonctionnalités à moins qu'elles soient rendus obsolètes par les nouvelles. Et il n'y a généralement pas de bonne raison de faire de la régression.

Bien sûr. Et tu fais comment avec du code tentaculaire, lorsque tu passes au travers de deux ou trois couches abstraites modifiées ?
Ben tu impactes deux ou trois modules sur ta modification, au lieu de simplement changer le "câblage logique" des modules entre eux.

Toi qui bosses sur des réseaux gigabit, tu dois bien connaitre le principe des couches réseau ? Ben les projets en général c'est exactement pareil, un module n'a besoin de s'appuyer que sur les modules de la couche d'en dessous, il a pas besoin de se taper toutes les couches d'abstraction jusqu'en bas. Donc je vois pas pourquoi il y en aurait deux ou trois de modifiées... Un module dépendant d'un autre, c'est UNE couche d'interface abstraite / API.

Et ils l'ont fait en Java ? C'est ... courageux, quand on cherche les performances et la montée en charge.

Non, en C#. Seule une toute petite partie (moins de 5%) est codée en unmanaged (en C++), et le code nécessitant les performances et la montée en charge est très loin de se limiter à ces seuls 5%.
Pour autant, ça n'empêche pas de supporter des dizaines de milliers de communications clients/serveur simultanées par machine déployée dans le cluster.

Si le projet était entièrement codé en bas niveau, peut-être bien qu'il pourrait supporter deux fois plus de charge, mais il n'aurait pas le quart des fonctionnalités qu'il a, ou alors il serait vendu quatre fois plus cher pour compenser le nombre de codeurs supplémentaires nécessaires.

Et avant que tu me répondes que doubler la puissance du hardware coute moins cher que quadrupler le coût de développement, réfléchis bien au fait qu'il n'y a pas que de l'embarqué dans la vie. Un serveur high-end typique ne coûte absolument rien.
(C'est d'ailleurs la raison principale pour laquelle notre produit a beaucoup de succès : parce qu'il tourne entièrement en software sur du hardware standard, là ou les solutions des concurrents coutent 20 fois plus cher à cause du hardware spécialisé requis.)

Je dois traduire ça en "le projet n'arrivait plus à des performances correctes sur le matos actuel, donc on passe sur des machines de monstre pour tenir les perfos" ?

Je ne voulais pas parler de hardware, mais des couches bas niveau de gestion des données et communications entre machines du cluster. Tu peux traduire ça en "l'ancienne couche ne satisfaisait plus les nouvelles contraintes apportées par les nouvelles fonctionnalités à implémenter, donc on passe un peu de temps à refaire une couche bas niveau spécifiquement adaptée aux besoins du produit à la place de l'ancienne couche toute prête".

C'est pourtant souvent le cas... Ce sont les exceptions qui sont rares.
Soyons par contre clairs sur un point : je n'ai rien contre les débutants, ni contre le fait de les former. Par contre, le débutant qui croit tout savoir et qui vient tenter de m'expliquer mon métier, j'apprécie moyen.

Tout à fait d'accord avec toi. Je suis tout à fait conscient de mon manque d'expérience et je ne prétends pas apprendre la vie à un développeur expérimenté. D'un autre côté, je sais aussi que dans 10 ans je ne dénigrerai pas gratuitement des débutants en prétendant avoir toujours raison par rapport à eux.

Par contre je sais faire preuve de bon sens, et quand un raisonnement semble stupide il y a de bonnes chances pour qu'il le soit en effet. Quand en plus des dizaines de gens bien plus expérimentés que moi sont d'accord avec moi sur un point précis et que le succès du projet sur lequel je travaille est un exemple flagrant de programmation modulaire bien maitrisée, j'ai de bonnes raisons d'être confiant dans mon argumentation.

Tu as l'air de prendre de haut le fait d'avoir des liens gigabit saturés :

Non, c'était juste une riposte gratuite à ta prise de haut de mes "projets d'école". Je respecte ton travail et je ne doute pas que tu fasses du très bon boulot, et je ne doute pas non plus que dans le domaine de l'embarqué il soit nécessaire de programmer à ta manière.

Par contre il ne faudrait pas oublier que l'embarqué ne représente qu'une maigre portion des projets d'informatique, et que ce qui est vrai dans le monde de l'embarqué ne l'est pas forcément ailleurs. En particulier,

- du hardware serveur standard coute infiniment moins cher que du temps de développement et des développeurs.

- il est peut-être nécessaire dans l'embarqué d'avoir des modules complètement indépendants les uns des autres sans la moindre dépendance, pour des raisons de fiabilité je suppose. Mais ailleurs, ce sont les contraintes humaines et économiques qui prévalent, et celles-ci imposent notamment d'avoir des modules correspondant à un découpage logique et intuitif des fonctionnalités et/ou domaines du produit, c'est nécessaire pour la lisibilité et la compréhension du projet.

Parce que si tu n'as jamais réussi à mettre un lien gigabit au taquet avec un soi-disant "serveur hautes performances", c'est bien triste... Ou on n'a définitivement pas la même conception de ce qu'est un "gros volume de données". Tout comme on n'a pas la même notion de "disponibilité", de "performances", ou de "sûreté de fonctionnement".

T'inquiètes pas, même en C# on peut gérer des dizaines de milliers de communications simultanées par machine, et ça peut aller largement au delà des 10 Gbits

[simcoin]

[...]on se retrouve souvent avec une interdiction d'utilisation d'allocation dynamique par exemple.

Et sans allocation dynamique cela deviens difficile de faire du java par exemple.

Oui bien sûr, on ne va pas embarquer du java ni du C# (en plus faudrait embarquer la VM ou l'environnement .Net, ça rajoute du poids conséquent), et encore moins du php
Je pensais plutôt à des langages compilés genre ADA (qui de plus encourage l'écriture de code robuste), moins bordéliques que le C/C++ et un peu plus haut niveau...
Bon évidemment il y a également peu de gens compétents en ADA, parce que c'est plus à la mode.

[alex_pi]

Oui bien sûr, on ne va pas embarquer du java

http://java.sun.com/javacard/

[jabbounet]

Oui bien sûr, on ne va pas embarquer du java ni du C# (en plus faudrait embarquer la VM ou l'environnement .Net, ça rajoute du poids conséquent), et encore moins du php
Je pensais plutôt à des langages compilés genre ADA (qui de plus encourage l'écriture de code robuste), moins bordéliques que le C/C++ et un peu plus haut niveau...
Bon évidemment il y a également peu de gens compétents en ADA, parce que c'est plus à la mode.

Ada est utilisé dans le ferroviaire embarqué (il a les certifications qui vont bien) et très certainement dans l'aéronautique et le nucléaire.


j'ai même développé (il y'a quelques années déjà) une partie de soft pour un calculateur chargé d'assurer la sureté de fonctionnement pour une ligne automatisé de métro, et là on utilisait un sous ensemble de Ada83 et des instructions spécifiquement développés pour interagir avec un processeur codé dont le but était de vérifier que le code ne partais pas en sucette.

concernant le processeur codé une petite explication du principe ici:
http://www.metro-pole.net/expl/sacem/ch04.htm

[davcha]

J'ai deux petites questions.

1 - qui a la plus grosse, alors ? Mac LAK ou ZoinX ?
2 - comment vous rendez deux modules totalement indépendants, quand l'un utilise les données générées par l'autre ?