Следует ли передавать внутренний код не-разработчикам в организации?

14

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

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

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

Некоторые аргументы до сих пор:

  • Пароли в VCS выставлены (решение: избавьтесь от паролей - они не должны быть там с самого начала)
  • Код открыт для атак безопасности белого ящика (контраргумент: это только защищает честных / ленивых злоумышленников)
  • Сотрудники службы поддержки могут спросить разработчиков, «как» все работает (счетчик: научить человека ловить рыбу и т. Д.)

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

Марк Макдональд
источник
4
Почему вы хотите скрыть это от них?
Марьян Венема
1
Можете ли вы привести закон, чтобы поддержать это?
Blrfl
3
@ S.Lott: Это «основной капитал», и поэтому компания имеет право контролировать, какие сотрудники могут иметь к нему доступ, а какие нет. Обычно компания хочет ограничить количество сотрудников, которые имеют доступ, чтобы ограничить количество людей, которые могут быть подкуплены или вынуждены отдать актив или злоупотреблять активом, когда они вступают в несогласие с компанией. Таким образом, в большинстве случаев это не должно быть раскрыто внутренне (всем; это должно быть раскрыто руководству).
Ян Худек
1
@JanHudec: «должен быть раскрыт руководству»; «Компания имеет право контролировать, какие сотрудники могут и не могут получить к ней доступ». Отлично. Это не зависит от разработчиков, чтобы принять эти решения. Отсюда и моя просьба о разъяснении. Как этот вопрос может возникнуть? Почему разработчики принимают это решение?
S.Lott
1
@ S.Lott: Я не вижу вопроса, подразумевающего, что это разработчики, которые принимают это решение. Управление имеет последнее слово, но кто-то должен собрать аргументы за них.
Ян Худек

Ответы:

8

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

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

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

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

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

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

Петер Тёрёк
источник
5

В большинстве организаций, в которых я работал, хранилище кода было открыто для всех разработчиков.

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

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

sleske
источник
4

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

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

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

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

MalsR
источник
3

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

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

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

Дипан Мехта
источник
3
«в большинстве организаций обычно есть открытые для всех хранилища для поддержки кода». - У меня есть сомнения по этому поводу. Можете ли вы привести какие-либо данные в обоснование этой претензии? Кроме того, как неспособность получить доступ к репозиторию проекта Foo должна демотивировать меня?
Петер Тёрёк
@ PéterTörök - Я подозреваю, что Дипан имеет в виду, что большинство организаций, с которыми у него есть опыт, код открыт для всех. Это согласуется с моим собственным опытом более 20 лет в различных организациях. Даже во время работы в оборонной промышленности было удивительно мало кода, который был только в защищенной сети.
Марк Бут
@ Марк, в этом смысле я согласен. До сих пор на большинстве моих рабочих мест я не видел много усилий для разработки политики доступа к репозиториям SCM, поэтому довольно часто они де-факто доступны всем, кто заходит. Но это результат пренебрежения, а не чьего-либо сознательного решения.
Петер Тёрёк