Statistiques d'un programme C++

Je viens de le retrouver, le voilà :
(C'est de l'anglais)
http://www.joelonsoftware.com/news/20020715.html

Je suis fan de ce site. Ce Joel a une vision très instructrice du métier
de développeur, en ce qui me concerne du moins.
J'hésite à acheter son livre. Quelqu'un l'a lu ?

--
Aurélien Regat-Barrel

Je viens de le retrouver, le voilà :
(C'est de l'anglais)
http://www.joelonsoftware.com/news/20020715.html

Je suis fan de ce site. Ce Joel a une vision très instructrice
du métier de développeur, en ce qui me concerne du moins.
J'hésite à acheter son livre. Quelqu'un l'a lu ?

Je n'ai pas lu ce livre, par contre je suis d'accord pour dire que ce

site est génial. Je l'ai découvert fin juin et depuis j'en ai lu une
bonne partie. Il y a beaucoup de choses très interessantes.

plouf wrote:

....

Ce n'est pas ce que disent les experts. Au contraire, des
outils de mesure sont essentiels si tu veux produire du
logiciel de qualité, à un prix prévisible.

D'après votre expérience, quelles sont les mesures les plus
significatives ? Et que représentent-elles exactement ? (et
comment sont-elles calculées ?)

Ça varie ; il n'y a pas une seule mesure qui capture tout. Et
significatives pour quoi ?

Pour l'évaluation du programmeur, c'est peut-être le pourcentage
des fois qu'il a passé une revue de code sans avoir besoin de
retravailler le code. Mais il y a aussi la question s'il a
maintenu les delais ou non, combien d'erreurs on a trouvées dans
son code, etc.

Pour la préparation d'une revue de code, la mesure de McCabe
s'est avérée assez bien.

Pour les mesures ultra-simples, comme celles dont il a été
question ici, l'intérêt est surtout quand on peut les utiliser
de façon comparative. Si, par exemple, un programmeur produit
typiquement mille lignes de code dans un mois, s'il se présente
à une revue de code avec cent lignes écrites dans le mois, ou
avec cinq mille, je regarderais de plus près. Dans le premier
cas, parce que le problème était probablement particulièrement
compliqué, et dans le seconde, soit il a appris une technique
nouvelle qui pourrait m'aider aussi, soit il a écrit trop vite,
sans penser.

Quelles sont celles qui ne servent pas ?

Toute information est bonne. Certaines sont meilleurs que
d'autres, mais il y en a peu qui ne me servent jamais.

Si vous avez des liens interessants sur ce sujet, je suis
preneur.

Plus que sur les mesures en soi, http://www.sei.cmu.edu/ est
une référence sur tout ce qui concerne la génie logicielle.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Aurelien Regat-Barrel wrote:

Je suis fan de ce site. Ce Joel a une vision très instructrice du métier
de développeur, en ce qui me concerne du moins.

Oui. Il pose même des questions intéressantes sur le C++ :

«
En C++, les classes de chaînes de caractères sont censées vous permettre
de faire semblant que les chaînes de caractères sont un type de données
à part entière. Elles tentent de faire abstraction du fait que les
chaînes de caractères sont difficiles à manipuler et vous permettent
d'agir comme si c'était aussi facile qu'avec des entiers. Presque toutes
les classes C++ de chaînes de caractères surchargent l'opérateur " + "
et vous pouvez écrire s + "toto" pour les concaténer. Mais vous savez
quoi ? Peu importe à quel point elles essaient, il n'y a pas sur Terre
de classe C++ de chaînes de caractères qui vous permette d'écrire "toto"
+ "titi", car les chaînes de caractères littérales en C++ sont toujours
des char*, jamais des chaînes. L'abstraction a créé une fuite que le
langage ne vous permet pas de reboucher. (De manière amusante,
l'histoire de l'évolution de C++ au fil du temps peut être décrite comme
l'histoire des tentatives pour reboucher les fuites dans l'abstraction
des chaînes de caractères. Pourquoi ne pouvaient-ils pas simplement
ajouter une classe de chaîne de caractères native au langage lui-même?
Cela m'échappe pour le moment.)
»

--
Arnaud

Aurelien Regat-Barrel wrote:

Je viens de le retrouver, le voilà :
(C'est de l'anglais)
http://www.joelonsoftware.com/news/20020715.html

Je suis fan de ce site. Ce Joel a une vision très instructrice
du métier de développeur, en ce qui me concerne du moins.
J'hésite à acheter son livre. Quelqu'un l'a lu ?

Je viens de jeter un coup d'oeil au site ; j'avoue que je suis
loin d'être emballé.

À son crédit, il dit lui-même que ses conseils concernent les
ISV, et qu'ils pourraient ne pas s'appliquer à d'autres
contextes. Mais du peu que j'ai vu, il ne connaît pas beaucoup
de ce qui se fait en génie logicielle, et je crois que si les
moyens de l'appliquer dépend bien du contexte, les principes de
base reste.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Arnaud Meurgues wrote:

Aurelien Regat-Barrel wrote:

Je suis fan de ce site. Ce Joel a une vision très instructrice
du métier de développeur, en ce qui me concerne du moins.

Oui. Il pose même des questions intéressantes sur le C++ :

Pose, ou simplement repête ?

En C++, les classes de chaînes de caractères sont censées vous permettre
de faire semblant que les chaînes de caractères sont un type de données
à part entière. Elles tentent de faire abstraction du fait que les
chaînes de caractères sont difficiles à manipuler et vous permettent
d'agir comme si c'était aussi facile qu'avec des entiers. Presque toutes
les classes C++ de chaînes de caractères surchargent l'opérateur " + "
et vous pouvez écrire s + "toto" pour les concaténer. Mais vous savez
quoi ? Peu importe à quel point elles essaient, il n'y a pas sur Terre
de classe C++ de chaînes de caractères qui vous permette d'écrire "toto"
+ "titi", car les chaînes de caractères littérales en C++ sont toujours
des char*, jamais des chaînes. L'abstraction a créé une fuite que le
langage ne vous permet pas de reboucher. (De manière amusante,
l'histoire de l'évolution de C++ au fil du temps peut être décrite comme
l'histoire des tentatives pour reboucher les fuites dans l'abstraction
des chaînes de caractères. Pourquoi ne pouvaient-ils pas simplement
ajouter une classe de chaîne de caractères native au langage lui-même?
Cela m'échappe pour le moment.)
»

Le problème est connu depuis longtemps ; je n'avais pas besoin
de ce cite pour me l'apprendre. Si c'est tous ce qu'apportait le
site. (Ce qu'on peut dire, c'est qu'il écrit bien. C'est un
plaisir de lire, même s'il ne dit rien d'intéressant. Ce qui
n'est pas rien ; je suis convaincu qu'une des raisons de la
réussite de C, c'est que Kernighan est un auteur génial.)

Aussi, je crois que le comité s'y est intéressé. Je ne suis pas
trop la normalisation depuis quelques années, mais il me semble
qu'il y a des membres qui se posent bien le problème : comment
faire pour que les classes peuvent ressembler plus à des types
de base. Au moins en partie, par rapport à l'initialisation.
(Parce que note bien, c'est un problème général, et non propre à
des chaînes de caractères. En ce qui me concerne, le fait que
"toto" + "titi" ne marche pas est assez mineur -- j'obtiens le
même effet pratique en ôtant le +. Ce qui n'est peut-être pas
joli, mais ce n'est pas la fin du monde. En revanche, le cirque
qu'il faut pour créer un std::vector const ou un std::map const
m'embête plus.)

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

James Kanze wrote:

Pose, ou simplement repête ?

Oh, peu importe... Je ne voulais pas dire que c'était un génie, mais
juste ramener le fil dans le sujet du newsgroup... :-)

--
Arnaud

Oui. Il pose même des questions intéressantes sur le C++ :

C'est cet article si je ne m'abuse:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Ce n'est pas pour ses remarques sur le C++, surtout après les
commentaires de James, que j'ai apprécié certains de ses articles. Mais
plutôt sur ses commentaires sur le développement en général,
indépendamment de tout langage. Par exemple, dans ce même article
justement, il explique que selon lui la programmation ne s'est pas
simplifiée du tout depuis 15 ans, malgré tout plein d'outils et de
langages toujours meilleurs, toujours plus simples. Paradoxalement, la
prolifération de technologies simplifiant la programmation l'a rendu
plus complexe.
Pour un jeune développeur comme moi, je trouve ce genre de retour
d'expérience important. Je cherche un livre dans cet esprit, d'où ma
question. Si vous avez de meilleures références, je suis preneur :-)
J'ai entendu beaucoup de bien de "Le mythe du mois-homme".

--
Aurélien Regat-Barrel

Aurelien Regat-Barrel wrote:

Oui. Il pose même des questions intéressantes sur le C++ :

C'est cet article si je ne m'abuse:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Ce n'est pas pour ses remarques sur le C++, surtout après les
commentaires de James, que j'ai apprécié certains de ses
articles. Mais plutôt sur ses commentaires sur le
développement en général, indépendamment de tout langage.

C'est justement là où je le trouve le plus faible. Il a une
connaissance (et une expérience) assez limitée dans le domaine.
Il n'a pas l'air de connaître ce qui se fait dans les meilleurs
environements.

Par exemple, dans ce même article justement, il explique que
selon lui la programmation ne s'est pas simplifiée du tout
depuis 15 ans, malgré tout plein d'outils et de langages
toujours meilleurs, toujours plus simples. Paradoxalement, la
prolifération de technologies simplifiant la programmation l'a
rendu plus complexe.

Ce qui n'est qu'un exemple de comment il se trompe. Il y a 15
ans, le hacker était encore la règle. Très peu d'endroits
utiliser les connaissances réeles de la génie logicielle. Et on
le remarquait d'après la qualité des logiciels. Aujourd'hui, le
progrès est énorme : c'est assez exceptionnel, par exemple,
qu'un projet ne finit pas dans les termines, et le taux
d'erreurs a baissé énormement. Justement, ce que je lui
rapproche, c'est d'être rester quinze ans en arrière dans ce
domaine.

Pour un jeune développeur comme moi, je trouve ce genre de
retour d'expérience important. Je cherche un livre dans cet
esprit, d'où ma question. Si vous avez de meilleures
références, je suis preneur :-) J'ai entendu beaucoup de bien
de "Le mythe du mois-homme".

C'est la référence. Il a plus de vingt-cinq ans ; beaucoup s'est
passé depuis. Mais il reste essentiel. C'est à la génie
logicielle ce que c'est "Structured Programming" pour la
programmation ; si tu n'appliques pas les principes expliquées
dans "The Mythical Man-Month", ce n'est pas la peine d'aller
plus loin.

Parmi les livres plus récents, ceux de Watts Humphrey me
semblent incontournable.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

J'ai entendu beaucoup de bien
de "Le mythe du mois-homme".

C'est la référence. Il a plus de vingt-cinq ans ; beaucoup s'est
passé depuis. Mais il reste essentiel. C'est à la génie
logicielle ce que c'est "Structured Programming" pour la
programmation ; si tu n'appliques pas les principes expliquées
dans "The Mythical Man-Month", ce n'est pas la peine d'aller
plus loin.

Bon, je sais quoi choisir :-)

--
Aurélien Regat-Barrel