Michael Doubez a écrit :
> On 21 juil, 20:35, Wykaaa wrote:
>> Michael DOUBEZ a écrit :
>>> Wykaaa a écrit :
>>> Donc, point trop n'en faut, utilisons un peu des deux. Mais dans ce c as,
>>> la décision se fait localement en fonction de l'application. Une
>>> ouverture de fichier ratée peut être plausible (ex: abscence de f ichier
>>> pour scanner des emplacements connus de fichier de config) ou être
>>> exceptionnelle (ex: pas les droits, fichier locké) auquel cas
>>> l'application doit prendre la décision.
>>> Pour ces différents cas, qui peut prendre la décision sinon le
>>> programmeur ?
>>> Dans quelle mesure cela est il spécifiable ?
>> Toutes les exceptions survenant lors de la manipulation de fichiers
>> doivent être traitées, la plupart du temps, les cas que tu mention nes
>> peuvent l'être par des exceptions (vois ce qui est fait en Java dans les
>> bibliothèques d'E/S standards).
> Prenons un exemple en Java:
> FileReader in;
> try{
> in = new FileReader(file);
> try{
> // ... read file
> }
> catch(IOException e){
> e.printStack();
> }
> finally{
> in.close();
> }
> }
> catch(FileNotFoundException e)
> {
> // could not open file
> }
> Ce qui est AMA inutilement verbeux (il y a peut être mieux, je n'ai
> pas fait de Java en 10 ans)
> et moins lisible que si je pouvais écrire:
> FileReader in = new FileReader(file);
> if( in.isOpen() ) {
> // error opening file
> }
> // if()...
> input.close();
> }
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
>> Je me rappelle d'une revue de conception dans laquelle nous
>> avions fait des choix concernant certaines exceptions dans un cadre
>> transactionnel. Un spécialiste du transactionnel (qui d'ailleurs
>> n'appartenait pas au projet reviewé), ayant un grand savoir-faire da ns
>> le domaine, nous avait indiqué que nos choix n'étaient pas valides car
>> ils ne permettaient pas de satisfaire les objectifs de performance
>> requis. Ca sert à cela les revues !
> Un spécialiste est bien sûr utile mais je peux aussi aller de mon
> propre chef voir un expert pour lui demander conseil ou alors, il
> aurait pu faire l'audit seul et localiser le problème.
> AMA, une revue de code sers moins à localiser les bugs qu'à confron ter
> les points de vue sur le design dans le cadre d'un projet donc assurer
> une communication de la culture et des savoir faire.
Je ne parle pas de revue de code mais de revue de conception.
Dans une
revue de code, on parle de code, pas de conception et on suppose qu'une
revue de conception a eu lieu (et on dispose de ses conclusions et de
ses "findings").
Remarque : j'ai été formé par Miller lui-même aux revues de code.
>>>> Quand à la réutilisation, on réutilise des modules existants, des
>>>> librairies, etc. via des interfaces qui, normalement, documentent le s
>>>> exceptions pouvant être levées. Si ce n'est pas le cas, cela sig nifie
>>>> que les modules en question ne sont pas réutilisables.
>>> Si il ne sont pas ré-utilisable, alors comment ont ils été util isés en
>>> premier lieu ? :)
>> Heureusement que tu as mis un smiley car tu sais très bien, du moins je
>> l'espère, qu'il y a une grande différence entre des modules qui so nt
>> utilisés spécifiquement dans une application et des modules
>> réutilisables dans différents contextes.
> Oui, c'était une boutade.
> Il y a, AMA, deux raisons majeurs de non ré-utilisation de code:
> 1. Le code n'a pas été utilisé: i.e. il a été conçu d ès le début
> pour être réutilisable sans utilisation pratique pour guider le
> design. C'est le cas des librairies trop générales ou mal conçues .
> 2. La modularisation est moisie: c-à-d que des fonctionnalités
> étrangères au module ont été inséré (souvent suite à un a jout de
> fonctionnalité qui aurait nécessité un refactoring) ou est trop
> spécifique à un environnement (modules spécifiques comme tu le di s).
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect d e l'un des
principes qui sous-tendent la modularité, à savoir le principe de for te
cohérence.
>> C'est la même différence qu'il
>> y a entre une application prototype et l'application finale (le
>> prototype correspond, en général, à 20% du code final...).
> Je ne comprends pas la similarité que tu exposes ici.
Je voulais dire que pour faire d'un module spécifique à une applicati on
un module réutilisable, il y a souvent 80% de travail supplémentaire à
faire sur le module (je me réfère à des études effectuées à l a NASA sur
du code ADA à la fin des années 80. Je n'ai, hélas, plus les réf érences
exactes).
>>>> je suis maintenant à la retraite, mais en suivant cette discussion ,
>>>> j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 4 0 ans !
>>>> C'est vraiment dramatique de rester si longtemps en enfance...
>>> Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de dét erminer
>>> les facteurs de succès et les publier. Chaque projet est différen t et
>>> fonctionne sous des contraintes différentes avec des personnes diff érentes.
>> Il y a des métriques qui existent, y compris pour mesurer le degré de
>> réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet d ans une
>> étude faite pour la DGA et j'ai élaboré des formules, hélas no n
>> publiables car le contrat spécifiait que mon étude devenait propri été de
>> la DGA à l'issue du contrat.
>> J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
>> projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 00 0
>> lignes de C++).
> Ces métrique étaient des mesures absolues ou permettainet elle de
> mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
> Je ne connais pas de mesure absolue applicable d'une équipe à une
> autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
>>> Peut être l'info devrait elle s'inspirer des techniques des science s
>>> sociales pour établir des postulats et ses méthodes.
>> Je ne connais pas les techniques des sciences sociales, je ne connais
>> que les techniques du "software engineering", désolé :-(
> Je pensais aux techniques d'enquète pour déterminer des lois
> empiriques. En fait, c'est ce qui se fait souvent (l'agilité est une
> reconnaissance de certaines valeurs) dans les méthodes modernes
> d'organisation du travail en info par opposition aux méthodes
> classiques scientifique.
Je crains fort que les méthodes "modernes" d'organisation du travail en
info soient en fait un gigantesque retour en arrière sur le mode
"essai/erreur" (si tu parles des méthodes "agiles") alors que les
méthodes classiques "scientifiques" ont largement fait leurs preuves, d u
moins dans mes domaines d'intervention qui sont les systèmes complexes à
logiciel prépondérant.
Michael Doubez a écrit :
> On 21 juil, 20:35, Wykaaa <wyk...@yahoo.fr> wrote:
>> Michael DOUBEZ a écrit :
>>> Wykaaa a écrit :
>>> Donc, point trop n'en faut, utilisons un peu des deux. Mais dans ce c as,
>>> la décision se fait localement en fonction de l'application. Une
>>> ouverture de fichier ratée peut être plausible (ex: abscence de f ichier
>>> pour scanner des emplacements connus de fichier de config) ou être
>>> exceptionnelle (ex: pas les droits, fichier locké) auquel cas
>>> l'application doit prendre la décision.
>>> Pour ces différents cas, qui peut prendre la décision sinon le
>>> programmeur ?
>>> Dans quelle mesure cela est il spécifiable ?
>> Toutes les exceptions survenant lors de la manipulation de fichiers
>> doivent être traitées, la plupart du temps, les cas que tu mention nes
>> peuvent l'être par des exceptions (vois ce qui est fait en Java dans les
>> bibliothèques d'E/S standards).
> Prenons un exemple en Java:
> FileReader in;
> try{
> in = new FileReader(file);
> try{
> // ... read file
> }
> catch(IOException e){
> e.printStack();
> }
> finally{
> in.close();
> }
> }
> catch(FileNotFoundException e)
> {
> // could not open file
> }
> Ce qui est AMA inutilement verbeux (il y a peut être mieux, je n'ai
> pas fait de Java en 10 ans)
> et moins lisible que si je pouvais écrire:
> FileReader in = new FileReader(file);
> if( in.isOpen() ) {
> // error opening file
> }
> // if()...
> input.close();
> }
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
>> Je me rappelle d'une revue de conception dans laquelle nous
>> avions fait des choix concernant certaines exceptions dans un cadre
>> transactionnel. Un spécialiste du transactionnel (qui d'ailleurs
>> n'appartenait pas au projet reviewé), ayant un grand savoir-faire da ns
>> le domaine, nous avait indiqué que nos choix n'étaient pas valides car
>> ils ne permettaient pas de satisfaire les objectifs de performance
>> requis. Ca sert à cela les revues !
> Un spécialiste est bien sûr utile mais je peux aussi aller de mon
> propre chef voir un expert pour lui demander conseil ou alors, il
> aurait pu faire l'audit seul et localiser le problème.
> AMA, une revue de code sers moins à localiser les bugs qu'à confron ter
> les points de vue sur le design dans le cadre d'un projet donc assurer
> une communication de la culture et des savoir faire.
Je ne parle pas de revue de code mais de revue de conception.
Dans une
revue de code, on parle de code, pas de conception et on suppose qu'une
revue de conception a eu lieu (et on dispose de ses conclusions et de
ses "findings").
Remarque : j'ai été formé par Miller lui-même aux revues de code.
>>>> Quand à la réutilisation, on réutilise des modules existants, des
>>>> librairies, etc. via des interfaces qui, normalement, documentent le s
>>>> exceptions pouvant être levées. Si ce n'est pas le cas, cela sig nifie
>>>> que les modules en question ne sont pas réutilisables.
>>> Si il ne sont pas ré-utilisable, alors comment ont ils été util isés en
>>> premier lieu ? :)
>> Heureusement que tu as mis un smiley car tu sais très bien, du moins je
>> l'espère, qu'il y a une grande différence entre des modules qui so nt
>> utilisés spécifiquement dans une application et des modules
>> réutilisables dans différents contextes.
> Oui, c'était une boutade.
> Il y a, AMA, deux raisons majeurs de non ré-utilisation de code:
> 1. Le code n'a pas été utilisé: i.e. il a été conçu d ès le début
> pour être réutilisable sans utilisation pratique pour guider le
> design. C'est le cas des librairies trop générales ou mal conçues .
> 2. La modularisation est moisie: c-à-d que des fonctionnalités
> étrangères au module ont été inséré (souvent suite à un a jout de
> fonctionnalité qui aurait nécessité un refactoring) ou est trop
> spécifique à un environnement (modules spécifiques comme tu le di s).
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect d e l'un des
principes qui sous-tendent la modularité, à savoir le principe de for te
cohérence.
>> C'est la même différence qu'il
>> y a entre une application prototype et l'application finale (le
>> prototype correspond, en général, à 20% du code final...).
> Je ne comprends pas la similarité que tu exposes ici.
Je voulais dire que pour faire d'un module spécifique à une applicati on
un module réutilisable, il y a souvent 80% de travail supplémentaire à
faire sur le module (je me réfère à des études effectuées à l a NASA sur
du code ADA à la fin des années 80. Je n'ai, hélas, plus les réf érences
exactes).
>>>> je suis maintenant à la retraite, mais en suivant cette discussion ,
>>>> j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 4 0 ans !
>>>> C'est vraiment dramatique de rester si longtemps en enfance...
>>> Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de dét erminer
>>> les facteurs de succès et les publier. Chaque projet est différen t et
>>> fonctionne sous des contraintes différentes avec des personnes diff érentes.
>> Il y a des métriques qui existent, y compris pour mesurer le degré de
>> réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet d ans une
>> étude faite pour la DGA et j'ai élaboré des formules, hélas no n
>> publiables car le contrat spécifiait que mon étude devenait propri été de
>> la DGA à l'issue du contrat.
>> J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
>> projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 00 0
>> lignes de C++).
> Ces métrique étaient des mesures absolues ou permettainet elle de
> mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
> Je ne connais pas de mesure absolue applicable d'une équipe à une
> autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
>>> Peut être l'info devrait elle s'inspirer des techniques des science s
>>> sociales pour établir des postulats et ses méthodes.
>> Je ne connais pas les techniques des sciences sociales, je ne connais
>> que les techniques du "software engineering", désolé :-(
> Je pensais aux techniques d'enquète pour déterminer des lois
> empiriques. En fait, c'est ce qui se fait souvent (l'agilité est une
> reconnaissance de certaines valeurs) dans les méthodes modernes
> d'organisation du travail en info par opposition aux méthodes
> classiques scientifique.
Je crains fort que les méthodes "modernes" d'organisation du travail en
info soient en fait un gigantesque retour en arrière sur le mode
"essai/erreur" (si tu parles des méthodes "agiles") alors que les
méthodes classiques "scientifiques" ont largement fait leurs preuves, d u
moins dans mes domaines d'intervention qui sont les systèmes complexes à
logiciel prépondérant.
Michael Doubez a écrit :
> On 21 juil, 20:35, Wykaaa wrote:
>> Michael DOUBEZ a écrit :
>>> Wykaaa a écrit :
>>> Donc, point trop n'en faut, utilisons un peu des deux. Mais dans ce c as,
>>> la décision se fait localement en fonction de l'application. Une
>>> ouverture de fichier ratée peut être plausible (ex: abscence de f ichier
>>> pour scanner des emplacements connus de fichier de config) ou être
>>> exceptionnelle (ex: pas les droits, fichier locké) auquel cas
>>> l'application doit prendre la décision.
>>> Pour ces différents cas, qui peut prendre la décision sinon le
>>> programmeur ?
>>> Dans quelle mesure cela est il spécifiable ?
>> Toutes les exceptions survenant lors de la manipulation de fichiers
>> doivent être traitées, la plupart du temps, les cas que tu mention nes
>> peuvent l'être par des exceptions (vois ce qui est fait en Java dans les
>> bibliothèques d'E/S standards).
> Prenons un exemple en Java:
> FileReader in;
> try{
> in = new FileReader(file);
> try{
> // ... read file
> }
> catch(IOException e){
> e.printStack();
> }
> finally{
> in.close();
> }
> }
> catch(FileNotFoundException e)
> {
> // could not open file
> }
> Ce qui est AMA inutilement verbeux (il y a peut être mieux, je n'ai
> pas fait de Java en 10 ans)
> et moins lisible que si je pouvais écrire:
> FileReader in = new FileReader(file);
> if( in.isOpen() ) {
> // error opening file
> }
> // if()...
> input.close();
> }
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
>> Je me rappelle d'une revue de conception dans laquelle nous
>> avions fait des choix concernant certaines exceptions dans un cadre
>> transactionnel. Un spécialiste du transactionnel (qui d'ailleurs
>> n'appartenait pas au projet reviewé), ayant un grand savoir-faire da ns
>> le domaine, nous avait indiqué que nos choix n'étaient pas valides car
>> ils ne permettaient pas de satisfaire les objectifs de performance
>> requis. Ca sert à cela les revues !
> Un spécialiste est bien sûr utile mais je peux aussi aller de mon
> propre chef voir un expert pour lui demander conseil ou alors, il
> aurait pu faire l'audit seul et localiser le problème.
> AMA, une revue de code sers moins à localiser les bugs qu'à confron ter
> les points de vue sur le design dans le cadre d'un projet donc assurer
> une communication de la culture et des savoir faire.
Je ne parle pas de revue de code mais de revue de conception.
Dans une
revue de code, on parle de code, pas de conception et on suppose qu'une
revue de conception a eu lieu (et on dispose de ses conclusions et de
ses "findings").
Remarque : j'ai été formé par Miller lui-même aux revues de code.
>>>> Quand à la réutilisation, on réutilise des modules existants, des
>>>> librairies, etc. via des interfaces qui, normalement, documentent le s
>>>> exceptions pouvant être levées. Si ce n'est pas le cas, cela sig nifie
>>>> que les modules en question ne sont pas réutilisables.
>>> Si il ne sont pas ré-utilisable, alors comment ont ils été util isés en
>>> premier lieu ? :)
>> Heureusement que tu as mis un smiley car tu sais très bien, du moins je
>> l'espère, qu'il y a une grande différence entre des modules qui so nt
>> utilisés spécifiquement dans une application et des modules
>> réutilisables dans différents contextes.
> Oui, c'était une boutade.
> Il y a, AMA, deux raisons majeurs de non ré-utilisation de code:
> 1. Le code n'a pas été utilisé: i.e. il a été conçu d ès le début
> pour être réutilisable sans utilisation pratique pour guider le
> design. C'est le cas des librairies trop générales ou mal conçues .
> 2. La modularisation est moisie: c-à-d que des fonctionnalités
> étrangères au module ont été inséré (souvent suite à un a jout de
> fonctionnalité qui aurait nécessité un refactoring) ou est trop
> spécifique à un environnement (modules spécifiques comme tu le di s).
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect d e l'un des
principes qui sous-tendent la modularité, à savoir le principe de for te
cohérence.
>> C'est la même différence qu'il
>> y a entre une application prototype et l'application finale (le
>> prototype correspond, en général, à 20% du code final...).
> Je ne comprends pas la similarité que tu exposes ici.
Je voulais dire que pour faire d'un module spécifique à une applicati on
un module réutilisable, il y a souvent 80% de travail supplémentaire à
faire sur le module (je me réfère à des études effectuées à l a NASA sur
du code ADA à la fin des années 80. Je n'ai, hélas, plus les réf érences
exactes).
>>>> je suis maintenant à la retraite, mais en suivant cette discussion ,
>>>> j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 4 0 ans !
>>>> C'est vraiment dramatique de rester si longtemps en enfance...
>>> Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de dét erminer
>>> les facteurs de succès et les publier. Chaque projet est différen t et
>>> fonctionne sous des contraintes différentes avec des personnes diff érentes.
>> Il y a des métriques qui existent, y compris pour mesurer le degré de
>> réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet d ans une
>> étude faite pour la DGA et j'ai élaboré des formules, hélas no n
>> publiables car le contrat spécifiait que mon étude devenait propri été de
>> la DGA à l'issue du contrat.
>> J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
>> projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 00 0
>> lignes de C++).
> Ces métrique étaient des mesures absolues ou permettainet elle de
> mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
> Je ne connais pas de mesure absolue applicable d'une équipe à une
> autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
>>> Peut être l'info devrait elle s'inspirer des techniques des science s
>>> sociales pour établir des postulats et ses méthodes.
>> Je ne connais pas les techniques des sciences sociales, je ne connais
>> que les techniques du "software engineering", désolé :-(
> Je pensais aux techniques d'enquète pour déterminer des lois
> empiriques. En fait, c'est ce qui se fait souvent (l'agilité est une
> reconnaissance de certaines valeurs) dans les méthodes modernes
> d'organisation du travail en info par opposition aux méthodes
> classiques scientifique.
Je crains fort que les méthodes "modernes" d'organisation du travail en
info soient en fait un gigantesque retour en arrière sur le mode
"essai/erreur" (si tu parles des méthodes "agiles") alors que les
méthodes classiques "scientifiques" ont largement fait leurs preuves, d u
moins dans mes domaines d'intervention qui sont les systèmes complexes à
logiciel prépondérant.
On 22 juil, 11:35, Wykaaa wrote:Michael Doubez a écrit :On 21 juil, 20:35, Wykaaa wrote:Michael DOUBEZ a écrit :Wykaaa a écrit :
Donc, point trop n'en faut, utilisons un peu des deux. Mais dans ce cas,
la décision se fait localement en fonction de l'application. Une
ouverture de fichier ratée peut être plausible (ex: abscence de fichier
pour scanner des emplacements connus de fichier de config) ou être
exceptionnelle (ex: pas les droits, fichier locké) auquel cas
l'application doit prendre la décision.
Pour ces différents cas, qui peut prendre la décision sinon le
programmeur ?
Dans quelle mesure cela est il spécifiable ?
Toutes les exceptions survenant lors de la manipulation de fichiers
doivent être traitées, la plupart du temps, les cas que tu mentionnes
peuvent l'être par des exceptions (vois ce qui est fait en Java dans les
bibliothèques d'E/S standards).
Prenons un exemple en Java:
FileReader in;
try{
in = new FileReader(file);
try{
// ... read file
}
catch(IOException e){
e.printStack();
}
finally{
in.close();
}
}
catch(FileNotFoundException e)
{
// could not open file
}
Ce qui est AMA inutilement verbeux (il y a peut être mieux, je n'ai
pas fait de Java en 10 ans)
et moins lisible que si je pouvais écrire:
FileReader in = new FileReader(file);
if( in.isOpen() ) {
// error opening file
}
// if()...
input.close();
}
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
cas n 'if' produisent n chemins.
Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
granularité de fonction (i.e. partitionnement en petites fonctions).
Mais je m'attendrais à ce que ça représente la majorité des cas en C++
(et même en C).
[snip]Je me rappelle d'une revue de conception dans laquelle nous
avions fait des choix concernant certaines exceptions dans un cadre
transactionnel. Un spécialiste du transactionnel (qui d'ailleurs
n'appartenait pas au projet reviewé), ayant un grand savoir-faire dans
le domaine, nous avait indiqué que nos choix n'étaient pas valides car
ils ne permettaient pas de satisfaire les objectifs de performance
requis. Ca sert à cela les revues !
Un spécialiste est bien sûr utile mais je peux aussi aller de mon
propre chef voir un expert pour lui demander conseil ou alors, il
aurait pu faire l'audit seul et localiser le problème.
AMA, une revue de code sers moins à localiser les bugs qu'à confronter
les points de vue sur le design dans le cadre d'un projet donc assurer
une communication de la culture et des savoir faire.
Je ne parle pas de revue de code mais de revue de conception.
Oups.Dans une
revue de code, on parle de code, pas de conception et on suppose qu'une
revue de conception a eu lieu (et on dispose de ses conclusions et de
ses "findings").
Remarque : j'ai été formé par Miller lui-même aux revues de code.Quand à la réutilisation, on réutilise des modules existants, des
librairies, etc. via des interfaces qui, normalement, documentent les
exceptions pouvant être levées. Si ce n'est pas le cas, cela signifie
que les modules en question ne sont pas réutilisables.
Si il ne sont pas ré-utilisable, alors comment ont ils été utilisés en
premier lieu ? :)
Heureusement que tu as mis un smiley car tu sais très bien, du moins je
l'espère, qu'il y a une grande différence entre des modules qui sont
utilisés spécifiquement dans une application et des modules
réutilisables dans différents contextes.
Oui, c'était une boutade.
Il y a, AMA, deux raisons majeurs de non ré-utilisation de code:
1. Le code n'a pas été utilisé: i.e. il a été conçu dès le début
pour être réutilisable sans utilisation pratique pour guider le
design. C'est le cas des librairies trop générales ou mal conçues.
2. La modularisation est moisie: c-à-d que des fonctionnalités
étrangères au module ont été inséré (souvent suite à un ajout de
fonctionnalité qui aurait nécessité un refactoring) ou est trop
spécifique à un environnement (modules spécifiques comme tu le dis).
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect de l'un des
principes qui sous-tendent la modularité, à savoir le principe de forte
cohérence.
Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
Par contre, d'après ce que j'ai entendu d'autres personnes, ça
arriverait dans des cas de maintenance pour diverses raisons:
- paresse/inconséquence
- le modificateur ne connait pas les responsabilités des modules
(manque de formation ou absence de doc).
- pression sur le temps nécessaire pour la modification
- glissement du domaine de solution
[snip]C'est la même différence qu'il
y a entre une application prototype et l'application finale (le
prototype correspond, en général, à 20% du code final...).
Je ne comprends pas la similarité que tu exposes ici.
Je voulais dire que pour faire d'un module spécifique à une application
un module réutilisable, il y a souvent 80% de travail supplémentaire à
faire sur le module (je me réfère à des études effectuées à la NASA sur
du code ADA à la fin des années 80. Je n'ai, hélas, plus les références
exactes).
OK.
[snip]je suis maintenant à la retraite, mais en suivant cette discussion,
j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
C'est vraiment dramatique de rester si longtemps en enfance...
Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de déterminer
les facteurs de succès et les publier. Chaque projet est différent et
fonctionne sous des contraintes différentes avec des personnes différentes.
Il y a des métriques qui existent, y compris pour mesurer le degré de
réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
étude faite pour la DGA et j'ai élaboré des formules, hélas non
publiables car le contrat spécifiait que mon étude devenait propriété de
la DGA à l'issue du contrat.
J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
lignes de C++).
Ces métrique étaient des mesures absolues ou permettainet elle de
mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
Ma question était: est ce que la valeur de la mesure de qualité est
significative ou est elle un indicateur d'évolution ?
D'après ta réponse je comprends que la valeur est significative en
soi.
Je ne connais pas de mesure absolue applicable d'une équipe à une
autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Peut être l'info devrait elle s'inspirer des techniques des sciences
sociales pour établir des postulats et ses méthodes.
Je ne connais pas les techniques des sciences sociales, je ne connais
que les techniques du "software engineering", désolé :-(
Je pensais aux techniques d'enquète pour déterminer des lois
empiriques. En fait, c'est ce qui se fait souvent (l'agilité est une
reconnaissance de certaines valeurs) dans les méthodes modernes
d'organisation du travail en info par opposition aux méthodes
classiques scientifique.
Je crains fort que les méthodes "modernes" d'organisation du travail en
info soient en fait un gigantesque retour en arrière sur le mode
"essai/erreur" (si tu parles des méthodes "agiles") alors que les
méthodes classiques "scientifiques" ont largement fait leurs preuves, du
moins dans mes domaines d'intervention qui sont les systèmes complexes à
logiciel prépondérant.
C'est justement mon propos. En fonction de la population adressée, les
normes et les méthodes devraient s'adapter et être étudiées.
AMA, les méthodes agiles répondent à un besoin suivant certaines
valeurs (processus de découverte du produit en partenariat avec le
client).
processus modélisés étaient moteur du développement et donc, d'autres
contraintes s'appliquent en priorités.
On 22 juil, 11:35, Wykaaa <wyk...@yahoo.fr> wrote:
Michael Doubez a écrit :
On 21 juil, 20:35, Wykaaa <wyk...@yahoo.fr> wrote:
Michael DOUBEZ a écrit :
Wykaaa a écrit :
Donc, point trop n'en faut, utilisons un peu des deux. Mais dans ce cas,
la décision se fait localement en fonction de l'application. Une
ouverture de fichier ratée peut être plausible (ex: abscence de fichier
pour scanner des emplacements connus de fichier de config) ou être
exceptionnelle (ex: pas les droits, fichier locké) auquel cas
l'application doit prendre la décision.
Pour ces différents cas, qui peut prendre la décision sinon le
programmeur ?
Dans quelle mesure cela est il spécifiable ?
Toutes les exceptions survenant lors de la manipulation de fichiers
doivent être traitées, la plupart du temps, les cas que tu mentionnes
peuvent l'être par des exceptions (vois ce qui est fait en Java dans les
bibliothèques d'E/S standards).
Prenons un exemple en Java:
FileReader in;
try{
in = new FileReader(file);
try{
// ... read file
}
catch(IOException e){
e.printStack();
}
finally{
in.close();
}
}
catch(FileNotFoundException e)
{
// could not open file
}
Ce qui est AMA inutilement verbeux (il y a peut être mieux, je n'ai
pas fait de Java en 10 ans)
et moins lisible que si je pouvais écrire:
FileReader in = new FileReader(file);
if( in.isOpen() ) {
// error opening file
}
// if()...
input.close();
}
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
cas n 'if' produisent n chemins.
Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
granularité de fonction (i.e. partitionnement en petites fonctions).
Mais je m'attendrais à ce que ça représente la majorité des cas en C++
(et même en C).
[snip]
Je me rappelle d'une revue de conception dans laquelle nous
avions fait des choix concernant certaines exceptions dans un cadre
transactionnel. Un spécialiste du transactionnel (qui d'ailleurs
n'appartenait pas au projet reviewé), ayant un grand savoir-faire dans
le domaine, nous avait indiqué que nos choix n'étaient pas valides car
ils ne permettaient pas de satisfaire les objectifs de performance
requis. Ca sert à cela les revues !
Un spécialiste est bien sûr utile mais je peux aussi aller de mon
propre chef voir un expert pour lui demander conseil ou alors, il
aurait pu faire l'audit seul et localiser le problème.
AMA, une revue de code sers moins à localiser les bugs qu'à confronter
les points de vue sur le design dans le cadre d'un projet donc assurer
une communication de la culture et des savoir faire.
Je ne parle pas de revue de code mais de revue de conception.
Oups.
Dans une
revue de code, on parle de code, pas de conception et on suppose qu'une
revue de conception a eu lieu (et on dispose de ses conclusions et de
ses "findings").
Remarque : j'ai été formé par Miller lui-même aux revues de code.
Quand à la réutilisation, on réutilise des modules existants, des
librairies, etc. via des interfaces qui, normalement, documentent les
exceptions pouvant être levées. Si ce n'est pas le cas, cela signifie
que les modules en question ne sont pas réutilisables.
Si il ne sont pas ré-utilisable, alors comment ont ils été utilisés en
premier lieu ? :)
Heureusement que tu as mis un smiley car tu sais très bien, du moins je
l'espère, qu'il y a une grande différence entre des modules qui sont
utilisés spécifiquement dans une application et des modules
réutilisables dans différents contextes.
Oui, c'était une boutade.
Il y a, AMA, deux raisons majeurs de non ré-utilisation de code:
1. Le code n'a pas été utilisé: i.e. il a été conçu dès le début
pour être réutilisable sans utilisation pratique pour guider le
design. C'est le cas des librairies trop générales ou mal conçues.
2. La modularisation est moisie: c-à-d que des fonctionnalités
étrangères au module ont été inséré (souvent suite à un ajout de
fonctionnalité qui aurait nécessité un refactoring) ou est trop
spécifique à un environnement (modules spécifiques comme tu le dis).
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect de l'un des
principes qui sous-tendent la modularité, à savoir le principe de forte
cohérence.
Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
Par contre, d'après ce que j'ai entendu d'autres personnes, ça
arriverait dans des cas de maintenance pour diverses raisons:
- paresse/inconséquence
- le modificateur ne connait pas les responsabilités des modules
(manque de formation ou absence de doc).
- pression sur le temps nécessaire pour la modification
- glissement du domaine de solution
[snip]
C'est la même différence qu'il
y a entre une application prototype et l'application finale (le
prototype correspond, en général, à 20% du code final...).
Je ne comprends pas la similarité que tu exposes ici.
Je voulais dire que pour faire d'un module spécifique à une application
un module réutilisable, il y a souvent 80% de travail supplémentaire à
faire sur le module (je me réfère à des études effectuées à la NASA sur
du code ADA à la fin des années 80. Je n'ai, hélas, plus les références
exactes).
OK.
[snip]
je suis maintenant à la retraite, mais en suivant cette discussion,
j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
C'est vraiment dramatique de rester si longtemps en enfance...
Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de déterminer
les facteurs de succès et les publier. Chaque projet est différent et
fonctionne sous des contraintes différentes avec des personnes différentes.
Il y a des métriques qui existent, y compris pour mesurer le degré de
réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
étude faite pour la DGA et j'ai élaboré des formules, hélas non
publiables car le contrat spécifiait que mon étude devenait propriété de
la DGA à l'issue du contrat.
J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
lignes de C++).
Ces métrique étaient des mesures absolues ou permettainet elle de
mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
Ma question était: est ce que la valeur de la mesure de qualité est
significative ou est elle un indicateur d'évolution ?
D'après ta réponse je comprends que la valeur est significative en
soi.
Je ne connais pas de mesure absolue applicable d'une équipe à une
autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Peut être l'info devrait elle s'inspirer des techniques des sciences
sociales pour établir des postulats et ses méthodes.
Je ne connais pas les techniques des sciences sociales, je ne connais
que les techniques du "software engineering", désolé :-(
Je pensais aux techniques d'enquète pour déterminer des lois
empiriques. En fait, c'est ce qui se fait souvent (l'agilité est une
reconnaissance de certaines valeurs) dans les méthodes modernes
d'organisation du travail en info par opposition aux méthodes
classiques scientifique.
Je crains fort que les méthodes "modernes" d'organisation du travail en
info soient en fait un gigantesque retour en arrière sur le mode
"essai/erreur" (si tu parles des méthodes "agiles") alors que les
méthodes classiques "scientifiques" ont largement fait leurs preuves, du
moins dans mes domaines d'intervention qui sont les systèmes complexes à
logiciel prépondérant.
C'est justement mon propos. En fonction de la population adressée, les
normes et les méthodes devraient s'adapter et être étudiées.
AMA, les méthodes agiles répondent à un besoin suivant certaines
valeurs (processus de découverte du produit en partenariat avec le
client).
processus modélisés étaient moteur du développement et donc, d'autres
contraintes s'appliquent en priorités.
On 22 juil, 11:35, Wykaaa wrote:Michael Doubez a écrit :On 21 juil, 20:35, Wykaaa wrote:Michael DOUBEZ a écrit :Wykaaa a écrit :
Donc, point trop n'en faut, utilisons un peu des deux. Mais dans ce cas,
la décision se fait localement en fonction de l'application. Une
ouverture de fichier ratée peut être plausible (ex: abscence de fichier
pour scanner des emplacements connus de fichier de config) ou être
exceptionnelle (ex: pas les droits, fichier locké) auquel cas
l'application doit prendre la décision.
Pour ces différents cas, qui peut prendre la décision sinon le
programmeur ?
Dans quelle mesure cela est il spécifiable ?
Toutes les exceptions survenant lors de la manipulation de fichiers
doivent être traitées, la plupart du temps, les cas que tu mentionnes
peuvent l'être par des exceptions (vois ce qui est fait en Java dans les
bibliothèques d'E/S standards).
Prenons un exemple en Java:
FileReader in;
try{
in = new FileReader(file);
try{
// ... read file
}
catch(IOException e){
e.printStack();
}
finally{
in.close();
}
}
catch(FileNotFoundException e)
{
// could not open file
}
Ce qui est AMA inutilement verbeux (il y a peut être mieux, je n'ai
pas fait de Java en 10 ans)
et moins lisible que si je pouvais écrire:
FileReader in = new FileReader(file);
if( in.isOpen() ) {
// error opening file
}
// if()...
input.close();
}
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
cas n 'if' produisent n chemins.
Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
granularité de fonction (i.e. partitionnement en petites fonctions).
Mais je m'attendrais à ce que ça représente la majorité des cas en C++
(et même en C).
[snip]Je me rappelle d'une revue de conception dans laquelle nous
avions fait des choix concernant certaines exceptions dans un cadre
transactionnel. Un spécialiste du transactionnel (qui d'ailleurs
n'appartenait pas au projet reviewé), ayant un grand savoir-faire dans
le domaine, nous avait indiqué que nos choix n'étaient pas valides car
ils ne permettaient pas de satisfaire les objectifs de performance
requis. Ca sert à cela les revues !
Un spécialiste est bien sûr utile mais je peux aussi aller de mon
propre chef voir un expert pour lui demander conseil ou alors, il
aurait pu faire l'audit seul et localiser le problème.
AMA, une revue de code sers moins à localiser les bugs qu'à confronter
les points de vue sur le design dans le cadre d'un projet donc assurer
une communication de la culture et des savoir faire.
Je ne parle pas de revue de code mais de revue de conception.
Oups.Dans une
revue de code, on parle de code, pas de conception et on suppose qu'une
revue de conception a eu lieu (et on dispose de ses conclusions et de
ses "findings").
Remarque : j'ai été formé par Miller lui-même aux revues de code.Quand à la réutilisation, on réutilise des modules existants, des
librairies, etc. via des interfaces qui, normalement, documentent les
exceptions pouvant être levées. Si ce n'est pas le cas, cela signifie
que les modules en question ne sont pas réutilisables.
Si il ne sont pas ré-utilisable, alors comment ont ils été utilisés en
premier lieu ? :)
Heureusement que tu as mis un smiley car tu sais très bien, du moins je
l'espère, qu'il y a une grande différence entre des modules qui sont
utilisés spécifiquement dans une application et des modules
réutilisables dans différents contextes.
Oui, c'était une boutade.
Il y a, AMA, deux raisons majeurs de non ré-utilisation de code:
1. Le code n'a pas été utilisé: i.e. il a été conçu dès le début
pour être réutilisable sans utilisation pratique pour guider le
design. C'est le cas des librairies trop générales ou mal conçues.
2. La modularisation est moisie: c-à-d que des fonctionnalités
étrangères au module ont été inséré (souvent suite à un ajout de
fonctionnalité qui aurait nécessité un refactoring) ou est trop
spécifique à un environnement (modules spécifiques comme tu le dis).
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect de l'un des
principes qui sous-tendent la modularité, à savoir le principe de forte
cohérence.
Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
Par contre, d'après ce que j'ai entendu d'autres personnes, ça
arriverait dans des cas de maintenance pour diverses raisons:
- paresse/inconséquence
- le modificateur ne connait pas les responsabilités des modules
(manque de formation ou absence de doc).
- pression sur le temps nécessaire pour la modification
- glissement du domaine de solution
[snip]C'est la même différence qu'il
y a entre une application prototype et l'application finale (le
prototype correspond, en général, à 20% du code final...).
Je ne comprends pas la similarité que tu exposes ici.
Je voulais dire que pour faire d'un module spécifique à une application
un module réutilisable, il y a souvent 80% de travail supplémentaire à
faire sur le module (je me réfère à des études effectuées à la NASA sur
du code ADA à la fin des années 80. Je n'ai, hélas, plus les références
exactes).
OK.
[snip]je suis maintenant à la retraite, mais en suivant cette discussion,
j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
C'est vraiment dramatique de rester si longtemps en enfance...
Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de déterminer
les facteurs de succès et les publier. Chaque projet est différent et
fonctionne sous des contraintes différentes avec des personnes différentes.
Il y a des métriques qui existent, y compris pour mesurer le degré de
réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
étude faite pour la DGA et j'ai élaboré des formules, hélas non
publiables car le contrat spécifiait que mon étude devenait propriété de
la DGA à l'issue du contrat.
J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
lignes de C++).
Ces métrique étaient des mesures absolues ou permettainet elle de
mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
Ma question était: est ce que la valeur de la mesure de qualité est
significative ou est elle un indicateur d'évolution ?
D'après ta réponse je comprends que la valeur est significative en
soi.
Je ne connais pas de mesure absolue applicable d'une équipe à une
autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Peut être l'info devrait elle s'inspirer des techniques des sciences
sociales pour établir des postulats et ses méthodes.
Je ne connais pas les techniques des sciences sociales, je ne connais
que les techniques du "software engineering", désolé :-(
Je pensais aux techniques d'enquète pour déterminer des lois
empiriques. En fait, c'est ce qui se fait souvent (l'agilité est une
reconnaissance de certaines valeurs) dans les méthodes modernes
d'organisation du travail en info par opposition aux méthodes
classiques scientifique.
Je crains fort que les méthodes "modernes" d'organisation du travail en
info soient en fait un gigantesque retour en arrière sur le mode
"essai/erreur" (si tu parles des méthodes "agiles") alors que les
méthodes classiques "scientifiques" ont largement fait leurs preuves, du
moins dans mes domaines d'intervention qui sont les systèmes complexes à
logiciel prépondérant.
C'est justement mon propos. En fonction de la population adressée, les
normes et les méthodes devraient s'adapter et être étudiées.
AMA, les méthodes agiles répondent à un besoin suivant certaines
valeurs (processus de découverte du produit en partenariat avec le
client).
processus modélisés étaient moteur du développement et donc, d'autres
contraintes s'appliquent en priorités.
On 22 juil, 11:35, Wykaaa wrote:Michael Doubez a écrit :On 21 juil, 20:35, Wykaaa wrote:Michael DOUBEZ a écrit :Wykaaa a écrit :
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
On 22 juil, 11:35, Wykaaa <wyk...@yahoo.fr> wrote:
Michael Doubez a écrit :
On 21 juil, 20:35, Wykaaa <wyk...@yahoo.fr> wrote:
Michael DOUBEZ a écrit :
Wykaaa a écrit :
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
On 22 juil, 11:35, Wykaaa wrote:Michael Doubez a écrit :On 21 juil, 20:35, Wykaaa wrote:Michael DOUBEZ a écrit :Wykaaa a écrit :
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Michael Doubez a écrit :
> On 22 juil, 11:35, Wykaaa wrote:
>> Non car le catch(IOException e) peut être affiné sans bouger le co de. En
>> l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
>> les I/O (ce qui peut être un plus) alors que l'écriture avec les i f
>> complexifie le graphe du code et augmente le nombre cyclomatique sans
>> apporter aucune plus-value.
>> En bref, l'écriture à l'aide des exceptions simplifie le graphe de
>> programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
>> chemins dans le graphe.Le déroutement sur des exceptions augmente de
>> façon linéaire le nombre de chemins (les chemins de déroutement sur les
>> exceptions ne se combinent pas). Les successions de "if" augmentent la
>> complexité de façon exponentielle.
> Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
> cas n 'if' produisent n chemins.
Alors, dans ce cas, on ne respecte plus la programmation structurée
puisqu'il y a plusieurs points de sortie par fonction "gérés par le
programmeur" (et non par le compilateur comme c'est le cas avec le
mécanisme d'exception).
C'est d'ailleurs justement un des critères qui font préférer, dans les
logiciels requérant une grande qualité et fiabilité, le mécanisme
d'exception.
> Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
> granularité de fonction (i.e. partitionnement en petites fonctions).
> Mais je m'attendrais à ce que ça représente la majorité des cas en C++
> (et même en C).
Je ne souhaite jamais avoir à faire à du code qui multiplie les sorti es
multiples de fonctions, qui plus est, dans un contexte de traitement
d'exception.
>> Le cas 2 ne devrait pas se produire car si des fonctionnalités
>> étrangères au module ont été insérées, c'est un non respec t de l'un des
>> principes qui sous-tendent la modularité, à savoir le principe de forte
>> cohérence.
> Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
> personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
> Par contre, d'après ce que j'ai entendu d'autres personnes, ça
> arriverait dans des cas de maintenance pour diverses raisons:
> - paresse/inconséquence
> - le modificateur ne connait pas les responsabilités des modules
> (manque de formation ou absence de doc).
> - pression sur le temps nécessaire pour la modification
> - glissement du domaine de solution
Tu reconnaîtras que toutes ces raisons, sont de mauvaises raisons :-)
>>>>>> je suis maintenant à la retraite, mais en suivant cette discussi on,
>>>>>> j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
>>>>>> C'est vraiment dramatique de rester si longtemps en enfance...
>>>>> Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de d éterminer
>>>>> les facteurs de succès et les publier. Chaque projet est différ ent et
>>>>> fonctionne sous des contraintes différentes avec des personnes di fférentes.
>>>> Il y a des métriques qui existent, y compris pour mesurer le degr é de
>>>> réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
>>>> étude faite pour la DGA et j'ai élaboré des formules, hélas non
>>>> publiables car le contrat spécifiait que mon étude devenait prop riété de
>>>> la DGA à l'issue du contrat.
>>>> J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
>>>> projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
>>>> lignes de C++).
>>> Ces métrique étaient des mesures absolues ou permettainet elle de
>>> mesurer l'évolution dans un projet ?
>> Ce sont des mesures absolues mais en comparant ces mesures sur des
>> versions successives on voit leur évolution.
> Ma question était: est ce que la valeur de la mesure de qualité est
> significative ou est elle un indicateur d'évolution ?
> D'après ta réponse je comprends que la valeur est significative en
> soi.
Oui, tu as bien compris.
>>> Je ne connais pas de mesure absolue applicable d'une équipe à une
>>> autre.
>> Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
>> mesures qui s'appliquent à la CONCEPTION et au CODE !
> Ca a l'air interessant.
Mais c'est très intéressant et les responsables de ces projets et m ême
certains développeurs ont passé du temps avec moi pour que je leur
explique en détail comment je mesurais la réutilisabilité.
Ils ont découverts, quelques fois avec stupéfaction, qu'un certain
nombre de "patterns" qu'ils considéraient comme de bonne pratique
faisaient chuter le facteur de réutilisabilité. Ce domaine est largem ent
contre-intuitif.
Michael Doubez a écrit :
> On 22 juil, 11:35, Wykaaa <wyk...@yahoo.fr> wrote:
>> Non car le catch(IOException e) peut être affiné sans bouger le co de. En
>> l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
>> les I/O (ce qui peut être un plus) alors que l'écriture avec les i f
>> complexifie le graphe du code et augmente le nombre cyclomatique sans
>> apporter aucune plus-value.
>> En bref, l'écriture à l'aide des exceptions simplifie le graphe de
>> programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
>> chemins dans le graphe.Le déroutement sur des exceptions augmente de
>> façon linéaire le nombre de chemins (les chemins de déroutement sur les
>> exceptions ne se combinent pas). Les successions de "if" augmentent la
>> complexité de façon exponentielle.
> Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
> cas n 'if' produisent n chemins.
Alors, dans ce cas, on ne respecte plus la programmation structurée
puisqu'il y a plusieurs points de sortie par fonction "gérés par le
programmeur" (et non par le compilateur comme c'est le cas avec le
mécanisme d'exception).
C'est d'ailleurs justement un des critères qui font préférer, dans les
logiciels requérant une grande qualité et fiabilité, le mécanisme
d'exception.
> Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
> granularité de fonction (i.e. partitionnement en petites fonctions).
> Mais je m'attendrais à ce que ça représente la majorité des cas en C++
> (et même en C).
Je ne souhaite jamais avoir à faire à du code qui multiplie les sorti es
multiples de fonctions, qui plus est, dans un contexte de traitement
d'exception.
>> Le cas 2 ne devrait pas se produire car si des fonctionnalités
>> étrangères au module ont été insérées, c'est un non respec t de l'un des
>> principes qui sous-tendent la modularité, à savoir le principe de forte
>> cohérence.
> Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
> personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
> Par contre, d'après ce que j'ai entendu d'autres personnes, ça
> arriverait dans des cas de maintenance pour diverses raisons:
> - paresse/inconséquence
> - le modificateur ne connait pas les responsabilités des modules
> (manque de formation ou absence de doc).
> - pression sur le temps nécessaire pour la modification
> - glissement du domaine de solution
Tu reconnaîtras que toutes ces raisons, sont de mauvaises raisons :-)
>>>>>> je suis maintenant à la retraite, mais en suivant cette discussi on,
>>>>>> j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
>>>>>> C'est vraiment dramatique de rester si longtemps en enfance...
>>>>> Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de d éterminer
>>>>> les facteurs de succès et les publier. Chaque projet est différ ent et
>>>>> fonctionne sous des contraintes différentes avec des personnes di fférentes.
>>>> Il y a des métriques qui existent, y compris pour mesurer le degr é de
>>>> réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
>>>> étude faite pour la DGA et j'ai élaboré des formules, hélas non
>>>> publiables car le contrat spécifiait que mon étude devenait prop riété de
>>>> la DGA à l'issue du contrat.
>>>> J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
>>>> projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
>>>> lignes de C++).
>>> Ces métrique étaient des mesures absolues ou permettainet elle de
>>> mesurer l'évolution dans un projet ?
>> Ce sont des mesures absolues mais en comparant ces mesures sur des
>> versions successives on voit leur évolution.
> Ma question était: est ce que la valeur de la mesure de qualité est
> significative ou est elle un indicateur d'évolution ?
> D'après ta réponse je comprends que la valeur est significative en
> soi.
Oui, tu as bien compris.
>>> Je ne connais pas de mesure absolue applicable d'une équipe à une
>>> autre.
>> Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
>> mesures qui s'appliquent à la CONCEPTION et au CODE !
> Ca a l'air interessant.
Mais c'est très intéressant et les responsables de ces projets et m ême
certains développeurs ont passé du temps avec moi pour que je leur
explique en détail comment je mesurais la réutilisabilité.
Ils ont découverts, quelques fois avec stupéfaction, qu'un certain
nombre de "patterns" qu'ils considéraient comme de bonne pratique
faisaient chuter le facteur de réutilisabilité. Ce domaine est largem ent
contre-intuitif.
Michael Doubez a écrit :
> On 22 juil, 11:35, Wykaaa wrote:
>> Non car le catch(IOException e) peut être affiné sans bouger le co de. En
>> l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
>> les I/O (ce qui peut être un plus) alors que l'écriture avec les i f
>> complexifie le graphe du code et augmente le nombre cyclomatique sans
>> apporter aucune plus-value.
>> En bref, l'écriture à l'aide des exceptions simplifie le graphe de
>> programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
>> chemins dans le graphe.Le déroutement sur des exceptions augmente de
>> façon linéaire le nombre de chemins (les chemins de déroutement sur les
>> exceptions ne se combinent pas). Les successions de "if" augmentent la
>> complexité de façon exponentielle.
> Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
> cas n 'if' produisent n chemins.
Alors, dans ce cas, on ne respecte plus la programmation structurée
puisqu'il y a plusieurs points de sortie par fonction "gérés par le
programmeur" (et non par le compilateur comme c'est le cas avec le
mécanisme d'exception).
C'est d'ailleurs justement un des critères qui font préférer, dans les
logiciels requérant une grande qualité et fiabilité, le mécanisme
d'exception.
> Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
> granularité de fonction (i.e. partitionnement en petites fonctions).
> Mais je m'attendrais à ce que ça représente la majorité des cas en C++
> (et même en C).
Je ne souhaite jamais avoir à faire à du code qui multiplie les sorti es
multiples de fonctions, qui plus est, dans un contexte de traitement
d'exception.
>> Le cas 2 ne devrait pas se produire car si des fonctionnalités
>> étrangères au module ont été insérées, c'est un non respec t de l'un des
>> principes qui sous-tendent la modularité, à savoir le principe de forte
>> cohérence.
> Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
> personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
> Par contre, d'après ce que j'ai entendu d'autres personnes, ça
> arriverait dans des cas de maintenance pour diverses raisons:
> - paresse/inconséquence
> - le modificateur ne connait pas les responsabilités des modules
> (manque de formation ou absence de doc).
> - pression sur le temps nécessaire pour la modification
> - glissement du domaine de solution
Tu reconnaîtras que toutes ces raisons, sont de mauvaises raisons :-)
>>>>>> je suis maintenant à la retraite, mais en suivant cette discussi on,
>>>>>> j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
>>>>>> C'est vraiment dramatique de rester si longtemps en enfance...
>>>>> Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de d éterminer
>>>>> les facteurs de succès et les publier. Chaque projet est différ ent et
>>>>> fonctionne sous des contraintes différentes avec des personnes di fférentes.
>>>> Il y a des métriques qui existent, y compris pour mesurer le degr é de
>>>> réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
>>>> étude faite pour la DGA et j'ai élaboré des formules, hélas non
>>>> publiables car le contrat spécifiait que mon étude devenait prop riété de
>>>> la DGA à l'issue du contrat.
>>>> J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
>>>> projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
>>>> lignes de C++).
>>> Ces métrique étaient des mesures absolues ou permettainet elle de
>>> mesurer l'évolution dans un projet ?
>> Ce sont des mesures absolues mais en comparant ces mesures sur des
>> versions successives on voit leur évolution.
> Ma question était: est ce que la valeur de la mesure de qualité est
> significative ou est elle un indicateur d'évolution ?
> D'après ta réponse je comprends que la valeur est significative en
> soi.
Oui, tu as bien compris.
>>> Je ne connais pas de mesure absolue applicable d'une équipe à une
>>> autre.
>> Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
>> mesures qui s'appliquent à la CONCEPTION et au CODE !
> Ca a l'air interessant.
Mais c'est très intéressant et les responsables de ces projets et m ême
certains développeurs ont passé du temps avec moi pour que je leur
explique en détail comment je mesurais la réutilisabilité.
Ils ont découverts, quelques fois avec stupéfaction, qu'un certain
nombre de "patterns" qu'ils considéraient comme de bonne pratique
faisaient chuter le facteur de réutilisabilité. Ce domaine est largem ent
contre-intuitif.
On 22 juil, 15:35, Wykaaa wrote:Michael Doubez a écrit :On 22 juil, 11:35, Wykaaa wrote:
[snip]Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
cas n 'if' produisent n chemins.
Alors, dans ce cas, on ne respecte plus la programmation structurée
puisqu'il y a plusieurs points de sortie par fonction "gérés par le
programmeur" (et non par le compilateur comme c'est le cas avec le
mécanisme d'exception).
Si tu parles du principe de "single exit point", avec RAII, c'est du
pareil au même.C'est d'ailleurs justement un des critères qui font préférer, dans les
logiciels requérant une grande qualité et fiabilité, le mécanisme
d'exception.
Avec le mecanisme d'exception, chaque ligne de code est
potentiellement un point de sortie, alors que sans, je peux quand même
me reposer de temps en temps.
Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
granularité de fonction (i.e. partitionnement en petites fonctions).
Mais je m'attendrais à ce que ça représente la majorité des cas en C++
(et même en C).
Je ne souhaite jamais avoir à faire à du code qui multiplie les sorties
multiples de fonctions, qui plus est, dans un contexte de traitement
d'exception.
Je pense que c'est moins un impératif en C++ qu'en C par exemple.
[snip]Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect de l'un des
principes qui sous-tendent la modularité, à savoir le principe de forte
cohérence.
Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
Par contre, d'après ce que j'ai entendu d'autres personnes, ça
arriverait dans des cas de maintenance pour diverses raisons:
- paresse/inconséquence
- le modificateur ne connait pas les responsabilités des modules
(manque de formation ou absence de doc).
- pression sur le temps nécessaire pour la modification
- glissement du domaine de solution
Tu reconnaîtras que toutes ces raisons, sont de mauvaises raisons :-)
Oui. Sauf en période de chomage :)je suis maintenant à la retraite, mais en suivant cette discussion,
j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
C'est vraiment dramatique de rester si longtemps en enfance...
Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de déterminer
les facteurs de succès et les publier. Chaque projet est différent et
fonctionne sous des contraintes différentes avec des personnes différentes.
Il y a des métriques qui existent, y compris pour mesurer le degré de
réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
étude faite pour la DGA et j'ai élaboré des formules, hélas non
publiables car le contrat spécifiait que mon étude devenait propriété de
la DGA à l'issue du contrat.
J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
lignes de C++).
Ces métrique étaient des mesures absolues ou permettainet elle de
mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
Ma question était: est ce que la valeur de la mesure de qualité est
significative ou est elle un indicateur d'évolution ?
D'après ta réponse je comprends que la valeur est significative en
soi.
Oui, tu as bien compris.
Je suis allé voir le site de la NASA que tu as indiqué. Je reconnais
que ces métriques sont utiles et le minimum des mesures d'un projet.
Je pensais plutôt aux mesures de modularité (caractérisant l'impact
d'une modif par exemple) ou autres mesures possible servant diectement
la qualité du code.
Je ne connais pas de mesure absolue applicable d'une équipe à une
autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Mais c'est très intéressant et les responsables de ces projets et même
certains développeurs ont passé du temps avec moi pour que je leur
explique en détail comment je mesurais la réutilisabilité.
Ils ont découverts, quelques fois avec stupéfaction, qu'un certain
nombre de "patterns" qu'ils considéraient comme de bonne pratique
faisaient chuter le facteur de réutilisabilité. Ce domaine est largement
contre-intuitif.
De patterns vraiment (à part singleton) ?!?
Ou d'idiomes ?
On 22 juil, 15:35, Wykaaa <wyk...@yahoo.fr> wrote:
Michael Doubez a écrit :
On 22 juil, 11:35, Wykaaa <wyk...@yahoo.fr> wrote:
[snip]
Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
cas n 'if' produisent n chemins.
Alors, dans ce cas, on ne respecte plus la programmation structurée
puisqu'il y a plusieurs points de sortie par fonction "gérés par le
programmeur" (et non par le compilateur comme c'est le cas avec le
mécanisme d'exception).
Si tu parles du principe de "single exit point", avec RAII, c'est du
pareil au même.
C'est d'ailleurs justement un des critères qui font préférer, dans les
logiciels requérant une grande qualité et fiabilité, le mécanisme
d'exception.
Avec le mecanisme d'exception, chaque ligne de code est
potentiellement un point de sortie, alors que sans, je peux quand même
me reposer de temps en temps.
Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
granularité de fonction (i.e. partitionnement en petites fonctions).
Mais je m'attendrais à ce que ça représente la majorité des cas en C++
(et même en C).
Je ne souhaite jamais avoir à faire à du code qui multiplie les sorties
multiples de fonctions, qui plus est, dans un contexte de traitement
d'exception.
Je pense que c'est moins un impératif en C++ qu'en C par exemple.
[snip]
Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect de l'un des
principes qui sous-tendent la modularité, à savoir le principe de forte
cohérence.
Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
Par contre, d'après ce que j'ai entendu d'autres personnes, ça
arriverait dans des cas de maintenance pour diverses raisons:
- paresse/inconséquence
- le modificateur ne connait pas les responsabilités des modules
(manque de formation ou absence de doc).
- pression sur le temps nécessaire pour la modification
- glissement du domaine de solution
Tu reconnaîtras que toutes ces raisons, sont de mauvaises raisons :-)
Oui. Sauf en période de chomage :)
je suis maintenant à la retraite, mais en suivant cette discussion,
j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
C'est vraiment dramatique de rester si longtemps en enfance...
Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de déterminer
les facteurs de succès et les publier. Chaque projet est différent et
fonctionne sous des contraintes différentes avec des personnes différentes.
Il y a des métriques qui existent, y compris pour mesurer le degré de
réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
étude faite pour la DGA et j'ai élaboré des formules, hélas non
publiables car le contrat spécifiait que mon étude devenait propriété de
la DGA à l'issue du contrat.
J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
lignes de C++).
Ces métrique étaient des mesures absolues ou permettainet elle de
mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
Ma question était: est ce que la valeur de la mesure de qualité est
significative ou est elle un indicateur d'évolution ?
D'après ta réponse je comprends que la valeur est significative en
soi.
Oui, tu as bien compris.
Je suis allé voir le site de la NASA que tu as indiqué. Je reconnais
que ces métriques sont utiles et le minimum des mesures d'un projet.
Je pensais plutôt aux mesures de modularité (caractérisant l'impact
d'une modif par exemple) ou autres mesures possible servant diectement
la qualité du code.
Je ne connais pas de mesure absolue applicable d'une équipe à une
autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Mais c'est très intéressant et les responsables de ces projets et même
certains développeurs ont passé du temps avec moi pour que je leur
explique en détail comment je mesurais la réutilisabilité.
Ils ont découverts, quelques fois avec stupéfaction, qu'un certain
nombre de "patterns" qu'ils considéraient comme de bonne pratique
faisaient chuter le facteur de réutilisabilité. Ce domaine est largement
contre-intuitif.
De patterns vraiment (à part singleton) ?!?
Ou d'idiomes ?
On 22 juil, 15:35, Wykaaa wrote:Michael Doubez a écrit :On 22 juil, 11:35, Wykaaa wrote:
[snip]Non car le catch(IOException e) peut être affiné sans bouger le code. En
l'état (tel que tu l'as écrit) il factorise toutes les exceptions sur
les I/O (ce qui peut être un plus) alors que l'écriture avec les if
complexifie le graphe du code et augmente le nombre cyclomatique sans
apporter aucune plus-value.
En bref, l'écriture à l'aide des exceptions simplifie le graphe de
programme (je rappelle que si n "if" se succèdent, ceci produit 2^n
chemins dans le graphe.Le déroutement sur des exceptions augmente de
façon linéaire le nombre de chemins (les chemins de déroutement sur les
exceptions ne se combinent pas). Les successions de "if" augmentent la
complexité de façon exponentielle.
Pas si le 'if', en detectant l'erreur, est un point de sortie auquel
cas n 'if' produisent n chemins.
Alors, dans ce cas, on ne respecte plus la programmation structurée
puisqu'il y a plusieurs points de sortie par fonction "gérés par le
programmeur" (et non par le compilateur comme c'est le cas avec le
mécanisme d'exception).
Si tu parles du principe de "single exit point", avec RAII, c'est du
pareil au même.C'est d'ailleurs justement un des critères qui font préférer, dans les
logiciels requérant une grande qualité et fiabilité, le mécanisme
d'exception.
Avec le mecanisme d'exception, chaque ligne de code est
potentiellement un point de sortie, alors que sans, je peux quand même
me reposer de temps en temps.
Globalement, cela n'est bien sûr valable qu'à partir d'une certaine
granularité de fonction (i.e. partitionnement en petites fonctions).
Mais je m'attendrais à ce que ça représente la majorité des cas en C++
(et même en C).
Je ne souhaite jamais avoir à faire à du code qui multiplie les sorties
multiples de fonctions, qui plus est, dans un contexte de traitement
d'exception.
Je pense que c'est moins un impératif en C++ qu'en C par exemple.
[snip]Le cas 2 ne devrait pas se produire car si des fonctionnalités
étrangères au module ont été insérées, c'est un non respect de l'un des
principes qui sous-tendent la modularité, à savoir le principe de forte
cohérence.
Oui, ça ne devrais pas arriver. J'ai une ou deux expérience
personnelle ou c'est arrivé mais je ne sais pas si c'était typique.
Par contre, d'après ce que j'ai entendu d'autres personnes, ça
arriverait dans des cas de maintenance pour diverses raisons:
- paresse/inconséquence
- le modificateur ne connait pas les responsabilités des modules
(manque de formation ou absence de doc).
- pression sur le temps nécessaire pour la modification
- glissement du domaine de solution
Tu reconnaîtras que toutes ces raisons, sont de mauvaises raisons :-)
Oui. Sauf en période de chomage :)je suis maintenant à la retraite, mais en suivant cette discussion,
j'ai l'impression que l'informatique n'a pas mûrie d'un pouce en 40 ans !
C'est vraiment dramatique de rester si longtemps en enfance...
Ce qu'il y a, c'est qu'il n'y a pas de métrique permettant de déterminer
les facteurs de succès et les publier. Chaque projet est différent et
fonctionne sous des contraintes différentes avec des personnes différentes.
Il y a des métriques qui existent, y compris pour mesurer le degré de
réutilisabilité d'un module. J'ai écrit 100 pages sur le sujet dans une
étude faite pour la DGA et j'ai élaboré des formules, hélas non
publiables car le contrat spécifiait que mon étude devenait propriété de
la DGA à l'issue du contrat.
J'ai même appliqué l'ensemble de ces formules (avec Logiscope) à 2 gros
projets de la DGA (l'un de 400 000 lignes de Java et l'autre de 200 000
lignes de C++).
Ces métrique étaient des mesures absolues ou permettainet elle de
mesurer l'évolution dans un projet ?
Ce sont des mesures absolues mais en comparant ces mesures sur des
versions successives on voit leur évolution.
Ma question était: est ce que la valeur de la mesure de qualité est
significative ou est elle un indicateur d'évolution ?
D'après ta réponse je comprends que la valeur est significative en
soi.
Oui, tu as bien compris.
Je suis allé voir le site de la NASA que tu as indiqué. Je reconnais
que ces métriques sont utiles et le minimum des mesures d'un projet.
Je pensais plutôt aux mesures de modularité (caractérisant l'impact
d'une modif par exemple) ou autres mesures possible servant diectement
la qualité du code.
Je ne connais pas de mesure absolue applicable d'une équipe à une
autre.
Ce ne sont pas des mesures qui s'appliquent à des équipes mais des
mesures qui s'appliquent à la CONCEPTION et au CODE !
Ca a l'air interessant.
Mais c'est très intéressant et les responsables de ces projets et même
certains développeurs ont passé du temps avec moi pour que je leur
explique en détail comment je mesurais la réutilisabilité.
Ils ont découverts, quelques fois avec stupéfaction, qu'un certain
nombre de "patterns" qu'ils considéraient comme de bonne pratique
faisaient chuter le facteur de réutilisabilité. Ce domaine est largement
contre-intuitif.
De patterns vraiment (à part singleton) ?!?
Ou d'idiomes ?
Michael Doubez a écrit :
> On 22 juil, 15:35, Wykaaa wrote:
>> C'est d'ailleurs justement un des critères qui font préférer, da ns les
>> logiciels requérant une grande qualité et fiabilité, le mécani sme
>> d'exception.
> Avec le mecanisme d'exception, chaque ligne de code est
> potentiellement un point de sortie, alors que sans, je peux quand mêm e
> me reposer de temps en temps.
Chaque ligne de code qui fait appel à une fonction qui est susceptible
de retourner une exception, ce qui est quand même très différent.
>>> Globalement, cela n'est bien sûr valable qu'à partir d'une certai ne
>>> granularité de fonction (i.e. partitionnement en petites fonctions) .
>>> Mais je m'attendrais à ce que ça représente la majorité des c as en C++
>>> (et même en C).
>> Je ne souhaite jamais avoir à faire à du code qui multiplie les so rties
>> multiples de fonctions, qui plus est, dans un contexte de traitement
>> d'exception.
> Je pense que c'est moins un impératif en C++ qu'en C par exemple.
ET pourquoi y aurait-il une différence entre les 2 langages ?
Michael Doubez a écrit :
> On 22 juil, 15:35, Wykaaa <wyk...@yahoo.fr> wrote:
>> C'est d'ailleurs justement un des critères qui font préférer, da ns les
>> logiciels requérant une grande qualité et fiabilité, le mécani sme
>> d'exception.
> Avec le mecanisme d'exception, chaque ligne de code est
> potentiellement un point de sortie, alors que sans, je peux quand mêm e
> me reposer de temps en temps.
Chaque ligne de code qui fait appel à une fonction qui est susceptible
de retourner une exception, ce qui est quand même très différent.
>>> Globalement, cela n'est bien sûr valable qu'à partir d'une certai ne
>>> granularité de fonction (i.e. partitionnement en petites fonctions) .
>>> Mais je m'attendrais à ce que ça représente la majorité des c as en C++
>>> (et même en C).
>> Je ne souhaite jamais avoir à faire à du code qui multiplie les so rties
>> multiples de fonctions, qui plus est, dans un contexte de traitement
>> d'exception.
> Je pense que c'est moins un impératif en C++ qu'en C par exemple.
ET pourquoi y aurait-il une différence entre les 2 langages ?
Michael Doubez a écrit :
> On 22 juil, 15:35, Wykaaa wrote:
>> C'est d'ailleurs justement un des critères qui font préférer, da ns les
>> logiciels requérant une grande qualité et fiabilité, le mécani sme
>> d'exception.
> Avec le mecanisme d'exception, chaque ligne de code est
> potentiellement un point de sortie, alors que sans, je peux quand mêm e
> me reposer de temps en temps.
Chaque ligne de code qui fait appel à une fonction qui est susceptible
de retourner une exception, ce qui est quand même très différent.
>>> Globalement, cela n'est bien sûr valable qu'à partir d'une certai ne
>>> granularité de fonction (i.e. partitionnement en petites fonctions) .
>>> Mais je m'attendrais à ce que ça représente la majorité des c as en C++
>>> (et même en C).
>> Je ne souhaite jamais avoir à faire à du code qui multiplie les so rties
>> multiples de fonctions, qui plus est, dans un contexte de traitement
>> d'exception.
> Je pense que c'est moins un impératif en C++ qu'en C par exemple.
ET pourquoi y aurait-il une différence entre les 2 langages ?