a écrit dans le message de
news:Pourquoi ? D'abord, évidemment, il faut une édition de liens là-dedans
quelque part. Or, des deux choses une :
Bon, par déformation je n'ai parlé que de la compilation, mais après
avoir éditer les sources, l'appuie d'une touche lance la compilation
des sources impactés et lance automatiquement l'édition de lien.- L'édition de liens et le code que tu déboggues, c'est le test
unitaire. Mais dans ce cas-là, tu as mis assez de sorties d'état
pour que l'erreur soit évidente, sans le déboggueur.
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne
peux pas faire l'édition de liens, parce qu'il en dépend d'autres
modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y
a une équipe d'integration.)
Là, il y a un problème d'échelle, je parlais en mon nom, développeur
d'applis non-gigantesques.
Que cela ne puisse pas s'appliquer partout, était implicite.
Dans la pratique, je me sers du déboggueur prèsqu'uniquement pour
l'analyse des core dumps : surtout pour le stack walkback après
l'échec d'une assertion. Sinon, assez rarement, pour l'analyse du
dynamique d'un code que je n'ai pas écrit.
Dans le professionnel, je réfuse d'essuyer les plâtres ; je ne
considère
Je n'ai pas cette chance, il m'arrive, encore, aujourd'hui, des faire
avec des brics et des brocs.que des produits « établis » avec assez d'utilisateurs pour qu'on
puisse être sûr que les grosses erreurs ont été déjà éradiquées.
Mais même sans essuyer les plâtres, il y a un coût énorme pour
simplement évaluer. Alors, à moins que la nouvelle technologie
m'apporte quelque chose, ce n'est pas la peine. Et quand on
m'annonce que l'amélioration apportée par un IDE, c'est une
amélioration de l'ergonomie du cycle edition+compilation+debug, ça
ne m'intéresse pas, parce que c'est un cycle qui n'existe pas dans
mon développement. C'est un peu comme si on offrait une technologie
pour rendre l'utilisation d'une voiture à cheval deux fois plus
facile.
De ton point de vue, fort honorable, je ne consterais pas la metaphore
de la voiture. De mon point de vue, je dirais : peintre sur soie et
peintre en batiment :-)
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0411180108.2e328949@posting.google.com...
Pourquoi ? D'abord, évidemment, il faut une édition de liens là-dedans
quelque part. Or, des deux choses une :
Bon, par déformation je n'ai parlé que de la compilation, mais après
avoir éditer les sources, l'appuie d'une touche lance la compilation
des sources impactés et lance automatiquement l'édition de lien.
- L'édition de liens et le code que tu déboggues, c'est le test
unitaire. Mais dans ce cas-là, tu as mis assez de sorties d'état
pour que l'erreur soit évidente, sans le déboggueur.
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne
peux pas faire l'édition de liens, parce qu'il en dépend d'autres
modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y
a une équipe d'integration.)
Là, il y a un problème d'échelle, je parlais en mon nom, développeur
d'applis non-gigantesques.
Que cela ne puisse pas s'appliquer partout, était implicite.
Dans la pratique, je me sers du déboggueur prèsqu'uniquement pour
l'analyse des core dumps : surtout pour le stack walkback après
l'échec d'une assertion. Sinon, assez rarement, pour l'analyse du
dynamique d'un code que je n'ai pas écrit.
Dans le professionnel, je réfuse d'essuyer les plâtres ; je ne
considère
Je n'ai pas cette chance, il m'arrive, encore, aujourd'hui, des faire
avec des brics et des brocs.
que des produits « établis » avec assez d'utilisateurs pour qu'on
puisse être sûr que les grosses erreurs ont été déjà éradiquées.
Mais même sans essuyer les plâtres, il y a un coût énorme pour
simplement évaluer. Alors, à moins que la nouvelle technologie
m'apporte quelque chose, ce n'est pas la peine. Et quand on
m'annonce que l'amélioration apportée par un IDE, c'est une
amélioration de l'ergonomie du cycle edition+compilation+debug, ça
ne m'intéresse pas, parce que c'est un cycle qui n'existe pas dans
mon développement. C'est un peu comme si on offrait une technologie
pour rendre l'utilisation d'une voiture à cheval deux fois plus
facile.
De ton point de vue, fort honorable, je ne consterais pas la metaphore
de la voiture. De mon point de vue, je dirais : peintre sur soie et
peintre en batiment :-)
a écrit dans le message de
news:Pourquoi ? D'abord, évidemment, il faut une édition de liens là-dedans
quelque part. Or, des deux choses une :
Bon, par déformation je n'ai parlé que de la compilation, mais après
avoir éditer les sources, l'appuie d'une touche lance la compilation
des sources impactés et lance automatiquement l'édition de lien.- L'édition de liens et le code que tu déboggues, c'est le test
unitaire. Mais dans ce cas-là, tu as mis assez de sorties d'état
pour que l'erreur soit évidente, sans le déboggueur.
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne
peux pas faire l'édition de liens, parce qu'il en dépend d'autres
modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y
a une équipe d'integration.)
Là, il y a un problème d'échelle, je parlais en mon nom, développeur
d'applis non-gigantesques.
Que cela ne puisse pas s'appliquer partout, était implicite.
Dans la pratique, je me sers du déboggueur prèsqu'uniquement pour
l'analyse des core dumps : surtout pour le stack walkback après
l'échec d'une assertion. Sinon, assez rarement, pour l'analyse du
dynamique d'un code que je n'ai pas écrit.
Dans le professionnel, je réfuse d'essuyer les plâtres ; je ne
considère
Je n'ai pas cette chance, il m'arrive, encore, aujourd'hui, des faire
avec des brics et des brocs.que des produits « établis » avec assez d'utilisateurs pour qu'on
puisse être sûr que les grosses erreurs ont été déjà éradiquées.
Mais même sans essuyer les plâtres, il y a un coût énorme pour
simplement évaluer. Alors, à moins que la nouvelle technologie
m'apporte quelque chose, ce n'est pas la peine. Et quand on
m'annonce que l'amélioration apportée par un IDE, c'est une
amélioration de l'ergonomie du cycle edition+compilation+debug, ça
ne m'intéresse pas, parce que c'est un cycle qui n'existe pas dans
mon développement. C'est un peu comme si on offrait une technologie
pour rendre l'utilisation d'une voiture à cheval deux fois plus
facile.
De ton point de vue, fort honorable, je ne consterais pas la metaphore
de la voiture. De mon point de vue, je dirais : peintre sur soie et
peintre en batiment :-)
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies
de GCC vers un format exploitable par Semantic.
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies
de GCC vers un format exploitable par Semantic.
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
Pourquoi ? J'avais un moment pensé exporter des infos requeillies
de GCC vers un format exploitable par Semantic.
writes:Matthieu Moy wrote in message
news:...writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse
en rien de pouvoir lancer le déboggueur directement depuis
l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core
dans la production. C-à-d une fois tous les six mois, environ.
C'est plus rare que moi, ca. Mais je crois que je touche plus a du
code que je n'ai pas ecrit que toi.
kanze@gabi-soft.fr writes:
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote in message
news:<vpqfz38elsl.fsf@ecrins.imag.fr>...
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse
en rien de pouvoir lancer le déboggueur directement depuis
l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core
dans la production. C-à-d une fois tous les six mois, environ.
C'est plus rare que moi, ca. Mais je crois que je touche plus a du
code que je n'ai pas ecrit que toi.
writes:Matthieu Moy wrote in message
news:...writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse
en rien de pouvoir lancer le déboggueur directement depuis
l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core
dans la production. C-à-d une fois tous les six mois, environ.
C'est plus rare que moi, ca. Mais je crois que je touche plus a du
code que je n'ai pas ecrit que toi.
Ce qui est intéressant, c'est que le prix du développement jusqu'au
déployement n'était pas plus cher. Faire correctement ne coûte pas plus
cher au début, et nettement moins cher à la longue. Mais il y a encore
beaucoup de boîtes qui ne l'ont pas compris.
Ce qui est intéressant, c'est que le prix du développement jusqu'au
déployement n'était pas plus cher. Faire correctement ne coûte pas plus
cher au début, et nettement moins cher à la longue. Mais il y a encore
beaucoup de boîtes qui ne l'ont pas compris.
Ce qui est intéressant, c'est que le prix du développement jusqu'au
déployement n'était pas plus cher. Faire correctement ne coûte pas plus
cher au début, et nettement moins cher à la longue. Mais il y a encore
beaucoup de boîtes qui ne l'ont pas compris.
wrote:Marc Boyer wrote in message
news:<cnf31i$7lg$...In article , drkm wrote:Marc Boyer writes:K. Ahausse wrote:"Marc Boyer" a écrit dans
le message de news:cncj0u$l3m$
Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.
Je ne sais pas ce que tu appelles IDE, mais la clef est
d'analyser le code. Emacs fait ça plutôt pas mal, cfr
<URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Oui, ou du moins un grand sous-ensemble.
Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous
un shell Unix:-).
L'aspect graphique est négligeable pour moi (à moins de développer
une IHM graphique bien sur).
En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches
nécessaires au développement des logiciels. Et voilà le hic, parce
que les tâches nécessaires au développement des logiciels dépendent
de qui développe et comment.
Oui, ou ils forcent à utiliser *une* solution.
Donc, les premiers IDE se vautaient beaucoup de la simplification
dans la cycle edit-compile-debug -- du coup, ça ne m'intéresse pas,
parce que ce n'est pas comme ça que je développe. (C'est où, la
documentation, dans ce cycle ? Et comment prend-il en compte la
gestion des versions, ou les révues de code ?)
Des choses comme VC++ ne font pas la gestion de version ?
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
En fait, je crois que les IDE moderne permettent bien l'intégration
de pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas
étonné d'apprendre que la même chose vaut pour Doxygen et un éditeur
de HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.
Si l'effort pour l'intégration est supérieur à ce qu'on
doit faire avec [X]emacs, pas la peine...
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
C'est un autre aspect.
C'est surtout là que le côté "intégration" est bienvenue.
Si les équipes qui développe éditeur et compilateur travaillent
main dans la main, on peut avoir quelque chose de très bien
(genre, pour une classe template, sa def, son implémentation
de base, ses spécialisations, et savoir pour une instanciation
donnée quelle est *la* spécialisation utilisée).
Et vim et emacs font un brin de compilation, et
connaît un peu de syntaxe C++. Mais ce n'est pas ce que j'entends sous
IDE en soi, c'est plutôt le concepte de browser.
Tout à fait.Si c'est vrai que la quasi-totalité des IDE integre un browser, il
est aussi possible d'utiliser des browser non integré, comme Sniff+.
Et les solutions vim/emacs proposées sont des browser integrés à
l'éditeur (or que Sniff prend l'approche opposé, et essaie
d'ingegrer l'éditeur dans un browser externe).
Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff
extrèmement intéressant pour comprendre du code existant mal
documenté.
Je vais regarder ça alors.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais
intéressant. J'avais testé la speedbar, mais celle qui est
installée par défaut chez moi se vautre lamentablement (reconnaît
pas les méthodes des classes, confond class et fonction...).
Mon expérience avec les speedbar pour le C++ est plutôt négative. Le
problème, c'est que pour un symbole donné, il y a typiquement
plusieurs endroits intéressants dans les sources. (Il y avait aussi
le problème que les speedbars que j'ai essayé, sous emacs, ne se
mettait pas à jour automatiquement. Mais c'était typiquement un
problème mineur.) Ça pose moins un problème avec Java (je me suis
servi de JDEE), mais dans tous les cas, ça impose qu'on enlève les
mains de la position de base du clavier -- pas un problème quand on
browse, mais genant et une perte de temps quand on développe
réelement (c-à-d lors qu'on écrit du code).
On doit bien pouvoir naviguer dans le speedbar au clavier, non ?
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cnf31i$7lg$1@news.cict.fr>...
In article <wkfz39d0bx.fsf_-_@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
K. Ahausse wrote:
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans
le message de news:cncj0u$l3m$4@news.cict.fr...
Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.
Je ne sais pas ce que tu appelles IDE, mais la clef est
d'analyser le code. Emacs fait ça plutôt pas mal, cfr
<URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Oui, ou du moins un grand sous-ensemble.
Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous
un shell Unix:-).
L'aspect graphique est négligeable pour moi (à moins de développer
une IHM graphique bien sur).
En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches
nécessaires au développement des logiciels. Et voilà le hic, parce
que les tâches nécessaires au développement des logiciels dépendent
de qui développe et comment.
Oui, ou ils forcent à utiliser *une* solution.
Donc, les premiers IDE se vautaient beaucoup de la simplification
dans la cycle edit-compile-debug -- du coup, ça ne m'intéresse pas,
parce que ce n'est pas comme ça que je développe. (C'est où, la
documentation, dans ce cycle ? Et comment prend-il en compte la
gestion des versions, ou les révues de code ?)
Des choses comme VC++ ne font pas la gestion de version ?
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
En fait, je crois que les IDE moderne permettent bien l'intégration
de pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas
étonné d'apprendre que la même chose vaut pour Doxygen et un éditeur
de HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.
Si l'effort pour l'intégration est supérieur à ce qu'on
doit faire avec [X]emacs, pas la peine...
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
C'est un autre aspect.
C'est surtout là que le côté "intégration" est bienvenue.
Si les équipes qui développe éditeur et compilateur travaillent
main dans la main, on peut avoir quelque chose de très bien
(genre, pour une classe template, sa def, son implémentation
de base, ses spécialisations, et savoir pour une instanciation
donnée quelle est *la* spécialisation utilisée).
Et vim et emacs font un brin de compilation, et
connaît un peu de syntaxe C++. Mais ce n'est pas ce que j'entends sous
IDE en soi, c'est plutôt le concepte de browser.
Tout à fait.
Si c'est vrai que la quasi-totalité des IDE integre un browser, il
est aussi possible d'utiliser des browser non integré, comme Sniff+.
Et les solutions vim/emacs proposées sont des browser integrés à
l'éditeur (or que Sniff prend l'approche opposé, et essaie
d'ingegrer l'éditeur dans un browser externe).
Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff
extrèmement intéressant pour comprendre du code existant mal
documenté.
Je vais regarder ça alors.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais
intéressant. J'avais testé la speedbar, mais celle qui est
installée par défaut chez moi se vautre lamentablement (reconnaît
pas les méthodes des classes, confond class et fonction...).
Mon expérience avec les speedbar pour le C++ est plutôt négative. Le
problème, c'est que pour un symbole donné, il y a typiquement
plusieurs endroits intéressants dans les sources. (Il y avait aussi
le problème que les speedbars que j'ai essayé, sous emacs, ne se
mettait pas à jour automatiquement. Mais c'était typiquement un
problème mineur.) Ça pose moins un problème avec Java (je me suis
servi de JDEE), mais dans tous les cas, ça impose qu'on enlève les
mains de la position de base du clavier -- pas un problème quand on
browse, mais genant et une perte de temps quand on développe
réelement (c-à-d lors qu'on écrit du code).
On doit bien pouvoir naviguer dans le speedbar au clavier, non ?
wrote:Marc Boyer wrote in message
news:<cnf31i$7lg$...In article , drkm wrote:Marc Boyer writes:K. Ahausse wrote:"Marc Boyer" a écrit dans
le message de news:cncj0u$l3m$
Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.
Je ne sais pas ce que tu appelles IDE, mais la clef est
d'analyser le code. Emacs fait ça plutôt pas mal, cfr
<URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Oui, ou du moins un grand sous-ensemble.
Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous
un shell Unix:-).
L'aspect graphique est négligeable pour moi (à moins de développer
une IHM graphique bien sur).
En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches
nécessaires au développement des logiciels. Et voilà le hic, parce
que les tâches nécessaires au développement des logiciels dépendent
de qui développe et comment.
Oui, ou ils forcent à utiliser *une* solution.
Donc, les premiers IDE se vautaient beaucoup de la simplification
dans la cycle edit-compile-debug -- du coup, ça ne m'intéresse pas,
parce que ce n'est pas comme ça que je développe. (C'est où, la
documentation, dans ce cycle ? Et comment prend-il en compte la
gestion des versions, ou les révues de code ?)
Des choses comme VC++ ne font pas la gestion de version ?
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
En fait, je crois que les IDE moderne permettent bien l'intégration
de pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas
étonné d'apprendre que la même chose vaut pour Doxygen et un éditeur
de HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.
Si l'effort pour l'intégration est supérieur à ce qu'on
doit faire avec [X]emacs, pas la peine...
En fait, ça demande à l'éditeur de faire un brin de compilation,
et c'est quand même plus facile à faire quand editeur+compilo sont
fait par la même équipe.
C'est un autre aspect.
C'est surtout là que le côté "intégration" est bienvenue.
Si les équipes qui développe éditeur et compilateur travaillent
main dans la main, on peut avoir quelque chose de très bien
(genre, pour une classe template, sa def, son implémentation
de base, ses spécialisations, et savoir pour une instanciation
donnée quelle est *la* spécialisation utilisée).
Et vim et emacs font un brin de compilation, et
connaît un peu de syntaxe C++. Mais ce n'est pas ce que j'entends sous
IDE en soi, c'est plutôt le concepte de browser.
Tout à fait.Si c'est vrai que la quasi-totalité des IDE integre un browser, il
est aussi possible d'utiliser des browser non integré, comme Sniff+.
Et les solutions vim/emacs proposées sont des browser integrés à
l'éditeur (or que Sniff prend l'approche opposé, et essaie
d'ingegrer l'éditeur dans un browser externe).
Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff
extrèmement intéressant pour comprendre du code existant mal
documenté.
Je vais regarder ça alors.
Mais j'ai parcouru ton lien: ça a l'air fouilli mais
intéressant. J'avais testé la speedbar, mais celle qui est
installée par défaut chez moi se vautre lamentablement (reconnaît
pas les méthodes des classes, confond class et fonction...).
Mon expérience avec les speedbar pour le C++ est plutôt négative. Le
problème, c'est que pour un symbole donné, il y a typiquement
plusieurs endroits intéressants dans les sources. (Il y avait aussi
le problème que les speedbars que j'ai essayé, sous emacs, ne se
mettait pas à jour automatiquement. Mais c'était typiquement un
problème mineur.) Ça pose moins un problème avec Java (je me suis
servi de JDEE), mais dans tous les cas, ça impose qu'on enlève les
mains de la position de base du clavier -- pas un problème quand on
browse, mais genant et une perte de temps quand on développe
réelement (c-à-d lors qu'on écrit du code).
On doit bien pouvoir naviguer dans le speedbar au clavier, non ?
wrote:Ce qui est intéressant, c'est que le prix du développement
jusqu'au déployement n'était pas plus cher. Faire correctement ne
coûte pas plus cher au début, et nettement moins cher à la
longue. Mais il y a encore beaucoup de boîtes qui ne l'ont pas
compris.
Ce n'est pas plus cher, mais est-ce que c'est plus long ?
kanze@gabi-soft.fr wrote:
Ce qui est intéressant, c'est que le prix du développement
jusqu'au déployement n'était pas plus cher. Faire correctement ne
coûte pas plus cher au début, et nettement moins cher à la
longue. Mais il y a encore beaucoup de boîtes qui ne l'ont pas
compris.
Ce n'est pas plus cher, mais est-ce que c'est plus long ?
wrote:Ce qui est intéressant, c'est que le prix du développement
jusqu'au déployement n'était pas plus cher. Faire correctement ne
coûte pas plus cher au début, et nettement moins cher à la
longue. Mais il y a encore beaucoup de boîtes qui ne l'ont pas
compris.
Ce n'est pas plus cher, mais est-ce que c'est plus long ?
Jean-Marc Bourguet wrote in message
news:...writes:Matthieu Moy wrote in message
news:...writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse
en rien de pouvoir lancer le déboggueur directement depuis
l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core
dans la production. C-à-d une fois tous les six mois, environ.
C'est plus rare que moi, ca. Mais je crois que je touche plus a du
code que je n'ai pas ecrit que toi.
Ce n'est pas tant une question de qui l'a écrit, mais de comment.
Jean-Marc Bourguet <jm@bourguet.org> wrote in message
news:<pxbu0rn345j.fsf@news.bourguet.org>...
kanze@gabi-soft.fr writes:
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote in message
news:<vpqfz38elsl.fsf@ecrins.imag.fr>...
kanze@gabi-soft.fr writes:
En ce qui concerne les autres fonctionalités, ça ne m'interesse
en rien de pouvoir lancer le déboggueur directement depuis
l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core
dans la production. C-à-d une fois tous les six mois, environ.
C'est plus rare que moi, ca. Mais je crois que je touche plus a du
code que je n'ai pas ecrit que toi.
Ce n'est pas tant une question de qui l'a écrit, mais de comment.
Jean-Marc Bourguet wrote in message
news:...writes:Matthieu Moy wrote in message
news:...writes:En ce qui concerne les autres fonctionalités, ça ne m'interesse
en rien de pouvoir lancer le déboggueur directement depuis
l'éditeur.
C'est pourtant bien pratique : En général, quand tu lances un
déboggueur,
En général, QUAND je lance un déboggueur, c'est que j'ai eu un core
dans la production. C-à-d une fois tous les six mois, environ.
C'est plus rare que moi, ca. Mais je crois que je touche plus a du
code que je n'ai pas ecrit que toi.
Ce n'est pas tant une question de qui l'a écrit, mais de comment.
Marc Boyer wrote in message
news:<cnhoeh$oef$...wrote:Marc Boyer wrote in message
news:<cnf31i$7lg$...In article , drkm wrote:Marc Boyer writes:K. Ahausse wrote:
Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.
Je ne sais pas ce que tu appelles IDE, mais la clef est
d'analyser le code. Emacs fait ça plutôt pas mal, cfr
<URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Oui, ou du moins un grand sous-ensemble.
Dans les shells d'Unix, il y a aussi pas mal qui ne sert pas directement
au développement. Tout ce que j'ai essayé à dire, c'est que selon la
définition qui se base strictement sur les mots anglais, un shell sous
Unix est un IDE.
Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous
un shell Unix:-).
L'aspect graphique est négligeable pour moi (à moins de développer
une IHM graphique bien sur).
La seule fois que j'ai développé un IHM graphique, c'était en Java, et
le « IDE », c'était bien CygWin et emacs (avec mode viper, et JDEE pour
le browser -- mais je crois que c'est devenu beaucoup plus maintenant).
En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches
nécessaires au développement des logiciels. Et voilà le hic, parce
que les tâches nécessaires au développement des logiciels dépendent
de qui développe et comment.
Oui, ou ils forcent à utiliser *une* solution.
Est-ce encore vrai ? Je sais que d'autres outils Microsoft, comme Word,
offre un grand choix dans les méthodes de travail ; il n'impose rien.
Donc, les premiers IDE se vautaient beaucoup de la simplification
dans la cycle edit-compile-debug -- du coup, ça ne m'intéresse pas,
parce que ce n'est pas comme ça que je développe. (C'est où, la
documentation, dans ce cycle ? Et comment prend-il en compte la
gestion des versions, ou les révues de code ?)
Des choses comme VC++ ne font pas la gestion de version ?
On peut en y ingegrer, mais je ne connais pas les détails. Comme j'ai
dit, Visual Studios a un défaut de taille en ce qui me concerne -- il ne
marche pas sur un Sparc sous Solaris. Ni sous Linux, ce qui semble la
direction de l'évolution ici, pour remplacer non seulement les Sparc,
mais aussi les PC Windows.
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
Ou carrément le shell, avec vim.
Sinon, j'aimerais aussi que quelque chose comme Rose y soit integré, ou
integrable.
Mais je crois que Visual Studios permet à integrer toutes ces
fonctionnalités -- il a déjà d'office l'édition, avec je crois la
recherche des symboles, la compilation et le debug. Et je suis prèsque
sûr qu'on peut y integrer Clearcase (qui est autrement intéressant que
CVS, sauf en ce qui concerne le prix), et sans doute d'autres. Je crois
qu'on peut y integrer Rose aussi.
S'il tournait sur des systèmes intéressants (Solaris, Linux, etc.), je
ne manquerais pas de l'essayer. Qu'on veuille l'avouer ou non, Microsoft
a développé un système ouvert. Non dans le sens qu'ils ont ouverts les
sources, mais quand même avec des interfaces qui permettent à d'autres
produits de s'y integrer.
En fait, je crois que les IDE moderne permettent bien l'intégration
de pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas
étonné d'apprendre que la même chose vaut pour Doxygen et un éditeur
de HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.
Si l'effort pour l'intégration est supérieur à ce qu'on
doit faire avec [X]emacs, pas la peine...
Il y a deux choses : l'effort de l'integration, et l'effort de
l'utilisation, une fois que c'est integré. Et vue le marché, c'est en
général le fournisseur du produit qui fait le premier. Tu l'installe,
après avoir installé Visual Studios, et du coup, il est integré. (Reste
à voir ce qui se passe par la suite avec des mises à jours.)
Mon expérience avec emacs, c'est qu'il faut prèsque toujours écrire un
peu de elisp, ce qui n'est pas forcement facile. (Enfin, avec le reseau,
c'est qu'il faut trouver quelqu'un qui a déjà écrit le bout de lisp
qu'il te faut. Ce qui est nettement plus facile.)
C'est surtout là que le côté "intégration" est bienvenue.
Si les équipes qui développe éditeur et compilateur travaillent
main dans la main, on peut avoir quelque chose de très bien
(genre, pour une classe template, sa def, son implémentation
de base, ses spécialisations, et savoir pour une instanciation
donnée quelle est *la* spécialisation utilisée).
Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des diagrammes
de classe, tu annotes la classe en décrivant ses membres (avec un
enchaînement des ménus qui n'est peut-être pas aussi simple qu'il
pourrait être), tu démandes la génération, et tu as tout ce que tu veux.
Tu peux aussi définir des stéréotypes (par exemple, basés sur des
modèles) qui fournissent une partie de la définition par défaut -- un
stéréotype « sémantique valeur » qui pré-déclare l'opérateur
d'affectation et le constructeur de copie, ou « singleton » qui
pré-déclare la fonction statique instance, par exemple.
Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff
extrèmement intéressant pour comprendre du code existant mal
documenté.
Je vais regarder ça alors.
Ça a été acheté par Wind River. Et c'est cher : environ $3000 pour une
personne.
Les prix sont un véritable problème. Pour le compilateur, ça va : g++
est un compilateur tout à fait correct, et si je veux encore mieux,
Comeau ne coûte que $50. Mais Rational Rose, c'est environ 5000 EUR, et
Sniff+ 2500. C-à-d que toute utilisation non professionnelle, disons
pour expérimenter chez soi, est pratiquement exclue. (Dans une boîte, ça
ne doit pas poser un problème. Un outil comme Rational Rose peut
augmenter la productivité d'un développeur de 25%, ce qui veut dire que
son prix est amorti au bout d'un mois. Mais dans beaucoup de boîtes, ça
sort d'un autre budget, et apparaît donc trop lourd aussi.)
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cnhoeh$oef$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cnf31i$7lg$1@news.cict.fr>...
In article <wkfz39d0bx.fsf_-_@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
K. Ahausse wrote:
Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.
Je ne sais pas ce que tu appelles IDE, mais la clef est
d'analyser le code. Emacs fait ça plutôt pas mal, cfr
<URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Oui, ou du moins un grand sous-ensemble.
Dans les shells d'Unix, il y a aussi pas mal qui ne sert pas directement
au développement. Tout ce que j'ai essayé à dire, c'est que selon la
définition qui se base strictement sur les mots anglais, un shell sous
Unix est un IDE.
Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous
un shell Unix:-).
L'aspect graphique est négligeable pour moi (à moins de développer
une IHM graphique bien sur).
La seule fois que j'ai développé un IHM graphique, c'était en Java, et
le « IDE », c'était bien CygWin et emacs (avec mode viper, et JDEE pour
le browser -- mais je crois que c'est devenu beaucoup plus maintenant).
En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches
nécessaires au développement des logiciels. Et voilà le hic, parce
que les tâches nécessaires au développement des logiciels dépendent
de qui développe et comment.
Oui, ou ils forcent à utiliser *une* solution.
Est-ce encore vrai ? Je sais que d'autres outils Microsoft, comme Word,
offre un grand choix dans les méthodes de travail ; il n'impose rien.
Donc, les premiers IDE se vautaient beaucoup de la simplification
dans la cycle edit-compile-debug -- du coup, ça ne m'intéresse pas,
parce que ce n'est pas comme ça que je développe. (C'est où, la
documentation, dans ce cycle ? Et comment prend-il en compte la
gestion des versions, ou les révues de code ?)
Des choses comme VC++ ne font pas la gestion de version ?
On peut en y ingegrer, mais je ne connais pas les détails. Comme j'ai
dit, Visual Studios a un défaut de taille en ce qui me concerne -- il ne
marche pas sur un Sparc sous Solaris. Ni sous Linux, ce qui semble la
direction de l'évolution ici, pour remplacer non seulement les Sparc,
mais aussi les PC Windows.
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
Ou carrément le shell, avec vim.
Sinon, j'aimerais aussi que quelque chose comme Rose y soit integré, ou
integrable.
Mais je crois que Visual Studios permet à integrer toutes ces
fonctionnalités -- il a déjà d'office l'édition, avec je crois la
recherche des symboles, la compilation et le debug. Et je suis prèsque
sûr qu'on peut y integrer Clearcase (qui est autrement intéressant que
CVS, sauf en ce qui concerne le prix), et sans doute d'autres. Je crois
qu'on peut y integrer Rose aussi.
S'il tournait sur des systèmes intéressants (Solaris, Linux, etc.), je
ne manquerais pas de l'essayer. Qu'on veuille l'avouer ou non, Microsoft
a développé un système ouvert. Non dans le sens qu'ils ont ouverts les
sources, mais quand même avec des interfaces qui permettent à d'autres
produits de s'y integrer.
En fait, je crois que les IDE moderne permettent bien l'intégration
de pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas
étonné d'apprendre que la même chose vaut pour Doxygen et un éditeur
de HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.
Si l'effort pour l'intégration est supérieur à ce qu'on
doit faire avec [X]emacs, pas la peine...
Il y a deux choses : l'effort de l'integration, et l'effort de
l'utilisation, une fois que c'est integré. Et vue le marché, c'est en
général le fournisseur du produit qui fait le premier. Tu l'installe,
après avoir installé Visual Studios, et du coup, il est integré. (Reste
à voir ce qui se passe par la suite avec des mises à jours.)
Mon expérience avec emacs, c'est qu'il faut prèsque toujours écrire un
peu de elisp, ce qui n'est pas forcement facile. (Enfin, avec le reseau,
c'est qu'il faut trouver quelqu'un qui a déjà écrit le bout de lisp
qu'il te faut. Ce qui est nettement plus facile.)
C'est surtout là que le côté "intégration" est bienvenue.
Si les équipes qui développe éditeur et compilateur travaillent
main dans la main, on peut avoir quelque chose de très bien
(genre, pour une classe template, sa def, son implémentation
de base, ses spécialisations, et savoir pour une instanciation
donnée quelle est *la* spécialisation utilisée).
Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des diagrammes
de classe, tu annotes la classe en décrivant ses membres (avec un
enchaînement des ménus qui n'est peut-être pas aussi simple qu'il
pourrait être), tu démandes la génération, et tu as tout ce que tu veux.
Tu peux aussi définir des stéréotypes (par exemple, basés sur des
modèles) qui fournissent une partie de la définition par défaut -- un
stéréotype « sémantique valeur » qui pré-déclare l'opérateur
d'affectation et le constructeur de copie, ou « singleton » qui
pré-déclare la fonction statique instance, par exemple.
Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff
extrèmement intéressant pour comprendre du code existant mal
documenté.
Je vais regarder ça alors.
Ça a été acheté par Wind River. Et c'est cher : environ $3000 pour une
personne.
Les prix sont un véritable problème. Pour le compilateur, ça va : g++
est un compilateur tout à fait correct, et si je veux encore mieux,
Comeau ne coûte que $50. Mais Rational Rose, c'est environ 5000 EUR, et
Sniff+ 2500. C-à-d que toute utilisation non professionnelle, disons
pour expérimenter chez soi, est pratiquement exclue. (Dans une boîte, ça
ne doit pas poser un problème. Un outil comme Rational Rose peut
augmenter la productivité d'un développeur de 25%, ce qui veut dire que
son prix est amorti au bout d'un mois. Mais dans beaucoup de boîtes, ça
sort d'un autre budget, et apparaît donc trop lourd aussi.)
Marc Boyer wrote in message
news:<cnhoeh$oef$...wrote:Marc Boyer wrote in message
news:<cnf31i$7lg$...In article , drkm wrote:Marc Boyer writes:K. Ahausse wrote:
Ce que j'avais beaucoup apprécié sur VB, c'était la complétion
automatique en fonction du type.
Ca, seul un IDE peut le faire car cela demande une partie
de compilation en ligne.
Je ne sais pas ce que tu appelles IDE, mais la clef est
d'analyser le code. Emacs fait ça plutôt pas mal, cfr
<URL:http://cedet.sf.net>.
IDE Integrated Dev. Env. non ?
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment pour
les faire. Le shell Unix, par exemple:-).
Oui, ou du moins un grand sous-ensemble.
Dans les shells d'Unix, il y a aussi pas mal qui ne sert pas directement
au développement. Tout ce que j'ai essayé à dire, c'est que selon la
définition qui se base strictement sur les mots anglais, un shell sous
Unix est un IDE.
Mais en général, on démande qu'il soit graphique aussi. Peut-être un
environement graphique d'où je peux faire tout ce que je fais sous
un shell Unix:-).
L'aspect graphique est négligeable pour moi (à moins de développer
une IHM graphique bien sur).
La seule fois que j'ai développé un IHM graphique, c'était en Java, et
le « IDE », c'était bien CygWin et emacs (avec mode viper, et JDEE pour
le browser -- mais je crois que c'est devenu beaucoup plus maintenant).
En fait, je crois qu'il y a réelemnt un peu de ça. On démande un
environement graphique d'où je peux faire toutes les tâches
nécessaires au développement des logiciels. Et voilà le hic, parce
que les tâches nécessaires au développement des logiciels dépendent
de qui développe et comment.
Oui, ou ils forcent à utiliser *une* solution.
Est-ce encore vrai ? Je sais que d'autres outils Microsoft, comme Word,
offre un grand choix dans les méthodes de travail ; il n'impose rien.
Donc, les premiers IDE se vautaient beaucoup de la simplification
dans la cycle edit-compile-debug -- du coup, ça ne m'intéresse pas,
parce que ce n'est pas comme ça que je développe. (C'est où, la
documentation, dans ce cycle ? Et comment prend-il en compte la
gestion des versions, ou les révues de code ?)
Des choses comme VC++ ne font pas la gestion de version ?
On peut en y ingegrer, mais je ne connais pas les détails. Comme j'ai
dit, Visual Studios a un défaut de taille en ce qui me concerne -- il ne
marche pas sur un Sparc sous Solaris. Ni sous Linux, ce qui semble la
direction de l'évolution ici, pour remplacer non seulement les Sparc,
mais aussi les PC Windows.
Le minimal pour moi à ce jour serait l'intégration
- édition + recherche des symboles
- compilation
- debug
- auto-documentation (Doxygen-like)
- gestion de version (CVS-like)
Sinon, autant garder emacs.
Ou carrément le shell, avec vim.
Sinon, j'aimerais aussi que quelque chose comme Rose y soit integré, ou
integrable.
Mais je crois que Visual Studios permet à integrer toutes ces
fonctionnalités -- il a déjà d'office l'édition, avec je crois la
recherche des symboles, la compilation et le debug. Et je suis prèsque
sûr qu'on peut y integrer Clearcase (qui est autrement intéressant que
CVS, sauf en ce qui concerne le prix), et sans doute d'autres. Je crois
qu'on peut y integrer Rose aussi.
S'il tournait sur des systèmes intéressants (Solaris, Linux, etc.), je
ne manquerais pas de l'essayer. Qu'on veuille l'avouer ou non, Microsoft
a développé un système ouvert. Non dans le sens qu'ils ont ouverts les
sources, mais quand même avec des interfaces qui permettent à d'autres
produits de s'y integrer.
En fait, je crois que les IDE moderne permettent bien l'intégration
de pas mal d'outils supplémentaires -- je sais qu'on peut intégrer
Clearcase dans Visual Studios, par exemple, et je ne serais pas
étonné d'apprendre que la même chose vaut pour Doxygen et un éditeur
de HTML. Et Rose. Le résultat pourrait être réelement utilisable, et
nettement plus facile à apprendre qu'un shell de Unix.
Si l'effort pour l'intégration est supérieur à ce qu'on
doit faire avec [X]emacs, pas la peine...
Il y a deux choses : l'effort de l'integration, et l'effort de
l'utilisation, une fois que c'est integré. Et vue le marché, c'est en
général le fournisseur du produit qui fait le premier. Tu l'installe,
après avoir installé Visual Studios, et du coup, il est integré. (Reste
à voir ce qui se passe par la suite avec des mises à jours.)
Mon expérience avec emacs, c'est qu'il faut prèsque toujours écrire un
peu de elisp, ce qui n'est pas forcement facile. (Enfin, avec le reseau,
c'est qu'il faut trouver quelqu'un qui a déjà écrit le bout de lisp
qu'il te faut. Ce qui est nettement plus facile.)
C'est surtout là que le côté "intégration" est bienvenue.
Si les équipes qui développe éditeur et compilateur travaillent
main dans la main, on peut avoir quelque chose de très bien
(genre, pour une classe template, sa def, son implémentation
de base, ses spécialisations, et savoir pour une instanciation
donnée quelle est *la* spécialisation utilisée).
Ce que j'ai vu du mieux à cet égard, c'est Rose. Tu crées des diagrammes
de classe, tu annotes la classe en décrivant ses membres (avec un
enchaînement des ménus qui n'est peut-être pas aussi simple qu'il
pourrait être), tu démandes la génération, et tu as tout ce que tu veux.
Tu peux aussi définir des stéréotypes (par exemple, basés sur des
modèles) qui fournissent une partie de la définition par défaut -- un
stéréotype « sémantique valeur » qui pré-déclare l'opérateur
d'affectation et le constructeur de copie, ou « singleton » qui
pré-déclare la fonction statique instance, par exemple.
Beaucoup dépend de ce que tu dois faire. J'ai trouvé Sniff
extrèmement intéressant pour comprendre du code existant mal
documenté.
Je vais regarder ça alors.
Ça a été acheté par Wind River. Et c'est cher : environ $3000 pour une
personne.
Les prix sont un véritable problème. Pour le compilateur, ça va : g++
est un compilateur tout à fait correct, et si je veux encore mieux,
Comeau ne coûte que $50. Mais Rational Rose, c'est environ 5000 EUR, et
Sniff+ 2500. C-à-d que toute utilisation non professionnelle, disons
pour expérimenter chez soi, est pratiquement exclue. (Dans une boîte, ça
ne doit pas poser un problème. Un outil comme Rational Rose peut
augmenter la productivité d'un développeur de 25%, ce qui veut dire que
son prix est amorti au bout d'un mois. Mais dans beaucoup de boîtes, ça
sort d'un autre budget, et apparaît donc trop lourd aussi.)
Jean-Marc Bourguet wrote:Meme nos tests unitaires sont fait dans le cadre de l'application (du
moins au niveau ou je travaille, dans les infrastructures ce n'est pas
toujours le cas) parce que justement on depend de tellement d'autres
choses -- infrastructure, passes precedantes,... -- que d'ecrire des
tests bench sans tout ca serait difficile. On ajoute parfois de
l'instrumentation a l'application pour augmenter l'observabilite de
l'etat interne et detecter des problemes plus pres de la source.
Ça fait du bien de lire ça. Mais pourquoi diable tout ceci n'est pas
enseigné dans la plupart des écoles ? J'ai l'impression que dans les
écoles d'info, seul compte le développement au sens pissage de code, et
rien n'est dit sur le test (encore moins sur l'observabilité de l'état
interne).
Jean-Marc Bourguet wrote:
Meme nos tests unitaires sont fait dans le cadre de l'application (du
moins au niveau ou je travaille, dans les infrastructures ce n'est pas
toujours le cas) parce que justement on depend de tellement d'autres
choses -- infrastructure, passes precedantes,... -- que d'ecrire des
tests bench sans tout ca serait difficile. On ajoute parfois de
l'instrumentation a l'application pour augmenter l'observabilite de
l'etat interne et detecter des problemes plus pres de la source.
Ça fait du bien de lire ça. Mais pourquoi diable tout ceci n'est pas
enseigné dans la plupart des écoles ? J'ai l'impression que dans les
écoles d'info, seul compte le développement au sens pissage de code, et
rien n'est dit sur le test (encore moins sur l'observabilité de l'état
interne).
Jean-Marc Bourguet wrote:Meme nos tests unitaires sont fait dans le cadre de l'application (du
moins au niveau ou je travaille, dans les infrastructures ce n'est pas
toujours le cas) parce que justement on depend de tellement d'autres
choses -- infrastructure, passes precedantes,... -- que d'ecrire des
tests bench sans tout ca serait difficile. On ajoute parfois de
l'instrumentation a l'application pour augmenter l'observabilite de
l'etat interne et detecter des problemes plus pres de la source.
Ça fait du bien de lire ça. Mais pourquoi diable tout ceci n'est pas
enseigné dans la plupart des écoles ? J'ai l'impression que dans les
écoles d'info, seul compte le développement au sens pissage de code, et
rien n'est dit sur le test (encore moins sur l'observabilité de l'état
interne).
En fait, il m'arrive par paresse de faire des raccourcis pour des petits
développements personnels. Avec le résultat, toujours, que je suis
obligé à me servir du déboggueur. ET qu'il me faut toujours bien plus de
temps que si j'avais fait correctement, avec les tests unitaires, etc.,
depuis le début.
Je ne comprends pas l'analogie. Mon point, c'est que l'utilisation du
déboggueur, c'est la méthodologie des années '70. Créer un support
technologique pour en facilité l'utilisation, c'est à peu près comme
créer une technologie pour améliorer la vitesse d'une voiture à cheval.
La solution aujourd'hui, ce n'est pas faciliter l'utilisation du
déboggueur ; c'est de faire passer les méthologies qui en rendent
l'utilisation inutile, qui ont l'avantage d'améliorer la productivité du
programmeur et la qualité du résultat.
En fait, il m'arrive par paresse de faire des raccourcis pour des petits
développements personnels. Avec le résultat, toujours, que je suis
obligé à me servir du déboggueur. ET qu'il me faut toujours bien plus de
temps que si j'avais fait correctement, avec les tests unitaires, etc.,
depuis le début.
Je ne comprends pas l'analogie. Mon point, c'est que l'utilisation du
déboggueur, c'est la méthodologie des années '70. Créer un support
technologique pour en facilité l'utilisation, c'est à peu près comme
créer une technologie pour améliorer la vitesse d'une voiture à cheval.
La solution aujourd'hui, ce n'est pas faciliter l'utilisation du
déboggueur ; c'est de faire passer les méthologies qui en rendent
l'utilisation inutile, qui ont l'avantage d'améliorer la productivité du
programmeur et la qualité du résultat.
En fait, il m'arrive par paresse de faire des raccourcis pour des petits
développements personnels. Avec le résultat, toujours, que je suis
obligé à me servir du déboggueur. ET qu'il me faut toujours bien plus de
temps que si j'avais fait correctement, avec les tests unitaires, etc.,
depuis le début.
Je ne comprends pas l'analogie. Mon point, c'est que l'utilisation du
déboggueur, c'est la méthodologie des années '70. Créer un support
technologique pour en facilité l'utilisation, c'est à peu près comme
créer une technologie pour améliorer la vitesse d'une voiture à cheval.
La solution aujourd'hui, ce n'est pas faciliter l'utilisation du
déboggueur ; c'est de faire passer les méthologies qui en rendent
l'utilisation inutile, qui ont l'avantage d'améliorer la productivité du
programmeur et la qualité du résultat.
