Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Journal : Qu'est-ce qu'un outils de développement de rève ?

Posté par Nicolas Boulay () le 16 janvier 2008
Une autre question métaphysique, aujourd'hui.

Quel serait votre outil de développement de rêve ?

Parmi les outils qui font gagner du temps, les gestionnaires de version permettent de suivre l'évolution d'un code et de mettre des points de repère entre les temps de essais/erreurs et une solution avec le code qu'il y avait "avant". Le "diff" permet de ne pas faire de grosses boulettes avec des oublies.

Un bug tracker permet d'éviter d'oublier des remarques. C'est un super pense bête même si on remet des choses à plus tard, rien ne peut être oublié.

Une gestion de doc simple comme un wiki ou doxygen peut être utile sur de gros projet. J'aime bien aussi l'outil de partage de document de Google pour écrire un document à plusieurs (même si un wiki permet de faire la même chose en ligne mais publiquement).

Les outils Gnu pour tester, profiler le code comme oprofile, gprof, valgrind ou les options de coverage de gcc.

Il y a aussi les autotools qui facilitent la construction de soft n'importe ou, remplacer lentement par cmake, qmake ou autre.

Pour un développeur de soft, un des trucs les plus chiant à faire est de trouver/corriger les bugs. C'est assez peu intéressant comme tâche. Il existe des outils pour aider comme Valgrind mais il est surtout pertinent que pour le C/C++ (pour trouver les fuites mémoires).

Les langages comme Java, Perl, Python, Ruby permette de coder plus vite avec leur syntaxe "haut niveau".

Pour vous, qu'est-ce que vous aimeriez pour vous faciliter la vie ? Qu'est-ce qui vous fait perdre le plus de temps ?

> Lire le journal (80 commentaires, moyenne: 2,9).  

Vous avez demandé le commentaire #897817.

no silver bullet

Posté par Antoine () le 19/01/2008 à 14:37. (lien). Évalué à 1.

Il faut éviter la fiction de l'« outil de développement de rêve » : de même qu'il n'y a pas de silver bullet technique (i.e. ce n'est pas en adoptant tel nouveau paradigme qu'on résout tous les problèmes), il n'y a pas d'outil miracle qui élimine tous les soucis de la programmation. La programmation est par construction une activité intellectuellement complexe et elle le restera.

De mon côté ce qui me plaît c'est d'avoir de petits outils légers et souples. Comme je vis dans le monde Python je choisirai mes exemples dans ce monde-là :
- un interpréteur interactif avec complétion des symboles locaux
- une commande help() dans ce même interpréteur interactif qui fonctionne sur n'importe quel objet
- un exécutable "pydoc" qui fait la même chose que le help() suscité, mais depuis bash (exemple : "pydoc unittest")
- la possibilité d'écrire simplement, et d'exécuter tout aussi simplement des tests unitaires (comme avec nose ou py.test)
- la possibilité de faire rapidement des packages ou bibliothèques, avec gestion de certaines métadonnées de base (setuptools)
- la possibilité d'installer facilement des bibliothèques ou outils packagés avec l'outil sus-mentionné (easy_install qui lit les métadonnées depuis http://pypi.python.org/ )
- des conventions saines définies par le langage, par exemple pour les exceptions
- des fonctions intégrées à la bibliothèque standard, pour faire du logging par exemple, voire du profiling

Certains, selon leur goût, ajouteront probablement un debugger intégré. Ne pas devoir recompiler (faire un build séparé) pour avoir la possibilité de debugger est certainement un très gros plus.

Le tout est d'avoir un environnement habitable et, comme dans une maison, cela veut dire combiner de multiples éléments de mobilier bien conçus, et non chercher la solution ultime (l'analogie originale est de Joel Spolsky je crois).

  • [^]Re: no silver bullet

    Posté par Nicolas Boulay () le 20/01/2008 à 14:26. (lien). Évalué à 2.

    Je n'avais pas en tête, un outil qui comble tous les besoins, mais un outil qui manque.

    Je me disais que chaque codeur rencontre toujours le même problème "chiant" dont il ne connait pas vraiment de moyen simple pour l'affronter.

    Par exemple, j'ai écris du logiciel pour des cibles qui n'existait pas encore. Tout tourne en simulation vhdl. Genre 10h de simulation pour un résultat. Tu peux t'amuser à rajouter des sortes de printf() mais cela rallonge encore la simulation.

    Comme info, tu as juste un gros log de la valeur des registres du cpu pour chaques instructions, à toi de faire le croisement entre la sortie assembleur, les symboles pour repérer une instruction fautive et comprendre l'origine d'un soucis. Cela peut être très chiant. Ici, pas question de debugger ou autre shell interactif...

    • [^]Re: no silver bullet

      Posté par ham () le 21/01/2008 à 23:32. (lien). Évalué à 1.

      je vois le Pb, c'est d'avoir un corrélation entre l'output de debug et le code , un peut comme l'omnicient debugger ci aprés.

      c'est assez standard d'inclure le fichier/ligne dans les traces, un outils/mode im/emacs/ide-de-ton-choix serais pas mal, ca aide pas mal de voir ce qui a été executé.

      Le debugger ca peut etre bien si on peut reproduire le probleme.

    [^]Re: no silver bullet

    Posté par Sylvain Sauvage () le 20/01/2008 à 18:57. (lien). Évalué à 3.

      il n'y a pas d'outil miracle qui élimine tous les soucis de la programmation. 

    Pff, encore un qui ne connaît pas la poudre verte…