조직 내 개발자가 아닌 사람과 내부 코드를 공유해야합니까?

내가 일하는 곳에서는 직원과 고객 모두가 사용하는 독점 응용 프로그램을 실행하는 많은 개발자와 많은 코드가 있습니다.

또한 시스템의 내부 작업을 이해하여 고객을 더 잘 지원하고 때때로 패치를 제출하는 스마트 지원 직원도 많이 있습니다.

비 개발 직원이 읽을 수 있도록 코드를 열어야합니까? 이 결정을 내릴 때 어떤 요소를 고려해야합니까? 나는 여러 가지 논쟁과 반론을 각각 겪었고 다른 사람들의 경험과 잘 이해 된 위험에 기초하여 결정을 내리고 싶습니다.

지금까지 몇 가지 주장 :

• VCS의 비밀번호가 노출됨 (해결 방법 : 비밀번호를 제거하십시오. 처음에는 비밀번호가 없어야 함)
• 코드는 화이트 박스 보안 공격에 개방적입니다 (반박 론 : 정직하고 게으른 공격자 만 차단)
• 지원 직원은 개발자에게 "어떻게"작동하는지 물어볼 수 있습니다 (카운터 : 물고기에게 사람을 가르치는 등)

조직의 직원에게 코드를 공개 한 사람이 있습니까? 문제가 되었습니까?

나는 이것에 대한 일반적인 대답이 없다고 생각합니다. 조직은 규모, 지리적 분포, 회사 문화, 저작권 정책, 개발중인 소프트웨어 종류 등이 크게 다릅니다.

예를 들어, 상품 / 인프라 유형의 소프트웨어를 개발하는 회사의 경우, 시스코가 몇 년 전 프린터 드라이버 소프트웨어 (IIRC)를 사용하여했던 것처럼 소스 코드를 쉽게 열 수 있습니다.

경쟁사보다 경쟁 우위를 점할 수있는 특수 알고리즘이나 물건을 포함하여 잠재적으로 희귀 한 독점 소프트웨어를 개발하는 회사의 경우 코드를 비밀로 유지하려고 노력하고 있는지 잘 이해할 수 있습니다. 예를 들어 AFAIK Google은 핵심 검색 알고리즘 구현에 대한 액세스 권한이 부여 된 사용자 수를 매우 엄격하게 제한합니다.

또한 다국적 조직은 오늘날 많은 국가, 시간대 및 문화에 퍼져 있으며 보안상의 이유로 인트라넷을 세그먼트 화하고 방화벽을 사용하여 다른 세그먼트 / 도메인 간의 트래픽을 제어합니다. 따라서 SCM 리포지토리를 "전체 회사"에 맞게 만들려면 실제로 시스템 관리자를위한 많은 추가 작업과 추가 보안 위험이 필요할 수 있습니다. 그것은 일반적으로 어떤 이익도 가져 오지 않지만, 완전히 다른 것들에 대해 다른 대륙에서 일하는 고용주는 아마도 우리 프로젝트에 대해 알지 못하기 때문에 긍정적으로 기여하는 것이 훨씬 적습니다.

따라서 부서 내 에서 및 / 또는 프로젝트와 관련된 사람들에게 어떤 의미가 있다면 , 왜 그렇지 않습니까? 그러나 일반적으로 "개방성"을 위해서 가치가 있는지는 확실하지 않습니다.

마지막 참고 사항 : 지원 담당자가 현명하고 패치를 제공하고자하는 경우에도 시스템에 통합되기 전에 개발자가 기여한 내용을 항상 검토해야한다고합니다.

내가 일한 대부분의 조직에서 코드 저장소는 모든 개발자에게 공개되었습니다.

일부에서는 소프트웨어와 함께 문서화하기 위해 문서 (예 : 사양 및 요구 사항)를 저장하는 데 사용되었습니다. 이 경우 대부분의 다른 직원들도 액세스 할 수있었습니다. 레포가 코드에만 사용되는 경우 일반적으로 개발자가 아닌 사람은 액세스 권한이 없었습니다.

나는 가능한 한 많은 개방성을 추천 할 것입니다. 따라서 사람들이 접근을 원한다면 명백한 문제가 없다면 그들에게 제공하십시오. 그러나 그것은 실제로 조직 문화의 문제입니다 ...

나는 이것에 대한 일반적인 / 실용적인 견해를 공유하며 또한 일 / 조직의 본질에 의존 할 수도 있습니다. 그러나 나는 코드베이스가 모두에게 열려 있어야한다고 생각합니다 (조직 내에서도 openess와 trust를 보여줄 것입니다).

또한 고객 요청을 처리하는 지원 / 헬프 데스크 팀이있는 곳에서 언급 한 것과 비슷한 설정으로 작업합니다. 그러나 시스템의 특정 복잡한 영역에는 추가 도움이 필요합니다. 필자의 경우 코드베이스는 문제가 발생하지 않은 모든 사람에게 열려 있습니다.

• 코드 기반을 열면 다른 지원 팀원들도 코드 기반을 체크 아웃하고 코드 기반을 체크 아웃하고 관심이 있거나 답변을 찾아야하는 비즈니스 규칙 / 영역에 익숙해 질 수 있습니다 (기술적 인 이해를 높이고 무언가를 살펴볼 수 있음) 시간이 허락한다면 단조로운 루틴과 다릅니다. 이는 지원 팀 구성원이 고객 문제와 로그를 얻을 때 유용하며, 예를 들어 스택 추적을보고 코드의 가능한 영역을 지적 / 지원할 수 있습니다 (예 : 문제에 따라 다름). 이것은 물론 문제에 따라 개발자와 시간을 절약 할 수 있습니다.

또한 모든 비즈니스 규칙 / 결정을 포함하는 제품의 최신 문서 / 위키를 갖는 것도 도움이 될 것입니다. 물론 새로운 기능 향상 및 / 또는 버그 수정 (동작이 변경되는 위치)에 영향을 미치도록 Wiki를 지속적으로 업데이트해야합니다. 나의 정직한 생각

일반적으로 조직의 관점에서 사람들은왔다 갔다합니다. 프로젝트 (또는 제품)는 계속 발전해야합니다. 따라서 대부분의 조직에는 일반적으로 코드를 유지하기위한 모든 저장소에 대한 공개가 있습니다.

일반적으로 무단 무단 액세스를 방지하기위한 액세스 권한 등이 있지만 (코드 도난 등을 방지하기 위해) 대부분의 상위업자는 실제로 이에 제한되지 않습니다. 조직 내에서 코드로 신뢰할 수있는 사람들을 충분히 신뢰해야합니다. 직원 (또는 동료)의 코드를 숨기는 것은 큰 동기 부여 요인입니다.

우리 조직에서는 사람들이 실제로 코드에 기여하지 않더라도 개발자에게 물건을 다시 버리고 잠들기보다는 현장에서 문제를 해결 / 소유하려고 시도하기 때문에 코드에 직접 액세스 할 수 있습니다!