Почему я должен использовать IDE? [закрытый]

автозавершение кода. Это очень помогает в изучении кода.

короткий ответ на вопрос, почему я использую IDE, - это лень.

Я ленивая душа, которая не любит делать вещи трудный путь, когда есть простой способ сделать это вместо меня. IDE делают жизнь легкой и поэтому обращаются к нам, ленивым людям.

когда я набираю код, IDE автоматически проверяет правильность кода, я могу выделить метод и нажать F1, чтобы получить помощь, щелкните правой кнопкой мыши и выберите "Перейти к определению", чтобы перейти прямо туда, где он определен. Я нажал одну кнопку и приложение, с автоматически подключенным отладчиком запускается для меня. И так список продолжается. Все, что разработчик делает на ежедневной основе, собирается под одной крышей.

нет необходимости использовать IDE. Просто гораздо труднее не делать этого.

Я не думаю, что справедливо делать классический "текстовый редактор и окно консоли против IDE", когда" текстовый редактор " действительно emacs. Большинство функций, типичных для IDE: s, также находятся в emacs. Или, возможно, они даже возникли там, и современные IDE:s в основном улучшения/упрощения интерфейса.

Это означает, что для исходного вопроса ответ не так ясен. Это зависит от как люди на сайте, о котором идет речь, используют emacs, если они в основном используют его как текст редактор, или если они все выходят и используют пользовательские сценарии, изучают команды для соответствующих режимов, знают о тегировании кода и так далее.

Я подхожу к этому вопросу с противоположной стороны. Я был воспитан в программировании с очень небольшим количеством питстопов в Makefile+Emacs land. С самого раннего компилятора на DOS, Microsoft Quick C, у меня была IDE для автоматизации вещей. Я провел много лет, работая в Visual C++ 6.0, и когда я закончил Enterprise Java, я работал с Borland JBuilder, а затем остановился на Eclipse, который стал очень продуктивным для меня.

на протяжении всего моего первоначального самообучения, колледжа и сейчас профессиональная карьера, я пришел, чтобы узнать, что любая крупная разработка программного обеспечения, сделанная исключительно в рамках IDE, становится контрпродуктивной. Я говорю это, потому что большинство IDE хочет, чтобы вы работали в их своеобразный стиль I-control-how-the-world-works. Вы должны нарезать и кости ваши проекты вдоль их линий. Вы управляете своими сборками проекта, используя их нечетные диалоговые окна. Большинство IDE плохо управляют сложными зависимостями сборки между проектами, и зависимости могут быть трудно получить работает на 100%. Я был в ситуациях, когда IDE не создавал бы рабочую сборку моего кода, если бы я не сделал чистую/перестроить все. Наконец, редко есть чистый способ переместить программное обеспечение из разработки в другие среды, такие как QA или производство из IDE. Обычно это clicky fest, чтобы построить все ваши подразделения развертывания, или у вас есть какой-то неудобный инструмент, который поставщик IDE дает вам, чтобы собрать вещи. Но опять же, этот инструмент обычно требует, чтобы ваш проект и структура сборки абсолютно соответствует их правилам - и иногда это просто не будет работать для требований ваших проектов.

Я узнал, что для крупномасштабной разработки с командой мы можем быть наиболее продуктивными, если мы разрабатываем наш код с помощью IDE и делаем все наши сборки с помощью сценариев командной строки, написанных вручную. (Нам нравится Apache Ant для разработки Java.) Мы обнаружили, что запуск наших скриптов из IDE-это просто click fest или кошмар автоматизации для сложных сборок, это много проще (и менее разрушительно) alt+tab в оболочку и запускать скрипты там.

ручные сборки требуют от нас пропустить некоторые тонкости в современной IDE, такие как фоновая компиляция, но то, что мы получаем, гораздо более важно: чистые и легкие сборки, которые могут жить в нескольких средах. "One click build", о котором говорят все эти проворные парни? Она у нас. Наши сценарии сборки могут быть непосредственно вызваны системами непрерывной интеграции. Имея строит управляемых через непрерывная интеграция позволяет нам более формально этапировать и переносить развертывания кода в различные среды и позволяет нам почти сразу же узнать, когда кто-то проверяет плохой код, который нарушает построение или модульные тесты.

по правде говоря, мое принятие роли сборки от IDE не повредило нам слишком сильно. Инструменты intellisense и рефакторинга в Eclipse по - прежнему полностью полезны и действительны-фоновая компиляция просто служит для поддержки этих инструментов. И, в Eclipse своеобразное нарезание проектов послужило очень хорошим способом мысленно разбить наши наборы проблем таким образом, чтобы каждый мог понять (все еще немного многословный на мой вкус). Я думаю, что одна из самых важных вещей в Eclipse-отличная интеграция SCM, что делает командное развитие таким приятным. Мы используем Subversion+Eclipse, и это было очень продуктивно и очень легко обучить наших людей, чтобы стать экспертами.

будучи автором ответа, который вы выделяете в своем вопросе, и, по общему признанию, приходя к этому немного поздно, я должен сказать, что среди многих причин, которые были перечислены, производительность профессионального разработчика является одним из самых высоко ценимых навыков.

под производительностью я подразумеваю способность эффективно выполнять свою работу с наилучшими возможными результатами. IDEs позволяют это на многих уровнях. Я не эксперт Emacs, но я сомневаюсь, что ему не хватает каких-либо функций крупных язей.

проектирование, документация, отслеживание, разработка, построение, анализ, развертывание и обслуживание, ключевые этапы в корпоративном приложении, могут быть выполнены в среде IDE.

Почему бы вам не использовать что-то настолько мощное, если у вас есть выбор?

в качестве эксперимента возьмите на себя обязательство использовать IDE, скажем, 30 дней, и посмотрите, как вы себя чувствуете. Я хотел бы прочитать ваши мысли об этом опыте.

наличие IDE имеет следующие преимущества:

• компиляция обычно "на лету", что означает, что больше нет переключения в командную строку для компиляции
• отладка интегрирована, и что в IDE означает, что отладчик использует редактора, чтобы наглядно показать вам, какой код выполняется
• IDE обычно имеют больше семантических знаний о языке, на котором вы работаете, и могут показать вам возможные проблемы при наборе текста. Рефакторинг намного мощнее, чем"поиск замены".

есть гораздо более, может быть, вы должны дать ему попробовать.

IDEs в основном:

• редактор с завершением кода, рефакторингом и документацией
• отладчик
• файловая система проводник!--4-->
• клиент SCMS
• построить инструмент

все в одном пакете.

вы можете иметь все это (и еще несколько), используя отдельные инструменты или просто отличный программируемый редактор и дополнительные инструменты, такие как Emacs (Vim, но имеет немного меньше IDEbility IMO).

Если вы найдете вы много переключаетесь между одной утилитой и следующей, которая может быть интегрирована в среду, или если вам не хватает некоторых возможностей, перечисленных здесь (и более полно в других сообщениях), возможно, пришло время перейти к IDE (или улучшить IDEbility вашей среды, добавив макросы или что-то еще). Если вы создали " IDE " (в том смысле, о котором я упоминал выше), используя более одной программы, нет необходимости переходить к реальной IDE.

затмение:

имея код higlighting, компиляции в фоновом режиме, указывая на мои ошибки, как я иду вперед.

интеграция с javadoc, предлагая имена переменных с ctrl-пробелом.

когда я компилирую, я получаю ошибки прямо там. Я могу дважды щелкнуть по ошибке, и она отобразит соответствующую строку.

очень хорошо интегрирован с JUnit, ctrl-F11 запускает тест, говорит мне, что тесты не удалось. Если в окне вывода есть исключение, Я могу дважды щелкнуть по строке и перейти к строке, которая не удалась. Не только это, но ctrl-F11 гарантирует, что все скомпилировано до запуска тестов (что означает, что я никогда не забываю это делать).

интеграция с ant. Одна команда для создания и развертывания приложения.

интеграция с отладчиками, включая удаленную отладку веб-серверов.

фантастические инструменты рефакторинга, поиск ссылок на раздел кода. Помогает мне узнать влияние изменение.

в целом, это делает меня более продуктивным.

Это определенно приводит к повышению производительности для меня. До такой степени, что я даже кодирую Приложения Linux в Visual Studio на Vista, а затем использую виртуальную машину Linux для их создания.

вам не нужно запоминать все аргументы для вызова функции или метода, как только вы начнете вводить его, IDE покажет вам, какие аргументы необходимы. Вы получаете мастера для установки свойств проекта, параметров компилятора и т. д. Вы можете искать вещи на протяжении всего проекта вместо текущего документа или файлов в папке. Если вы получаете ошибку компилятора, дважды щелкните ее, и она приведет вас прямо к оскорбительной строке.

интеграция таких инструментов, как редакторы моделей, подключение и просмотр внешних баз данных, управление коллекциями "фрагментов кода", инструменты моделирования GUI и т. д. Все эти вещи можно было бы иметь отдельно, но имея их все в одной среде разработки экономит много времени и держит процесс разработки течет больше эффективно.

Я использовал Emacs в качестве основной среды для развития и почты/новостей около 10 лет (1994-2004). Я обнаружил силу IDEs, когда заставил себя изучать Java в 2004 году, и к моему удивлению, мне действительно понравилась IDE (IntelliJ IDEA).

Я не буду вдаваться в конкретные причины, так как многие из них уже упоминались здесь-просто помните, что разные люди любят разные функции. Я и коллега использовали одну и ту же IDE, оба из мы использовали только часть доступных функций, и нам не нравился друг другу способ использования IDE (но нам обоим нравилась сама IDE).

но есть одно преимущество с IDEs над средами, связанными с Emacs/Vim, на которых я хочу сосредоточиться: вы тратите меньше времени на установку/настройку необходимых функций.

с крыло IDE (для Python) я готов начать разработку через 15-20 минут после установки. Не знаю, сколько часов мне понадобится, чтобы получить функции, которые я использую и работает с Emacs/Vim есть. :)

для разных людей могут быть разные причины. Для меня это преимущества.

1. обеспечивает интегрированное чувство к проекту. Например, у меня будут все связанные файлы проектов в одном представлении.
2. обеспечивает повышение производительности кода
   1. Синтаксис
   2. ссылка на сборки
   3. Intellisense
   4. централизованное представление базы данных и связанных файлов пользовательского интерфейса.
   5. отладка особенности

В конце концов, это помогает мне кодировать быстрее, чем я могу сделать в блокноте или wordpad. Это довольно веская причина для меня предпочесть IDE.

IDE can быть "превосходным" выбором, основанным на том, что разработчик пытается выполнить.

текстовый редактор can быть "превосходящим", потому что IDE обычно ориентированы на один (или небольшой выбор) языков.

Если разработчик проводит большую часть своего времени в одном languge или "кластере" связанных языков (например, C# и T-SQL), в одной ОС, то дизайн GUI, отладка, intellisense, рефакторинг и т. д. инструменты, предлагаемые хорошая IDE может быть очень убедительным. Если, например, вы проводите большую часть времени, работая в VB.NET, возможно, с небольшим T-SQL время от времени, в среде Windows, тогда было бы довольно глупо не смотреть на Visual Studio или сопоставимую IDE.

У меня нет предубеждения к тем, кто предпочитает IDEs или текстовые редакторы, оба могут быть очень продуктивными и полезными если научился хорошо!

Я думаю, что это в основном связано с объемом осведомленности для разработчика. Среда IDE предоставляет макроскопическое представление рабочего контекста разработчика. Вы можете одновременно видеть иерархии классов, ссылочные ресурсы, схемы баз данных, справочные ссылки SDK и т. д. И с таким количеством вещей, затронутых и влияющих на ваши нажатия клавиш, а также расширяющийся объем архитектур и архитектурных пересечений, становится все труднее работать только с одного острова кода в время.

OTOH, "только я, ВИМ и man pages" дает мне гораздо более тонкий микроскопический - но интенсивный и точный - вид моей работы. Это нормально, если у меня есть хорошо спроектированная, хорошо разбитая, редко связанная высокосвязанная кодовая база, построенная на одном языке с одним набором статических библиотек для работы-не ваша типичная ситуация, особенно когда размеры команды разработчиков растут и изменяют структуру кода со временем, расстоянием и личными предпочтениями.

в настоящее время я работаю на проекты в Flex и .Сеть. Одна из приятных вещей о Flex - это то, как мало разных способов выполнить стандартную вещь-вытащить данные из базы данных, открыть/закрыть/прочитать/написать файл и т. д. (Тем не менее, я использую Flex Builder/Eclipse IDE - типичный пример тяжелого веса, такой как VS, потому что я все еще изучаю основы, и мне нужны обучающие колеса. Я ожидаю, что вернусь к vim, как только буду уверен в своих шаблонах.) С этой точки зрения, я могу сделать то, что мне нужно сделать профессионально, зная несколько вещей очень, очень хорошо.

OTOH, я не могу себе представить, как добраться до этой точки с .NET, потому что представление, которое я должен поддерживать, продолжает расширяться и смещаться. Там гораздо меньше концептуальной целостности, и над несколькими разработчиками над проектом в течение нескольких месяцев, гораздо меньше согласованности - но IDE поддерживает это, возможно, поощряет его. Поэтому разработчику действительно нужно (и может быть проще) знать гораздо больше вещей адекватно. Который также имеет преимущество помочь им ответить (или даже понять) a лот более высокий процент вопросов по StackOverflow. Т. е. у нас может быть более глубокий стек знаний. И мы можем реагировать на более широкий спектр объявлений о помощи.

вещи могут зайти слишком далеко в обоих направлениях. Может быть, с областью " только для редактора "это похоже на"если у вас есть только молоток, все выглядит как гвоздь". С подходом IDE, для чего бы вы ни хотели закрепить вместе, у вас есть широкий выбор крепежей и связанных диапазонов инструментов на выбор - nals / молотки, винты / отвертки, болты / ключи, клеи/клеевые пистолеты / зажимы, магниты и т. д.-Все у вас под рукой (с помощью мастера, который поможет вам начать работу).

Не думаю, что это эксклюзив. Используйте IDE для преимуществ, которые он предоставляет, и переключитесь на Vim/предпочтительный текстовый редактор, когда вам нужно серьезно сосредоточиться.

Я считаю, что IDE лучше для рефакторинга, просмотра и отладки и для выяснения что сделать. Маленькие вещи затем выполняются прямо в IDE, большие вещи я переворачиваю на vim, чтобы закончить работу.

в дополнение к другим ответам, я люблю комбинировать разработки мощность IDE с редактирование мощность Vim, используя что-то вроде ViPlugin на затмение.

IntelliSense, интегрированный отладчик и непосредственное окно делают меня чрезвычайно более продуктивным (Visual Studio 2008). Имея все под рукой, я могу держать подавляющее большинство огромного проекта в голове во время написания кода. Microsoft может продолжать отбрасывать мяч на своих ОС, но Visual Studio является одним из лучших продуктов, когда-либо разработанных.

для меня IDE лучше, потому что она позволяет быстрее перемещаться в коде, что важно, если у вас есть что-то в уме для реализации. Предполагается, что вы не используете IDE, требуется больше времени, чтобы добраться до места назначения. Ваши мысли могут прерываться чаще. Это означает, что больше кликов / больше клавиш должны быть нажаты. Нужно больше концентрироваться на мысли, как реализовать вещи. Конечно, вы тоже можете записывать, но тогда нужно прыгать между дизайном и реализацией. Кроме того, GUI designer имеет большое значение. Если вы делаете это вручную, это может занять больше времени.

идентификаторы на основе GUI, такие как Visual Studio и Eclipse, имеют несколько преимуществ перед текстовыми идентификаторами, такими как Emacs или vim, из-за их возможностей отображения:

• WYSIWYG предварительный просмотр и живое редактирование для дизайна GUI
• эффективные Редакторы свойств (например. выбор цвета с помощью графического палитры, включая градиент позиционирования остановок и т. д.)
• графическое изображение контуров кода, взаимосвязи файлов и т. д.
• более эффективное использование экрана недвижимости показать точки останова, закладки, ошибки и т. д.
• лучше перетащите поддержку с ОС и других приложений
• интегрированное редактирование чертежей, изображений, 3D моделей и т. д.
• отображение и редактирование моделей баз данных

в основном с помощью IDE на основе GUI вы можете получить более полезную информацию на экране сразу, и вы можете просматривать/редактировать графические части вашего приложения так же легко, как текстовые части.

одна из самых крутых вещей опыт разработчика-это редактирование метода, который вычисляет некоторые данные и видит живой вывод вашего кода, отображаемый графически в другом окне, так же, как ваш пользователь увидит его при запуске приложения. Теперь это редактирование WYSIWYG!

текстовые IDE, такие как Emacs и vim, могут добавлять такие функции, как завершение кода и рефакторинг с течением времени, поэтому в долгосрочной перспективе их основным ограничением является их текстовая модель отображения.

Я не понимаю, о чем вы спрашиваете. Вы спрашиваете: "должен ли я использовать IDE вместо...- но я не понимаю, какова альтернатива ... --1-->Vim и Emacs выполняют многие функции, которые даст вам любая IDE. Единственный аспект, который они не обрабатывают, что большая IDE может быть такими вещами, как дизайнеры пользовательского интерфейса. Тогда ваш вопрос сводится к простому "какую IDE я должен использовать" с аргументами, которые будут сделаны для более простой области Vim и Emacs.

сохраняет время превратиться
Облегчает жизнь, предоставляя такие функции, как интегрированная отладка, intellisense.

есть много много, но мы рекомендуем использовать один, они более чем очевидны.

Я не уверен, что есть четкая разделительная линия между текстовым редактором и IDE. У вас есть такие, как блокнот на одном конце шкалы, и лучшие современные Иды на другом, но есть много вещей между ними. Большинство текстовых редакторов имеют подсветку синтаксиса; Редакторы, предназначенные для программистов, часто имеют различные другие функции, такие как удобная навигация по коду и автозаполнение. Emacs даже позволяет интегрировать отладчик. Иды даже десять лет назад имели гораздо меньше возможностей, чтобы помочь программистам, чем в наши дни можно ожидать серьезного текстового редактора.

моя основная причина использовать один, когда код выходит за рамки 100 файлов.

хотя ctags может сделать работу,некоторые IDEs есть довольно хороший способ легко перемещаться по файлам супер быстро.

Это экономит время, когда у вас много работы.

для меня это просто версия GUI всего, что мы делали в старые добрые времена терминала. Я всегда соглашусь, что IDE не очень превосходит, потому что они скрывают много вещей, особенно в отношении связующего материала, но в некоторых случаях они имеют заметное преимущество, например, с определенными платформами разработки, такими как Qt.

некоторые IDE, такие как visual других, даже, кажется, анализируют ваш код по мере его ввода и обнаруживают ошибки перед компиляцией: кажется, что только логика IDE может работать в тесном контакте с компилятором, чтобы сразу обнаружить проблему в печатный источник.

мой дикий ответ, что война пламени IDE/командной строки существует только потому, что исполняемое здание C/C++ не очень хорошо обрабатывается со стандартизированной точки зрения, в отличие от языка D; каждая платформа обрабатывает компиляцию/связывание/etc по-своему, поэтому, чтобы сделать его менее грязным, они делают IDE.

с вашей точки зрения, было бы проще использовать командную строку, если там был бы только один компилятор со стандартными опциями, это было бы легко, но правда в том, что C/C++ является гибким, поэтому, в конце концов, все платформы делают это по-своему, поэтому IDE не тратит время на объяснения, как это сделать.

Если вы можете узнать, как исполняемый файл разговаривает с ядром или если вы знаете что-нибудь о дизайне компилятора, возможно, есть способ работать с правильной командной строкой, но я сомневаюсь, что у вас есть.

Microsoft или Apple, все зло, которое они будут, должны предложить прямой способ построения приложения без ввода деталей, а поскольку построение приложения напрямую зависит от архитектуры ОС, вряд ли будет "стандартным", как командная строка.

проще говоря, большие и сложные приложения, где вы не хотите копать слишком глубоко в то, что он делает -> IDE, маленькие кусочки программного обеспечения или простое системное программное обеспечение-дизайн -> командная строка. За исключением, конечно, тех изящных библиотек, которые встраивают Makefile, но это другое история.

также я думаю, что язь используются, когда приложение поставляется что-то делать с, как ни странно, GUI или что-то, что имеет интерфейс или напрямую привязан к ОС, так опять же, это также для людей, которые будут использовать интерфейс/графический интерфейс, не зная, как это работает, в то время как люди, которые будут программировать системы не нужно все это.

IDE - это просто современное дерьмо, но я думаю, что через 100 лет командная строка все еще будет существовать.

Я также почти исключительно использую Vim (почти потому, что я пытаюсь изучить emacs сейчас) для всех моих разработок. Я думаю, что чистая интуиция (из GUI, конечно) является основной причиной, почему люди любят использовать IDEs. Будучи интуитивным, мало не требуется никаких затрат на обучение инструмента. Чем меньше затраты на обучение, тем больше они могут выполнить работу.

An IDE позволяет работать быстрее и проще... Я заметил, что потратил много времени на навигацию в коде в простом текстовом редакторе...

в хорошей IDE это время идет вниз, если IDE поддерживает переход к функциям,к предыдущей позиции редактирования, к переменным... Кроме того, хорошая IDE сокращает время для экспериментов с различными языковыми функциями и проектами, так как время запуска может быть небольшим.

Мне нравится IDE, потому что он ставит много функциональности у меня под рукой. Редактирование/компиляция / видимость файлов в проекте-это все, что я ценю в IDE. Теперь я использую Visual Studio, но в прошлой жизни я использовал SlickEdit и обнаружил, что это сделало мой процесс разработки более упорядоченным, чем когда я его не использовал.

есть только одна вещь, которую следует учитывать при принятии решения об использовании IDE или нет, и это делает вас более продуктивным или нет.

короткий вопрос, короткий ответ :)

проще говоря, IDE предлагает дополнительные функции экономии времени над простым редактором.

Это сильно зависит от того, что вы делаете и на каком языке вы делаете это. Лично я стараюсь не использовать IDE (или "мой IDE состоит из 3 xterms работает ВИМ, один работает на базе клиента, и с командной строке или специальных журналах", в зависимости от того, насколько широко вы определяете "язь") для большинства моих работ, но, если я окажусь разработке платформы-родной GUI, то я тянулся к соответствующей языку язя в одно мгновение - ИМО, язь и графической форме редактирования явно сделан для друг с другом.