Pourquoi devrais-je utiliser un IDE?
Dans une autre question, Mark parle hautement des IDE, disant que "certaines personnes ne savent toujours pas" pourquoi "elles devraient en utiliser un ...". En tant que personne qui utilise vim pour la programmation et travaille dans un environnement où la plupart/tous mes collègues utilisent vim ou emacs pour l'ensemble de leur travail, quels sont les avantages des EDI? Pourquoi devrais-je en utiliser un?
Je suis sûr que c'est un problème très chargé pour certaines personnes et que le fait de déclencher une guerre des flammes ne m'intéresse pas. Par conséquent, , répondez uniquement en indiquant les raisons pour lesquelles vous estimez qu'une approche basée sur l'EDI est supérieure. . Je ne suis pas intéressé à entendre pourquoi je ne devrais pas utiliser un IDE; Je n'en utilise déjà pas un. Je suis intéressé à entendre "de l'autre côté de la clôture", pour ainsi dire.
Si vous pensez que les IDE peuvent convenir à certains types de travail mais pas à d’autres, je voudrais aussi savoir pourquoi.
Cela dépend vraiment de la langue que vous utilisez, mais en C # et Java, je trouve les IDE avantageux pour:
- Navigation rapide vers un type sans avoir à se soucier de l'espace de noms, du projet, etc.
- Navigation vers les membres en les traitant comme des hyperliens
- Complétion automatique lorsque vous ne vous souvenez plus des noms de tous les membres par cœur
- Génération automatique de code
- Refactoring (massive)
- Organiser les importations (en ajoutant automatiquement les importations appropriées en Java, à l'aide de directives en C #)
- Warning-as-you-type (certaines erreurs ne nécessitent même pas un cycle de compilation)
- Survoler quelque chose pour voir les docs
- Garder une vue utile des fichiers, des erreurs/avertissements/tests de la console/de l'unité, etc., ainsi que du code source, simultanément et simultanément
- Facilité d'exécution des tests unitaires à partir de la même fenêtre
- Débogage intégré
- Contrôle de source intégré
- Accédez à l'emplacement où une erreur de compilation ou une exception d'exécution s'est produite directement à partir des détails de l'erreur.
- Etc!
Tout cela fait gagner du temps. Ce sont des choses que je pourrais faire manuellement, mais avec plus de douleur: je préférerais coder.
Achèvement du code. Cela aide beaucoup à explorer le code.
La réponse courte quant à la raison pour laquelle j’utilise un IDE est la paresse.
Je suis une âme paresseuse qui n'aime pas faire les choses de manière difficile lorsqu'il existe un moyen facile de le faire. Les IDE facilitent la vie et attirent tellement les fainéants.
Pendant que je tape le code, le IDE vérifie automatiquement la validité du code, je peux mettre une méthode en surbrillance et appuyer sur F1 pour obtenir de l'aide. Cliquez avec le bouton droit de la souris et sélectionnez "Aller à la définition" pour aller directement à l'endroit où il se trouve. défini. Je frappe un bouton et l'application, avec le débogueur automatiquement attaché est lancée pour moi. Et ainsi de suite. Toutes les activités quotidiennes d’un développeur sont regroupées sous un même toit.
Il n'est pas nécessaire d'utiliser un IDE. C'est juste un travail beaucoup plus difficile à ne pas faire.
Je ne pense pas qu'il soit juste de faire le classique "éditeur de texte et fenêtre de console vs IDE" quand "éditeur de texte" est vraiment emacs. La plupart des fonctionnalités typiques de IDE: s se trouvent également dans emacs. Ou peut-être même y sont-ils nés, et les IDE modernes sont principalement des améliorations/simplifications d’interface.
Cela signifie que pour la question initiale, la réponse n'est pas aussi claire. Cela dépend de comment les personnes sur le site en question utilisent emacs, s’ils l’utilisent principalement comme éditeur de texte, ou s’ils font tout leur possible et utilisent des scripts personnalisés, apprennent les commandes des modes sur le marquage de code et ainsi de suite.
Je viens à cette question de la direction opposée. J'ai été initié à la programmation avec très peu d'arrêts dans Makefile + Emacs. De mon tout premier compilateur sous DOS, Microsoft Quick C, j'avais un IDE pour automatiser les choses. J'ai passé de nombreuses années à travailler avec Visual C++ 6.0 et, après avoir obtenu mon diplôme en entreprise Java, j'ai travaillé avec Borland JBuilder, puis j'ai opté pour Eclipse, qui est devenu très productif pour moi.
Tout au long de ma carrière initiale d’auto-enseignement, de collège et maintenant de profession libérale, j’ai appris que tout développement logiciel majeur effectué uniquement dans le cadre de IDE devient contre-productif. Je dis cela parce que la plupart des IDE veulent que vous travailliez dans leur style particulier, celui du I-control-how-the-world-works. Vous devez couper vos projets en deux. Vous avez géré les constructions de votre projet en utilisant leurs boîtes de dialogue impaires. La plupart des IDE gèrent mal les dépendances de construction complexes entre projets, et il peut être difficile d'obtenir des dépendances à 100%. J'ai été dans des situations où IDE ne produirait pas une version de travail de mon code à moins que je ne fasse un Clean/Rebuild All. Enfin, il existe rarement un moyen propre de sortir votre logiciel du développement et de le placer dans d'autres environnements tels que le contrôle qualité ou la production à partir d'un environnement de développement intégré. C’est généralement un clic qui permet de construire toutes vos unités de déploiement, ou vous avez un outil maladroit que le vendeur IDE vous offre pour regrouper des éléments. Mais encore une fois, cet outil exige généralement que votre projet et votre structure de construction soient absolument conformes à leurs règles - et parfois cela ne répondra pas aux exigences de vos projets.
J'ai appris que, pour effectuer un développement à grande échelle avec une équipe, nous pouvons être les plus productifs si nous développons notre code à l'aide d'un IDE et si nous construisons toutes nos versions à l'aide de scripts de ligne de commande écrits manuellement. (Nous aimons Apache Ant pour le développement Java.) Nous avons constaté que l'exécution de nos scripts à partir de IDE n'est qu'un simple clic ou un cauchemar d'automatisation pour les versions complexes, c'est beaucoup plus facile. (et moins perturbant) pour alt + tab vers un shell et y exécuter les scripts.
Les constructions manuelles nous obligent à négliger certaines des subtilités de la compilation d'arrière-plan moderneIDE, mais ce que nous gagnons est beaucoup plus essentiel: des constructions propres et faciles pouvant vivre dans plusieurs environnements. Le "one click build" dont tous les gars agiles parlent? Nous l'avons. Nos scripts de construction peuvent également être directement appelés par des systèmes d’intégration continue. Le fait de gérer les builds via une intégration continue nous permet de formaliser et de migrer de manière plus formelle vos déploiements de code vers différents environnements, et nous permet de savoir presque immédiatement quand quelqu'un vérifie un code incorrect qui rompt la build ou les tests unitaires.
En vérité, prendre le rôle de construire loin du IDE ne nous a pas trop fait mal. Les outils intellisense et de refactoring d’Eclipse restent tout à fait utiles et valides - la compilation en arrière-plan sert simplement à les prendre en charge. Et le découpage particulier des projets par Eclipse a été un très bon moyen de décomposer mentalement nos problèmes de manière que tout le monde puisse comprendre (encore un peu verbeux à mon goût). Je pense que l’un des aspects les plus importants d’Eclipse est l’excellente intégration de SCM, c’est ce qui rend le développement en équipe si agréable. Nous utilisons Subversion + Eclipse, et cela a été très productif et très facile de former notre personnel à devenir des experts.
En tant qu'auteur de la réponse que vous avez soulignée dans votre question et que, certes, j'arrive un peu tard à celle-ci, je dois dire que parmi les nombreuses raisons énumérées, la productivité d'un développeur professionnel est l'une des plus importantes. compétences hautement considérées.
Par productivité, j'entends la capacité de faire votre travail efficacement avec les meilleurs résultats possibles. Les IDE permettent cela à plusieurs niveaux. Je ne suis pas un expert d'Emacs, mais je doute qu'il lui manque l'une des fonctionnalités des principaux IDE.
La conception, la documentation, le suivi, le développement, la construction, l'analyse, le déploiement et la maintenance, éléments clés d'une application d'entreprise, peuvent tous être effectués dans un environnement de développement intégré.
Pourquoi ne pas utiliser quelque chose d'aussi puissant si vous avez le choix?
En guise d’expérience, engagez-vous à utiliser un IDE pendant 30 jours, par exemple, et voyez ce que vous ressentez. J'aimerais lire vos pensées sur l'expérience.
Avoir un IDE présente les avantages suivants:
- La compilation est généralement "à la volée", ce qui signifie que vous ne devez plus passer en ligne de commande pour la compilation.
- Le débogage est intégré et avoir cela dans un IDE signifie que le débogueur d'étape utilise réellement votre éditeur in-situ pour vous montrer visuellement quel code est exécuté.
- Les IDE ont généralement une connaissance plus sémantique de la langue dans laquelle vous travaillez et peuvent vous montrer les problèmes possibles lors de la frappe. Le refactoring est beaucoup plus puissant que le "search replace".
Il y a beaucoup plus, vous devriez peut-être essayer.
Les IDE sont essentiellement:
- Éditeur avec complétion de code, refactoring et documentation
- Débogueur
- Explorateur de système de fichiers
- Client SCMS
- Outil de construction
le tout dans un seul paquet.
Vous pouvez avoir tout cela (et même plus) en utilisant des outils séparés ou tout simplement un excellent éditeur programmable et des outils supplémentaires, comme Emacs (Vim également, mais avec un peu moins d'IME IMO).
Si vous trouvez que vous passez souvent d’un utilitaire à l’autre pouvant être intégré à l’environnement ou si vous manquez certaines des compétences énumérées ici (et plus complètement dans d’autres articles), il est peut-être temps de passer à un IDE (ou pour améliorer l'IDE de votre environnement en ajoutant des macros ou non). Si vous avez créé vous-même un "IDE" (au sens que j'ai mentionné ci-dessus) en utilisant plusieurs programmes, il n'est pas nécessaire de passer à un IDE réel.
Éclipse:
Mettre en évidence le code, compiler en arrière-plan, signaler mes erreurs au fur et à mesure.
Intégration avec javadoc, suggérant des noms de variables avec ctrl-espace.
Quand je compile, je reçois des erreurs juste là. Je peux double-cliquer sur une erreur pour afficher la ligne appropriée.
Vraiment bien intégré à JUnit, ctrl-F11 exécute le test et me dit que les tests ont échoué. S'il y a une exception dans la fenêtre de sortie, je peux double-cliquer sur une ligne et m'emmener à la ligne qui a échoué. De plus, ctrl-F11 s'assure que tout est compilé avant d'exécuter les tests (ce qui signifie que je n'oublie jamais de le faire).
Intégration avec ant. Une commande pour construire et déployer l'application.
Intégration avec les débogueurs, y compris le débogage à distance des serveurs Web.
FANTASTIC outils de refactoring, recherchant des références à une section de code. M'aide à connaître l'impact d'un changement.
Globalement, cela me rend plus productif.
J'ai utilisé Emacs comme environnement principal pour le développement et le courrier/nouvelles pendant environ 10 ans (1994-2004). J'ai découvert le pouvoir des IDE lorsque je me suis forcé à apprendre Java en 2004, et à ma grande surprise d'apprendre que j'aimais bien le IDE ( IntelliJ IDEA ).
Je n'entrerai pas dans les détails, car bon nombre d'entre eux ont déjà été mentionnés ici - rappelez-vous simplement que les différentes personnes aiment différentes fonctionnalités. Un de mes collègues et moi-même utilisions le même IDE. Nous utilisions tous les deux une infime partie des fonctionnalités disponibles et nous n'aimions pas utiliser les autres comme IDE (mais nous aimions tous les deux le IDE].
Mais les IDE présentent un avantage par rapport aux environnements Emacs/Vim sur lesquels je souhaite me concentrer: vous passez moins de temps à installer/configurer les fonctionnalités souhaitées.
Avec Wing IDE (pour Python), je suis prêt à commencer à développer 15 à 20 minutes après l’installation. Aucune idée du nombre d'heures nécessaires pour utiliser les fonctionnalités que j'utilise avec Emacs/Vim. :)
Cela conduit certainement à une amélioration de la productivité pour moi. Au point que je code même des applications Linux dans Visual Studio sous Vista, puis que je les utilise sur une machine virtuelle Linux.
Vous n'êtes pas obligé de mémoriser tous les arguments d'un appel de fonction ou de méthode. Une fois que vous avez commencé à le saisir, le IDE vous indiquera les arguments nécessaires. Vous obtenez des assistants pour définir les propriétés du projet, les options du compilateur, etc. Vous pouvez rechercher des éléments dans l'ensemble du projet au lieu du document ou des fichiers en cours dans un dossier. Si vous obtenez une erreur du compilateur, double-cliquez dessus et cela vous mènera directement à la ligne incriminée.
Intégration d'outils tels que des éditeurs de modèles, connexion à des bases de données externes et navigation dans ces bases, gestion de collections de "fragments" de code, outils de modélisation d'interface graphique, etc. Toutes ces fonctionnalités peuvent être utilisées séparément. temps et permet au processus de développement de s’écouler plus efficacement.
Il peut y avoir différentes raisons pour différentes personnes. Pour moi, ce sont les avantages.
- Fournit une sensation intégrée au projet. Par exemple, je vais avoir tous les fichiers de projets liés en vue unique.
- Fournit une productivité accrue du code, telle que
- Mise en évidence de la syntaxe
- Référence des assemblées
- Intellisense
- Vue centralisée de la base de données et des fichiers d'interface utilisateur associés.
- Fonctions de débogage
À la fin de la journée, cela m’aide à coder plus vite que je ne peux le faire dans un bloc-notes ou un wordpad. C'est une très bonne raison pour moi de préférer un IDE.
Un IDE can peut être un choix "supérieur" en fonction de ce qu'un développeur tente d'accomplir.
Un éditeur de texte peut être 'supérieur' car les IDE sont généralement orientés vers une (ou une petite sélection) de langues.
Si un développeur passe le plus clair de son temps dans une seule langue ou dans un "cluster" de langages apparentés (tels que C # et T-SQL), dans un système d'exploitation, les outils de conception graphique, de débogage, d'intellisense, de refactoring, etc. proposés par un bon IDE peut être très convaincant. Si, par exemple, vous passez la plupart de votre temps à travailler dans VB.NET, avec peut-être un peu de T-SQL de temps en temps, dans un environnement Windows, vous seriez assez bête de ne pas regarder Visual Studio ou un IDE comparable. .
Je n'ai aucun préjugé envers ceux qui préfèrent les IDE ou les éditeurs de texte, les deux peuvent être très productifs et utiles si bien appris!
Je pense que cela a principalement à voir avec la portée de la sensibilisation pour le développeur. Le IDE fournit une vue macroscopique du contexte de travail du développeur. Vous pouvez voir simultanément les hiérarchies de classe, les ressources référencées, les schémas de base de données, les références d’aide SDK, etc. travailler uniquement à partir d'une île de code à la fois.
OTOH, "just me and vim and the man pages" me donne une vision microscopique beaucoup plus mince, mais intense et précise, de mon travail. Ceci est correct si j'ai une base de code cohésive bien conçue, bien partitionnée et faiblement couplée, construite dans un langage avec un ensemble de bibliothèques statiques sur lesquelles travailler, ce n'est pas votre situation habituelle, d'autant plus que la taille de l'équipe de développement augmente et modifie la structure du code. avec le temps, la distance et les préférences personnelles.
Je travaille actuellement sur des projets Flex et .NET. L’un des aspects les plus intéressants de Flex réside dans le fait qu’il existe peu de façons différentes d’atteindre un objectif standard: extraire des données d’une base de données, ouvrir/fermer/lire/écrire un fichier, etc. (Pourtant, j’utilise Flex Builder/Eclipse IDE - un exemple typique de poids lourd comme VS, car j'apprends toujours les bases et j'ai besoin des roues d'entraînement. Je m'attends à ce que je revienne à vim une fois que je suis sûr de mes habitudes.) De mon point de vue, je peux faire ce que je dois faire de façon professionnelle en sachant très bien certaines choses.
OTOH, je ne peux pas imaginer arriver à ce point avec .NET parce que la vue que je suis censé maintenir doit continuer à s’étendre et à se modifier. Il y a beaucoup moins d'intégrité conceptuelle, et sur plusieurs développeurs d'un projet sur plusieurs mois, beaucoup moins de cohérence - mais le IDE le soutient, peut-être l'encourage-t-il. Ainsi, le développeur doit vraiment (et peut plus facilement) en savoir beaucoup plus. Ce qui a également l'avantage de les aider à répondre (ou même à comprendre) un pourcentage beaucoup plus élevé des questions sur StackOverflow. C'est à dire. nous pouvons avoir une pile de connaissances plus profonde. Et nous pouvons répondre à une plus grande variété d’annonces d’aide.
Les choses peuvent aller trop loin dans les deux sens. Peut-être qu'avec la portée "éditeur uniquement", c'est comme "si vous n'avez qu'un marteau, tout ressemble à un clou". Avec l’approche IDE, quel que soit le type de fixation que vous souhaitez assembler, vous disposez d’un large choix de fixations et de gammes d’outils connexes - nals/marteaux, vis/tournevis, vis/clés, adhésifs/colle -pistolets/pinces, aimants et ainsi de suite - le tout à portée de main (avec un assistant pour vous aider à démarrer).
IntelliSense , le débogueur intégré et la fenêtre immédiate me rendent énormément plus productif ( Visual Studio 2008 ). Avec tout à portée de main, je peux garder la grande majorité d'un projet énorme dans ma tête tout en écrivant du code. Microsoft peut continuer à laisser tomber la balle sur leurs systèmes d'exploitation, mais Visual Studio est l'un des meilleurs produits jamais développés.
Ne pensez pas que c'est exclusif. Utilisez IDE pour les avantages qu'il procure et passez à l'éditeur de texte vim/preferred lorsque vous avez besoin d'une attention particulière.
Je trouve le IDE meilleur pour le refactoring, la navigation, le débogage et le calcul de quoi à faire. Les petites choses sont ensuite effectuées correctement dans l'IDE, les grandes choses que je passe à vim pour terminer le travail.
Je ne comprends pas ce que vous demandez. Vous demandez "Dois-je utiliser un IDE au lieu de ...", mais je ne comprends pas quelle est l'alternative - Vim et Emacs remplit de nombreuses fonctions de n'importe quel IDE vous en donnera. Le seul aspect qu’ils ne gèrent pas qu’un plus grand IDE peut être des choses comme les concepteurs d’interface utilisateur. Ensuite, votre question se résume à simplement "quel IDE devrais-je utiliser" avec des arguments à présenter pour le royaume plus simple de Vim et Emacs.
Les IDE graphiques tels que Visual Studio et Eclipse présentent plusieurs avantages par rapport aux IDE textuels tels que Emacs ou vim en raison de leurs capacités d'affichage:
- Aperçu WYSIWYG et édition en direct pour la conception d'interface graphique
- Éditeurs de propriétés efficaces (par exemple, sélection des couleurs à l'aide d'une palette d'interface graphique, y compris les arrêts de dégradés de positionnement, etc.)
- Représentation graphique des contours de code, des interrelations de fichiers, etc.
- Utilisation plus efficace de l'immobilier à l'écran pour afficher les points d'arrêt, les signets, les erreurs, etc.
- Meilleur support par glisser/déposer avec le système d'exploitation et d'autres applications
- Edition intégrée de dessins, images, modèles 3D, etc.
- Affichage et édition de modèles de base de données
Fondamentalement, avec un IDE basé sur une interface graphique, vous pouvez obtenir simultanément plus d’informations utiles à l’écran et vous pouvez visualiser/éditer des parties graphiques de votre application aussi facilement que des parties de texte.
L’une des choses les plus intéressantes à faire en tant que développeur consiste à éditer une méthode qui calcule des données et à afficher la sortie en direct de votre code sous forme graphique dans une autre fenêtre, comme le verra votre utilisateur lorsque vous exécuterez l’application. Maintenant, c'est l'édition WYSIWYG!
Les IDE basés sur le texte tels qu'Emacs et vim peuvent ajouter des fonctionnalités telles que l'achèvement de code et le refactoring au fil du temps. Par conséquent, leur principal inconvénient à long terme est leur modèle d'affichage basé sur le texte.
J'utilise aussi presque exclusivement Vim (presque parce que j'essaie d'apprendre emacs maintenant) pour tous mes projets de développement. Je pense que l’intuition (de l’interface graphique bien sûr) est la principale raison pour laquelle les gens aiment utiliser les IDE. En étant intuitif, il n’est pas nécessaire d’apprendre trop d’outil d’apprentissage. Plus le temps d'apprentissage est petit, plus ils peuvent travailler.
Je peux penser à deux raisons pour utiliser un IDE:
- L'aide intégrée est un favori.
- Le refactor intégré avec aperçu du Visual Studio
- IntelliSense , mise en évidence de la syntaxe, facilité de navigation pour les grands projets, débogage intégré, etc. Emacs et Vim ).
- De plus, je pense que les IDE ont de nos jours une base d'utilisateurs plus large et probablement plus de personnes développant des compléments pour eux, mais je me trompe peut-être.
Et franchement, j'aime ma souris. Lorsque j'utilise des éditeurs de texte purs, je me sens seul.
Un IDE permet de travailler plus rapidement et plus facilement ... J'ai remarqué que j'ai passé beaucoup de temps à naviguer dans le code dans un simple éditeur de texte ...
Dans un bon IDE, ce temps diminue si le IDE prend en charge le saut aux fonctions, à la position d'édition précédente, aux variables ... De plus, un bon IDE réduit le temps d'expérimentation différentes fonctionnalités linguistiques et des projets, car le temps de démarrage peut être petit.
Pour moi, un IDE est préférable, car il permet une navigation plus rapide dans le code, ce qui est important si vous avez quelque chose à l'esprit à implémenter. Si vous n'utilisez pas d'IDE, il faut plus de temps pour arriver à la destination. Vos pensées peuvent être interrompues plus souvent. Cela signifie que plus de clics/plus de touches doivent être appuyés. Il faut se concentrer davantage sur la façon de mettre en œuvre les choses. Bien sûr, vous pouvez aussi écrire des choses, mais il faut ensuite basculer entre la conception et la mise en œuvre. En outre, un concepteur d'interface graphique fait une grande différence. Si vous le faites à la main, cela peut prendre plus de temps.
Gain de temps pour se développer
Facilite la vie en fournissant des fonctionnalités telles que le débogage intégré, intellisense.
Il y en a beaucoup, mais je recommanderai d'en utiliser un, ils sont plus qu'évidents.
Pour moi, c’est la version graphique de tout ce que nous avons fait au bon vieux temps du terminal. Je conviendrai toujours que IDE ne sont pas très supérieurs, car ils cachent beaucoup de choses, en particulier en ce qui concerne les liens, mais ils ont un avantage notable dans certains cas, par exemple avec certaines plates-formes de développement comme Qt.
Certains IDE comme les visuels des autres semblent même analyser votre code au fur et à mesure de la frappe et détecter les erreurs avant même de compiler: il semble logique que seul un IDE puisse travailler en étroite collaboration avec un compilateur pour détecter immédiatement le problème dans la source typée.
Ma réponse sauvage à l’existence de la guerre des flammes entre IDE et ligne de commande tient au fait que le fichier exécutable C/C++ n’est pas très bien géré d’un point de vue normalisé, contrairement au langage D; chaque plate-forme gère la compilation/la liaison de/etc à sa manière, afin de la rendre moins compliquée, elle crée un environnement de développement intégré.
De votre point de vue, il serait peut-être plus simple d’utiliser la ligne de commande. S’il y aurait eu un seul compilateur avec des options standard, c’était simple, mais le fait est que C/C++ est flexible; faites-le à leur manière, d'où le IDE à ne pas perdre à expliquer comment le faire.
Si vous pouvez savoir comment un exécutable communique avec le noyau ou si vous connaissez la conception du compilateur, il existe peut-être un moyen de travailler avec une ligne de commande appropriée, mais je doute que vous l'ayez fait.
Microsoft ou Apple, tous méchants qu’ils soient, doivent proposer un moyen simple de construire une application sans entrer dans les détails, et puisque la construction d’une application dépend directement de l’architecture de son système d’exploitation, elle ne sera guère "standard", la ligne de commande est.
Pour simplifier, les applications volumineuses et complexes dans lesquelles vous ne voulez pas plonger trop profondément dans ce qu’il fait -> IDE, de petits logiciels ou une simple conception de logiciel système -> ligne de commande. Excepté bien sûr ces bibliothèques astucieuses qui intègrent un Makefile, mais c'est une autre histoire.
De plus, je pense que IDE sont utilisés lorsque l'application livrée a quelque chose à voir avec, ironiquement, une interface graphique ou quelque chose qui a une interface ou qui est directement lié à un système d'exploitation. Encore une fois, c'est aussi pour les personnes qui vont utiliser une interface utilisateur/interface graphique sans savoir comment cela fonctionne, alors que les personnes qui programmeront des systèmes n'auront pas besoin de tout.
IDE est juste une merde moderne, mais je pense que dans 100 ans, la ligne de commande existera toujours.
Ma principale raison d’en utiliser un, c’est lorsque le code dépasse 100 fichiers.
Bien que ctags puisse faire le travail, certains IDE ont un très bon moyen de parcourir les fichiers facilement et très rapidement.
Cela vous fait gagner du temps lorsque vous avez beaucoup de travail à faire.
Je ne suis pas sûr qu'il y ait une ligne de démarcation claire entre un éditeur de texte et un IDE. Vous avez le type Bloc-notes à un bout de l'échelle et les meilleurs IDE modernes à l'autre bout, mais il y a beaucoup de choses entre les deux. La plupart des éditeurs de texte ont la coloration syntaxique. Les éditeurs destinés aux programmeurs ont souvent diverses autres fonctionnalités telles que la navigation par code facile et la saisie automatique. Emacs vous permet même d'intégrer un débogueur. Il y a dix ans à peine, les IDE avaient beaucoup moins de fonctionnalités pour aider les programmeurs que ce à quoi on s'attend de la part d'un éditeur de texte sérieux.
Cela dépend fortement de ce que vous faites et de la langue dans laquelle vous le faites. Personnellement, j’ai tendance à ne pas utiliser un IDE (ou "my IDE) composé de 3 xterms en cours d'exécution. vim, l’un exécutant un client de base de données et l’autre avec une invite bash ou des journaux ", en fonction de la définition générale de" IDE ") pour la plupart de mes travaux, mais si je devais développer moi-même une interface graphique native pour la plate-forme, alors je chercherais un IDE approprié à la langue en un instant - IMO, les IDE et l'édition de formulaires graphiques sont clairement faits l'un pour l'autre.
Un IDE gère le travail difficile qui vous fait gagner du temps.
Il conserve tous les fichiers de projet associés ensemble, ce qui facilite la collaboration.
Vous pouvez généralement intégrer votre contrôle de code source à votre IDE afin d’économiser davantage de travail saccadé et d’améliorer encore la collaboration.
Si elle comporte des fonctionnalités de saisie automatique, elle peut vous aider à explorer la langue de votre choix et à enregistrer des dactylographies.
Fondamentalement, un IDE réduit le travail non programmé du programmeur.
J'aime un IDE parce qu'il me donne beaucoup de fonctionnalités. Éditer/Compiler/La visibilité des fichiers dans le projet sont toutes les choses que je valorise dans un IDE. J'utilise Visual Studio maintenant, mais dans une vie antérieure, j'utilisais SlickEdit et trouvais que cela rendait mon processus de développement plus simple que lorsque je ne l'utilisais pas.
Je ne suis pas entièrement vendu sur l'utilisation des IDE. Cependant, je pense que l’aspect le plus précieux d’un bon IDE, comme Eclipse , est la fonctionnalité bien intégrée Cscope - - compréhension rapide d’une grande base de code.
Par exemple, dans Eclipse, vous voyez qu'une méthode prend un argument de type FooBar, mais vous n'avez aucune idée de ce que cela signifie. Plutôt que de perdre une minute à trouver la définition à la dure (et à risquer toutes sortes de distractions en chemin), il suffit de sélectionner FooBar, cliquez sur F3et ouvre le fichier source correspondant à la ligne même que FooBar est définie.
L'inconvénient des IDE, à mon avis, est qu'ils vous donnent une courbe d'apprentissage plus longue, sauf dans le cas où vous souhaitez utiliser la configuration absolue par défaut. (Ceci est vrai pour Emacs également.)
Il n’ya qu’une chose à prendre en compte lorsque vous décidez d’utiliser un IDE ou non, c’est de savoir si cela vous rend plus productif ou non.
Question courte donc réponse courte :)
C'est vraiment TRES simple. Mais cette réponse est un peu paradoxale dans le sens où je discute de quelque chose que seuls les développeurs de niveau EMBEDDED rencontrent. C’est parce que, franchement, lorsque je travaillais dans le monde du travail intégré (la brève période où je gagnais de l’argent réel), un IDE serait en train de devenir étrange et la plupart de vos collègues se demanderaient pourquoi vous pouvez Vous ne vous en souvenez plus assez sur SNMP / ASN.1 ou quel que soit le protocole que vous utilisiez pour simplement/faire votre travail /. MAIS vous ne pouvez PAS, autant que je sache, faire une simulation graphique de ce que votre microcontrôleur fait quelque chose comme/temps réel/sans "IDE".
Je préfère un IDE parce qu'il me permet d'intégrer l'édition/la compilation/le débogage, en effectuant un saut d'un clic d'une erreur à une autre. De plus, cela permet de disposer de plusieurs panneaux d’informations avec des interfaces standard du système d’exploitation affichant les informations. En bref, il offre à l'utilisateur une interface d'entrée basée sur la souris avec une interface de sortie moderne au lieu de s'appuyer sur la technologie et les interfaces des années 1970 pour mon aide.
Il existe des utilisateurs et des utilisations plus sophistiqués pour un IDE, je ne prétends pas les utiliser ou les connaître tous. Quand j'aurai besoin, je les apprendrai.
En termes simples, un IDE offre des fonctionnalités supplémentaires permettant de gagner du temps par rapport à un simple éditeur.