Être dépendant de l'IDE. Comment cela peut-il me nuire?

Je suis un développeur très dépendant de l'IDE (NetBeans et Eclipse car je suis un développeur JAVA). Je peux coder correctement si j'ai un IDE. Je peux beaucoup compter sur cela pour le développement, le débogage et le déploiement. Mais sans IDE, je ne peux rien faire. Peut coder un simple programme hello world ou un simple arrangement d'interface utilisateur, mais j'ai besoin d'un IDE pour faire des choses complexes ou un long codage de choses plus simples.

Pensez-vous que cela me fait du mal? Certains programmeurs qui ont plus de 6 ans d'expérience en développement croient fermement que cela peut être nocif, mais je pense que si je peux faire des choses complexes rapidement et correctement, pourquoi devrais-je m'en tenir au bloc-notes et aux outils de ligne de commande pour effectuer une tâche longue lorsque Les IDE ont un bouton pour cliquer?

Comme d'autres l'ont dit, il est bien d'être plus rapide dans votre IDE que sans lui, c'est un peu le point. Être capable d'utiliser correctement des outils complexes pour augmenter votre productivité est une compétence importante.

Cependant, une dépendance excessive à l'égard des IDE peut entraîner des problèmes. Les compétences et les connaissances que vous n'exercez plus disparaîtront et votre compréhension de certains aspects peut être superficielle. Un exemple classique est la compilation et l'exécution sur la ligne de commande - presque chaque fois que je fais cela, je me trompe (généralement lié au chemin de classe), car 99% du temps je laisse Eclipse le faire pour moi.

Cela ne vous affecte pas seulement lorsque vous êtes hors de l'IDE - si votre connaissance des complexités que l'IDE vous cache est superficielle, alors quand ça va mal (et ça va mal, à un moment donné), vous trouverez il est beaucoup plus difficile à réparer.

Je gère ces deux façons:

1. Apprenez de nouveaux outils dans leur forme la plus élémentaire. Par exemple, je suis passé de SVN à Mercurial, mais j'ai commencé avec le client de ligne de commande plutôt qu'avec le plugin Eclipse. Cela m'a permis de comprendre ce qui se passait beaucoup plus profondément, ce qui signifiait que je savais ce qui n'allait pas et comment y remédier lorsque l'EDI lançait des erreurs.

2. Pratiquez vos compétences de codage de base sur la ligne de commande. Un bon endroit pour le faire est CodingBat où vous n'obtenez aucune mise en évidence de la syntaxe, aucune correspondance entre crochets, aucun soulignement rouge, rien. N'oubliez pas de pratiquer également ces compétences en ligne de commande java et javac! (Et tous les autres appropriés à votre flux de travail - pour moi, cela comprendrait également hg et ant)

Enfin, ne vous en faites pas trop. Il est peu probable que vous ayez à faire un gros travail sans NetBeans ou Eclipse, donc tant que vous êtes capable de coder sans eux et de comprendre ce que l'IDE fait pour vous, peu importe que vous '' re plus lent ou faire plus d'erreurs sans cela.

Non, je pense que c'est l'inverse en fait. L'IDE supprime la nécessité pour vous de connaître un framework par cœur (via intellisense) et simplifie les tâches autrement ennuyeuses / répétitives / complexes (débogage, déploiement), des choses qui ne vous intéressent vraiment pas. Cela vous permet de vous concentrer sur la résolution du problème commercial actuel . Connaître et IDE et bien le connaître peut vraiment vous aider à écrire du code maintenable plus rapidement.

Et bien sûr, être développeur ne se résume pas à cela. L'expérience que vous avez en tant que développeur vous aide à appliquer la bonne solution à un problème qui vous traverse. Je pense que c'est la vraie compétence.

Non, cela ne vous "fait pas de mal". Bien sûr, vous devez comprendre comment les choses fonctionnent sans IDE (c'est-à-dire que vous devez comprendre le processus de compilation de base, etc.) mais ne soyons pas masochistes à ce sujet ... si un IDE vous rend plus productif que de ne pas en utiliser un, alors pourquoi ne le ferait-il pas? vous?

Être dépendant de l'IDE présente les risques suivants:

• vous finissez par créer une version logicielle qui nécessite un IDE et une version spécifiques.
• vous forcez d'autres personnes de votre équipe à utiliser cet IDE pour créer le système.
• vous ne pouvez pas facilement automatiser la construction de votre logiciel.
• vous n'avez aucune idée de vos dépendances logicielles.

Assurez-vous donc que vous pouvez également créer votre logiciel à partir de la ligne de commande. Par exemple, en Java, utilisez maven ou ant. Ensuite, vous atténuez les risques ci-dessus.

Autres risques de dépendance IDE:

• l'IDE signale les erreurs et les avertissements dans votre code et vous donne des correctifs rapides. Ceux-ci peuvent ne pas être appropriés - il y a peut-être un problème de conception ou d'exigences en jeu.
• vous oubliez les bases - vous devez connaître les bases de la langue de votre choix afin de pouvoir la maîtriser et de transmettre votre compétence lors des entretiens.
• vous vous retrouvez coincé dans un bac à sable IDE - peur d'essayer quelque chose de nouveau ou tout ce qui n'est pas pris en charge par votre IDE. Par exemple, votre IDE peut avoir des fonctions assez étendues de recherche et de remplacement. Mais ce n'est rien comparé à la puissance et à la vitesse des outils de ligne de commande tels que grep et sed. Vous ne pouvez pas faire de développement Android car votre IDE choisi (par exemple, netbeans) ne le prend pas bien en charge.
• certains IDE ne peuvent pas gérer de gros fichiers - par exemple, essayez d'ouvrir un grand fichier de sortie du serveur dans eclipse. Cela prend une éternité et / ou manque de mémoire.

Il n'y a rien de mal à être plus productif avec l'ensemble d'outils que vous avez choisi. Mais si vous ne pouvez pas travailler sans cela, je me méfierais de votre connaissance intérieure.

N'abandonnez pas l'IDE; mais de temps en temps, essayez de faire quelques classes «faciles» avec juste un éditeur et de la documentation sur un navigateur.

N'oubliez pas que même plus rapidement que les meilleurs outils, vous n'avez pas à les utiliser.

Mais sans IDE, je ne peux rien faire.

J'ai besoin d'un IDE pour faire des choses complexes ou un long codage de choses plus simples.

Vous pouvez résoudre ce problème, vous savez.

Vous pourriez réellement apprendre le langage et le cadre.

Rien ne vous arrête.

À moins, bien sûr, que vous ne vous vantiez d'être dépendant de l'IDE.

pourquoi devrais-je m'en tenir au bloc-notes et aux outils de ligne de commande pour effectuer une tâche fastidieuse lorsque les IDE ont un clic sur le bouton pour le faire?

Est sans rapport. "Stick to notepad" n'a rien à voir avec "sans IDE je ne peux rien faire". Ne rien faire dans le bloc-notes n'a rien à voir avec le fait de s'en tenir au bloc-notes. Lequel est-ce?

Vous n'êtes pas si "dépendant", car vos deux IDE sont open source, donc ils ne disparaîtront pas ou ne seront pas accidentellement "améliorés" au point d'être inutilisables. Et la langue de votre choix ne vous laisse aucune option - vous dépendez de millions de bibliothèques, et il est juste stupide d'essayer de se souvenir de toutes ces choses sans importance quand il y a un IDE pour vous aider. Java est verbeux, verbeux et vous ne pouvez pas être productif sans des outils intelligents qui exploitent la verbosité redondante.

Je pense que le mal de la dépendance excessive à l'égard d'un IDE entre en jeu lorsque vous comptez aveuglément sur les assistants pour générer du code pour vous. NetBeans et Eclipse sont assez légers sur ceux-ci, ce qui est une bonne chose OMI. Un autre inconvénient serait que vous ne connaissiez qu'un seul IDE et que vous ne puissiez pas en utiliser d'autres. Certaines entreprises ont des politiques qui dictent ce que vous utiliserez. Pour le meilleur ou pour le pire, c'est ce que c'est.

Je dirais que si un IDE ne vous rend pas plus productif, il n'en vaut pas la peine. Par exemple, je suis le plus productif avec JetBrains IDEA, mais Eclipse a parcouru un long chemin et je peux être assez productif avec cela. Eclipse a également été adapté pour une large gamme d'utilisations - ce qui est un double avantage. Bien que je puisse me déplacer dans VIM, ou dans un autre éditeur de texte, il existe d'autres fonctionnalités que je trouve irremplaçables dans la plupart des IDE actuels, comme la prise en charge de la refactorisation.

Je ne pense pas que vous vous rendiez service. Certes, vous utilisez Eclipse, qui est disponible gratuitement et fonctionne partout où vous avez une machine virtuelle Java. Mais j'ai rencontré des situations auparavant où je devais me connecter à une autre machine via une session de terminal sans serveur X, ce qui signifie que je devais utiliser un éditeur de texte brut comme vi et construire sur la ligne de commande. Je travaille également dans un environnement où le réseau de développement est physiquement isolé du reste du monde, et tous les transferts entre celui-ci et le réseau public se font via des supports physiques. La seule raison pour laquelle nous avons Eclipse sur ce réseau est qu'il a d'abord traversé plusieurs couches d'approbation.

J'ai coupé mes dents sur C et Fortran 77 dans un environnement de ligne de commande (VAX / VMS), donc je trouve la notion d' avoir besoin d' un IDE quelque peu suspecte. Cependant, ce sont de minuscules langages par rapport à la bête qu'est Java; étant donné que vous avez besoin d'un chariot élévateur pour transporter le dernier livre Java Nutshell, je peux voir comment avoir l'IDE disponible rend la vie beaucoup plus facile.

Cela ne peut pas vraiment vous «nuire», mais vous y gagneriez si vous êtes également habitué à faire des choses sans l'IDE. N'ayez pas peur d'élargir votre horizon.

N'oubliez pas que la plupart des outils de développement sont d'abord écrits comme des outils de ligne de commande. Les IDE sont des réflexions après coup, ce qui est bien. D'un autre côté, vous trouverez souvent des «commutateurs de ligne de commande de gemme cachés» ou des «astuces avancées» que vous ne pourrez jamais découvrir si vous gardez le point et cliquez.

Donc, pour répondre à la question "Comment cela peut-il me nuire?" Je pense que cela vous nuirait lorsque vous vous y attacheriez tellement que vous pensez que tous les outils de ligne de commande vont être plus lents que de cliquer sur des boutons, au point que vous évitez d'apprendre les outils de ligne de commande (qui sont les origines).

C'est comme apprendre l'assemblage en tant que programmeur - très peu d'entre nous écrivent l'assemblage à la main aujourd'hui, mais je crois que ceux qui comprennent l'assemblage sont de meilleurs programmeurs dans le langage qu'ils utilisent.

Être dépendant de l'ordinateur est déjà assez dangereux. Je programme toujours dans un pagne avec une grosse tablette de pierre et un marteau. Le code met un certain temps à disparaître, mais lorsque vous terminez une méthode particulièrement importante, vous mangez généralement quelque chose. Là, j'essaie d'être indépendant du supermarché et de ce genre de choses, alors je cultive tout mon blé à la maison et je mange ça. Bien sûr, les fournisseurs de semences de blé et d'eau m'ont presque accroché, ce qui me fait penser qu'il n'y a aucun moyen de sortir de ce cycle de dépendance.

Sérieusement: si <disclaimer>vous utilisez un IDE et que </disclaimer>vous vous retrouvez sans IDE et que vous DEVEZ programmer, vous devez simplement vous considérer comme un jeu terminé et

1. Appelez-le ou
2. Résolvez le problème vous-même si vous êtes IT

Non seulement vous ne devez pas programmer sans les outils que vous jugez nécessaires, mais vous ne pouvez pas non plus utiliser de dentifrice comme pâte thermique.

Être dépendant de l'IDE ne peut pas nécessairement vous nuire, mais être capable de fonctionner sans l'environnement de votre choix est une compétence vitale.

Les IDE peuvent vous empêcher d'apprendre de `` petites choses '' qui sont généralement insignifiantes et peuvent vous aider à faire le travail plus rapidement car vous évitez la dactylographie / passe-partout inutile. Vous pouvez également généralement résoudre les problèmes à mesure qu'ils se produisent, par exemple une faute d'orthographe sur une fonction.

Ma règle personnelle lors de l'apprentissage de n'importe quel langage / framework / etc est de l'apprendre en premier. Ensuite, une fois que je l'ai maîtrisé, je suis tombé, j'ai gagné le droit de le faire facilement. Le truc, c'est que si vous ne connaissez pas certains des petits détails, lorsque votre canalisation d'égout commence à cracher de la merde hors de l'évier de la cuisine, vous serez SOL. Si vous savez quelles opérations sous-jacentes pourraient être une cause potentielle, vous pouvez probablement résoudre le problème ou l'empêcher de se produire complètement.

Essayons un bon éditeur de texte, par exemple PSPad pour MS-Windows (freeware), TextMate pour Mac OS X, Geany pour GNU Desktop (opensource) ou Kate pour KDE (opensource).

MultiEdit4.0 pour MS-DOS a changé ma vie il y a plusieurs années, depuis lors, je suis très sensible aux éditeurs de texte.