Discussion :

[Zartan]

Et sur un module réellement transversal, tu fais du code tentaculaire qui référence 200 modules... Et quand tu fais l'arbre d'impact de ta modification, tu pleures.

En admettant que j'ai ajouté un paramètre dans l'interface de mon module de log, là effectivement ça va atteindre tous les fichiers. Ceci dit je ne vais pas être sans ressources, et je peux probablement arriver à m'en sortir.

C'est un problème connu depuis plus de 20 ans, les techniques objets ont en partie été développées pour y pallier. C'est possible d'y remédier en C également, en suivant des règles de conservation assez simples.

Code :

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

1
2
3
4
5
6
7
#define INTERFACE_VERSION 1
struct alpha
{
   int al_version ;
/* éléments */
};

peut être étendue en :

Code :

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

1
2
3
4
5
6
7
#define INTERFACE_VERSION 2
struct beta
{
     struct alpha be_alpha ;
     /* nouveaux éléments */
};

Ca revient à simuler de l'objet en C, la compatibilité avec l'ancien code étant préservée. Je peux donc ajouter autant de paramètres que je veux à partir du moment où je me sers d'un struct pour les interfacer. Les fonctions à paramètres variables sont une autre possibilité.

Code :

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

1
2
3
4
   log(LOG_FILE, "nomfic",
        LOG_MESSAGE, "hello, world",
        LOG_END) ;

peut devenir

Code :

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

1
2
3
4
5
   log(LOG_FILE, "nomfic",
        LOG_MESSAGE, "hello, world",
        LOG_TIME, "18:00",
        LOG_END) ;

Si un paramètre n'est pas indiqué une valeur par défaut lui est attribuée, garantissant encore une fois la compatibilité avec l'ancien code.

Ces techniques et d'autres encore permettent de concevoir ses interfaces avec soin.

Et quand les interfaces sont conçues avec soin l'extension n'est jamais un problème.

Il va sans dire que les méthodes offertes par la POO vont encore plus loin dans ce sens.

[Mac LAK]

En admettant que j'ai ajouté un paramètre dans l'interface de mon module de log, là effectivement ça va atteindre tous les fichiers. Ceci dit je ne vais pas être sans ressources, et je peux probablement arriver à m'en sortir.

Le problème n'est pas "de s'en sortir" : c'est "juste" notre métier de savoir le faire.

Le problème, c'est de le faire vite, sans erreurs et en évitant de devoir revalider l'intégralité du projet jusque dans le moindre recoin... Ce que ne permet pas le code tentaculaire.

Tu comprends mieux ce que je veux te faire comprendre ?

[Zartan]

Tout à fait, si les interfaces sont suffisamment robustes ça ne doit pas poser de problème. C'est effectivement tout le défi du code "tentaculaire" de créer des interfaces correctes.

[souviron34]

Encore une fois, si ton code est propre, ce genre de phrase n'a aucun sens.

absolument, mais de l'autre côté ce débat est sur "comment obtenir", pas sur "on a un code propre"..

il faut arrêter de délirer une étude scientifique reste une étude scientifique c'est tout, l'interprétation qu'on en fait est relative, tu crois à cela de manière absolu ?

Bien sûr que non, mais la limite (même si ce n'est pas 7) n'en est pas moins réelle..

"Overload system"

L'exmple donné par Zartan est simplissime.. Que des choses de premier niveau...

Mais déjà, fonctionner au premier niveau avec 15 ou 20 répertoires indique déjà à mon avis une mauvaise conception.. Des répertoires comme "Ad" ou "Amf" ou "captcha" ne me disent rien du tout, un répertoire "application" !!! c'est pas ce qu'on est en train de regarder, une application ?? Et "crypt" ?? crypter quoi ? A quoi cela s'applique-t-il ?? et quelques autres...

Ceci dit je ne vais pas être sans ressources, et je peux probablement arriver à m'en sortir.

Comme le dit Mac,

Le problème n'est pas "de s'en sortir" : c'est "juste" notre métier de savoir le faire.

Le problème, c'est de le faire vite, sans erreurs et en évitant de devoir revalider l'intégralité du projet jusque dans le moindre recoin...

C'est un problème connu depuis plus de 20 ans, les techniques objets ont en partie été développées pour y pallier.

Mais qu'est-ce que tu crois ???

Que l'objet est la panacée ?? Que tous les "anciens" étaient c.ns ?

Un projet est un projet, quel que soit son langage !!!!


C'est marrant, on dirait une religion ou les communistes (ou ultra-libéraux, pour ne pas faire de jaloux ): "avec l'objet, tous vos problèmes sont résolus" ...

LES PROBLEMES DES PROJETS SONT LES PROBLEMES DES PROJETS....


Un bon architecte en "procédural" fera un bon projet. Un mauvais architecte en objet fera un mauvais projet..

Ca revient à simuler de l'objet en C, la compatibilité avec l'ancien code étant préservée.

Faux..

Les 3 seules possibilités réelles et maintenables de faire quelque chose comme ça serait soit un #ifdef clair et précis :

Code :

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

1
2
3
4
5
6
7
#ifdef VERSION_1
void toto (int A, int B)
#else
#ifdef VERSION_2
void toto (int A, int B, char *Login)
#endif
#endif

car là au moins c'est clair et c'est limité

ou bien :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
typedef union pValue {
      int       iVal ;
      float    fVal ;
      double dVal ;
      char    cVal ;
      char   $sVal ;
} Value ;

typedef struct pParam {
     int    Type ;
     Value Val ;
} Param ;

typedef struct pMaStruct {
     int        VersionNumber ;
     int        NParams ;
     Param *MesParams ;
} MaStruct ;

void toto(MaStruct *MaMienne)

ou encore fonctionner par fonctions enregistrées...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/* Version */
void toto1 (void *Struct)
{
   MaStruct *MaMienne=(MaStruct *)MaMienne ;
   int i,j ;

   i = MaMienne->A ;
   j = MaMienne->B ;
}

/* Version 2 */
void toto2 (void *Struct)
{
   MaStruct *MaMienne=(MaStruct *)MaMienne ;
   int i,j ;
   char *MonLogin ;

   i = MaMienne->A ;
   k = MaMienne->B ;
   MonLogin = MaMienne->Login ;
}
 
......

if ( Version1 )
    RegisterFunction ( ACTION_TOTO, toto1 );
else
if ( Version2)
    RegisterFunction ( ACTION_TOTO, toto2 );
  
....

if ( RegisteredFunction ( ACTION_TOTO ) )
  {
      CallRegisteredFunction ( ACTION_TOTO, (void *)&MaStruct );
  }

qu'on peut aussi décliner avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void toto (void *Struct)
{
   MaStruct *MaMienne=(MaStruct *)MaMienne ;
   int i,j ;
 
   i = MaMienne->A ;
   k = MaMienne->B ;
   if ( MaMienne->Version == 2 )
    {
      char *MonLogin ;

      MonLogin = MaMienne->Login ; 
    }
}
 
......

    RegisterFunction ( ACTION_TOTO, toto );

auquel cas tu peux avoir une version 1 et une version 2 sans changer quoi que ce soit à ton code d'appel... (pour peu que l'on ait placé les fonctions dans un seul module, ou que le module contenant la définiton de la fonction soit dans une biblothèque portant le même nom mais différente suivant le paramètre de link)

Les fonctions à paramètres variables sont une autre possibilité.

A éviter comme la peste....


Dès que tu reprends un code où les paramètres sont variables, le temps passé à comprendre ce qu'ils pourraient être, à quoi ils pourraient servir, et comment on pourrait s'en servir est bien plus lent que d'avoir 5 méthodes avec 5 interfaces...

C'est effectivement tout le défi du code "tentaculaire" de créer des interfaces correctes.

Et comme je l'ai dit plus haut, un code tentaculaire peut tout à fait exister (et c'est même plus courant que le contraire) en objet..

[Furikawari]

absolument, mais de l'autre côté ce débat est sur "comment obtenir", pas sur "on a un code propre"..

J'ai pas l'impression que ce soit le point de vue de Mac. En tout cas, travailler avec du code existant est toujours un problème. Dans tous les cas, commencer par du refactoring (dont l'extraction n'est pas un des moindres aspects) est fondamental. Après quand on intervient en mode pompier avec des délais pas raisonnable on n'a pas forcément le choix , mais ce n'est pas non plus la règle.

[Mac LAK]

Dans tous les cas, commencer par du refactoring (dont l'extraction n'est pas un des moindres aspects) est fondamental.

Jeune idéaliste...

Refactoring ? Sur certains projets, crois-moi, tu auras environ 2 minutes allouées au refactoring, le temps de descendre le projet depuis la gestion de conf.
Et après, tu seras (presque) aimablement prié d'arrêter de tripoter du code qui marche depuis des années, qui a fait ses preuves et en lequel le client a confiance par simple retour d'expérience. Et de te dépêcher d'ajouter la fonction pour laquelle on te paie...

Et même sur les projets que l'on démarre seulement, tu as toujours d'un côté les financiers qui réduisent ton budget de développement (sous la pression des commerciaux qui cassent les prix pour récupérer un marché), et de l'autre le client qui veut un truc répondant à son besoin.
Tu dois donc forcément sacrifier quelque chose pour tenir ton planning : au mieux, c'est la conception (et une pieuvre de code, une !), au pire, c'est la validation (et un projet sous garantie permanente, un !).

Et si vraiment c'est la cata, c'est les deux qui sautent... Essaie de demander 3 mois de dev pour refactoriser ça, tu verras bien comment tu seras reçu dans la plupart des boîtes. Ce n'est hélas pas le monde des Bisounours dehors, la concurrence est souvent féroce.

[el_slapper]

+1 avec Mac Lak.

Les seuls cas ou j'ai vu des gens pouvoir faire du refactoring, c'est quand ils étaient en position de force. Et c'est pas le cas classique. Il m'est arrivé d'en faire quand les délais étaient généreux, mais c'est l'exception, pas la règle.

[Zartan]

Des répertoires comme "Ad" ou "Amf" ou "captcha" ne me disent rien du tout

Les captcha sont les mots déformés que l'on tape pour s'identifier sur un site web.

Les 3 seules possibilités réelles et maintenables de faire quelque chose comme ça serait soit un #ifdef clair et précis

C'est faux, les méthodes que j'ai cité ont été mises au point dans les années 90. Elles ont été utilisées pour interfacer un système d'exploitation. Et cela fonctionnait très bien, des milliers de développeurs les ont utilisées, à chaque fois que le système évoluait, l'ancien code continuait à tourner.

Code :

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

1
2
Dès que tu reprends un code où les paramètres sont variables, le temps passé à comprendre ce qu'ils pourraient être, à quoi ils pourraient servir, et comment on pourrait s'en servir est bien plus lent que d'avoir 5 méthodes avec 5 interfaces...

Ce qu'il faut éviter comme la peste c'est justement de citer les paramètres dans l'interface de la fonction, car cela empêche toute évolution.
On peut également utiliser cette méthode recommandée par B. Meyer

Code :

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

1
2
3
4
5
objet = new Objet() ;
objet->setunparam(unparam) ;
objet->setunautreparam(autreparam) ;
objet->faitquelquechose() ;

Quelle que soit la manière de coder on est bien obligé de se demander ce qu'ils pourraient être et et à quoi ils pourraient servir. Perdre son temps en recherches dénoterait un manque d'outils de documentation.

Un outil moderne de documentation : http://www.javadoconline.com/search....n&class=string

[Furikawari]

Jeune idéaliste...

Refactoring ? Sur certains projets, crois-moi, tu auras environ 2 minutes allouées au refactoring, le temps de descendre le projet depuis la gestion de conf.
Et après, tu seras (presque) aimablement prié d'arrêter de tripoter du code qui marche depuis des années, qui a fait ses preuves et en lequel le client a confiance par simple retour d'expérience. Et de te dépêcher d'ajouter la fonction pour laquelle on te paie...

Et même sur les projets que l'on démarre seulement, tu as toujours d'un côté les financiers qui réduisent ton budget de développement (sous la pression des commerciaux qui cassent les prix pour récupérer un marché), et de l'autre le client qui veut un truc répondant à son besoin.
Tu dois donc forcément sacrifier quelque chose pour tenir ton planning : au mieux, c'est la conception (et une pieuvre de code, une !), au pire, c'est la validation (et un projet sous garantie permanente, un !).

Et si vraiment c'est la cata, c'est les deux qui sautent... Essaie de demander 3 mois de dev pour refactoriser ça, tu verras bien comment tu seras reçu dans la plupart des boîtes. Ce n'est hélas pas le monde des Bisounours dehors, la concurrence est souvent féroce.

Je n'ai pas dit refactoriser par plaisir. J'ai dit refactoriser là où on doit intervenir. Ca n'a rien à voir avec les délais ou je ne sais quoi, ça a à voir avec ta propre méthodologie pour travailler avec du code existant. Evidemment ça demande de la pratique et pour être efficace il faut pratiquer en dehors du contexte professionnel (au moins dans un premier temps).

Pour ce qui est des jugements de valeur à l'emporte pièce, à 4 mois prêts j'ai l'âge que tu affiches sur ton profil. J'espère que ça te fera méditer un peu ...

[Mac LAK]

Je n'ai pas dit refactoriser par plaisir. J'ai dit refactoriser là où on doit intervenir.

Et c'est surtout impossible de le faire "localement" dans un code tentaculaire, ce qui arrive souvent avec une débauche de fichiers...
Sans même parler que si tu es dans une structure un minimum rigide (=application de normes données), tu vas devoir justifier chaque ligne modifiée, et prouver que ça ne change ni l'implémentation, ni les E/S, et que ça continue de respecter la norme.
Je te signale quand même que certaines de ces normes interdisent strictement tout ce qui est pointeurs...

Ca n'a rien à voir avec les délais ou je ne sais quoi, ça a à voir avec ta propre méthodologie pour travailler avec du code existant.

Tout a à voir avec les délais... A part en recherche / veille techno, aucune boîte censée ne te filera un budget illimité pour réaliser une action X ! Tu auras toujours, quoi qu'il arrive, une charge allouée (jours de devs) et une date butoir calendaire pour livrer.

Essaie un jour d'aller expliquer à un client que tu vas avoir un mois de bourre parce que t'as voulu te simplifier la vie, tout en expliquant au contrôleur de gestion pourquoi t'as 30 jours/homme de plus sur la balance et en esquivant la Qualité pour non-respect soit des normes, soit du processus de validation...

Evidemment ça demande de la pratique et pour être efficace il faut pratiquer en dehors du contexte professionnel (au moins dans un premier temps).

Une grosse partie de mon boulot est, justement, la remise à niveau d'ancien code vers des technos / normes / etc. récentes, ainsi que du portage / adaptation / stub de code.

Il n'y a RIEN dans le domaine privé qui puisse te préparer à certaines horreurs / conflits que l'on peut trouver dans le milieu pro "réel"... Sans même parler de la problématique du matériel (que tu n'auras pas à la maison) et qui t'empêchera de tester !

Je te passe bien sûr sur le code obscur que tu serais tenté de remplacer par une variante "propre", jusqu'à ce que tu te rendes compte que ça explose sur certaines plate-formes : j'ai déjà eu la farce avec un code de recopie très laid, remplacé par une copie "propre" qui avait la particularité amusante de crasher en "Bus error" sur des CPU Sparc... Le genre de bug assez mignon à retrouver, surtout en plein milieu d'une cascade de templates C++ imbriqués les uns dans les autres. Au final, obligé de remettre le code "laid", agrémenté toutefois de nouveaux commentaires expliquant le pourquoi du comment...

Pour ce qui est des jugements de valeur à l'emporte pièce, à 4 mois prêts j'ai l'âge que tu affiches sur ton profil. J'espère que ça te fera méditer un peu ...

Quoi que tu dises, ta manière de voir les choses (idéaliste) est proche de celle des débutants (jeunes), lorsqu'ils n'ont pas encore pris conscience de certaines réalités et contraintes.
On peut avoir 60 ans et être "jeune" d'un certain point de vue, comme être "vieux" à 15 ans... Sur ce coup, tu es "jeune" parce que tu sembles penser que le refactoring, c'est simplement utiliser le menu contextuel d'Eclipse sur du code Java bien propre. Et ça, c'est vraiment la poussière au dessus de la partie visible de l'iceberg... Rassures-toi, t'es loin d'être le seul.

Une citation pour la route :
Quelle est la différence entre la théorie et la pratique ?
En théorie, il n'y en a pas. En pratique, si.

A méditer attentivement...

[Furikawari]

Quoi que tu dises, ta manière de voir les choses (idéaliste) est proche de celle des débutants (jeunes), lorsqu'ils n'ont pas encore pris conscience de certaines réalités et contraintes.
On peut avoir 60 ans et être "jeune" d'un certain point de vue, comme être "vieux" à 15 ans... Sur ce coup, tu es "jeune" parce que tu sembles penser que le refactoring, c'est simplement utiliser le menu contextuel d'Eclipse sur du code Java bien propre. Et ça, c'est vraiment la poussière au dessus de la partie visible de l'iceberg... Rassures-toi, t'es loin d'être le seul.

Une citation pour la route :
Quelle est la différence entre la théorie et la pratique ?
En théorie, il n'y en a pas. En pratique, si.

A méditer attentivement...

Ce débat prend une tournure non rationnelle... Encore une fois tu fais preuve de préjugés sans connaître mes antécédents / mon expérience... On arrête là.

[Mac LAK]

Ce débat prend une tournure non rationnelle... Encore une fois tu fais preuve de préjugés sans connaître mes antécédents / mon expérience... On arrête là.

Je me base sur ce que tu écris, comme c'est l'usage et l'habitude sur les forums.

Prendre comme pré-requis un refactoring sur un code tentaculaire, c'est qu'on ne doit vraiment pas avoir la même notion de ce qu'est ce genre de code... Ou que tu n'as vu que des cas "légers" !! Je suis désolé, mais pour moi, ce que tu as écris est aussi idéaliste que de prétendre qu'on peut négocier ses dettes en devenant copain avec son créancier...

Quand à zapper les 3/4 de ma réponse pour te focaliser sur la dernière partie, c'est soit du troll, soit effectivement une attitude "jeune" car tu te vexes sur ce point précis.

[souviron34]

JDans tous les cas, commencer par du refactoring (dont l'extraction n'est pas un des moindres aspects) est fondamental.

Jeune idéaliste...

Refactoring ?

on a déjà eu l'occasion d'en discuter avec Furikawari..

Il est très très très très très rare que l'on soit autorisé/que l'on ait le temps de faire du refactoring..

Et quand c'est le cas, c'est en général parce que l'application marche mais est très vieille, et qu'il n'y a plus la connaissance.. ni la documentation..

Donc on est hors sujet par rapport au thread, car le code qui était peut-être propre au début ne l'est quasiment certainement plus au bout de 5 ans, et ne parlons pas de 20 ou 30 ans......

Les captcha sont les mots déformés que l'on tape pour s'identifier sur un site web.

Qui s'appeleront autrement dans 5 ou 10 ans, faisant perdre toute notion de ce que cache ce répertoire..

C'est faux, les méthodes que j'ai cité ont été mises au point dans les années 90. Elles ont été utilisées pour interfacer un système d'exploitation. Et cela fonctionnait très bien, des milliers de développeurs les ont utilisées, à chaque fois que le système évoluait, l'ancien code continuait à tourner.

Admettons. Mais les OS sont un cas extrêmement particulier des applications...

Ce qu'il faut éviter comme la peste c'est justement de citer les paramètres dans l'interface de la fonction, car cela empêche toute évolution.

On verra ce que tu diras quand tu tomberas sur un code comme ça, dans 15 ans...

Perdre son temps en recherches dénoterait un manque d'outils de documentation.

Un outil moderne de documentation : http://www.javadoconline.com/search....n&class=string

Très bien pour des nouveaux projets..

Mais, de toutes façons, quels que soient les projets et les outils, tu peux être absolument certain que si le soft dure un certain temps, dans 5 ou 7 ans la doc ne sera plus à jour, et dans 10 ans tu ne pourras peut-être même plus relire ce format...

[Tommy31]

Qui s'appeleront autrement dans 5 ou 10 ans, faisant perdre toute notion de ce que cache ce répertoire..

Mmm, je pense pas. Le terme capatcha est bien assis aujourd'hui. D'une part parce que c'est un (retro)-acronyme et d'autre part une marque déposée par l'université Carnegie Mellon (cf wikipedia). Dans le futur, si le terme venait a ne plus être employé, il devrait continuer à faire parti de la culture générale.

[el_slapper]

Mmm, je pense pas. Le terme capatcha est bien assis aujourd'hui. D'une part parce que c'est un (retro)-acronyme et d'autre part une marque déposée par l'université Carnegie Mellon (cf wikipedia). Dans le futur, si le terme venait a ne plus être employé, il devrait continuer à faire parti de la culture générale.

Possible, mais ça reste un risque. Moi, si j'arrive sur ce projet(peu probable, c'est pas mon domaine, mais en SSII, sait-on jamais?), il faudra m'expliquer.

Et puis les termes changent, je me trimballe des données "POL" qui sont des numéros de contrats(avant c'était des polices), des "INTERM" ou des "GES" qui sont des numéros d'agents, des "FORMV" qui sont des tops impression.....tous ces termes avaient un sens clair un précis en 1972, mais moi, j'ai eu beaucoup de mal.

[Tommy31]

Possible, mais ça reste un risque. Moi, si j'arrive sur ce projet(peu probable, c'est pas mon domaine, mais en SSII, sait-on jamais?), il faudra m'expliquer.

Certes. Mais comment aurais-tu appelé ton répertoire alors ?

[Mac LAK]

Certes. Mais comment aurais-tu appelé ton répertoire alors ?

"VisualCryptogram"... On ne te facture pas les noms des répertoires au prix du caractère, quand même.

[Philou67430]

Mmm... en cherchant "Visual Cryptogram" sur internet, on tombe plus facilement sur le code à trois chiffres au dos des cartes bancaires que sur un test automatique de contrôle visuel d'une internaute humain.
Avec Captcha, on sait exactement de quelle fonctionnalité il s'agit.
Là vraiment, je ne te suis pas.

[Mac LAK]

Mmm... en cherchant "Visual Cryptogram" sur internet, on tombe plus facilement sur le code à trois chiffres au dos des cartes bancaires que sur un test automatique de contrôle visuel d'une internaute humain.

Change de moteur de recherche, moi je tombe bien sur une page correcte dans les premiers résultats...

On n'est jamais à l'abri d'un abus de langage. Ce code, normalement, est nommé CVV (Card Verification Value), ce qui n'a absolument rien à voir avec un "cryptogramme visuel"... Ce terme est par contre vastement employé sur le net pour les captcha, que ce soit sur les forums, les mails, etc. et ceci depuis bien avant l'utilisation massive du CVV.

Ceci étant dit, ça, encore, c'est un cas particulier. Le nommage type "Auth" ou "Crypt" est bien plus critique à mon sens... "Auth", c'est quoi ? Author ? Authentification ? Authenticator ? Authentifier ? Authority ?
Idem pour "Crypt", là aussi t'as des tonnes de possibilités rendant l'utilisation d'un simple "Auth" ou "Crypt" ambigu lorsque tu débarques sur ce genre de projet...

[gl]

Juste une petite digression, qui ne change pas grand chose au fond du problème.

Ce code, normalement, est nommé CVV (Card Verification Value), ce qui n'a absolument rien à voir avec un "cryptogramme visuel"...

Non ce n'est pas si simple que ça.

Le terme CVV (en fait CVV2) est le terme employé par Visa. Mastercard utilise le terme de CVC2, American Express utilise CID, 4DBC ou CID/4DBC et le GIE Carte Bancaire emploie pour sa part effectivement plutôt le terme de cryptogramme visuel (mais les anglophones ne comprendront généralement pas le "Visual Cryptogram").