В другом вопросе Марк высоко оценивает IDE, говоря, что «некоторые люди до сих пор просто не знают», почему «они должны использовать один ...». Как человек, который использует vim для программирования и работает в среде, где большинство / все мои коллеги используют vim или emacs для всей своей работы, каковы преимущества IDE? Почему я должен использовать один?
Я уверен, что для некоторых людей это проблема, и я не заинтересован в развязывании пламенной войны, поэтому, пожалуйста, отвечайте только на те причины, по которым вы считаете, что подход на основе IDE лучше . Мне не интересно слышать о том, почему я не должен использовать IDE; Я уже не использую один. Мне интересно услышать, так сказать, «с другой стороны забора».
Если вы считаете, что IDE могут подходить для некоторых видов работ, но не для других, мне также интересно узнать, почему.
Ответы:
Это действительно зависит от того, какой язык вы используете, но в C # и Java я считаю IDE полезными для:
Все это экономит время. Это вещи, которые я мог бы сделать вручную, но с большей болью: я бы предпочел писать код.
источник
Завершение кода. Это очень помогает в изучении кода.
источник
vim
мне кажется, можно использовать.Короткий ответ относительно того, почему я использую IDE - это лень.
Я ленивая душа, которая не любит делать сложные вещи, когда есть простой способ сделать это. IDE делают жизнь проще и поэтому обращаются к нам ленивым людям.
Когда я набираю код, среда IDE автоматически проверяет правильность кода, я могу выделить метод и нажать F1, чтобы получить помощь, щелкнуть правой кнопкой мыши и выбрать «перейти к определению», чтобы перейти прямо к тому месту, где он определен. Я нажимаю одну кнопку и запускается приложение с автоматически подключенным отладчиком. И этот список можно продолжить. Все, что делает разработчик на ежедневной основе, собрано под одной крышей.
Нет необходимости использовать IDE. Это просто гораздо тяжелее, чем не работать.
источник
Я не думаю, что было бы справедливо делать классический «текстовый редактор и окно консоли против IDE», когда «текстовый редактор» действительно emacs. Большинство функций, которые типичны для IDE: также есть в emacs. Или, возможно, они даже возникли там, и современные IDE - это главным образом улучшения / упрощения интерфейса.
Это означает, что для исходного вопроса ответ не так однозначен. Это зависит от того, как люди на рассматриваемом сайте используют emacs, если они в основном используют его в качестве текстового редактора, или они полностью используют пользовательские сценарии, изучают команды для соответствующих режимов, знают о тегах кода и так далее.
источник
Я подхожу к этому вопросу с противоположной стороны. Я был воспитан в программировании с очень немногими пит-топами в Makefile + Emacs land. С самого раннего компилятора для DOS, Microsoft Quick C, у меня была IDE для автоматизации вещей. Я провел много лет, работая в Visual C ++ 6.0, и, получив диплом Enterprise Java, я работал с Borland JBuilder, а затем остановился на Eclipse, который стал для меня очень продуктивным.
На протяжении моей первоначальной самостоятельной работы в колледже, а теперь и в профессиональной карьере я узнал, что любая серьезная разработка программного обеспечения, выполняемая исключительно в рамках IDE, становится контрпродуктивной. Я говорю это потому, что большинство IDE хотят, чтобы вы работали в ихсвоеобразный стиль "я управляю миром". Вы должны нарезать и нарезать кубиками ваши проекты по их направлениям. Вы управляете сборками своего проекта, используя их странные диалоговые окна. Большинство IDE плохо справляются со сложными зависимостями сборки между проектами, и может быть сложно заставить работать 100%. Я был в ситуациях, когда IDE не производили бы работающую сборку моего кода, если бы я не сделал Очистить / Перестроить Все. Наконец, редко существует чистый способ вывести ваше программное обеспечение из разработки в другие среды, такие как QA или Production из IDE. Обычно это щелчок, чтобы собрать все ваши модули развертывания, или у вас есть какой-то неуклюжий инструмент, который поставщик IDE дает вам для объединения вещей. Но опять же
Я узнал, что для крупномасштабной разработки с командой мы можем быть наиболее продуктивными, если мы разрабатываем наш код с использованием IDE и выполняем все наши сборки с использованием сценариев командной строки, написанных вручную. (Нам нравится Apache Ant для разработки на Java.) Мы обнаружили, что запуск наших сценариев из среды IDE - это всего лишь щелчок мышью или кошмар автоматизации для сложных сборок, гораздо проще (и менее разрушительным) выделить alt + tab в Оболочка и запустить сценарии там.
Ручная сборка требует, чтобы мы упустили некоторые тонкости современной IDE, такие как фоновая компиляция, но то, что мы получаем, гораздо важнее: чистые и простые сборки, которые могут работать в разных средах. «Сборка в один клик», о которой говорят все эти проворные парни? У нас это есть. Наши сценарии сборки также могут напрямую вызываться системами непрерывной интеграции. Управление сборками с помощью непрерывной интеграции позволяет нам более формально выполнять этапы развертывания кода и переносить его в различные среды, а также почти сразу же узнавать, когда кто-то проверяет неверный код, который нарушает сборку или модульные тесты.
По правде говоря, то, что я взял на себя роль билда вдали от IDE, нас не сильно обидело. Инструменты Intellisense и рефакторинга в Eclipse по-прежнему полностью полезны и действительны - фоновая компиляция просто служит для поддержки этих инструментов. И, своеобразное разделение проектов в Eclipse послужило очень хорошим способом мысленно разбить наши наборы задач так, чтобы все могли их понять (хотя для моих вкусов я все же немного многословен). Я думаю, что одна из самых важных вещей в Eclipse - это отличная интеграция SCM, которая делает групповую разработку такой приятной. Мы используем Subversion + Eclipse, и это было очень продуктивно и очень легко научить наших людей стать экспертами.
источник
Будучи автором ответа, который вы выделили в своем вопросе, и, по общему признанию, немного позже, я бы сказал, что среди множества перечисленных причин производительность профессионального разработчика является одной из самых высоко оцененные навыки.
Под производительностью я подразумеваю способность эффективно выполнять свою работу с наилучшими возможными результатами. IDE позволяют это на многих уровнях. Я не эксперт по Emacs, но сомневаюсь, что в нем отсутствуют какие-либо функции основных IDE.
Проектирование, документирование, отслеживание, разработка, сборка, анализ, развертывание и обслуживание, ключевые этапы в корпоративном приложении, могут быть выполнены в среде IDE.
Почему бы вам не использовать что-то такое мощное, если у вас есть выбор?
В качестве эксперимента возьмите на себя обязательство использовать IDE, скажем, в течение 30 дней, и посмотрите, как вы себя чувствуете. Я хотел бы прочитать ваши мысли на опыте.
источник
Наличие IDE имеет следующие преимущества:
Есть гораздо больше, может быть, вы должны попробовать.
источник
IDE в основном:
все в одной упаковке.
Вы можете получить все это (и некоторые другие), используя отдельные инструменты или просто отличный программируемый редактор и дополнительные инструменты, такие как Emacs (также Vim, но с немного меньшей IDEbility IMO).
Если вы обнаружите, что переключаетесь между одной утилитой и следующей, которая может быть интегрирована в среду, или если вам не хватает некоторых из перечисленных здесь способностей (и более подробно в других публикациях), возможно, пришло время перейти к IDE (или улучшить IDEbility вашей среды, добавляя макросы или что нет). Если вы создали «IDE» (в смысле, о котором я упоминал выше) с использованием более чем одной программы, нет необходимости переходить к реальной IDE.
источник
Затмение:
Подсветка кода, компиляция в фоновом режиме, указание на мои ошибки, когда я иду вперед.
Интеграция с Javadoc, предлагая имена переменных с помощью Ctrl-Space.
Когда я компилирую, я сразу получаю ошибки. Я могу дважды щелкнуть по ошибке, и она отобразит соответствующую строку.
Действительно хорошо интегрированный с JUnit, ctrl-F11 запускает тест, говорит мне, что тесты провалились. Если в окне вывода есть исключение, я могу дважды щелкнуть строку и перенести меня на строку, которая не удалась. Кроме того, ctrl-F11 гарантирует, что все скомпилировано до запуска тестов (что означает, что я никогда не забуду это сделать).
Интеграция с муравьем. Одна команда для создания и развертывания приложения.
Интеграция с отладчиками, включая удаленную отладку веб-серверов.
FANTASTIC инструменты рефакторинга, поиск ссылок на раздел кода. Помогает мне знать влияние изменений.
В общем, это делает меня более продуктивным.
источник
Я использовал Emacs в качестве основного окружения для разработки и рассылки / новостей примерно 10 лет (1994-2004). Я открыл для себя возможности IDE, когда в 2004 году заставил себя изучать Java, и, к своему удивлению, мне действительно понравилась IDE ( IntelliJ IDEA ).
Я не буду вдаваться в конкретные причины, поскольку многие из них уже упоминались здесь - просто помните, что разные люди любят разные функции. Я и коллега использовали одну и ту же среду IDE, мы оба использовали лишь небольшую часть доступных функций, и нам не нравился способ использования IDE друг друга (но нам обеим понравилась сама среда IDE).
Но у IDE есть одно преимущество перед средами, связанными с Emacs / Vim, на которых я хочу сосредоточиться: вы тратите меньше времени на установку / настройку нужных вам функций.
С Wing IDE (для Python) я готов начать разработку через 15-20 минут после установки. Не знаю, сколько часов мне понадобится, чтобы получить функции, которые я использую и работаю с Emacs / Vim. :)
источник
clone
их в любое время для настройки своей работы. окружающая обстановка. :)Это определенно приводит к улучшению производительности для меня. В тот момент, когда я даже кодирую приложения Linux в Visual Studio на Vista, а затем использую виртуальную машину Linux для их создания.
Вам не нужно запоминать все аргументы вызова функции или метода, как только вы начнете вводить его, IDE покажет вам, какие аргументы необходимы. Вы получаете мастера для установки свойств проекта, параметров компилятора и т. Д. Вы можете искать вещи по всему проекту, а не только по текущему документу или файлам в папке. Если вы получили сообщение об ошибке компилятора, дважды щелкните по нему, и вы попадете прямо в оскорбительную строку.
Интеграция инструментов, таких как редакторы моделей, подключение к внешним базам данных и их просмотр, управление коллекциями «фрагментов кода», инструменты моделирования GUI и т. Д. Все эти вещи можно использовать отдельно, но их объединение в одной среде разработки позволяет сэкономить много время и поддерживает процесс разработки более эффективно.
источник
Там могут быть разные причины для разных людей. Для меня это преимущества.
В конце дня, это помогает мне кодировать быстрее, чем я могу сделать в блокноте или WordPad. Это довольно веская причина для меня, чтобы предпочесть IDE.
источник
IDE может быть «превосходным» выбором в зависимости от того, что разработчик пытается достичь.
Текстовый редактор может быть «превосходящим», потому что IDE обычно ориентированы на один (или небольшой выбор) языков.
Если разработчик проводит большую часть своего времени в одном языке или «кластере» родственных языков (таких как C # и T-SQL), в одной ОС, тогда инструменты проектирования, отладки, intellisense, рефакторинга и т. Д., Предлагаемые хорошая IDE может быть очень убедительной. Если, например, вы проводите большую часть своего времени, работая в VB.NET, а иногда и с небольшим T-SQL, в среде Windows, то было бы довольно глупо не смотреть на Visual Studio или сопоставимую IDE. ,
У меня нет предубеждений по отношению к тем, кто предпочитает IDE или текстовые редакторы, оба могут быть очень продуктивными и полезными, если их хорошо выучить !
источник
Я думаю, что это в основном связано с уровнем осведомленности для разработчика. IDE предоставляет макроскопическое представление рабочего контекста разработчика. Вы можете одновременно видеть иерархии классов, ссылочные ресурсы, схемы баз данных, ссылки на справку SDK и т. Д. И с таким большим количеством вещей, на которые влияют и влияют ваши нажатия клавиш, а также расширяющийся объем архитектур и пересечений архитектур, становится все труднее работать только с одного острова кода одновременно.
OTOH, «только я, vim и man-страницы», дают мне более тонкий микроскопический - но интенсивный и точный - взгляд на мою работу. Это нормально, если у меня есть хорошо спроектированная, хорошо разбитая, разреженно связанная, очень сплоченная кодовая база, построенная на одном языке с одним набором статических библиотек для работы - не ваша типичная ситуация, особенно когда размеры команды разработчиков растут и изменяют структуру кода со временем, расстоянием и личными предпочтениями.
В настоящее время я работаю над проектами во Flex и .NET. Одна из самых приятных вещей во Flex - это то, как мало разных способов сделать стандартную вещь - извлечь данные из базы данных, открыть / закрыть / прочитать / записать файл и т. Д. (Тем не менее, я использую Flex Builder / Eclipse IDE - типичный тяжелый пример, такой как VS, потому что я все еще изучаю основы и мне нужны тренировочные колеса. Я ожидаю, что смогу вернуться к vim, когда буду уверен в своих моделях.) С этой точки зрения я могу делать то, что Мне нужно делать профессионально, зная действительно несколько хороших вещей.
OTOH, я не могу себе представить, чтобы достичь этой точки с .NET, потому что представление, которое я должен поддерживать, продолжает расширяться и сдвигаться. Там гораздо меньше концептуальной целостности и более нескольких разработчиков в проекте в течение нескольких месяцев, гораздо меньше согласованности - но IDE это поддерживает, может, поощряет. Таким образом, разработчик действительно должен (и может легче) знать намного больше вещей адекватно. Это также помогает им отвечать (или даже понимать) гораздо больший процент вопросов на StackOverflow. Т.е. у нас может быть более глубокий стек знаний. И мы можем ответить на более широкий спектр объявлений о поиске помощи.
Вещи могут зайти слишком далеко в обоих направлениях. Возможно, с областью «только для редактора», это похоже на «если у вас есть только молоток, все выглядит как гвоздь». Благодаря подходу IDE для того, что вы хотите скрепить вместе, у вас есть широкий выбор крепежа и связанных с ним наборов инструментов на выбор - налы / молотки, винты / отвертки, болты / гаечные ключи, клеи / клеевые пистолеты / зажимы, магниты и так далее - все под рукой (с помощью мастера, который поможет вам начать работу).
источник
Не думай об этом как об эксклюзиве. Используйте интегрированную среду разработки для получения преимуществ, которые она предоставляет, и переключитесь на vim / предпочитаемый текстовый редактор, когда вам нужно серьезно сосредоточиться.
Я нахожу IDE лучше для рефакторинга, просмотра и отладки и для выяснения, что делать. Маленькие вещи затем делаются прямо в IDE, большие вещи я переворачиваю, чтобы закончить работу.
источник
В дополнение к другим ответам мне нравится сочетать развивающую мощь IDE с возможностями редактирования Vim, используя что-то вроде ViPlugin для Eclipse .
источник
IntelliSense , встроенный отладчик и непосредственное окно делают меня чрезвычайно продуктивным ( Visual Studio 2008 ). Имея все под рукой, я могу держать подавляющее большинство огромных проектов в своей голове во время написания кода. Microsoft может продолжать играть в свои ОС, но Visual Studio - один из лучших продуктов, когда-либо созданных.
источник
Я не понимаю, о чем вы спрашиваете. Вы спрашиваете «Должен ли я использовать IDE вместо ...», но я не понимаю, какая альтернатива - Vim и Emacs выполняют многие функции, которые вам даст любая IDE. Единственный аспект, который они не обрабатывают, что большая IDE может это вещи, такие как дизайнеры пользовательского интерфейса. Тогда ваш вопрос сводится к простому «какую IDE я должен использовать» с аргументами, которые нужно сделать для более простой области Vim и Emacs.
источник
Для меня, IDE лучше, потому что она позволяет более быструю навигацию в коде, что важно, если у вас есть что реализовать в уме. Предполагается, что вы не используете IDE, чтобы добраться до места назначения, потребуется больше времени. Ваши мысли могут прерываться чаще. Это означает, что нужно нажимать больше кликов / больше клавиш. Нужно больше концентрироваться на мысли, как реализовать вещи. Конечно, вы тоже можете записывать вещи, но тогда нужно прыгнуть между дизайном и реализацией. Кроме того, GUI дизайнер имеет большое значение. Если вы делаете это вручную, это может занять больше времени.
источник
Основанные на GUI IDE, такие как Visual Studio и Eclipse, имеют ряд преимуществ по сравнению с текстовыми IDE, такими как Emacs или vim, благодаря их возможностям отображения:
По сути, с помощью IDE на основе графического интерфейса вы можете сразу получить больше полезной информации на экране, а также просматривать и редактировать графические части своего приложения так же легко, как текстовые части.
Одна из самых крутых вещей, которые могут испытать разработчики, - это отредактировать метод, который вычисляет некоторые данные, и видеть, как живой вывод вашего кода отображается графически в другом окне, так же, как ваш пользователь увидит его при запуске приложения. Теперь это WYSIWYG редактирование!
Текстовые IDE, такие как Emacs и vim, со временем могут добавлять такие функции, как автозавершение кода и рефакторинг, поэтому в долгосрочной перспективе их основным ограничением является их текстовая модель отображения.
источник
Я также почти исключительно использую Vim (почти потому, что сейчас пытаюсь изучать emacs) для всех своих разработок. Я думаю, что чистая интуитивность (конечно же, из графического интерфейса) является основной причиной, по которой людям нравится использовать IDE. Благодаря интуитивному восприятию инструментальных затрат практически не требуется. Чем меньше накладных расходов на обучение, тем больше они могут выполнить работу.
источник
IDE позволяет легко работать быстрее и более ... Я заметил , что я провел много времени навигации в коде в простом текстовом редакторе ...
В хорошей IDE это время уменьшается, если IDE поддерживает переход к функциям, к предыдущей позиции редактирования, к переменным ... Кроме того, хорошая IDE сокращает время экспериментирования с различными языковыми функциями и проектами, как время запуска. может быть маленьким.
источник
Я могу подумать о нескольких причинах использования IDE:
И, честно говоря, мне нравится моя мышь. Когда я использую чисто текстовые редакторы, мне становится одиноко.
источник
Экономит время на разработку.
Делает жизнь проще, предоставляя такие функции, как встроенная отладка, intellisense.
Их много, но рекомендую использовать один, они более чем очевидны.
источник
Я не уверен, что есть четкая разделительная линия между текстовым редактором и IDE. В одном конце шкалы есть такие же, как Notepad, а в другом - лучшие современные IDE, но между ними много всего. Большинство текстовых редакторов имеют подсветку синтаксиса; Редакторы, предназначенные для программистов, часто имеют различные другие функции, такие как простая навигация по коду и автоматическое заполнение. Emacs даже позволяет интегрировать отладчик. IDE даже десять лет назад имели гораздо меньше возможностей, чтобы помочь программистам, чем можно было бы ожидать от серьезного текстового редактора в наши дни.
источник
Моя основная причина использовать один, когда код выходит за рамки 100 файлов.
Хотя ctags и могут выполнять эту работу, в некоторых IDE есть довольно хороший способ быстрой и простой навигации по файлам.
Это экономит время, когда у вас много работы.
источник
Для меня это всего лишь GUI-версия всего, что мы делали в старые добрые времена терминала. Я всегда соглашусь с тем, что IDE не очень хороши, потому что они скрывают много вещей, особенно связанных со ссылками, но в некоторых случаях они имеют заметное преимущество, например, с некоторыми платформами разработки, такими как Qt.
Некоторые IDE, подобные визуальным для других, даже, кажется, анализируют ваш код по мере его ввода и обнаруживают ошибки еще до того, как вы даже скомпилируете: кажется логичным, что только IDE может работать в тесном контакте с компилятором, чтобы немедленно обнаружить проблему в типизированном источнике.
Мой дикий ответ, что война пламени в среде IDE / командной строки существует, заключается лишь в том, что исполняемый файл C / C ++ не очень хорошо обрабатывается со стандартизированной точки зрения, в отличие от языка D; каждая платформа обрабатывает компиляцию / компоновку / etc по-своему, поэтому, чтобы сделать ее менее запутанной, они создают IDE.
С вашей точки зрения, было бы проще использовать командную строку, если бы был только один компилятор со стандартными опциями, это было бы легко, но правда в том, что C / C ++ является гибким, поэтому, в конце концов, все платформы делайте это по-своему, поэтому в IDE не стоит тратить время на объяснения, как это сделать.
Если вы можете узнать, как исполняемый файл взаимодействует с ядром, или вы знаете что-нибудь о дизайне компилятора, возможно, есть способ работать с правильной командной строкой, но я сомневаюсь, что у вас есть.
Microsoft или Apple, какими бы злыми они ни были, должны предложить прямой способ создания приложения, не вдаваясь в детали, а поскольку создание приложения напрямую зависит от архитектуры ОС, оно вряд ли будет «стандартным», поскольку командная строка есть.
Проще говоря, это большие, сложные и сложные приложения, в которых вы не хотите слишком углубляться в то, что они делают -> IDE, небольшие кусочки программного обеспечения или простой дизайн системного программного обеспечения -> командная строка. За исключением, конечно, тех изящных библиотек, которые встраивают Makefile, но это другая история.
Кроме того, я думаю, что IDE используются, когда доставленное приложение имеет какое-то отношение, по иронии судьбы, к графическому интерфейсу пользователя или к чему-то, что имеет интерфейс или напрямую связано с ОС, поэтому, опять же, это также для людей, которые будут использовать пользовательский интерфейс / графический интерфейс, не зная как это работает, в то время как люди, которые будут программировать системы, не будут нуждаться во всем этом.
IDE - просто современное дерьмо, но я думаю, что через 100 лет командная строка все еще будет существовать.
источник
Мне нравится IDE, потому что в моих руках много функциональности. Редактирование / компиляция / видимость файлов в проекте - это все, что я ценю в IDE. Я использую Visual Studio сейчас, но в прошлой жизни я использовал SlickEdit и обнаружил, что он сделал мой процесс разработки более упорядоченным, чем когда я его не использовал.
источник
При принятии решения о том, использовать ли IDE или нет, нужно учитывать только одну вещь: делает ли она вас более продуктивным или нет.
Короткий вопрос, так короткий ответ :)
источник
Это сильно зависит от того, что вы делаете, и на каком языке вы это делаете. Лично я склонен не использовать IDE (или «моя IDE состоит из 3 xterms, на которых выполняется vim, одного с клиентом базы данных и одного с bash, «Журналы подсказок или хвостов», в зависимости от того, насколько широко вы определяете «IDE») для большей части моей работы, но, если бы мне пришлось разрабатывать GUI на платформе, я бы нашел подходящую для языка IDE в мгновенно - IMO, IDE и графическая форма редактирования явно сделаны друг для друга.
источник