Re: [CBLX] Développer en aveugle!

[Emmanuel COUTRIS <emmanuel.coutris@xxxxxxxxx>]

Salut Christophe et tous,

On Thu, Mar 17, 2011 at 09:52:32AM +0100, Delaunay Christophe wrote:
> 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.

En réalité je ne connais pas d'IDE proprement dit en console mais les grands
éditeurs (Emacs, Vim, Jed) peuvent être configuré comme des IDEs. Ils se
décrivent comme "éditeurs pour programmeurs" et je trouve que c'est assez
justifié.

> 
> >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.

La complétion existe bien dans Emacs, il me semble aussi dans Vim... Dans
Jed aussi. Tu as aussi l'autocorrection et les abbrevs qui peuvent servir
dans ce domaine.

> 
> >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.

Bon je sais ... je me fais l'avocat du diable mais c'est une tendance chez
moi pour pouvoir toujours me remettre en question. Un modèle est preuve
qu'il est souvent utilisé. Il peut être moins chargé d'erreur OU tous les
gens qui l'utilisent font les mêmes erreurs!

> 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.

Tiens... tu me fais penser à un truc: est-ce que tu as déjà essayer la
méthode de gestion de projet XP (eXtrem Programming)? Franchement, depuis
que je l'ai découverte je ne jure que par ça :) Parmi les principes
principaux il y a ça: écrire les tests avant le développement et automatiser
tests pour pouvoir les lancer à chaque nouvelle avancée dans le projet.

Ce qui me fait penser à te dire ça c'est que tu parles d'efficacité et par
ces principes tu perds beaucoup moins de temps en débuggage et ... tu
t'amuses aussi à prévoir des scénarios et écrire des tests simples.

> 
> >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.

Le point de vue se défend :)

> 
> > 
> >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.

Sauf si tu fais des tests unitaires à toutes les étapes (voir au-dessus).

> 
> 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.

Oui, ça se défend comme piont de vue.

Je suis content de pouvoir échanger sur ce genre de sujet! Ici, pour
l'instant, je suis condamné à développer tout seul dans mon coin alors... :)

Amicalement,

Manu
> 
> 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
> 

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