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

Question

Должны ли разработчики ограничиваться определенными приложениями для использования в процессе разработки?

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

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

Область применения

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

Возможные решения

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

2. Создайте черный список для программного обеспечения.Разработчики перечисляют все используемое программное обеспечение.Наблюдательный совет периодически просматривает список.

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

Редактировать

Проясненный вопрос.Попытался высказаться менее аргументированно.

Answer 1

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

1) Компания блокирует компьютер и относится к разработчику так же компетентно, как к секретарю

Что происходит, когда разработчику нужно что-то сделать с правами администратора?НАПРИМЕР:Зарегистрировать COM-объект, перезапустить IIS или установить продукт, который они создают?Вы только что отключили их.

2) Создайте белый список одобренного программного обеспечения...

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

Если вы предпримете любое из этих действий, вы достигнете следующего:

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

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

3. Вы существенно подорвете моральный дух команды.Никому не нравится чувствовать себя запертым в клетке, и каждый раз, когда они думают: "Это было бы закончено 5 часов назад, если бы только я мог установить grep", они будут недовольны.

Более приемлемый ответ - создать черный список для "проблемного" программного обеспечения (и веб-сайтов), такого как Pidgin, MSN messenger и т.д., Если у вас возникли проблемы с бездействием разработчиков.Некоторые разработчики также будут возражать против этого, но многие согласятся с этим, при условии, что вы разумно относитесь к тому, что вносите в черный список, и не перегибаете палку.

Answer 2

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

Реальный ответ:НЕТ!!!

Answer 3

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

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

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

Answer 4

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

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

Answer 5

Что бы они ни делали, не надо уберите интернет вообще.Google = Справка по кодированию 101 :)

Или, может быть, просто уйти www.stackoverflow.com разрешено, ха-ха.

Answer 6

Я бы сказал, что это зависит от целого ряда факторов.

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

Другим фактором является то, что делают эти разработчики.Если они компилируют код на C, используя проприетарный компилятор для встроенной платформы, все сильно отличается от команды, производящей распределенное веб-программное обеспечение или программное обеспечение для ПК в постоянно меняющейся среде.

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

Есть и другие факторы, но в конечном итоге все сводится к двум противоречивым целям:

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

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

Answer 7

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

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

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