Во многих крупных компаниях соображения безопасности означают, что разработчики не имеют системных разрешений, необходимых для установки собственного программного обеспечения, что может привести к снижению производительности. Как такая компания, как Google, которая, как известно, является инновационной и ориентированной на разработчиков, решает эту проблему?
Разработчики всегда должны развиваться как обычные пользователи машины по двум (возможно, и другим) причинам:
Я разрабатываю с использованием учетной записи пользователя. У меня есть административная учетная запись, которую я использую для установки программного обеспечения или настройки машины (Windows или Unix, это не имеет значения). Последнее, что мне (и моему работодателю, если на то пошло) нужно сделать, это потратить день или два на очистку и переустановку моего компьютера (даже если это связано с восстановлением резервных копий), потому что что-то пошло не так, потому что я вошел в систему как администратор.
Я работаю в крупной компании, и у меня нет прав администратора на моем компьютере. Все должно быть запрошено и одобрено. Сначала меня это немного раздражало, но теперь это всего лишь часть процесса. Я получил свою Visual Studio, notepad ++ и тому подобное, после того, как были отправлены все утверждения документов. Я даже упомянул netbeans / java sdk на случай, если это потребуется для работы. ИТ-директор и сотрудники хотят сохранить контроль над своей сетью и иметь строгие правила по программному обеспечению в зависимости от типа работы. Однако они понимают, что я разработчик и мне нужен больший доступ, чем другим сотрудникам офиса. Я пришел из ИТ-сферы в разработку программного обеспечения, поэтому я всегда привык к полному машинному доступу. Однако чем больше я работаю с вещами, это не такая большая проблема, как я думал.
До сих пор я не делал никакого программного обеспечения, которое требует доступа администратора к пользовательским машинам, так что это еще не было проблемой, но это могло быть проблемой в будущем.
Я помню, как много лет назад читал старую статью об инженерах Google. Им разрешено использовать любые инструменты, которые им нужны для помощи в их задаче, что довольно приятно. Я уверен, что если вы «загуглите» свой запрос в Google, там будет несколько статей, описывающих их рабочую среду.
Наиболее компании (которые разбираются в программном обеспечении), с которыми я работал как разработчик, допускают некоторую гибкость в плане программного обеспечения, поскольку многие программисты очень разборчивы в своих собственных инструментах (vim против emacs; текстовая панель против блокнота ++ и т. д.). Чаще всего это права администратора на своей локальной машине. Как и ожидалось, обычные права безопасности (пароли, группы и т. Д.) Применяются к машинам за пределами локальной рабочей станции, таким как промежуточная и производственная среды. Таким образом, наличие администратора на локальном уровне - это здорово, а наличие ограниченного доступа к серверам базы данных, сети, обмена сообщениями и т. Д. И т. Д. И т. Д. Управляемо и понятно.
Обычно разработчики получают полную свободу действий в среде разработки. Я сравниваю это с игрой в песочнице. Постановка должна имитировать производство, но строго контролироваться несколькими ведущими разработчиками. А производственная среда обычно вне пределов. Внесены изменения в разработку -> повышен до промежуточного уровня -> повышен до производственного (конечно, ожидается тестирование). Теперь я понимаю, что эта методология идеальный. Это не значит, что все это практикуют. Как Google это делает, мне непонятно. Но я не удивлюсь, если это будет похоже на этот метод.
Это действительно зависит от офиса и сценария.
Я обычно обнаруживаю, что в большинстве офисов их разработчики и несколько других ролей обычно имеют машины, которые находятся в сети / домене с ограниченными привилегиями, однако у них обычно есть права локального администратора, поэтому они могут устанавливать и делать все, что захотят.
Некоторые другие офисы со строгими политиками, как правило, предоставляют своим сотрудникам заблокированную машину для работы, связанной с сетью, например, Outlook, а затем другую машину, которая находится в отдельной сети, которая просто имеет доступ к Интернету для бездельничанья.
Нет смысла продавать по телефону или поддерживать полный доступ администратора, когда им нужно использовать только несколько программ.
Небольшие компании хороши тем, что позволяют вам делать такие вещи. Я работал в нескольких небольших ИТ-компаниях, и вы не только получаете root-права на своей машине, но и получаете root-права на всех машинах. :)
В небольшой компании предоставление разработчикам свободы выбора инструментов может вызвать проблемы, если затем разработчик уйдет из компании, и никто другой не имеет опыта работы с этим инструментом. Это кривая обучения, которая, если бы разработчик использовал то же, что и все остальные, не потребовалась бы.