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

Должны они? Это до корпорации. Лично я думаю, что это прекрасно, пока существуют некоторые понятые правила.

1. Быть администратором на Вашем поле является полномочием НЕ право.
   2. Заражение вирусами в нескольких случаях отменит право
   3. Отключение корпоративных агентов отменит право - AV/inventory/software развертывание/и т.д.
   4. В основном, если Вы сделаете что-то, что рискует сетью, то отменят право
2. Любые инструменты, которые Вы устанавливаете, не должны быть сделаны зависимостью Вашего проекта, не получая их в официально одобренном списке. Спросите приятно не прибывают, отказывая в день развертывания и требуют, чтобы $random_library были установлены на всех серверах без тестирования
3. Для чего-либо за пределами нормальных приложений, установленных везде еще, поддерживают, будут максимальные усилия. Справочная служба и/или системные администраторы не проведут 5 часов, пытаясь отладить, почему у Вас есть конфликты dll.

У разработчиков должно (идеально) быть два доменных логина.

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

Это должно затем уменьшить вероятность ItWorksOnMyMachine-itis, который иногда появляется.....

Для корпораций, которые волнуются по поводу безопасности, они сделают, чтобы люди безопасности продиктовали и попытались осуществить политику, которая работает с их моделью разработки и систем. В Windows Environment большинство людей скажет Вам, что необходимо иметь Административные права на хосте, который они разрабатывают на том, для выполнения их задач.

Это не обязательно верно...

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

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

Существуют разработчики и существуют Разработчики. Если "разработчиком" является JBoss приблизительно за $40/часов парень Java, пишущий правила для механизма правил затем, конечно, нет. Если "разработчик" является парнем C/Assembly за $350/часов, заставляющим Ваше программное обеспечение редактирования видео работать максимально быстро на GPU, то да, конечно.

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

Как Java-разработчик, у меня едва была потребность иметь права администратора на моей машине на непрерывной основе. Однако существуют законные случаи при необходимости в доступе администратора по запросу (.ie., необходимо переместить ноутбук через физически отдельные домены, и необходимо изменить NIC соответственно.), Который был единственным временем, были, мне действительно был нужен постоянный, продолжающийся доступ администратора к моей машине.

Иногда Вам нужен доступ администратора, потому что IT неукомплектован (или некомпетентен или испачкан в бюрократизме.), Но если Вы работаете с компетентным отделом ИТ, они могут установить материал для Вас даже удаленно (или путем обеспечения пользовательских установщиков, которые будут "работать как" администратор и устанавливать материал для Вас, просто нажав в них.)

Таким образом, ответ (снова) - он зависит. У Вас есть быстро реагирующий штат IT, который может установить вещи по требованию (или в течение разумного срока)? Разработчикам на самом деле нужен он для задач, которые им платят?

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

Иначе, нет. Помните принцип наименьшего количества полномочия, людей.

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

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

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

Что-либо идет не так, как надо, и можно вытереть и восстановить в течение минут.

Я должен (по-видимому), обеспечить несогласный голос и сказать не только не, но и "heck не". У меня нет проблемы при предоставлении devs прав администратора на поигравшем в песочнице VM, который не имеет никакого доступа к сети. Zypher имел его почти право (полужирное исправление):

"1. Быть администратором на моем поле является полномочием НЕ право". Эти системы являются корпоративным имуществом, за которое я в конечном счете ответственен. Когда Joe Developer устанавливает свою пиратскую копию Microsoft Bob ("потому что мне была нужна она"), это не будет им, который должен объяснить, как это не было найдено перед аудитом. Разработчики обычно думают, что так или иначе корпоративные правила просто не относятся к ним. Путем предоставления им поигравшего в песочнице VM они могут следовать всем правилам, за которыми все остальные должны следовать (так как теперь только IT может скопировать файлы в и от системы). Волшебно система запроса привыкает разработчиками снова, небо больше не падает, когда Joe Developer искажает свое поле разработки - он просто просит нового (или восстановление, если его просят относительно резервных копий),

Г-н Denny упомянул разработчиков, стоящих денег, когда они должны ожидать приложений, которые будут установлены, A. привет... мое время является обычно столь же бесценным как Joe Developer (обычно больше, так как я сохраняю exisiting выполнение пробного программного обеспечения - и делаю я действительно должен упомянуть все время потраченный на помощь разработчику Joe отладить его последний шедевр), и B. когда dev идет сверхбюджет, потому что они ожидали приложения и попытки обвинить IT в нем, я скажу:

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

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

Править: Это certianly довольно возможный, что разработчики, которым я был подвергнут, необычно тусклы (опрос текущей обрезки, которую только 1 услышал о stackoverflow, для предоставления некоторого уровня сравнительного теста). Начальная точка зрения, что я начинаю, "что делает необходимо сделать то, что компания оплачивает Вас, чтобы сделать". При необходимости в правах администратора, Вы получаете их, но Вы не были должны stqart с ними и если я могу дать Вам поле, что откровенно я не забочусь о том, что Вы делаете к нему, и это работает затем, мы оба хороши для движения.

Я думаю, что Вы задаете неправильный вопрос, необходимо спрашивать:

Хороший разработчик будет работать на работодателя, который не дает ему права администратора на их ПК?

В чем кто-то “нуждается” и что они ожидают, часто не то же самое, в конце концов, Вы не должны позволять разработчику выпить кофе в часы работ, но если Вы не делаете …

(Удостоверьтесь, что Вы вырабатываете свою политику, ясную в этапе интервью, иначе можно получить людей, устраивающихся на работу, которые затем презирают компанию из-за отсутствия прав администратора – не ожидают, что программисты будут думать логическим способом об этом виде вещи!)

Ответ, вероятно, будет субъективен и характерен для каждого отдельного сценария, но в большинстве случаев я сказал бы да.

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

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

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

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

Отказ от ответственности: Я - разработчик.

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

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

1. Что минимальное полномочие требуется выполнить функции отдела? Это - наша базовая линия.
2. Каковы риски предоставления им больше доступа? (фактические риски, не только лучшие/хуже варианты развития событий)
3. Что истинной является ожидаемая стоимость предоставления им больше доступа? (затраты на поддержку, фиксируя непреднамеренные изменения, внесенные неопытным администратором, и т.д.)
4. Что истинной является ожидаемая стоимость не предоставления им больше доступа? (потерянная производительность, требуя IT поддерживает для выполнения ежедневных задач, оборота опытных людей из-за морального духа, и т.д.),

С этими отвеченными вопросами можно сделать обоснованное решение, а не страстное.

Для Вашей определенной среды существуют некоторые вещи, которые требуют прав администратора (см. Пользовательские Права и Visual Studio) - если они не делают тех вещей, затем можно ответить на вопросы 2 - 4.

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

В среде Windows, и особенно при использовании продуктов разработчика Microsoft, dev потребует прав администратора на их машине. При отклонении их те права их способность делать, их работы будут ограничены, если не предотвращенный в целом.

Существует и наука и искусство в разработке; это не столь просто как "знающий", в чем мы нуждаемся. Если бы у нас уже был ответ, то половина нашего задания была бы спорна; нахождение корректного подхода является часто повторяющимся, и может включить несколько инструментов непредсказуемыми способами. Требование, чтобы посредник установил каждый из них (часто с высокой задержкой), только нашел (приблизительно час в), что для Вашего сценария "super-uber дополнение инструмента" необходим, глупо.

В то время как VM идеален для этого, существует также много средств разработки, которые не могут работать (правильно, или даже вообще) в VM, потому что они сами - VM - и я не имею в виду вещи как JVM; я имею в виду полную машину emus/vms, такую как инструментарии устройства. Совместимость там улучшается.

Кроме того, большинство средств разработки имеет очень большое место - намного больше, чем "обычные" инструменты (делающий хостинг VM немного более болезненного, чем Вы могли бы ожидать), и часто по природе того, чтобы быть отладчиком процесса требуют поднятого доступа. Не говоря уже о том, что они могут быть интенсивным GUI; попытка выполнить полный рабочий день на GUI VM является... чрезвычайно болезненной.

Производительность является огромным, здесь; Вы думали бы, что для пользователей было нормально ожидать спустя 3 секунды после каждого нажатия клавиши в Word для их ключа к регистру? Я не шучу - средства разработки на VMs и т.д. могут быть этим sucky; в большинстве целей разработки Вам нужна скорость отклика. Прерывание потока сложной логики с мозга на клавиатуру может сделать в значительной степени невозможным сделать задание. И я очень не хочу сказать это, но да: время разработки является дорогим.

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

По моему скромному мнению, лучшая рабочая среда, которую я видел по сей день, - то, где эти две группы сохраняются разделенными. У разработчиков есть свой собственный домен в лесу (посредством чего IT управляет тем, что этот домен и его пользователи могут сделать в остальной части компании), и они - все локальные администраторы с опытными парнями с MCSE, действующим как локальные администраторы домена, они имеют свою собственную тестовую среду и могут сделать в значительной степени, что они хотят и нуждаются на их локальной LAN с единственной политикой IT (никакое пиратское программное обеспечение). Корпоративный IT не ответственен и не представляет поддержку devs и только осуществляет некоторые корпоративные правила высокого уровня (никакой Facebook, порно или подобный через брандмауэр, devs не позволяют смешивать с корпоративной LAN), и у них всех есть RSA базирующийся VPNs для работы из дома, который помещает их непосредственно в их LAN. Аккуратный, не так ли?

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