Bon allez, je trouve que vous êtes un peu binaires dans vos jugements (ça doit être normal pour des informaticiens)
Dans cette discussion, j'ai l'impression qu'il y a :
- ceux qui sont contre l'IDE parce que cela va générer du code lourd et pas optimisé.
- ceux qui sont pour parce que cela leur facilite la vie.
L'informaticien malin va utiliser la partie de l'IDE qui lui permet d'avancer rapidement (refactoring, coloration syntaxique, gestion de projet ...)
L'informaticien bourrin va essayer de tout faire avec les assistants et les plug-in ; et là, bien sûr, ça coince parce que l'IDE ne peut pas couvrir tous les besoins.
Dans NetBeans, on peut se faire un petit écran de saisie vite fait et bien présenté à condition qu'il soit assez simple.
Par contre, dès que le formulaire doit se construire à la volé en fonction du contexte, il est clair qu'il faut coder à la main.
Mais je ne vais pas renoncer à NetBeans au motif qu'il ne sait pas tout faire !
Est-ce qu'un ébéniste utilisant une scie sauteuse plutôt qu'une scie toute simple est fainéant ?
Est-ce qu'utiliser un ascenseur pour aller en haut d'un immeuble de 50 étages est de la paresse et qu'il faut toujours prendre les escaliers ?
Un bon développeur est celui qui saura utiliser les bons outils pour atteindre le résultat dans les meilleures conditions et le plus rapidement possible.
Un bon développeur préférera se focaliser sur les problématiques métier qui lui sont soumises et comment implémenter sa solution plutôt que savoir exactement le nom et la qualification de toutes les classes qu'il a à disposition.
S'il faut à certain de "souffrir" sans IDE pour avoir l'impression de faire un meilleur travail, libre à eux, mais ça m'étonnerai que le code produit soit meilleur.
Autant coder avec 250Mo de RAM, sous un OS light au possible, avec une chaise en bois...
Je trouve que cette article est du grand n'importe quoi, je pense qu'un développeur dois savoir utilisé les nouveaux outils mis a ça disposition sans pour autant qu'il oublie c'est connaissances, si ça peut le rendre plus productif au contraire, la personne qui a écrit cette article, n'a pas d'argument valable, et surtout il ne peux en aucun cas vérifier ce qu'il dit, bien sur on parle de développeur professionnel et non les gens qui débutent
Dans l'apprentissage academique je peux comprendre que l'utilisation abusive des IDE peut compromettre la compréhension des concepts.Comme le Swing en Java avec les écouteurs et actions.il est plus aisé de faire un glisser deposer mais certains étudiants ont du mal à taper du code personnalisé après.
Maintenant pour de professionels l'IDE est un outil essentielle en terme de productivité.Rechercher des fonctions,refractorer,generer du code.
Tout cela n'enlèves en rien le fait que tu puisses savoir quel fonction utilisé et Quelques fois on oublie les definitions de ces fonctions.
L'IDE est bénéfique.pourquoi saisir dans un bloc notes 50 classes avec des erreurs de parenthèses et autres.
Moi j'utilise du block notes uniquement pour éditer rapidement du code ou extraire des parties.
Le drag & drop permet de faire des interfaces assez rapidement qui, de toute les façon devront être reprises "à la main" ensuite, soit parce que le code généré sera dégueulasse ou doit être adapté (QtCreator), soit parce qu'il est impossible de faire ce que l'on veut (Android entre autre ou encore Scene Builder).La chose est d’autant plus flagrante avec l’utilisation de la fonctionnalité de création des interfaces utilisateurs fournie par certains IDE. En effet, tout ce que doit faire le développeur c’est glisser/déposer des composants pour qu’ensuite l’IDE génère le code correspondant pour eux.
Pour moi on peut utiliser les deux mais de toute façon on sera obligé de repasser à la main derrière.
Maintenant, en ce qui concerne la compilation, il est évident qu'à force d'utiliser les ide on ne sait pas forcément comment ça compile derrière (du moins pour ma part, je saurais l'expliquer, mais la refaire à la main c'est autre chose ... )
Et les calculatrices électroniques ont rendu tout le monde mauvais en maths...
Théoriquement, non. Maintenant dans la pratique, oui. Tout comme Google fait que les gens lisent moins bien, on peut aussi dire que les calculatrices font que les gens font moins bien des maths (tout le monde n'est pas mauvais mais combien sauraient encore faire des divisions avec des chiffres à virgule ? D'autant qu'au bout d'un moment, en maths, il n'y a plus beaucoup de chiffres mais des lettres ).
On peut donc en déduire que les gens se reposant trop sur des outils perdent la main sur le coeur de la chose, mais ce n'est pas pour autant qu'ils sont mauvais, ils n'ont plus juste l'habitude.
Un IDE qui génère le code lors de l'insertion d'un composant est un RAD (rapid application development). Je trouve aussi que ce n'est pas la meilleure méthode d'écrire de bon code, car ça donne souvent des executables mamouth, dont seulement une partie du code est utilisée, ou bien des executables qui nécessitent que telle ou telle bibliothèque soit installée. Aussi, le développeur n'a souvent pas d'idée de ce que fait vraiment le code qu'il utilise (bon, c'est aussi l'un des buts de la programmation orientée aux objets - "hiding the implementation"). C'est comme ça qu'on arrive à avoir des choses complètement artificielles, inutiles et surtout énormément encombrantes comme par exemple le .NET Framework (Comment serait Windows 7 sans .NET Framework ? - sans doute un vrai successeur de l'XP). Mais on peut facilement observer qu'avec un outil comme ça, on peut embaucher un "demi-développeur", qui ne doit que connaître le kit qu'il utilise, sans se préoccuper des choses plus profondes.
Par contre, je trouve qu'un IDE qui permet d'éditer les fichiers de code et les ressources, sans rajouter de code lui même, est un outil très utile, qui permet de ne pas "redécouvrir le feu et de réinventer la roue" chaque fois qu'on veut développer une application. Ça aide vraiment, car ce n'est plus nécessaire de taper chaque fois la commande pour compiler etc. et évite aussi de faire des erreurs lors de ces temps morts. Ça permet aussi de se concentrer vraiment sur le code qu'on doit écrire.
Le seul chose qui m'intéresse dans une IDE c'est l'auto-complétion. J'ai du mal à me souvenir de l'intégralité des méthodes de toutes les classes de mon projet et leur arguments (facultatif ou non en PHP).
Après, j'ai longtemps fonctionné sans. Sur un projet pas trop gros c'est gérable sans trop de problème, mais passé une certaines tailles avec des bibliothèques, pour moi ce n'est plus possible. De plus, pour certains trucs que je créer des raccourcies sur des méthodes que j’utilise souvent.
Comme je fais du web, je dois dire que je n'ai aucune confiance pour tout ce qui la partie HTML, je fais donc tout à la main.
Bordel, mais pourquoi ceux qui programment ces logiciels, les préconfigurent à dessein d'exploser les yeux du pauvre programmeur qui s'apprête à passer 8 heures devant son écran (ie: écran blanc + police noire (avé quelques couleurs ) et illisible (1 quasi indifférenciable de l ou | etc... )).
Pour les couleurs, cela fait plusieurs fois que j'entends parler que les fonds blanc et la police noire est mauvaise pour les yeux, mais je ne trouve pas grand chose sur le sujet à part que les fonds noirs réduiraient la consommation de l'ordinateur.
Est-ce que ce n'est pas plutôt une question de lumière ambiante ? Quand je travail sur fond blanc la nuit sans allumer ma lampe, j'avoue que mes yeux fatiguent assez vite (et dans ce cas là un fond noir serait peut-être plus reposant) mais si j'ai de la lumière autours, je n'ai aucun problème.
Une autre chose, les fond noir ont tendance à effrayer les débutants pour qui la console = truc magique. Donc proposer un fond blanc par défaut ne me semble pas si bête que cela surtout qu'on peut ensuite modifier cela dans les configurations.
Les IDE que j'utilise principalement sont Eclipse et Visual Studio. J'utilise aussi QtCreator, très bien fait pour de la programmation 100% Qt pour mes projets personnels (en plus Qt a une doc très bien faite, je ne m'en réjouirai jamais assez) mais vite limité, je trouve, pour de gros projets. J'ai aussi beaucoup utilisé Emacs par le passé.
Je n'utilise pas la génération de code de type "snippet", probablement parce que je n'ai pas pris le temps d'apprendre à m'en servir et aussi parce que je n'en ai jamais ressenti le besoin.
Pour moi un IDE c'est surtout un bon outils pour naviguer dans le code et faire du debug.
J'utilise aussi les outils de création d'interface. Pour avoir fait des interfaces entièrement à la main (en Qt mais aussi directement en XWindow parfois) pendant mes études et mes premiers stages, j'apprécie grandement ces outils et je ne m'en passerai plus pour réaliser de "vraies" interface. Sur ce point d'ailleurs beaucoup de frameworks ont évolués spécialement pour que les interface soient générées automatiquement, par exemple en adoptant des formats XML pour décrire les interfaces. Ça n'empêche pas que pour écrire tout le dynamisme d'une interface il faut encore savoir programmer!
Peut-être parce que simplement tous ces IDE avancés n'existaient pas quand j'ai fait mes études, je n'utilise pas toutes les fonctionnalités avancées des IDE. En revanche je pense qu'aujourd'hui ne pas savoir se servir efficacement d'un IDE pourrait être considéré comme un manque de compétence.
Evidemment tout dépend du langage, du framework, des besoins, des projets...
D'ailleurs où commence la distinction entre un IDE et un éditeur de texte?
Bof.
Les seules différences réelles entre IDE et DE ( developent environment en l'occurrence... oui, je sais, ça veut aussi dire Desktop environment... en même temps la différence est pas énorme au final ) c'est:
_ l'IDE reproduit des fonctionnalités déjà existantes dans le système: gestion de fichiers, gestion de fenêtres, par exemple. Sous windows, vu qu'il n'y a pas de gestionnaire de fenêtre efficace, entres autres, c'est un mal nécessaire. Cette duplication rends l'IDE lourd et consommateur.
_ l'IDE est utilisable sans avoir besoin de connaître les outils dont on a besoin: il fournit pléthore d'outils, dont la plupart des utilisateurs n'ont même pas conscience. Parallèlement, il restreint l'utilisateur en imposant de n'utiliser que des outils compatibles avec lui-même ( en fonction de l'IDE, ça peut être vaste... ou pas. )
_ le DE nécessite de passer plus de temps à configurer.
Résultat: l'un est plus lourd que l'autre, mais fonctionne out of the box, tandis que l'autre impose de connaître ses besoins et les logiciels qui y pallient, mais est plus flexible.
Rien à voir donc avec la compétence de l'utilisateur. Pour ce qui est de la génération de code, la moyenne des outils produit de la merde, c'est clair. Mais qui ne trouve pas confortable d'utiliser des scripts de génération, genre en C++ demander la création d'une classe, et le header généré à déjà:
Ce code, avec un petit coup d'astyle, deviens fidèle aux exigences du dev, et lui épargne une tâche répétitive et error-prone.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13 #ifndef FOO_HPP #define FOO_HPP #include <bar.hpp> #include "hello.hpp" class foo : public bar, virtual protected hello { }; #endif
Astyle que l'on peut d'ailleurs insérer automatiquement avant tout commit, et on peut même imaginer utiliser un script mêlant astyle et diff pour empêcher le commit si le dev n'a pas respecté la mise en forme ( laisser un outil modifier le code sans contrôle est dangereux, pour moi ).
Et le source incluant déjà l'include du header?
Ce code n'a rien de crade, pas vrai? Tant que le générateur ne se mêle que de sucre syntaxique, il n'y a pas de souci, en fait. C'est quand on utilise un générateur pour générer de la logique, et des IHM que l'on sera amené à modifier, que le souci se pose. Autrement dit, quand le RAD sert à compenser les faiblesses de la lib graphique ( absence de layout forçant à placer les boutons au pixel, nécessité de plusieurs lignes de code pour ajouter un seul contrôle, etc ), lib graphiques qui sont, en général, des framework touchant à tout et à rien.
Le jour ou un RAD sera capable de générer du code respectant mes conventions de nommage, me permettant de modifier le code qu'il a généré, et d'actualiser le document source ( qu'il soit un méta-langage, ou des diagrammes, ou quoique ce soit ne m'importe pas ) et de réinsérer des modif que j'aurai faites dans le doc source dans le code sans m'imposer de passer derrière pour être sûr, je serai heureux de changer d'avis.
Surtout si l'outil en question ne dépend pas d'une usine à gaz de framework invasif. Pas demain la veille on dirait
Autre gros avantage de ne pas utiliser d'IDE: on est jamais, et ne sera jamais, enfermé par un seul outil, chacun d'entre eux est remplaçable à moindre frais ( frais d'apprentissages, hein ). Le jour ou un IDE n'est plus maintenu, il faut en apprendre un autre, et donc toute la chaîne. Pour un outil non intégré, il n'y a qu'un outil à changer.
Moi j'ai arreter d'utiliser Windows, parce que si jamais il est abandonné, je vais devoir tout réapprendre.Autre gros avantage de ne pas utiliser d'IDE: on est jamais, et ne sera jamais, enfermé par un seul outil, chacun d'entre eux est remplaçable à moindre frais ( frais d'apprentissages, hein ). Le jour ou un IDE n'est plus maintenu, il faut en apprendre un autre, et donc toute la chaîne. Pour un outil non intégré, il n'y a qu'un outil à changer.
Puis je préfere ne pas savoir conduire, parce que si je prend une voiture avec toutes options, le jours ou je ne les aurais plus je ne saurais plus conduire.
Et si un jours peugeot ferme, je devrais réapprendre à conduire avec une citroën, et si la marche arrière n'est pas au même droit...
Bref il vaut mieux resté à pieds.
Bon les abandons IDE, ca doit pas être très courant, de plus même si ils sont abandonnés, tu peux continuer à les utiliser, c'est juste leurs suivi et leurs améliorations qui ne seront plus faites.
Bref je vais perdre du temps en n'utilisant pas les outils offerts, car un hypothétique jours, je devrais peut-être me reformer. (Heursement qu'on travaille dans l'informatique)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager