Чи слід ділитися внутрішнім кодом в організації, що не розробляється?

Там, де я працюю, у нас є багато розробників і дуже багато коду, який працює з нашими власними програмами, якими користуються співробітники та клієнти.

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

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

Деякі аргументи поки що:

• Паролі в VCS піддаються (рішення: позбудьтеся паролів - вони не повинні бути там для початку)
• Код відкритий для атак безпеки на безпеку (контр-аргумент: це запобігає лише чесним / ледачим нападникам)
• Служби підтримки можуть запитати розробників "як" справи (лічильник: навчити людину ловити рибу тощо)

Хтось відкриває свій код персоналу в їх організації? Чи це викликало якісь проблеми?

Я не думаю, що на це є загальна відповідь. Організації дивовижно відрізняються за розмірами, географічним розповсюдженням, культурою компанії, політикою щодо авторських прав, видом програмного забезпечення, що розробляється тощо, тощо. Тощо.

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

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

Також багатонаціональна організація сьогодні поширюється в багатьох країнах, часових поясах і культурах, і з міркувань безпеки вони, ймовірно, сегментують свою внутрішню мережу та використовують міжмережеві стіни для контролю трафіку між різними сегментами / доменами. Таким чином, зробити репо-SCM неможливим для "всієї компанії" може насправді вимагати багато додаткової роботи для системних адміністраторів та додатковий ризик для безпеки. Хоча це зазвичай не приносить користі взагалі, оскільки роботодавці, які працюють на іншому континенті над абсолютно різними матеріалами, ймовірно, навіть не знають про наш проект тут, тим більше, щоб позитивно сприяти цьому.

Тож якщо це має сенс у вашому відділенні та / або для людей, пов'язаних із проектом, якимось чином, чому б ні. Але взагалі, просто заради «відкритості», я не зовсім впевнений, що того варто.

Останнє зауваження: навіть коли люди, які працюють у службі підтримки, розумні і прагнуть внести виправлення, я б сказав, що їх внески завжди повинні переглядати розробник, перш ніж інтегруватися в систему.

У більшості організацій, в яких я працював, сховище коду було відкрите для всіх розробників.

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

Я рекомендую якомога більше відкритості - тому, якщо люди хочуть доступу, надайте їм їх, якщо не буде очевидної проблеми. Але це справді питання культури організації ...

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

Я також працюю в подібній установці, як ви згадали, де у нас є команда служби підтримки / служби підтримки, яка займається запитами клієнтів. Однак у деяких складних областях системи вони потребують додаткової допомоги. У моєму випадку база коду відкрита для всіх, з якими ми не стикалися.

• Думаю, відкривши базу коду, інші зацікавлені члени групи підтримки можуть також перевірити кодову базу та ознайомитись з діловими правилами / сферою, яка їх цікавить, або потрібно знайти відповіді (і, можливо, покращити своє технічне розуміння та переглянувши щось відрізняється від монотонного розпорядку, якщо дозволяє час;)). Це також може виявитися корисним, коли члени групи підтримки отримують проблеми із клієнтами та журнали, і вони зможуть вказати / допомогти на можливі області коду, де це відбувається, переглянувши стек трек, наприклад (очевидно, це залежатиме від проблеми тощо). Це також заощадить час з розробником, але залежно від проблеми, звичайно.

Також допоможе наявність актуальної документації / вікі продукту, яка містить усі ділові правила / рішення. Але, звичайно, вам потрібно переконатися, що вікі постійно оновлюється для отримання нових вдосконалень та / або виправлень помилок (де змінюється поведінка). Мої чесні думки

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

Зазвичай є права доступу тощо для запобігання непоміченого несанкціонованого доступу (для запобігання крадіжки коду тощо), але більшість вищих вікон дійсно не заборонені в цьому. В організації потрібно довіряти людям (достатньо), що ви можете довіряти їм код. Приховування коду від співробітників (або колеги) є чудовим демотивуючим фактором.

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