Является ли заказ компании переключением на определенную IDE красным флагом? [закрыто]


80

Я недавно присоединился к быстро растущему стартапу. За последние 3 месяца команда разработчиков выросла с 4 до 12. До сих пор они были очень невежливы в отношении того, что разработчики использовали для своей работы. Фактически, одна из вещей, которые я изначально нашел привлекательными в компании, это то, что большинство программистов использовали Linux или любую ОС, которая, по их мнению, лучше всего подходила для их усилий.

Теперь пришли приказы без обсуждения, что каждый должен перейти на Eclipse. Прекрасный редактор. Я предпочитаю SublimeText2, но это только мой личный вкус.

Просто чтобы прояснить: мы команда JS, использующая Backbone, а Eclipse просто не очень хорошо понимает код Backbone. Это означает, что те в команде, которые используют / good / IDE (PHP Storm), должны вернуться к выполнению многих видов поиска: поиск-о-о-ждать-где-я-три-назад-назад вместо того, чтобы просто нажимать Ctrl + и использовать назад / вперед - возможно, снижение производительности, скажем, на 15% и удовольствия на 50% ...

Это красный флаг? Кажется капризным и неоправданно контролирующим сообщать разработчикам (не MS), какую IDE или наборы инструментов использовать, если они уже установлены и продуктивны.


7
Каков ваш процесс сборки? Что нужно сделать, чтобы символы, которые вы вводите, стали бинарным кодом для покупателей.

22
Это стартап. Если руководство в одностороннем порядке принимает решение, например, влияет на развитие, без обсуждения, это может быть серьезным красным сигналом, независимо от того, о чем идет речь.
joshin4colours

29
Нет - есть множество причин для перехода на одну IDE: лицензирование, процесс, преемственность, последовательность ...
Wonko the Sane

55
Растущая компания, пытающаяся установить стандарт на ранних этапах, является умной в моей книге (независимо от того, что это)! Разместите всех на одной странице и накопите опыт с помощью общей IDE. Тогда команда становится более эффективной, потому что все могут помогать друг другу и легче делиться кодом, не беспокоясь о ширине табуляции, кодировании и тому подобном.
Яник Жируард

23
Eclipse - это целая среда, а не просто редактор. Возможно, ИТ-специалисты обнаружили, что работа с каждой особой снежинкой в ​​растущей компании становится огромной и обременительной задачей, и она хотела стандартизироваться. Может быть, есть инструмент в управлении экосистемой Eclipse, который нужно использовать в ближайшее время. Возможно, 12 разных редакторов автоформатирования выводили из строя ваш репозиторий и вызывали дополнительные сборки. Возможно, нелицензионные инструменты «из дома» волнуют менеджеров, которые не хотят получать судебные иски. Может быть, вы новый парень, вы действительно рассчитываете на консультации по широким решениям в области ИТ и развития? Может быть миллион причин, все в здравом уме.
Патрик Хьюз

Ответы:


92

«Теперь пришли приказы без обсуждения , что каждый должен перейти на Eclipse».

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

Это звучит как чрезмерное управление заостренными боссами. Имеет ли лицо / команда, принимающее решение, соответствующее понимание этого решения?


Учитывая, что лица, принимающие решения, достаточно квалифицированы для такого решения, отсутствие мнения команды разработчиков имеет как минимум два недостатка:

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

  • Руководство, однако опытное, не работает на 100% с разработкой этого конкретного кода. Предполагать, что люди, у которых нет интересного понимания, было бы наивно. Конечно, это может быть так, что менеджеры думали обо всем, что придумывали разработчики, но единственный способ узнать это - спросить.


9
Бред какой то. То, что с командой не консультировались, не означает, что высшие взлеты не имеют смысла. Он интересен как не Java-разработчик, я знаю, что Eclipse - это IDE, которым можно пользоваться, но он никогда не слышал о фаворитах OP, пока не опубликовал его. Было бы ошибкой позволить команде стандартизировать IDE, что необычно, создавая проблемы с набором других новых разработчиков.
Энди

5
Считали ли вы, что «высшее руководство» может быть старшими разработчиками? В некоторых организациях много слоев?

2
Вы слишком много читаете об этом. У менеджмента могут быть другие проблемы, такие как варианты поддержки, и, возможно, все сводится к тому, что было довольно популярно при разумных затратах на поддержку (я говорю о платных случаях поддержки). Если это так, то, возможно, другого выбора не было, так какой смысл спрашивать разработчиков? Кроме того, вы пытались заставить даже небольшое количество (10-15) разработчиков договориться о чем-то? Есть причина, по которой они говорят, что заставлять разработчиков соглашаться - это как копить кошек.
Энди

3
@ Andy Hoarding кошек легко (поговорите с любой девой), услышать их совсем другое дело. ; о)
JW01

3
@ JW01 Ага, я неправильно понял. Но не будет ли это стадом? :-)
Энди

63

Разумно, что когда вы работаете вместе над общим проектом, что на каждой рабочей станции у вас есть все инструменты, доступные для редактирования / сборки / отладки вашего программного обеспечения, и что основные инструменты для выполнения около 90% разработки известны каждому команда. Эту цель труднее достичь, если ваша команда растет, и каждый использует свой любимый набор инструментов - чем больше людей, тем больше мнений. И административная работа также становится проще, если вы не позволите количеству инструментов расти больше, чем необходимо.

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


2
Прежде всего, разработчик редко вносит изменения на чужой машине. Я согласен с «чем больше людей, тем больше мнений», но это не проблема, если люди не пытаются навязать свое мнение другим. По словам источника, все проекты должны иметь автоматический процесс сборки одной командой. Пока это работает, а код следует соглашениям, не имеет значения, какие люди используют IDE. Большинство IDE интуитивно понятны для простых вещей (каждый из них имеет свои преимущества для более сложных задач), поэтому парное программирование не является проблемой. Если есть вопросы, разработчик, использующий IDE, может ответить.
Мэтью Флэшен

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

30
Я работаю в Google, и в моей конкретной команде один человек использует Eclipse, а человек использует intellij. Я использую Emacs со злым режимом для подражания Vim, а один человек использует сам Vim. Мы отлично работаем друг с другом, и различия в инструментах не проблема. Помогает то, что мы все используем одну и ту же систему сборки и имеем руководство по стилю для чтения кода, но это не имеет ничего общего с выбором редактора для каждого отдельного пользователя.
Джереми Уолл

@JeremyWall: как я уже сказал, это может быть хорошо, если ваш исходный код отображается одинаково во всех редакторах, которые вы используете, и вы не занимаетесь парным программированием.
Док Браун

5
@JeremyWall: То, что ваша команда разработчиков может работать таким образом, не означает, что все команды могут работать таким образом, и на самом деле я бы посчитал, что команда разработчиков Google находится за пределами нормы.
Джеймс П. Райт

25

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

Но если вы сравните это с попыткой быть наиболее эффективным, то это не стоит того


7
+1 за то, что вы отметили преимущества подобных сред разработки при парном программировании
jcmeloni

1
+1. Я не мог согласиться больше. Работа с несколькими разработчиками, каждый из которых имеет свои собственные предпочтительные инструменты и способы кодирования, может быть адом! Например, вы можете использовать пробелы над вкладками, определенный размер отступа и кодировку UTF-8 для всех ваших источников. Я должен был пройти через это в моей команде раньше, и мы должны были, чтобы все использовали одну и ту же среду IDE в конце концов точно по причинам, упомянутым выше. Любому серьезному разработчику в любом случае не придется тратить много времени на адаптацию к новой IDE, поэтому я не вижу в этом вреда. Это также упрощает освоение новых членов, если все используют один и тот же инструмент.
Яник Жируард

@Yanick: Пробел над вкладками, размер отступа, кодировка ... Все эти параметры должны соответствовать стандарту кодирования, которому должны соответствовать все разработчики. Неважно, как они хотят их соблюдать, не так ли? Требования к форматированию должны быть направлены на то, чтобы результат был правильным, а не на то, как этого добиться. Если разработчикам нужно переключить IDE, чтобы получить правильное форматирование, я бы не назвал их «серьезными разработчиками», извините за смелость.
Готье

18

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


38
Сильно зависит от причин, по которым IDE должна быть одинаковой.

3
Мы не уверены в вопросе, кто принял решение или почему. Термин «без обсуждения» может означать, что они не включают нового парня.
mhoran_psprep

3
У меня нет представителя, чтобы понизить голос, но я не согласен с этой точкой зрения. Даже если инструмент, предложенный руководством, на самом деле не самый лучший, это будет лучше, чем отсутствие стандартизации. Очевидно, что разработчики не способны принять решение о том, что является «лучшим», так как предоставленные своим устройствам, они все выбрали разные инструменты. Глупо утверждать, что разные инструменты работают лучше в разных контекстах, так как большинство из этих разработчиков в любом случае не станут свободно владеть многими.
FumbleFingers

4
«Очевидно, что разработчики не способны принять решение о том, что является« лучшим », так как предоставленные на их собственные устройства, они выбрали разные инструменты». Они выбирают лучший (самый производительный) инструмент для себя . У всех разный опыт и рабочие схемы. Они все могут быть правы.
Мэтью Флэшен

2
@ Andy Thats 'на самом деле не правда, как показывают разногласия Vim против Emacs. И это в первую очередь текстовые редакторы, а не полные IDE. Могут потребоваться годы, чтобы набрать скорость в новой среде.
Изката

14

Это не красный флаг сам по себе.

Иногда руководству нужно принимать решения . Любые вопросы, требующие стандартизации чего-либо, как правило, попадают в эту категорию. Однажды я работал с клиентом, который несколько лет допускал смещение стандартов, и у них было более 20 различных инструментов SCM. То, что начиналось как самостоятельный выбор различными командами разработчиков, превратилось в логистический кошмар, который серьезно затруднил обмен навыками и совместную работу над кодом в рамках всей организации. Комплексная сборка была ..... ээ ..... не очень интегрированная .....

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

  1. Примите решение самостоятельно, если у вас достаточно знаний о плюсах и минусах, и это не является достаточно важным решением, требующим широких консультаций.
  2. Проконсультируйтесь с несколькими ключевыми лицами (которые, вероятно, будут старшими разработчиками, наиболее квалифицированными для принятия решения).
  3. Поднимите тот факт, что вы принимаете решение для всех, кто может быть затронут (электронная почта, встреча в мэрии, встречи команды). Скажите, что вы считаете правильным решением, но вы готовы изменить это, если появятся новые доказательства обратного. Пригласите людей выступить индивидуально, если у них есть важные мнения
  4. Пригласите людей сформировать подгруппу, чтобы рассмотреть варианты и рекомендовать решение. Хороший вариант, если это действительно близкий звонок, вы не знаете ответа и хотите, чтобы вовлеченные лица были вовлечены в решение.

Для чего-то, как разработчик инструментов (который является потенциально спорный вопрос), я бы, вероятно, сделать 2 следует либо 3 или 4 то есть определенно был бы некоторые люди, я бы не стал говорить лично по этому вопросу, но с другой стороны, большинство из ключевых людей получит шанс внести свой вклад в принятие решений.

Для меня настоящий красный флаг был бы рядом, если вы твердо уверены, что было принято неправильное решение (неправильное == это наносит вред компании, а не просто ваш любимый инструмент не будет выбран). Как руководство реагирует, когда вы поднимаете эту проблему:

  • Хороший менеджмент прислушается к вашим аргументам, искренне благодарю вас за отзывы и пересмотрю их позицию в случае, если вы поднимете новые идеи . Они могут по-прежнему не соглашаться с вами и могут придерживаться своего решения, но они будут благодарны вам за то, что вы подняли его с ними, и вы любезно скажете, почему они придерживаются своего решения. Они могут даже изменить то, как они будут принимать такие решения в будущем, и, если вы сделали хорошие замечания, можете включить вас в свой список «умных людей, которых нужно спрашивать».
  • Плохое управление будет защищаться, скажем, что «решение принято» и другие подобные тактики, чтобы избежать столкновения с тем фактом, что они, возможно, приняли неправильное решение. Они могут видеть вас как "нарушителя спокойствия". Компания страдает, как и ваша вера в управление. Это настоящий красный флаг! Убирайся, пока можешь!

6
Существует довольно большое отличие от ide / editor и scm или системы сборки. И ide / редактор предназначен для личного использования и, как правило, с учетом индивидуальных особенностей. Система scm или build используется глобально всеми. Одна из этих вещей нуждается в централизованном управлении, другая, безусловно, не нуждается.
Джереми Уолл

2
Мой ответ был нацелен на вопросы управления, а не на конкретное решение по IDE как таковое. Однако есть также много веских причин для стандартизации в среде IDE (например, навыки, обучение, затраты на лицензирование, эффективность парного программирования, интеграция с другими инструментами, общее качество среды IDE, затраты на поддержку, простота развертывания). В некоторых контекстах правильным решением будет стандартизация - вы ошибаетесь, если считаете, что это всегда можно оставить за индивидуальным выбором (даже если это правильное решение во многих ситуациях)
mikera

2
@ Джереми: Я думаю, что ваша точка зрения идеально подходит для группы из одного человека или небольшой группы хакеров. Я сильно сочувствую: я точно такой же для своих личных проектов. Но этот подход просто не подходит для более крупных корпоративных контекстов. Хорошо отдавать предпочтение инструментам, но я ожидаю, что хороший профессиональный разработчик будет готов и способен изучать и применять любые инструменты, которые сделают организацию наиболее эффективной в целом.
Микера

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

2
Крутая, отличная компания, и вам повезло работать в таком месте, которое способно работать как множество "небольших групп хакеров" в относительно независимых проектах. К сожалению, большинство крупных предприятий не имеют такой роскоши. Подумайте о большом банке, которому необходимо нанять и обучить 100 индийских Java-кодеров начального уровня для работы по поддержке приложений для call-центра. Поощрение их к творчеству и выбору собственного IDE / процесса сборки просто не сработает.
Микера

12

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

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


например. если вы хотите использовать ADF, то естественным выбором будет JDeveloper, плагины для других идентификаторов могут не иметь всех функций.
Рохит Банга

11

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

В среде IDE против редактора ... почти для всех языков я настоятельно предпочитаю IDE (IntelliJ), потому что он может сделать для вас гораздо больше, чем редактор. Есть некоторые вещи, для которых я возвращаюсь к ST2 или Emacs, но для повседневного кодирования, несмотря на то, насколько мне нравятся оба ST2 / Emacs, IDE почти всегда побеждает.


1
Я оспариваю ваше утверждение о том, что IDE может сделать значительно больше, чем редактор. Существуют явно худшие редакторы, например, вы бы не занимались серьезной разработкой с использованием nano или gedit, но я могу писать код быстрее в vim, чем я, и, как я полагаю, большинство других, могут в IDE. И хотя я ненавижу защищать emacs, я уверен, что опытный пользователь emacs быстрее в emacs, чем в IDE.
Кевин

1
@Kevin Спор прочь - я давний пользователь Emacs, и мне становится лучше с ST2, и нет никакого сравнения. Лучшее, более зависимое от контекста завершение, более тесная интеграция отладки, не так уж много вещей, за которые я бы отдал должное текстовому редактору. Некоторые языки работают лучше, чем другие, например, я бы не стал кодировать Java в Emacs, несмотря ни на что, для Ruby и Python я почти наполовину, но IntelliJ меня побеждает. Для реального редактирования текста , будь то код или нет, я использую редактор.
Дейв Ньютон

1
Я знаю вопрос, и большинство ответов направлены на мир Java, но здесь, в мире Microsoft .NET, идея о том, что редактор может быть лучше, чем основной IDE (Visual Studio), абсолютно запаздывает. Я бы не стал нанимать разработчика .NET, который настаивал на использовании Notepad ++ поверх Visual Studio.
Грэм

11

У каждой команды, в которой я когда-либо был, было множество IDE и редакторов: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - это никогда не было проблемой. Никогда.

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

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

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


8

В нашем магазине Ruby настоятельно рекомендуется использовать IDE, которой нравится большинство сотрудников (RubyMine), потому что мы знаем, что он выполняет свою работу, и мы можем научить друг друга сочетаниям клавиш и т. Д.

Разработчики могут свободно использовать другую IDE, но мы требуем, чтобы они обладали серьезными навыками в этом редакторе, если они того пожелают. Если мы видим, что кто-то изо всех сил пытается перемещаться по своему проекту или редактировать текст в своем пользовательском FooEdit, RubyMine для них это так.


4

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

Быть вынужденным стандартизировать IDE звучит как ужасная идея.


2

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

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


2

Это массивный красный флаг. У каждой компании есть несколько таких глупых идей, но если другие красные флаги продолжают появляться, просто уходите.


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

2

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

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

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


1

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

Как вы знаете, вы не знаете, что на самом деле будет делать код, пока не запустите его. Тьюринг доказал это на заре компьютерных технологий. Это означает, что при написании программного обеспечения не существует какой-либо значимой меры производительности. Однако, чтобы руководство выполняло свою работу, производительность труда должна быть четкой. Поскольку вы не можете измерить код (а люди пробовали - например, строки кода), они будут измерять то, что они могут видеть. Программисты более разборчивы, чем программное обеспечение, которое они разрабатывают. Типичная команда менеджеров пытается контролировать программистов, чтобы сделать их понятными (вместо того, чтобы выполнять свою реальную работу: уходить с дороги). И поскольку они измеряют неправильные вещи, это не очень хорошо работает.

Сказав это, вы все еще можете пройти долгий путь со слабосвязанной командой. Команда разработчиков Github насчитывает около 50 человек, и они нарушают все правила в учебниках по управлению бизнесом. Кажется, у них все хорошо. Ошибки исправляются (в конце концов). Особенности добавляются. Пожары потушить.

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


Это кажется совершенно не связанным с вопросом. Вы хотели опубликовать в другом месте?
Дениф

@Daenyth Я хочу опубликовать это здесь. Оригинальный заголовок "Одна IDE, чтобы управлять ими всеми?" не имеет ничего общего с пояснительным пунктом. Похоже, что ОП спрашивает, указывает ли то, что принуждение к использованию IDE указывает на время освобождения под залог компании.
Хо-Шэн Сяо

1

Конечно, это плохая идея. Это неизбежно, что команда станет менее продуктивной, поскольку они должны научиться использовать новые инструменты. И даже тогда они не будут столь же эффективны , как с инструментами , они уже ГРОК .

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

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

С другой стороны ... этот последний бит не был бы необходим, если бы каждый использовал свое предпочтительное программное обеспечение. ;)


0

Вы можете «использовать» Eclipse, все еще печатая в SublimeText2.

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


0

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


0

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

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


0

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

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

И последнее: внедрение процесса на этом уровне может указывать на то, что компания намерена расширить команду разработчиков и хочет иметь определенную структуру, чтобы новые товарищи по команде могли быстрее работать. Если вы думаете, что Rails (или Django) - это «самоуверенный» фреймворк, вы поймете, что наличие структуры помогает легче понимать новые приложения.


0

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

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

Получить 12 голосов разработчиков было бы легко. Конечно, было достаточно времени, чтобы сделать это! Вывод был бы болезненным для некоторых так или иначе, и это, возможно, даже в конечном итоге быть Eclipse, в конце концов, но маркировка требование как «красный флаг» в этом случае будет гораздо более спорным.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.