Discussion :

[Invité]

Quand je pense que nombreux sont les développeurs qui ne savent même pas ce qu'un débuggeur est. Alors un profileur

Alors là, qu'est ce que je suis d'accord! On en revient au débat sur l'enseignement...

Ceci dit, pour avoir essayé de faire utiliser, dans des vies antérieures, débuggers et profileurs à des informaticiens "de base", y'a des fois où l'on préfère qu'ils ne les connaissent pas... Sans ces outils, ils sont lents et pas trop bons, avec, ils deviennent paranoiaques et encore moins bons... Là aussi, il faut un niveau de base.

Dans la pratique, ça signifie des boites qui refusent des contrats, plutôt que d'embaucher des nuls. C'est con...

François

[Issam_Lahlali]

Pour l'histoire d'optimisation et de profiling il y a une démarche qui peut beaucoup aider, il s'agit de l'approche "Test Driven" ou dés le départ du projet on commence a faire des tests unitaires , pour finalement avoir une batterie de test ou on a entre autre le temps d'exécution de ce test , et puisque chaque test isole une fonctionnalité on peut facilement détecter quelle partie du code est couteuse donc on cible rapidement l'endroit qu'il faut améliorer.

et la difficulté de cette démarche c'est qu'il faut la commencer dés le départ pas a la fin, ça devient très difficile si on veut l'implémenter a la fin du dev.

malheureusement on parle plus de cette approche dans d'autres langages que dans C++ , et rare ceux qui ont utiliser CppUnit ou équivalent.

ça apporte beaucoup d'avantages, juste l'avantage d'éviter les redressions et le stress lié a chaque livraison ou en général le client appelle quelques minutes après la livraison pour signaler qu'il y pas mal de régressions

[Invité]

Pour l'histoire d'optimisation et de profiling il y a une démarche qui peut beaucoup aider, il s'agit de l'approche "Test Driven" ou dés le départ du projet on commence a faire des tests unitaires , pour finalement avoir une batterie de test ou on a entre autre le temps d'exécution de ce test , et puisque chaque test isole une fonctionnalité on peut facilement détecter quelle partie du code est couteuse donc on cible rapidement l'endroit qu'il faut améliorer.

Ce qui est un peu étonnant, c'est que ceci soit qualifié d'approche... Tester les fonctions au moment où on les écrit, et pas à la fin, quand on les assemble dans un gigantesque Mécano, ça me parait la seule possibilité.

Non?

Francois

[koala01]

Ce qui est un peu étonnant, c'est que ceci soit qualifié d'approche... Tester les fonctions au moment où on les écrit, et pas à la fin, quand on les assemble dans un gigantesque Mécano, ça me parait la seule possibilité.

Non?

Francois

Le terme est, certes mal choisi, mais quel autre utiliser

Bien que l'on sorte encore une fois du nœud du débat, il est clair que l'idéal reste d'avoir un optique de développement où les différentes phases (analyse des besoins, conception, codage, test,profiling suivi de bugs / régressions, documentation) sont habilement intégrées les unes au autres et où chaque phase intervient en temps utile (et pas forcément dans l'ordre dans lequel je les ai cité )...

Mais cela nous ramène systématiquement aux problèmes de la (l'in)compétence des gens, de l'enseignement et de la politique de l'équipte / de l'entreprise

Car, si on a jusqu'à présent pesté essentiellement sur les deux premiers, le troisième problème est aussi à prendre en compte si l'on veut avoir une vision globale des choses:

Autant il sera agréable à quelqu'un de compétant de travailler dans une entreprise où la politique est, justement, d'intégrer correctement les différentes phases et d'utiliser les bons outils au bon moment, autant la compétence seule d'un programmeur au sein d'une entreprise qui n'a pas conscience de ce besoin d'intégration globale n'améliorera en définitive pas grand chose (EDIT et fera que le programmeur compétant s'emm..dera comme un rat mort dans son travail, avec sans doute comme corolaire le fait que les seuls programmeurs que l'entreprise saura garder seront... les incompétents )

[metagoto]

"agile development" et C++ sont rarement associés dans une même phrase

Alors qu'il est concevable de faire des tests unitaires pour C++, j'ai du mal à imaginer comment on s'y prend pour tester du C++ au niveau behavioral (disons un niveau supérieur au tests unitaires) sans devoir écrire une app en tant que telle (et donc lui appliquer des tests unitaires aussi ?)
Enfin, c'est mon interrogation. Jusqu'à quel point pratiquez-vous une approche test driven ?

Juste par curiosité, je suis tombé sur cet interview de Stepanov et McJones au sujet de leur récent bouquin The Elements of Programming. Ils mentionnent un travail en pair programming avec tests unitaires pour le code présenté dans leur bouquin. Les sources sont dispo ici:
http://www.elementsofprogramming.com/code.html
Interessant.

[Invité]

Autant il sera agréable à quelqu'un de compétant de travailler dans une entreprise où la politique est, justement, d'intégrer correctement les différentes phases et d'utiliser les bons outils au bon moment, autant la compétence seule d'un programmeur au sein d'une entreprise qui n'a pas conscience de ce besoin d'intégration globale n'améliorera en définitive pas grand chose

Je ne suis qu'à moitié d'accord, mais je pense que c'est une question de parcours professionnel.

Dans les PME (le monde dans lequel je vis actuellement), les développeurs sont généralement assez libres (personnellement, je suis prêt à avoir un compilateur, voire un langage par personne, si ça permet auxdites personnes de bien travailler), et il n'y a pas de "politique" sur les différentes phases, on est juste trop petits pour ça. En revanche, on repère vite la "perle rare", c'est à dire la personne qui teste son code, qui vient te poser des questions quand il a besoin d'info (et seulement dans ces cas), qui, mine de rien, pose les bonnes questions, et lit les bons livres.

(Malheureusement, elle est rare, comme son nom l'indique: en général, tu tombes plutôt sur la personne qui vient te voir toutes les 3 minutes, pour te poser des questions auxquelles une lecture des premières pages du manuel de son compilateur répond, et qui quand tu lui demandes si le code est testé, te répond "il compile"...)

Dans une grosse boîte, peut être que la politique d'entreprise est déterminante. Une petite boîte, c'est juste une somme d'individus, s'ils sont bons, c'est une bonne boîte, sinon...

Francois

[Invité]

"agile development" et C++ sont rarement associés dans une même phrase

Alors qu'il est concevable de faire des tests unitaires pour C++, j'ai du mal à imaginer comment on s'y prend pour tester du C++ au niveau behavioral (disons un niveau supérieur au tests unitaires) sans devoir écrire une app en tant que telle (et donc lui appliquer des tests unitaires aussi ?)

Je ne vois pas le problème spécifique au C++. Lors de la conception, quand on découpe le problème en parties, qui vont former les entités du programme final, il faut concevoir les tests qui vont avec, qui vérifient, en gros, les "contrats" associés à chaque méthode, et testent l'invariance des invariants.

Qaunt à l'agilité, elle est possible en C++, mais demande un peu de ruse... Pas trop de hiérarchies de la mort, à 30 niveaux, pas trop d'abstraction gratuite, ...

Francois

[Jean-Marc.Bourguet]

"agile development"

Apres XML, le developpement agile... difficile de resister quand meme (Et malheureusement, ce n'est pas qu'une vision du management)

[Matthieu Brucher]

Pour l'histoire d'optimisation et de profiling il y a une démarche qui peut beaucoup aider, il s'agit de l'approche "Test Driven"

Pour le debuggage, OK, pour optimisation et profiling, aucun rapport.
Maintenant, on ajoute parfois des indicateurs de vitesse pour les tests, mais c'est plus lors des tests fonctionnels que lors des tests uniatires, et pour cause, on n'a pas encore profilé l'application

Ce qui est un peu étonnant, c'est que ceci soit qualifié d'approche... Tester les fonctions au moment où on les écrit, et pas à la fin, quand on les assemble dans un gigantesque Mécano, ça me parait la seule possibilité.

Oui, c'est ce que tu crois, mais en fait non. Dans la pratique, de nombreuses SSII ont l'air de faire les tests à la fin. Même dans les contrats, l'ajout du résultat des tests unitaires dans les livrables est payant.

Juste par curiosité, je suis tombé sur cet interview de Stepanov et McJones au sujet de leur récent bouquin The Elements of Programming. Ils mentionnent un travail en pair programming avec tests unitaires pour le code présenté dans leur bouquin. Les sources sont dispo ici:
http://www.elementsofprogramming.com/code.html
Interessant.

C'est un des points d'XP, mais bon, c'est rarement applicable dans la pratique surtout pas dans mon contexte par exemple.

[koala01]

Je ne suis qu'à moitié d'accord, mais je pense que c'est une question de parcours professionnel.

Dans les PME (le monde dans lequel je vis actuellement), les développeurs sont généralement assez libres (personnellement, je suis prêt à avoir un compilateur, voire un langage par personne, si ça permet auxdites personnes de bien travailler), et il n'y a pas de "politique" sur les différentes phases, on est juste trop petits pour ça. En revanche, on repère vite la "perle rare", c'est à dire la personne qui teste son code, qui vient te poser des questions quand il a besoin d'info (et seulement dans ces cas), qui, mine de rien, pose les bonnes questions, et lit les bons livres.

(Malheureusement, elle est rare, comme son nom l'indique: en général, tu tombes plutôt sur la personne qui vient te voir toutes les 3 minutes, pour te poser des questions auxquelles une lecture des premières pages du manuel de son compilateur répond, et qui quand tu lui demandes si le code est testé, te répond "il compile"...)

Dans une grosse boîte, peut être que la politique d'entreprise est déterminante. Une petite boîte, c'est juste une somme d'individus, s'ils sont bons, c'est une bonne boîte, sinon...

Francois

C'est donc bien que tu as une "bonne politique" dans l'entreprise

Le fait est qu'il arrive (ce n'est pas forcément le cas partout, encore heureux) de trouver des entreprises dans lesquelles:

• on te dis "perd pas ton temps avec la doc"
• on n'a jamais le temps pour répondre à la moindre question
• on t'engueule pour ainsi dire si tu demande la doc d'un projet interne
• on est fort pres de "la gestion de bug... c'est quoi cette bête"
• on te dit "perd pas ton temps avec les tests"
• on te dit "un système de gestion de versions? pour quoi faire"
• j'en passe et de meilleures

Et ce ne sont pas forcément les entreprises qui font faillite après trois ans

Je suis d'accord avec toi qu'une entreprise dans laquelle tous ces points seraient réunis est à la limite de la caricature, mais il y a de nombreuses sociétés dans lesquelles le mot d'ordre est au moins l'une ou l'autre de ces dérives

[metagoto]

Apres XML, le developpement agile... difficile de resister quand meme (Et malheureusement, ce n'est pas qu'une vision du management)

Je suis tout à fait d'accord avec toi. Tout ceci me paraît être bien plus du hype qu'autre chose...

En rédigeant ce (court) post, histoire de vérifier l'inexistance de framework de mock objects pour C++, je suis tombé sur ce projet de google:
http://code.google.com/p/googlemock/
Interessant (tout ce que fait google est interessant de toute façon, non ? )

[Luc Hermitte]

"agile development" et C++ sont rarement associés dans une même phrase

Alors qu'il est concevable de faire des tests unitaires pour C++, j'ai du mal à imaginer comment on s'y prend pour tester du C++ au niveau behavioral (disons un niveau supérieur au tests unitaires) sans devoir écrire une app en tant que telle (et donc lui appliquer des tests unitaires aussi ?)
Enfin, c'est mon interrogation. Jusqu'à quel point pratiquez-vous une approche test driven ?

Juste par curiosité, je suis tombé sur cet interview de Stepanov et McJones au sujet de leur récent bouquin The Elements of Programming. Ils mentionnent un travail en pair programming avec tests unitaires pour le code présenté dans leur bouquin. Les sources sont dispo ici:
http://www.elementsofprogramming.com/code.html
Interessant.

Les tests unitaires sont moins critiques en C++ que dans les langages interprétés ou ceux à typage laxiste. La phase de compilation traite quantité de problèmes traités par TU ailleurs.

Après je m'en sers pour vérfier des mises en œuvres d'algos. Pas pour les partie MT, ou IHM. Et puis, TI et TV existaient depuis déjà pas mal de temps. Ils ont leur utilité, et il ne faut pas les négliger.

Pour le bouquin, dans le passé il était disponible en ligne avec ses sources LaTeX. En gros ils y refont quantités d'algorithmes comme ceux présents dans le STL. C'est très intéressant. Et les TU sont particulièrement adaptés à ce type de code.

Mais alors avec CppUnit ? Certainement pas. Il y a tellement mieux.

[Issam_Lahlali]

Pour le debuggage, OK, pour optimisation et profiling, aucun rapport.

lorsqu'on a une bonne batterie de tests finalement on isole le test de chaque fonctionnalité, est si on a un probléme d'optimisation on peut savoir laquelle qui est couteuse en temps, mais c'est valide que si on a une vrai batterie test pas juste 1 ou 2 tests.


et bien sur c'est très couteux et en général on ne voit pas l'intérêt ,et pour le voir juste fait les statistique sur les rapports d'activités des developpeurs ou le temps passé sur la maintenance est énorme, donc finalement ce qu'on va perdre au départ comme temps on va le gagner a la fin et surtout ca contribue a avoir un produit de qualité, pas un produit ou on resoud un bug et on introduit une dizaine

et sincèrement en pratique l'utilisation des profilers en C++ est une chose très délicate et très couteuse en temps,surtout pour les grands projets ou juste le chargement des dlls instrumentés prend des minutes.

[metagoto]

Pour le bouquin, dans le passé il était disponible en ligne avec ses sources LaTeX. En gros ils y refont quantités d'algorithmes comme ceux présents dans le STL. C'est très intéressant. Et les TU sont particulièrement adaptés à ce type de code.

Oui, j'ai pu lire une partie d'un extrait officiel. J'ai prévu de me l'offrir un de ces 4 (Stepanov, c'est comme google, c'est interessant par définition, non ? )

Avec mon oeil externe et candide, j'ai quand même l'impression que les tests unitaires sont parfois négligés en C++, non pas parceque le typage statique catch beaucoup d'erreurs (quoique, je comprends que ça aide), mais parce que c'est fastidieux à mettre en place en C++. Ce n'est pas dans la culture du C++ (d'ailleurs je ne serai pas étonné que cela participe indirectement à dévaloriser le C++ auprès des agile managers ). Un petit Herb Sutter "Agile C++ for dummies" ferait un malheur eheh

[Issam_Lahlali]

Mais alors avec CppUnit ? Certainement pas. Il y a tellement mieux.

en fait le probléme n'est pas forcement l'outil a utiliser, on peut même faire un outil fait maison , mais le probléme c'est qu'on voit pas du tout l'intérêt des tests unitaires comme quoi c'est un autre truc a la mode qui ne sert a rien.

et le role de TU c'est pas le test syntaxique mais comportemental, ou on essaye de detecter les bugs d'implementations et de behavior, si on attend qu'une fonction qui calcule un taux qu'elle retourne 1 et elle retourne 2 c'est pas forcement un probléme de syntaxe mais l'algorithme n'est pas bien implementé.

et revenons au cœur de la discussion, la communauté C++ ne communique pas trop a propos de ce sujet, est ce qu'on considère que tout ce qui n'est pas initié par la communauté C++ c'est du marketing et ça ne sert finalement a rien?

[Matthieu Brucher]

et sincèrement en pratique l'utilisation des profilers en C++ est une chose très délicate et très couteuse en temps,surtout pour les grands projets ou juste le chargement des dlls instrumentés prend des minutes.

Tout dépend du profiler, du compilateur, ... Tu prends un valgrind, et oui, tu souffres. Tu prends un Visual Studio ou un Intel Amplifier, aucun souci, mais tu n'auras pas les mêmes infos dans les deux.

[Luc Hermitte]

Avec mon oeil externe et candide, j'ai quand même l'impression que les tests unitaires sont parfois négligés en C++, non pas parce que le typage statique catch beaucoup d'erreurs (quoique, je comprends que ça aide), mais parce que c'est fastidieux à mettre en place en C++. Ce n'est pas dans la culture du C++ (d'ailleurs je ne serai pas étonné que cela participe indirectement à dévaloriser le C++ auprès des agile managers ).

Ou parce que l'agile c'est revenir en arrière ? Pour reprendre le Dilbert, on arrête la conception et on code à l'arrache. Cela voudrait-il dire que la culture C++ est plus pro que les autres ?

Plus sérieusement, pour une bibliothèque d'algo, il est évident que cela sert (cf boost). Pour une application, ils ne sont qu'un tout petit élément parmi d'autres tout aussi importants.

Accessoirement, c'est vraiment très simple à mettre en œuvre -- tant que l'on ne tombe pas dans le piège jUnit -> cppUnit.

et revenons au cœur de la discussion, la communauté C++ ne communique pas trop a propos de ce sujet, est ce qu'on considère que tout ce qui n'est pas initié par la communauté C++ c'est du marketing et ça ne sert finalement a rien?

Il y a-t-il vraiment besoin de 50 articles à ce sujet ? Il y a plein de gens qui vantent les mérites du principe, donc nul besoin d'y revenir, après reste à trouver un bon framework et c'est tout.

[Invité]

et sincèrement en pratique l'utilisation des profilers en C++ est une chose très délicate et très couteuse en temps,surtout pour les grands projets ou juste le chargement des dlls instrumentés prend des minutes.

Ben, c'est un peu comme débuguer, en fait... Essayer d'un coup de profileur de savoir pourquoi une énorme application se traine (et espérer trouver un remède), c'est très difficile. Il faut travailler par module (la plupart des profileurs le permettent), en ayant une idée générale du temps passé dans chacun (ça aussi les profileurs modernes le permettent).

L'idéal est d'utiliser un profileur assez tôt dans le développement, pour savoir où sont les zones critiques, ce qu'il faut améliorer, et ce qui n'a aucune importance. Ce type de développement fait un peu mentir Knuth, puisqu'il consiste en fait à construire l'application autour d'un assez petit nombre de morceaux de codes critiques optimisés et testés, mais c'est souvent une approche assez efficace.

Francois

[jabbounet]

Pour le debuggage, OK, pour optimisation et profiling, aucun rapport.
Maintenant, on ajoute parfois des indicateurs de vitesse pour les tests, mais c'est plus lors des tests fonctionnels que lors des tests uniatires, et pour cause, on n'a pas encore profilé l'application

je suis plutot d'accord avec ça les test unitaire ne sont pas forcément reprenseatifs des cas d'utilisation réels de ton appli, donc faire du profiling dessus peu ne pas apporter grand chose. par exemple optimiser une classe qui n'est utilisé que de façon annécdotique dans l'application, mais qui apparait comme lente en test unitaire ne sert vraiment pas a grand chose.

maintenant identifier les cas qui sont representatifs n'est pas toujours évident quand le produit est neuf et que tu le vend a d'autres entreprises. la façon dont on pense qu'elle sera utilisé en interne n'est pas forcément la façon dont les clients l'utiliseront. et parfois on a vraiment des surprises aussi de ce coté là.

[r0d]

Pour revenir sur la question initiale, il est évident que c'est une mauvaise question et que la communauté C++ s'intéresse énormément à la conception. Peut-être même en premier lieu, mais là cela dépend de ce que nous entendons par "communauté". Le simple fait d'être passé du C au C++ clôt la discussion (après, on peut en rajouter en parlant des multiples possibilités que le langage offre en matière de conception - multi-paradigme - et des efforts constants qui sont faits dans ce sens par le comité de normalisation, etc, mais ça en me semble pas nécessaire.). C'est tellement évident qu'effectivement, cette question, pour nous, sonne comme un troll.

En revanche, plus tard dans la discussion, est venu le classique: "le c++ est un langage élitiste".

Ma réponse à cette critique ('critique' au sens scientifique, positif. Toute critique étant la bienvenue, et même encouragée) est la suivante. Le c++ est un langage qui permet d'accéder aux plus basses couches (on peut inclure de l'assembleur dans du code c++), mais également il permet un niveau d'abstraction très élevé, et ce, de différentes façons (héritages, template,...). C'est, à ma connaissance, le seul langage qui permet cela. Et cela a un coût, effectivement. A bas niveau, il faut faire plus attention à certaines choses. A haut niveau, certains patterns nécessitent quelques "remaniements". Etc.

Donc si je suis d'accord que c'est un langage qui nécessite un peu plus d'attention, je ne suis pas d'accord pour en faire un langage "élitiste". Par exemple j'ai travaillé avec des programmeurs issus du java qui s'en sont très bien sortis lorsqu'il fut question de coder en C++. Avec quelques efforts certes (d'ailleurs finalement pas beaucoup plus que l'inverse, pe. quand moi je dois coder en java), mais ce n'est pas non plus Babel. Et puis il y a toutes les ressources sur internet pour s'en sortir. Le c++ serait élitiste s'il n'y avait pas de ressources, que le seul moyen d'apprendre serait d'avoir un "maître", mais là tout est disponible, il suffit juste d'un peu de... je sais pas... d'envie peut-être?

Bon donc moi, je connais bien le C#, assez bien le java, très bien le C++, et un peu de divers autres langages, et je suis d'accord pour dire que le C++ est un peu plus difficile que les autres car il demande plus d'attention, mais je rejette catégoriquement le qualificatif de 'élitiste'.