RE: [CBLX] Développer en aveugle!

[Delaunay Christophe <christophe.delaunay@xxxxxxxxxxxxxxx>]

Bonjour Emmanuel,

Tu as écrit:

>Euh... je ne serais pas aussi catégorique. Il suffit de voir les outils de
>dev en console qui sortent: les dernières mises à jour ne datent pas
>toujours de longtemps.

Oh oh! Des IDE en console, synaptic ne m'en a pas montré mais j'ai
peut-être loupé quelque chose. gnat-gps peut-être parce que j'ai
naïvement cru que tout ce qui avait "gnat" dans son nom était fait pour
le langage Ada. Alors merci Philippe de me l'avoir pointé. Je vais y
regarder de plus près bien que ce qui m'ennuie, c'est que visiblement,
personne d'autre n'utilise ça ici.

>Entre nous, pas mal de choses peuvent être (ou le sont déjà) automatisés.

Oops, j'ai donc dû louper quelque chose. En particulier, pour la
complétion des noms, (de classes, de méthodes, et même d'instances),
tout ça je sais faire dans Visual sans me prendre la tête. C'est livré
de base. Sous vim, je ne sais pas.

>Eclipse et compagnie n'automatisent pas forcément: ils appliquent des
>modèles comme ce qu'on pourrait faire en recopiant des modèles et appliquer
>des scripts sed/awk.

Ben justement: les modèles, c'est le gage d'utiliser quelque chose que
tu n'es pas le seul à utiliser, et donc, forcément moins chargé d'erreur.
Ici, on ne nous demande pas de faire du joli, de l'optimisé à outrance ou
que sais-je. Ce qui compte, c'est de faire du fiable. La première
qualité qu'on nous demande, c'est d'être suffisamment modeste pour ne pas
systématiquement chercher à réinventer la roue, et préférer se servir de
quelque chose qui a déjà fait ses preuves. En ce sens, la R&D est bien
différente de la recherche appliquée, ou pis encore, de la recherche
fondamentale.

>Après, il y a un problème de goût personnel!

Pas seulement.

>Moi, je préfère coder comme
>j'ai envie plutôt que de devoir paramétrer des modèles.

Moi aussi je préférais faire ça. D'ailleurs, le premier projet que j'ai
développé sous linux, je l'ai entièrement construit sous vim, (code et
Makefiles compris). Malheureusement, je me suis fait bien taper sur les
doigts, pas parce que le résultat n'était pas bon. D'ailleurs, il s'est
avéré après coup qu'il était bien plus résistant que les choses un peu
similaires qui avaient été faites par d'autres équipes. Ce qu'on me
reprochait, c'est de n'avoir pas livré dans les délais et, de ce fait,
d'avoir fait perdre un marché. C'est le genre de choses qu'il ne faut
pas refaire N fois.

> 
>Petite question: quel type d'erreur les IDE empêchent en tant que
>développeur DV?

Un exemple très simple: la complétion. Si, au lieu de systématiquement
taper le nom d'un pointeur, d'une méthode, d'une variable, tu peux vite
le retrouver dès que tu en tapes les premières lettres, tu vas mettre le
reste du nom dans ton code en cliquant dessus. Au moins, tu seras sûr de
n'avoir pas fait de typo en le tapant. Bon, certes, en C ou C++ ou même
en java, ce genre d'erreurs te sera montré à la compile mais c'est
toujours après coup. Et malheureusement, comme il y a de plus en plus de
langages qui ne t'obligent plus à déclarer tes variables, (qu'on le
regrette ou pas, c'est une autre question), avec ce genre de langages, tu
vas découvrir l'erreur à force de débogage.

En ce sens, tu as raison. Il n'y a pas d'erreur corrigée par les IDEs qui
ne soit correctible autrement, mais le plus vite elle est corrigée, le
moins on perd de temps.

>> Alors, ça m'ennuie mais je vais développer sous win, avec visual,
>> m'obliger à faire du portable win->linux, (ça ce n'est vraiment pas
>> efficace mais sûrement plus que de tout faire à la main sous vi),
>
>Euh... tu parlais d'éviter des lourdeurs...?

Justement. C'est pour ça que je cherche à faire autrement: tout dans l'OS
cible. Cependant, planning et vérificateur à l'appui, j'allais plus vite
en faisant ça qu'à la main.

>Si tu as des maquettes de Makefile pourquoi pas partir directement de
>Linux...?

Les maquettes de Makefiles, c'est une chose. Tiens: un modèle comme tu
dis mais le modèle est encore bien pauvre. Ce qui lui manque, c'est
malheureusement l'essentiel: le code et un moyen efficace de le déboguer.
Je ne veux pas dire que GDB n'est pas efficace. Bien loin de moi cette
idée. D'ailleurs, pour déboguer mon premier projet linux, c'est l'outil
dont je me suis servi avec succès finalement. Mais il y a infiniment plus
performant en termes d'interface utilisateur pour arriver au même
résultat.

L'autre dimension du problème, c'est la capacité à s'intégrer dans un
travail collaboratif. Ici, on n'est jamais tout seul à développer un
projet. C'est aussi pour faciliter les échanges que je souhaite utiliser
les mêmes outils que les collègues chaque fois que c'est possible.

Bonne journée. @+ ChD

---
--
   CarrefourBLinuX MailingListe
   Pour obtenir de l'aide, envoyez le sujet  help  à:
   carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
   Archives:
   http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux