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

23

Как вы думаете, имеет ли смысл обеспечивать, чтобы каждый член команды использовал одну и ту же IDE?

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

Есть ли у вас опыт работы с командами "mixed IDE"? Если так, то, что это?

Финрод
источник
4
Проблема, с которой я часто сталкивался в средах со смешанным редактором, заключается в автоматическом форматировании кода и обработке таких вещей, как вкладки. Пока вы все понимаете, это не будет иметь большого значения.
Майкл Кохн

Ответы:

54

При условии, что «официальная» система сборки (используемая серверами Continuous Build) одинакова для всех, я не вижу никаких причин, почему каждый член команды не мог выбрать инструменты, которые он хочет ...

Ксавье Ноде
источник
5
Это правильный ответ.
31
Я бы добавил, что если официальная система сборки зависит от IDE, то есть проблема.
AProgrammer
4
Когда вы проводите много времени за столами других членов команды, вам может быть неудобно выяснять их настройку, прежде чем вы сможете им помочь.
Дуг Т.
4
О, МОЙ БОГ!!! Внутренне разработанная IDE ??? Это рецепт для катастрофы, как внутренняя система отслеживания ошибок.
Работа
8
@Job, я работаю в Microsoft, так что, строго говоря, VS также является внутренне разработанной IDE. Мы также используем собственные системы отслеживания ошибок ... TFS и Product Studio :).
JSB ձոգչ
7

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

Dszordan
источник
7
Если ваша команда использует плагин IDE для чего-то нетривиального, у вас уже есть более серьезные проблемы.
HedgeMage,
@HedgeMage Только сит имеет дело с абсолютами. Например, что если проект основан на платформе Eclipse? Я не знаю, каково текущее состояние, но пару лет назад IntelliJ был неспособен выполнить сложную проверку и тому подобное для метаданных плагина Eclipse. У нас в команде был разработчик, который настаивал на IntelliJ - не раз проверяя неработающий код.
Евгений
3

Недостатком является то, что при сопряжении вы не можете так быстро переключать клавиатуру между собой. Между основными IDE это, вероятно, не большая проблема, но если один человек привык к Eclipse, а другой - к vim, то будет несоответствие. Пользователь Eclipse вполне может быть не в состоянии использовать vim, в то время как пользователь vim (это я;) тратит много времени, проклиная себе под нос на ужасную медлительность использования ванильного Eclipse.

Тем не менее, я бы все-таки предпочел использовать vim сам. При условии, что ваша пара довольна тем, что один из вас «ездит» в течение длительного периода времени, все в порядке.

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

Хэмиш Даунер
источник
2

Нет никакого смысла заставлять каждого разработчика ядра Linux использовать одну и ту же IDE (или вообще использовать любую IDE).

выдаёт ошибку сегментации
источник
2

У меня нет опыта работы со смешанными IDE, если не считать коммерческую IDE с периодическим дополнением текстовым редактором «несколько IDE», но я могу вспомнить пару плюсов и минусов.

Pros

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

Cons

  • Вопросы лицензирования. Если задействовано несколько коммерческих IDE, возможно, это дороже. По крайней мере, это может быть больше, чтобы отслеживать.
  • Вопросы лицензирования 2. Если существуют платформы или плагины, которые лицензируются IDE или langauge, будет ли это проблемой?
  • Как упоминал Dszordan, некоторые плагины могут быть несовместимы с разными IDE.
  • Если в средах разработки есть компоненты генерации кода или механизмы форматирования стилей, которые работают по-другому, это может вызвать некоторую путаницу.
Бернард Ди
источник
1

Есть причина, по которой это можно заставить. Просто рассмотрите visual studio и emacs / vim. Как на окнах Visual Studio добавит дополнительные \ r в конце строки. Это портит отображение в emacs / vim. Также вкладки создают проблему. Проблема с нами в том, что мы, разработчики, работаем в Linux, но наша архитектура программного обеспечения удобна в визуальной студии. Однажды он проклинает нас, говоря, что мы неправильно форматируем файл. Но потом, когда он обнаружил, что это из-за проблемы с настройками по умолчанию, мы все согласились на один и тот же формат.
Если кто-то заставит меня использовать конкретную IDE, я не буду чувствовать себя плохо. Что бы ни было хорошо для команды, я буду уважать это и идти на компромисс.

Маной Р
источник
1
Вы путаете стандарт форматирования кода с использованием IDE. Если вы решите использовать 3 пробела для уровня отступа, вы можете установить его в Visual Studio или Emacs (я знаю, я использую их оба). Другие проблемы, такие как разные окончания строк в Windows, Mac и Unix, могут быть решены с помощью пользовательских сценариев регистрации / возврата, а именно, если OS == Windoze ...
SnoopDougieDoug
1

Сегодняшние разработчики хотят выбирать свои инструменты.

Со временем это изменилось. 10 или 15 лет назад в местах, где я работал, было не так много вариантов. (Да, было много редакторов, но они не были «выбором»). Магазин, в котором я работал 15 лет назад, был «старой школой» (даже тогда!), И vi был редактором. Нет выбора. На самом деле это было довольно полезно, потому что после первого месяца ругательств и ругательств мне это действительно нравилось.

Сегодня есть много вариантов, и у каждого есть много преимуществ.

По своему личному опыту я использовал IDE - rubyMine - пару лет, прежде чем переключиться обратно на vi (m). Я сделал это, потому что Ruby - очень сложный язык для написания IDE (типизирование утки и другие динамические функции), и в результате IDE, как правило, работают медленно и / или требуют самой последней, самой быстрой машины.

Майкл Даррант
источник
0

Ну да, у меня есть некоторый опыт в том, что касается участия в смешанной команде windows / unix & c ++ / java. Я думаю, что это не проблема, если либо всем комфортно работать с другой IDE, либо никогда не будет ситуации, когда кому-то, кто не знаком с IDE Y, нужно поработать с другим парнем (это парень с IDE Y). ) система.

Gaurav
источник
0

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

Кстати, Emacs!

compman
источник
0

Я не думаю, что у всех должна быть «та же» IDE, но было бы хорошо, чтобы у всех была «поддерживаемая» IDE.

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

Если ваша компания использует среду для совместной работы, такую ​​как Rational Team Concert, и один или два парня хотят использовать неподдерживаемую IDE (или другую версию), в то время как все остальные используют совместимые, то жизнь людей, которые решили стать вне петли поддержки.

Зу
источник
-2

У нас дома мы строим наши проекты с использованием Visual Studio. Когда дело доходит до редактирования текста, я переключаюсь на Emacs. Вашей компании должно быть все равно, пока работа сделана.

rfcoder89
источник
-3

Звучит как «мы использовали это на моей старой работе». Ну, они не на своей старой работе.

Если это не влияет на вашу цепочку инструментов или плагины управления исходным кодом, тогда, возможно, да. С другой стороны, могут ли два новых народа продемонстрировать явную выгоду? Они использовали вашу IDE?

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

ГБН
источник
Не должны ли предпочтения людей иметь значение для рабочего места? Это чепуха предпочтений? Разве удовлетворение программистов не приносит пользу компании? Извините, но это не для меня "компилируется".
Дарамарак
@daramarak: Где это превращается в высокомерие или быть примадонной, особенно для крупных магазинов с корпоративным стандартом? Помните: новые парни, входящие в новую компанию, говоря: «Мы хотим этого» - это высокомерие.
ГБН
-6

ДА! Внедрить Singleton IDE.

Это создает проблемы при изменении зависимости проекта. если кто-то вводит новую зависимость в проект, то каждый будет тратить время на внедрение этой новой зависимости, а некоторые могут потерпеть неудачу и потратить время на этот процесс. ОГРОМНАЯ ТРАТА ВРЕМЕНИ.

должно быть ДЕЙСТВИТЕЛЬНО хорошее обоснование для добавления другой IDE в команду, что означает, что сэкономленное время должно превышать время, выделенное для миграции системы на разные IDE.

Отображаемое имя
источник
IDE действительно редактор. Редактор никоим образом не является зависимостью проекта. (Я знаю, что этот ответ, возможно, был саркастическим, однако, это не место для сарказма)
Арафангион
IDE на самом деле не редактор, потому что вы не используете Notepad.exe. вам нужна дополнительная работа, проделанная IDE, а ide не имеет стандартов, что затрудняет использование внешних возможностей. и если вы говорите, что шестнадцатеричное редактирование - это просто «текстовый редактор», то код - это не просто текст.
Отображаемое имя
Среда IDE - это просто редактор с кучей других инструментов, подавляющее большинство которых в любом случае можно вызывать из командной строки.
Арафангион
у меня здесь нет людей они говорят, что внутренний идеал плох, а единый иде плох. поэтому ide должно быть единым для всех программистов, но не для всех программистов, работающих над одним и тем же проектом. Да ?! Я не получаю это!
Отображаемое имя
2
Это просто инструмент. Любой компетентный программист должен иметь возможность использовать свои инструменты надлежащим образом, и если он считает, что другой IDE более подходит для разработки, он должен это сделать.
Арафангион