Discussion :

[Mac LAK]

Si on a deux classes qui sont tellement liees qu'utiliser une sans utiliser l'autre n'a pas de sens, on les mets dans le meme entete qu'on nomme correctement. C'est la solution non proposee

Je l'ai abordée indirectement, via l'utilisation d'une classe-mère servant à masquer le pointeur privé via polymorphisme... Et qui évite, au passage, toute déclaration anticipée.

[koala01]

Makefiles et projets Visual, oui. On ne va pas non plus taper les commandes de compilation à la main, hein...

Tu me rassures

C'est justement là le souci : les conflits de mises à jour / corrections / ajouts... Les dépendances internes posent de gros soucis, car il est déjà arrivé d'avoir des recompilations abusives (inclusions de .H qui n'avaient rien à foutre là), et aussi des recompilations manquantes (la "bonne compilation" d'un bidule dépendait de l'ordre d'inclusion dans le CPP du .H en question...).

Comme je l'ai dit, il serait bon de ne pas mélanger deux débats ici:

Nous parlons ici d'inclusions circulaires, et non d'inclusions "en cascade" (et dans un certain ordre)...

Je n'imaginerais effectivement pas la création d'un en-tête qui fasse explicitement référence à, mettons <limits> sans l'inclure directement dans l'en-tête, mais d'un autre coté, si, en interne, j'utilise std::limits<>, je ne vois absolument pas de raisons de forcer la dépendance pour tous les fichiers qui utiliseront mon en-tête perso

Mais c'est un aure débat

Faut le vivre pour le comprendre, je pense...
Classe privée = classe invisible et inconnue, ça c'est le secret du bonheur...

Ca peut effectivement être le secret du bonheur... dans le cadre d'une inclusion "en cascade", mais pas forcément dans celui d'une inclusion circulaire

Le débat est, encore une fois, tout autre

Oui, en effet. Sachant que tu passes souvent de l'un à l'autre en fonction des besoins et de la charge, ce qui biaise fortement ta vue "concepteur" et ta vue "utilisateur", car tu fais aussi souvent l'un que l'autre.

Je ne nie absolument pas qu'on passe son temps à se balader entre les deux mondes...

Et c'est justement pour cela que j'insiste sur le fait que la documentation utilisateur est particulièrement importante: l'information "glanée" en tant qu'utilisateur aura des répercussions importantes sur ton travail de conception...

Mais, c'est en tant qu'utilisateur que tu aborde généralement une bibliothèque ou un projet externe

Il ne devrait même pas être autorisé qu'une librairie dépende d'une autre de façon "planquée"... La référence devrait impérativement être publique, ne serait-ce que pour permettre l'utilisation d'un stub si besoin.

là, nous entrons dans un autre débat

Quelle documentation ? Le commentaire au fin fond du .CPP ?
Module interne = pas d'autre doc que les commentaires la plupart du temps... Ou, pire, la doc existe mais c'est la croix et la bannière pour retrouver dans QUEL projet elle était incluse !!!

La documentation utilisateur...

Celle qui me donne la liste des fonctions et des structures auxquelles j'ai accès et leur utilité.

Bref, la documentation minimale à laquelle j'estime avoir droit lorsque je me procure un projet ou une bibliothèque en vue d'utilisation de celui-ci

Sur le projet complet, oui, bien entendu.

ouf... tu me rassures encore

Sur les modules internes plus ou moins réutilisés à chaque projet, non : pas de crédits pour ça. Donc, soit tu épluches les docs du projet précédent (et tu te fais engueuler, en admettant que tu y aie accès !!), soit tu lis les commentaires du code (enfin... ce qui sert de commentaire) qui incluent rarement ce genre d'information.

Et c'est là qu'entre en jeu... la documentation utilisateur...

Tu ne peux en effet absolument pas envisager d'utiliser un module si, tout ce que tu sais sur lui, c'est "ce module permet tel types de manipulation" mais que tu ignore complètement les fonctions qu'il te fournit pour effectuer ces manipulation

Et, de même, un module qui ne précise pas dans la documentation utilisateur qu'il nécessite, pour son usage interne, la liaison avec une bibliothèque tierce est, à mon sens, tout à fait inutilisable, en tant qu'utilisateur de ce module...

Si, quand je débarque dans ton entreprise, on me dit "ne te casse pas la tête, on dispose du module machinchose qui fait cela très bien, tu n'a qu'à le réutiliser", il faut bien se douter que la première chose que je ferai, c'est de plonger dans la doc utilisateur, non pas pour connaitre le fonctionnement interne (dont je me fout à la limite royalement), mais pour savoir... comment l'utiliser

C'est rarement autrement en général : la doc n'est faite que si quelqu'un la paie. Je suis le premier à le déplorer, mais c'est hélas courant.

Oui, malheureusement...

Mais c'est un très mauvais calcul... Du moins au niveau de la doc utilisateur

Parce que, si je dois m'amuser, en débarquant dans ton entreprise à parcourir les centaines de fichiers d'en-tête d'un module existant pour savoir comment le réutiliser, je vais perdre bien plus de temps (et donc couter bien plus cher à la boite) que si je peux disposer d'une documentation cohérente sur la manière de l'utiliser

T'as même pas idée à quel point c'est "peu", vu que c'est zéro.

si si, j'ai bien idée

On parie ?

Je reformule:

Avec les outils dont on dispose, si on les utilise à bon escient et qu'on applique une politique cohérente, il doit rester *relativement* simple d'assurer un minimum de cohésion entre les différents modules d'un projet

Et je reconnais que l'idée même de vouloir imposer une politique cohérente revient parfois à se heurter contre un mur

Je sais. Cependant, on a en général les points suivants :

• Le commercial vend au plus juste, quitte à ne pas tenir compte du chiffrage des techniques.
• Le CP ne regarde que SON projet, aucun autre, et se fiche de plomber les autres projets avec du code "bouillasse" tant que SON projet est dans les budgets.
• Les financiers / responsables jouent à la roulette avec la maintenance : si jamais il n'y en a pas besoin, c'est tout bénèf, si jamais y'a des bugs, "on avisera".
• Dans tous les cas, leur montrer les chiffres d'un précédent projet renvoie les réponses "C'était un cas particulier", "On a progressé depuis", "Y'a pas de risques, faut juste adapter le code ('adapter' s'applique par exemple au portage d'une appli Win 3.1 en VB4 vers du Java sous un Linux embarqué, au fait...)", etc. Bref, il n'y a pas pire sourd que celui qui ne veut pas entendre.
• Les dévs doivent réparer toutes ces conneries (dont ils ne sont pourtant pas responsables), et tenir les délais, d'où une impasse sur tout ce qui est maintenabilité ultérieure d'autant plus grande que le projet est à la bourre, et le code "critique"...

C'est une raison de plus pour inciter "les pôôvre malheureux développeurs" à faire front tant au niveau de l'entreprise qu'au niveau global de manière à faire évoluer les mentalités

Et le forum est sans doute l'endroit par excellence pour ce faire

[Mac LAK]

Je n'imaginerais effectivement pas la création d'un en-tête qui fasse explicitement référence à, mettons <limits> sans l'inclure directement dans l'en-tête, mais d'un autre coté, si, en interne, j'utilise std::limits<>, je ne vois absolument pas de raisons de forcer la dépendance pour tous les fichiers qui utiliseront mon en-tête perso

C'est ce que j'appelle "public" et "privé", il est parfois délicat pour le développeur de tracer la ligne entre les deux... Pour ma part, j'ai tendance à partir sur une base de trois fichiers systématiquement :

• L'entête public, ne contenant au départ que les fonctions devant être publiques. Il inclus les entêtes principaux des librairies connues à l'avance comme dépendances.
• L'entête privé, contenant le reste des déclarations, et incluant l'entête public (en début ou fin de fichier, ça dépend...). L'entête privé est destiné exclusivement aux autres CPP du projet, et non pas aux déclarations purement internes au fichier source, qui seront alors dans le fichier source lui-même (ex : variable contenant un singleton par exemple).
• Le CPP, vide, incluant l'entête privé exclusivement.

Ensuite, j'ajoute systématiquement toute nouvelle déclaration dans le CPP en priorité, puis dans l'entête privé, et enfin en dernier recours dans l'entête public (pour les modules utilisateurs de ce que je développe). Tout ajout dans l'entête public étant à priori inutile, je vérifie à chaque fois s'il est judicieux de masquer l'implémentation, d'ajouter un entête public/privé à la place, un entête standard, etc.

Prends ça comme "base" de mes propos quand je parle de public / privé, sinon, effectivement, on ne va jamais réussir à se comprendre...

Celle qui me donne la liste des fonctions et des structures auxquelles j'ai accès et leur utilité.

Yep, le .H principal et la liste des méthodes pour lesquelles tu pries afin que le nom de la fonction soit réellement explicite...

Bref, la documentation minimale à laquelle j'estime avoir droit lorsque je me procure un projet ou une bibliothèque en vue d'utilisation de celui-ci

Oui, tu y as droit. En théorie. En pratique, tu fais du reverse engineering le plus souvent.

Tu ne peux en effet absolument pas envisager d'utiliser un module si, tout ce que tu sais sur lui, c'est "ce module permet tel types de manipulation" mais que tu ignore complètement les fonctions qu'il te fournit pour effectuer ces manipulation

On parie ?
Soyons bien d'accord par contre : je ne cautionne en AUCUN CAS ce genre de "développement", je me contente de le SUBIR. Nuance.
Et mes habitudes de développement sont souvent issues de ces situations bancales (et hélas courantes...), et de tentatives plus ou moins réussies de couper quelques tentacules qui se baladent.

Mais c'est un très mauvais calcul... Du moins au niveau de la doc utilisateur

Tu prêches un converti. Mais il faut faire avec l'existant aussi... Même s'il est crade.

Parce que, si je dois m'amuser, en débarquant dans ton entreprise à parcourir les centaines de fichiers d'en-tête d'un module existant pour savoir comment le réutiliser, je vais perdre bien plus de temps (et donc couter bien plus cher à la boite) que si je peux disposer d'une documentation cohérente sur la manière de l'utiliser

Oui. Mais apparemment, ce calcul n'est pas compréhensible par la plupart des financiers, qui ne voient par exemple AUCUN problème au fait qu'une personne, unique dans la société, détienne dans sa tête des informations cruciales jamais couchées sur papier, qui mettraient en péril le projet (voire la société !!) si jamais il lui arrivait un pépin...

Avec les outils dont on dispose, si on les utilise à bon escient et qu'on applique une politique cohérente, il doit rester *relativement* simple d'assurer un minimum de cohésion entre les différents modules d'un projet

"Politique cohérente" est le point le plus problématique.

Et le forum est sans doute l'endroit par excellence pour ce faire

Les financiers lisent rarement le forum "Langage C++", tu sais...

[koala01]

<snip d'un tas de points sur lesquels nous sommes, d'accord même si on les exprimes différemment >

Les financiers lisent rarement le forum "Langage C++", tu sais...

Non, mes les devs, bien

Et j'ai l'intime conviction que, si les "pôôvres malheureux développeurs" que nous sommes arrivaient à faire front commun afin de faire connaitre et accepter leur point de vue aux "instances supérieures" (à commencer par le chef de projet), il serait possible, sur le long terme d'influer valablement sur la politique de n'importe quelle entreprise...

Si nous donnons aux développeurs des arguments en faveur d'une amélioration de leurs "conditions de travail" (après les avoir convaincus eux-même le cas échéans qu'ils étaient sur "la mauvaise pente"), nous leur donnons la possibilité de rallier leur chef de projet à leur cause.

Les chefs de projets pourront alors eux-même influer valablement sur la politique de communication entre les différentes équipes de développeurs, ce qui sera déjà tout bénéfice (pour les devs) et pourront, une fois convaincus, eux-même défendre certains arguments vis à vis des financiers en leur faisant prendre conscience de la plus value que peut apporter cette meilleure collaboration

Et les financiers pourront eux-même influencer valablement les commerciaux afin qu'ils intègrent le cout de la comm interne comme une constante à ne pas négliger

Il y a deux possibilités pour ébranler une pyramide:

La première est de s'attaquer au sommet, et de détruire l'ensemble des pierres que l'on rencontre, mais, au final, cela prend un temps bête

La deuxième est de s'attaquer à la base, car, dés qu'on l'a suffisamment affaiblie, la pyramide s'effondre comme un château de cartes

Tout cela pour dire qu'une pyramide ne vaut en définitive que par la robustesse de sa base

Aussi, donnons à la base le moyen de devenir plus robuste, cela bénéficiera à l'ensemble de la pyramide que peut représenter une société fournissant des programmes informatiques

Et ce forum est la tribune idéale pour y arriver

[Invité]

Les chefs de projets pourront alors eux-même influer valablement sur la politique de communication entre les différentes équipes de développeurs, ce qui sera déjà tout bénéfice (pour les devs) et pourront, une fois convaincus, eux-même défendre certains arguments vis à vis des financiers en leur faisant prendre conscience de la plus value que peut apporter cette meilleure collaboration

Je ne suis pas certain que tous les financiers ignorent ce problème (ne serait ce que parce qu'un certain nombre d'actionnaires de petites boites de dev sont des développeurs, ou d'anciens développeurs).

Mais, c'est bien plus dur qu'il n'y parait...

D'expérience, pour bien documenter les code, le nettoyer pour pouvoir le garder évolutif, répercuter les améliorations et les trouvailles de part et d'autre, bref, faire évoluer le code "interne", il faut y consacrer entre 20 et 25% du temps consacré au développement. En pratique, ceci signifie une augmentation du budget du projet d'un quart à un tiers...

Le problème, c'est qu'on a rarement la possibilité de facturer de tels prix. Pour une boite qui ferait cela, il y a trois concurrents qui ne le font pas. A ton avis, qui a le marché, à la fin? Donc, le surcout doit être pris sur la marge, et là, c'est marrant, parce que la marge bénéficiaire d'une boite de dev qui va bien, c'est justement 25 à 33% ...

Le deal est donc le suivant : on peut mieux vivre, mais sans marge, et adieu benefs, dividendes (et primes de fin d'années pour les developpeurs... je ne sais pas s'il vont tous te suivre, ou alors juste un an...)... ou continuer comme on fait, ou essayer des demi mesures, qui en général échouent.

Bien sur, ce n'est pas si simple, et certaines boites coupent la poire en deux (surtout s'il y a des dev parmi les financiers...), mais même si elles acceptent de le faire, un second problème se pose...

Les 25-33% de charge supplémentaire, c'est de l'argent, mais c'est aussi des délais. On pourrait le faire en augmentant l'équipe, mais là, on va avoir besoin de davantage de coordination (et donc les couts augmentent encore, et là, les financiers vont dire "pouce!"), alors bon, c'est un délai de livraison retardé...

Du coup, pour bien faire, il faudrait avoir un projet pas trop contraint, ni en terme de budget, ni en terme de temps... Si quelqu'un en connait, j'échange toute info contre votre poids en carambars ou en fraises tagada !

Francois