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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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