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

Question

Я соучредитель и технический директор OnePage (http://myOnePage.com/joel).

Мне было бы интересно услышать ваши мнения и ответы на эту конкретную проблему:

Я уверен, что Yahoo! или Google не раскрывает весь свой код своим разработчикам! Мне просто интересно, какой метод вы используете, чтобы запретить людям видеть полный код? Во всех проектах, очевидно, будут части кода, содержащие важные учетные данные для доступа к базе данных и ключи API.

Спасибо

Answer 1

Если разработчики не получат доступ к коду, это определенно окажется контрпродуктивным в долгосрочной перспективе. Это ограничило бы их продуктивность / эффективность при добавлении новых функций. Так что ИМХО, переосмыслить на это. Лучше нанять людей, которым вы доверяете, и позволить им получить доступ к коду, чем пытаться ограничить его. Во-вторых, что вы пытаетесь ограничить Линии кода программы или детали базы данных, учетные данные для входа и т. Д.? Данные для входа в db обычно находятся в файле свойств. Вы можете зашифровать содержимое файла свойств и запутать код, который читает файл свойств и расшифровывает его. Чтобы программисты не понимали код, вы можете запутать свои библиотеки кода. Но запутывание приходит с собственным багажом.

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

Answer 2

Сокрытие исходного кода не самая сложная проблема для решения. Например, вы можете разделить его на отдельные репозитории и установить для них другой пароль. Затем распространите скомпилированный код (например, jar-файлы) среди команд, которым он нужен. Или предоставьте функциональность кода в виде веб-API, чтобы избежать угроз декомпиляции (таких как Google-графики)

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Если вы хотите сохранить некоторую секретность от POV безопасности, то учетные данные и т. Д. Должны быть настраиваемыми. Разработчики могут иметь информацию об учетных данных для сред разработки / тестирования и т. Д. (Например, база данных разработки).

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

Answer 6

Предоставление сторонним разработчикам сборок или API некоторого рода.

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

Answer 7

С помощью Subversion вы можете настроить ACL и группы. Проверка:

• Параметры авторизации в svnbook
• Контроль доступа для Subversion с Apache2 и Authz
• и т.д.

Answer 8

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

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

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

Единственная часть, которую я не понимаю, - почему в коде должны быть учетные данные и т. Д.? Те, которые входят в конфигурацию;)

Answer 9

Хотя я не работал над общедоступной версией этого, я был в нескольких рабочих средах, где были структуры, как делить код на различные компоненты. Позвольте мне описать примеры, которые могут помочь:

Настройка ASP / COM: В одной компании на веб-страницах существовал VBScript для кода ASP с объектной моделью, написанной на C ++, которая взаимодействовала с серверной частью Oracle. Были только некоторые разработчики, которые могли изменить объектную модель, что ограничивало то, что некоторые из нас могли сделать, но также обеспечивало способ отделить, кто чем занимался, и разные навыки для каждого. У разработчиков переднего плана было несколько сценариев, позволяющих загружать двоичные файлы, и, кроме API, часто не заботились о том, как это делается.

Внутренняя / внешняя настройка: в другой компании существовала внутренняя платформа с собственным именем, над которой работали несколько разработчиков. Пара других разработчиков работали над интерфейсом, который подключался через API, используя удаленное взаимодействие объектов .Net для выполнения различных функций. У этого были свои хорошие и плохие моменты, поскольку бывали времена, когда клиенту требовались новые вызовы, и нам приходилось ждать, пока эти вызовы будут реализованы.

Надеюсь, это как-то полезно.

Answer 10

Эй, давайте не будем слишком жесткими с бедным Джоэлом! Мне не нравится, когда меня отстраняют от вещей больше, чем от следующего парня, и у меня была доля разочарований, когда я должен был что-то исправить в спешке, но у меня не было соответствующих полномочий для этого. С другой стороны, «наймите людей, которым вы можете доверять, и тогда вам не придется беспокоиться о внутренней безопасности», сказать гораздо легче, чем сделать. Как вы собираетесь гарантировать, что все новые сотрудники заслуживают доверия? Что вы собираетесь делать, на собеседовании спросите их, являются ли они ворами? Вы действительно ожидаете, что воры просто признаются в этом? Требуется только один нечестный человек, который крадет несколько миллионов долларов и исчезает, чтобы разрушить компанию. Или даже один благонамеренный, но некомпетентный человек, у которого есть ключи от комнаты, где хранятся резервные копии, чтобы решить, что все эти диски, вставленные в неиспользуемый шкаф, должны быть переработаны. Я, конечно, не хотел бы, чтобы мой банк или люди, которые владеют моим 401k, выдавали разрешение каждому новому нанятому человеку, чтобы они могли входить в мой аккаунт и манипулировать данными без ограничений.