Discussion :

[rafar]

nirgal76 :
En résumé, il n'y a pas de mauvais outils, il n'y a que des mauvais usages (et des mauvais développeurs surtout).

Herve-Loiret :
Non sans plaisanter, après l'encapsulation des données qui est un principe de base de la programmation orientée, moi je dis vive l'encapsulation des connaissances.*

Franchement, tout est dit.

Je code en windev depuis 1 mois, j'ai une formation de 6 mois en développement plus général, et aucune expérience; je suis sans doute le plus inexpérimenté de tous les intervenants.
Mais ça ne m'empêche pas de voir que les problématiques soulevées ici sont valables dans tous les domaines;
cette discussion provoque beaucoup de réactions parce que le vrai problème s'étend bien au-delà du développement informatique, mais trop d'intervenants s'obstinent à ne répondre que du point de vue du développement, sur des points de détails, ils ont tous raison à leur façon, et on en finit pas.

Plus le temps passe, plus les systèmes (au sens propre, philo du terme) créés par l'humain se complexifient, des sous-domaines d'activités deviennent des sciences à part entière, avec des besoins, des compétences, des problématiques et des outils particuliers...

Un exemple tout bête: la médecine se résumait il y a pas si longtemps à arracher des dents et à faire des saignées, maintenant on a des dentistes, des neurologues, des kiné', etc...

Heureusement, qu'un dentiste n'a pas besoin de comprendre ce que fait le neurologue ou le kiné, sinon 150 d'études ne suffiraient pas;
heureusement qu'un médecin bac+8 n'a pas besoin de connaître la biochimie pour savoir ce qui se passe dans le corps du patient quand il administre tel ou tel médoc, et caetera...

Pour mon esprit naïf et simplificateur, ceux qui veulent des médecins-biochimistes veulent le beurre et l'argent du beurre, croient sûrement au grand-soir, à la justice et à l'égalité dans le monde, et ce sont sans doute les mêmes gens qui voudraient que les universités françaises soient ouvertes à tous pour pas cher mais aient le niveau des écoles d'élite, et je pourrais continuer longtemps...car c'est pas une discussion informatique, c'est politico-philosophique!

[madfu]

Utiliser un IDE c'est comme utiliser un moteur de recherche comme Google, ça permet de travailler beaucoup plus vite.
Certains vivent dans le passé, laissons-les. Il existe le train et l'avion et pourtant certains préfèrent voyager en vélo, ça met plus de temps mais le résultat est le même.

Après il faut voir ce qu'on entend par IDE, d'après moi tous les projets conséquents se développent aujourd'hui avec un IDE qui peut prendre la forme :
- d'un éditeur VI bien configuré, entouré d'une batterie de scripts schells de builds et lancement de tests en tous genres et gérés pourquoi pas dans un gestionnaire de fenêtres en mode texte
- ou d'un éditeur graphique style netbeans / visual studio
j'ai tendance à utiliser la deuxième méthode pour la plupart de mes développements, mais je bosse aussi avec d'autres équipes qui préfèrent eux la méthode VI & co et très honnêtement on est très comparable question productivité, c'est avant tout une question de préférence.

[jabbounet]

Après il faut voir ce qu'on entend par IDE, d'après moi tous les projets conséquents se développent aujourd'hui avec un IDE qui peut prendre la forme :
- d'un éditeur VI bien configuré, entouré d'une batterie de scripts schells de builds et lancement de tests en tous genres et gérés pourquoi pas dans un gestionnaire de fenêtres en mode texte
- ou d'un éditeur graphique style netbeans / visual studio
j'ai tendance à utiliser la deuxième méthode pour la plupart de mes développements, mais je bosse aussi avec d'autres équipes qui préfèrent eux la méthode VI & co et très honnêtement on est très comparable question productivité, c'est avant tout une question de préférence.

+1
Comme disent certains collègues, chacun possède sa façon d'être efficace, imposer un éditeur/EDI à quelqu'un c'est un peu comme demander à un plombier d'utiliser un marteau piqueur pour réparer les tuyauteries.

[el_slapper]

+1
comme dise certains collègues, chacun possède sa façon d'être efficace, imposer un éditeur/EDI a quelqu'un c'est un peu comme demander a un plombier d'utiliser un marteau piqueur pour réparer les tuyauteries.

Et encore +1

L'important n'est pas "quel est le meilleur outil", mais "quel est le meilleur outil pour moi"

[e-ric]

100% d'accord avec ce monsieur, je développe depuis 1981, et je continue a développer avec un simple éditeur de texte. Pour moi les développeurs de nos jours se ne sont que des petits curieux qui ne savait pas quoi faire de leur temps et vu que Microsoft à "démicratisé" la programmation pour tout le monde, ceux-ci on vu la une bonne oportunité pour faire quelque chose dans leur vie, mais que l'on ne se trompe pas, ce ne seront jamais de vrais programmeurs mais des amateurs qui savent se servir d'outils un peu pro, parce que quand il faut faire quelque chose "tout main", ses gens son complètement perdus.

Bonjour

Qui peut prétendre dire ce qu'est un VRAI développeur ? Cela fait 15 ans que je travaille dans le développement, j'avoue que je n'ai pas une réponse bien claire à ce sujet. Vous semblez avoir une question définitive sur le sujet.

L'outil n'est rien sans une certaine maîtrise, il vaut mieux travailler avec celui sur lequel on est le plus à l'aise. Le prétendu élitisme des "tout en ligne de commande" m'amuse beaucoup. Il faut choisir l'outil de préférence en fonction du problème à résoudre. Les guerres de religion (tout Java, tout C, tout .Net), cela devrait être du passé.

Dans la vraie vie, il n'est pas toujours facile de faire du boulot dont on serait fier, on ne nous donne pas toujours le temps. Donc on rencontre souvent du code de m...e mais l'auteur a pu se décourager. Cela ne m'empêche pas d'enrager quand je tombe face à certaines horreurs, je tente parfois de corriger mais c'est pas toujours faisable.

Je trouve que votre opinion est bien tranchée pourtant il n'y a pas de quoi. L'expérience n'est pas forcément une excuse pour justifier tout et n'importe quoi.

[B.AF]

On développe toujours mieux que les autres. Je ne connais pas un développeur qui ne se plaigne pas du code des autres (Et surtout le développeur C++ !). C'est quasiment une forme de comportement tribal.
D'ailleurs, plus le langage est illisible et incompréhensible (genre C++; Perl; regex...) et le code compliqué, plus le développeur a l'impression que son code est bon.

Il y en a trois familles :

• Ceux qui développent pour les autres et donc n'ont pas grand chose à faire ni de l'outil ni de la technologie et qui s'adaptent et prennent plus de plaisir à satisfaire l'utilisateur final.
  Prenant la technologie comme un moyen, il s'agit des curieux qui n'hésitent jamais à prendre leur derniére trouvaille pour réaliser un nouveau projet, et sur lequel la qualité du code sera inversement proportionnel à la volonté de faire plaisir au client. Dans sa version dangereuse il peut dire qu'une question n'est pas importante parce que c'est de la technologie. C'est typiquement celui qui met des singletons partout parce que "c'est plus facile" et qui absolument vouloir des services Rest avec un client HTML5 avec un pol en timer. Le risque c'est que son code est vite plein de librairies béta, alpha ou de trucs téléchargés dont personne ne sait trop ce que ça donnera.
  Il n'a jamais fini dans les délais mais il a pensé à autre chose de sympa qu'il va te montrer.
• Ceux qui développent pour eux et qui n'ont aucun plaisir dans l'utilité finale tant qu'ils utilisent ce qu'ils veulent et qui ont des dogmes sur l'outillage et les technos à priori de tout sujet. C'est souvent là que l'on trouve les envolées sur le libre, le "old school", les conflits de théorie et une resistance à la nouveauté forte. Typiquement, ceux là sont les ennemis du NoSQL, font de l'utilisation d'une techno une guerre de religion. Avec souvent au terme une excellente technicité, mais à canaliser sous peine qu'elle soit répandue dans des méandres d'architecture incompréhensible. Typiquement, tu lui demandes de construire une architecture et un tool de développement; il commence par ré-écrire le threading si c'est un furieux, ou il commence par développer des générateurs de code pour un ORM si c'est un jeune, où il commence par écrire tout ce qui a été ajouté dans le Framework depuis 10 ans mais qui par principe est mal fait. Au bout de 9 mois, tu obtiens un framework qui contient 9000 classes, dont 95% sont des interfaces avec une méthode. Quand tu lui demandes de développer quelquechose, il est toujours à la bourre parce qu'il faut qu'il développe un truc de bas niveau ou qu'il faut patcher un truc ou qu'il faut déployer 62 nouveaux serveurs et que la machine virtuelle est en rade.
• Ceux qui développent par hasard ou par nécessité (scientifiques) et qui n'aime pas particuliérement ça. Comme tous les gens mis devant le fait accompli, il dispose d'un recul évident car ils n'ont pas passionné le sujet du débat. Il s'agit souvent de profils très intéressant car restant dans la simplicité maximum; et souvent très limités car ils ne prennent pas vraiment de plaisir.

[ThomasR]

D'ailleurs, plus le langage est illisible et incompréhensible (genre C++; Perl; regex...) et le code compliqué, plus le développeur a l'impression que son code est bon.

Je ne sais pas dans quel micro-climat tu te trouves mais pour moi ça a toujours été l'inverse, plus le code parait complexe et plus je me dis que j'ai foiré quelque-part, alors je reprends tout, j'imagine que c'est le cas également pour une large majorité de développeurs.

J'aime beaucoup ce que tu dis par la suite

[jabbounet]

On développe toujours mieux que les autres. Je ne connais pas un développeur qui ne se plaigne pas du code des autres (Et surtout le développeur C++ !). C'est quasiment une forme de comportement tribal.

Me concernant, non j'ai déjà vu des codes très propres et bien foutu et que je n'ai pas développé, parfois chez des concurrents (là ça fait mal de le reconnaitre). En général ils provenaient de gens qui avaient compris la philosophie sous-jacentes des technos qu'ils utilisaient et qui comprenaient le domaine fonctionnel dans lequel ils évoluaient.

De plus pour évoluer dans une technos, il faut savoir reconnaitre quand une application est bien faite retenir pourquoi s'en inspirer éventuellement plus tard, et aussi savoir ce qui est à éviter et surtout dans quels cas d'utilisation.

D'ailleurs, plus le langage est illisible et incompréhensible (genre C++; Perl; regex...) et le code compliqué, plus le développeur a l'impression que son code est bon.

Du code lisible et du code illisible c'est possible dans tous les langages/technos, de même pour le code simple/compliqué.

Personnellement je suis satisfait quand le code est suffisamment simple pour que n'importe quel développeur soit capable de le relire de le comprendre et le maintenir sans se faire de nœud au cerveau. En général les choses simples sont souvent efficaces et plus facile a maintenir.

[ok.Idriss]

Bonjour.

Pour mon esprit naïf et simplificateur, ceux qui veulent des médecins-biochimistes veulent le beurre et l'argent du beurre

Bof, là on parle de développeurs qui utilisent des éditeurs et/ou des IDE, on reste dans le même domaine et la comparaison peut se faire ...

Pour ma part, je suis d'accord avec la majorité qui dit qu'il faut utiliser les outils avec lequel on est le plus à l'aise mais je suis aussi d'accord avec le fait qu'il est toujours mieux d'avoir un minimum d'expérience sur les deux types d'environnements énoncés. Ceci dit, cela n'empêchera pas un développeur d'être bon techniquement si celui-ci ne sait utiliser qu'un IDE mais c'est toujours une compétence de plus de savoir utiliser un éditeur (l'inverse étant vrais également).

De toutes façons, le plus important chez un développeur AMHA c'est de développer avec méthode et de documenter son projet afin qu'il reste maintenable par les autres (étude-analyse de faisabilité, spécifications, conception, codage, tests, intégration). Beaucoup sont très compétant techniquement (bonne connaissance du langage, des outils, etc) mais leur code n'est pas toujours maintenus car il n'est pas documenté et les autres qui passent derrière lui n'ont soit pas la compétence, soit pas le temps de faire de la rétro ingénierie.

Cordialement,
Idriss

[ManusDei]

Du code lisible et du code illisible c'est possible dans tous les langages/technos, de même pour le code simple/compliqué.

Y a une rumeur qui dit qu'en ADA c'est plus difficile de faire du code illisible

Pour revenir au sujet de base, en prenant mon cas (étudiant), oui, je sais développer avec un éditeur de texte, mais, pour prendre l'exemple du C, écrire mon Makefile à la main alors que j'ai un environnement de développement qui peut le faire pour moi, c'est une perte de temps (temps que je peux passer à apprendre à me servir d'une nouvelle bibliothèque, par exemple).

Bref je sais faire, mais j'ai des outils qui le font pour moi, alors pourquoi je devrais le faire à la main ?

[GanYoshi]

Ceci dit, cela n'empêchera pas un développeur d'être bon techniquement si celui-ci ne sait utiliser qu'un IDE mais c'est toujours une compétence de plus de savoir utiliser un éditeur (l'inverse étant vrais également).

Je suis d'accord avec toi.
Je tiens juste à rappeler, que le temps n'étant pas extensible, qui dit "une compétence en plus à savoir utiliser un truc qu'on utilise pas" dit aussi "une compétence en moins ailleurs, et potentiellement dans un domaine utile"....

[ok.Idriss]

Je tiens juste à rappeler, que le temps n'étant pas extensible, qui dit "une compétence en plus à savoir utiliser un truc qu'on utilise pas" dit aussi "une compétence en moins ailleurs, et potentiellement dans un domaine utile"....

C'est pas faux mais de là à dire qu'utiliser un autre type d'environnement que celui que tu utilise habituellement est une compétence totalement inutile : Tu peut parfois être amené sur certaines plateformes à utiliser un EDI comme tu peut parfois être obligé sur certains serveurs non graphiques de développer via un éditeur comme vi (notamment pour le scripting) ... Après il faut savoir ordonner par degrés d'utilité (personnel) les compétences à acquérir.

[jabbounet]

Bref je sais faire, mais j'ai des outils qui le font pour moi, alors pourquoi je devrais le faire à la main ?

trois raisons issue de l'expérience:

1/ Avoir un idée du fonctionnement de ces outils n'est pas négligeable, ce sont des logiciels comme les autres.

2/ Tu peux te retrouver dans des environnements de travail ou certains outils sont imposés (gestion de conf/chaine de compilation) et la ton outil qui fait pas tout seul peut passer à la trappe dans certains cas.

3/ Avoir un plugin sur ton éditeur qui te fait tout ce boulot c'est bien. Mais lorsque tu dois partager ton appli avec d'autre et que ces derniers utilisent d'autre outils qui ne sont pas compatible avec ton éditeur être capable de leur expliquer comment ton application se compile peut avoir son utilité.

et un peu de culture informatique ça ne fait pas de mal au développeur.

[GanYoshi]

C'est pas faux mais de là à dire qu'utiliser un autre type d'environnement que celui que tu utilises habituellement est une compétence totalement inutile : Tu peut parfois être amené sur certaines plateformes à utiliser un EDI comme tu peux parfois être obligé sur certains serveurs non graphiques de développer via un éditeur comme vi (notamment pour le scripting) ... Après il faut savoir ordonner par degrés d'utilité (personnel) les compétences à acquérir.

Exactement.

[ManusDei]

du texte

J'ai mis que je savais faire, c'est-à-dire que j'en ai fait, et que je saurais le refaire si besoin est.

Donc tant que je peux utiliser mon outil, je ne vois pas de raison de ne pas le faire.

[jabbounet]

J'ai mis que je savais faire, c'est-à-dire que j'en ai fait, et que je saurais le refaire si besoin est.

Donc tant que je peux utiliser mon outil, je ne vois pas de raison de ne pas le faire.

j'ai jamais dit que je n'étais pas d'accord avec l'utilisation d'outils qui simplifient la vie, simplement regarder un peu sous le capot, savoir comment il est possible de faire quelque chose d'équivalent n'est pas un perte de temps.

l'avoir fait plusieurs fois à la main pour voir comment faire aide a fixer la connaissance.
maintenant si tes profs te l'imposent systématiquement c'est un peu bête.

[ManusDei]

maintenant si tes profs te l'impose systématiquement c'est un peu bête.

Plutôt que les profs, c'est surtout certains de mes camarades de promotion qui estiment que si tu ne codes pas ton makefile sous vi en mode texte, ton projet est pas maintenable, ou a toutes les chances de se planter (et j'exagère à peine).

[Fenn_]

J'ai l'impression que c'est un faux débat non?
Effectivement, chacun va avoir ses préférences et ses habitudes.
Mais le développement, c'est un métier de service quelque part, non?
Si on tombe dans un environnement où sont utilisés d'autres outils/technos que ceux que l'on a l'habitude d'employer, à nous de nous adapter, on ne va pas refaire l'infrastructure de l'environnement parce que cela ne nous plaît pas.

Je suis développeur .Net (encore en formation), j'utilise un IDE (en faisant gaffe quand même au code généré derrière), je bosse sous windows...

Si demain on me demande de coder en Java sous éditeur de texte avec un framework donné sur une machine Linux (ce qui a quand même peu de chance d'arriver si je suis embauché rapport à mon CV xD), je ne vais pas me mettre à chouiner ou à gueuler comme un putois, que les choix me plaisent ou non. Parce que dans les grandes lignes, mes algos, mes entités, mes relations etc, ce seront les mêmes, et la partie qui m'éclate c'est ça.
Après, arrivé à l'implémentation, c'est sûr que ma productivité va en prendre un coup, surtout au démarrage.
L'important c'est de s'assurer que le "commanditaire" (entendre par là celui qui planifie le boulot) en ait conscience, histoire qu'il ne soit pas pris au dépourvu.
Et d'avoir un accès à la doc nécessaire et suffisante pour ne pas avoir à casser les pieds de quelqu'un toutes les 5 minutes.

Faut voir ça à la fois comme un défi et une source d'enrichissement personnel.

Geindre qu'on a pas ce qu'on veut, c'est désagréable pour l'entourage, et c'est totalement improductif.

[jblecanard]

Plutôt que les profs, c'est surtout certains de mes camarades de promotion qui estiment que si tu ne codes pas ton makefile sous vi en mode texte, ton projet est pas maintenable, ou a toutes les chances de se planter (et j'exagère à peine).

Très amusant, surtout que rédiger un makefile à la main, c'est antédiluvien comme technique, et vraiment dommage quand on a de bien meilleurs outils (je pense à CMake mais il y en a d'autres). C'est le même genre de branques qui font un projet en GTK+ alors qu'on le leur avait demandé en ligne de commande et qui se tape une bulle parce que leur bazar est bugué.

Pour répondre à la question du post, oui, je sais tout faire à la mano et je sais ce que fait mon IDE. D'ailleurs, mon IDE ne produit peu ou pas de code : il m'aide principalement à naviguer dans celui-ci et à gérer le SCM maison, et quoi qu'on en dise, aller se mettre dans le bon fichier au bon endroit est coûteux en temps.

J'ai utilisé VI pendant un bon moment et c'est franchement trop élitiste. Oui on peut être efficace sur VI avec une bonne batterie de scripts et tout le bazar... mais ça reste pas pratique à utiliser. Le concept "je n'utilise que le clavier" n'est plus valable selon moi dans un environnement industriel ou tu dois coder vite et souvent copier-coller des morceaux de code pour le réorganiser ou réutiliser un autre code. Surtout que les éditeurs de texte modernes commencent à avoir des fonctionnalités d'édition de texte et des raccourcis clavier assez poussés.

Une autre raison qui me pousse à m'éloigner de telles solutions est le fait qu'on est souvent confrontés à changer d'environnement. Par exemple, au boulot j'utilise VS et chez moi j'utilise Eclipse. Et bien heureusement qu'une bonne partie des raccourcis clavier sont les mêmes, parce que sinon ça me rendrait vite fou !

Les vieux geeks qui ne jurent que par VI et Emacs me font bien rigoler. Qu'ils les utilisent s'ils en ont envie, mais qu'ils ne viennent pas me faire des leçons de productivité, parce que ça n'a aucun sens tant les critères sont nombreux et hautement variables d'une personne à une autre. Et comme le dit Fenn, il faut savoir s'adapter à chaque environnement plutôt que vouloir imposer sa sauce.

Et au fait, ces gens là, ils débuguent avec quoi ? Avec gdb en ligne de commande ? J'aimerai bien en trouver un qui ose me défendre qu'on débugue plus efficacement en ligne de commande qu'avec l'assistance d'un IDE. Et qu'on ne me parle pas de cette horreur appelée ddd.

[zecreator]

Moi aussi j'ai débuté sur Amstrad CPC et Thomson MO5 à faire du code au kilomètre...

Mais bon, la conjoncture a changé, il faut vivre avec son temps. Les machines et les outils changent, faut faire avec.

Il est temps de comprendre que ce que les entreprises appellent un développeur pro, c'est un développeur pas cher et qui produit vite. Pas un pisseur de code sur un vieux Notepad+...

lol.