문제

개발자가 개발 용도로 특정 응용 프로그램으로 제한되어야합니까?

대부분의 경우, 개발 팀이 중요하지 않아야한다는 데 동의하는 한 답은 대답입니다.

보안 인증에 대한 감사가있는 회사의 경우 회사의 위험과 개발자의 유연성, 성능의 균형을 맞추는 방법이 있습니까?

범위

  1. 코딩/개발 소프트웨어
  2. 시스템 소프트웨어를 구축하십시오
  3. 배포 (라이브러리, 유틸리티)에 포함 된 타사 소프트웨어
  4. (추가의) 워크 스테이션에 나머지 소프트웨어

가능한 해결책

  1. 개발자가 원하는 소프트웨어를 사용하기 전에 원하는 소프트웨어에 대한 승인을 요청 해야하는 승인 된 소프트웨어의 흰색 목록을 작성하십시오. 승인은 비즈니스 목적/보안 위험을 기반으로합니다.

  2. 소프트웨어 용 블랙리스트를 만듭니다. 개발자는 사용 된 모든 소프트웨어를 나열합니다. 검토 보드는 정기적으로 목록을 넘어갑니다.

팀 환경을 넘어 개발자 도구를 제한하는 회사에서 일해야했던 사람이 있습니까? 그들은 상황을 어떻게 처리 했습니까?

편집하다

정리 질문. 논증을 덜 시도했다.

도움이 되었습니까?

해결책

아니요, 개발자는 사용하는 소프트웨어에 제한되어 있지 않아야합니다. 왜냐하면 자신의 업무를 성공적으로 수행하지 못하게하기 때문입니다. 개발자 팀에 대해 얼마를 지불하고 있는지 생각해보십시오. 인위적으로 문제를 해결하는 것을 막았 기 때문에 모든 돈이 배수구를 나선 곳으로 가기를 원하십니까?

1) 회사는 PC를 잠그고 개발자를 비서로서 유능한 것으로 취급합니다.

개발자가 관리 권한으로 무언가를해야 할 때 어떻게됩니까? 예 : COM 객체를 등록하거나 IIS를 다시 시작하거나 건축 한 제품을 설치합니까? 당신은 방금 그들을 종료했습니다.

2) 승인 된 소프트웨어의 흰색 목록 작성 ...

이것은 또한 엄청난 양의 소프트웨어로 인해 비현실적입니다. .NET 개발자로서 저는 정기적으로 (적어도 주당 한 번) 50 개 이상의 구별 응용 프로그램을 사용하며 이러한 많은 응용 프로그램에 대한 새로운 업그레이드/대안을 지속적으로 평가하고 있습니다. 모든 것이 화이트리스트를 통과해야한다면, 당신의 "승인"직원은 팀의 팀은 물론 하나 또는 2 명의 개발자에 의해 완전히 늪에 빠질 것입니다.

이 조치 중 하나를 사용하면 다음을 달성 할 수 있습니다.

  1. 개발자가 승인 팀을 기다리는 엄지 손가락에 앉거나 도움이되는 도구를 설치할 수 없었기 때문에 길고 느리게 지루한 일을하는 거대한 시간과 돈 더미를 태울 것입니다.

  2. 당신은 자신을 개발 부서의 적으로 만들 것입니다 (개발자가 실제로 요청하는 일을하기를 원한다면 좋지 않습니다).

  3. 팀 사기를 실질적으로 우울하게 할 것입니다. 아무도 새장에 갇힌 것처럼 느끼는 것을 좋아하지 않으며, "Grep을 설치할 수 있다면 5 시간 전에 끝날 것"이라고 생각할 때마다 불행 할 것입니다.

보다 허용되는 대답은 개발자가 느슨해지는 데 문제가있는 경우 Pidgin, MSN Messenger 등과 같은 "문제"소프트웨어 (및 웹 사이트)에 대한 블랙리스트를 만드는 것입니다. 일부 개발자는 또한 이에 반대 할 것이지만, 블랙리스트에 합리적이고 배 밖으로 가지 않는 경우에는 많은 사람들이 괜찮을 것입니다.

다른 팁

개발자가 작업 기계에서 사용할 수있는 소프트웨어를 제한하는 것은 환상적인 아이디어입니다. 이런 식으로 모든 개발자가 그만두면 회사가 급여와 장비에 많은 돈을 쓸 필요가 없어서 이익이 높아집니다.

진짜 답변 : 아니요 !!!

개발자는 자신의 작업을 수행 할 수있는 한 사용하는 응용 프로그램을 완전히 제어해야한다고 생각합니다. 개발자의 생산성은 작업 환경과 직접 관련이 있으며 아무도 제한되는 것을 좋아하지 않으며 모든 사람이 자신이 좋아하는 소프트웨어를 사용하는 것을 좋아합니다.

물론 버전 제어, 문서 형식 등의 표준이 있어야하지만 일반적으로 개발자는 원하는 프로그램을 사용할 권리가 있어야합니다.

보안은 개발자의 관심사 여야합니다. 회사 관리자는 모든 종류의 공격으로부터 보호하기 위해 적절한 방화벽을 설립하는 데 관심을 가져야합니다.

더 나은 솔루션은 개발자에게 안전한 독립 환경을 조성하는 것입니다. 타협하면 나머지 회사를 위험에 빠뜨리지 않는 환경.

발전의 본질은 교활한 독창적 인 괴짜 솔루션을 만드는 것입니다. 이를 달성하려면 실패가 발생해야합니다.

그들이 무엇을하든 ~하지 않다 일반적으로 인터넷을 제거하십시오. Google = 코딩 도움말 101 :)

또는 www.stackoverflow.com을 허용하실 수 있습니다.

나는 이것이 꽤 많은 요소에 달려 있다고 말하고 싶습니다.

하나는 팀 규모입니다. 6 명의 개발자로 구성된 팀이있는 경우 일부 응용 프로그램이 팝업 될 때마다 협상 할 수 있습니다. 100 명의 개발자 팀이있는 경우 일부 정책이 순서대로있을 것입니다.

또 다른 요인은 개발자들이하는 일입니다. 임베디드 플랫폼에 대한 독점 컴파일러를 사용하여 C 코드를 컴파일하는 경우, 끊임없이 변화하는 환경에서 분산 웹 또는 PC 소프트웨어를 생산하는 팀과는 매우 다릅니다.

당신이 생산하는 소프트웨어와 대상 고객도 중요합니다. Linux 커널을 일부 새로운 플랫폼으로 포팅하는 경우 코드 누출이 그다지 나쁘지 않을 것입니다. Otoh, 이것이 많은 경우가 있습니다. 매우 다른.

더 많은 요인이 있지만 결국에는 모두 두 가지 상충되는 목표로 요약됩니다.

  • 당신은 개발자에게 창의성을 자극하기 때문에 개발자에게 가능한 많은 자유를주고 싶습니다.
  • 위험을 줄이기 때문에 가능한 한 많이 제한하고 싶습니다. (저는 보안 위험과 비 기능 소프트웨어를 배송 할 위험에 대해 이야기하고 있습니다.)

회사를 해치지 않을 수있는 충분한 보증을 허용하면서 창의성을 해치지 않는 중간 근거를 찾아야합니다.

물론! 반복 가능한 빌드 프로세스를 원한다면 프로그래머가 코드의 일부를 생성하는 도구로 사용하는 임의의 쓰레기에 의해 오염되기를 원하지 않습니다. 구축하는 응용 프로그램이 누구보다 예상보다 훨씬 오래 지속되므로 빌드에 사용하는 도구가 거의 동일한 기간 동안 사용할 수 있도록하고자합니다. 인터넷의 임의 도구는 그러한 gaurantee를 제공하지 않습니다.

팀은 "다음 도구는 다음과 같은 도구와 다른 도구가 허용되지 않습니다"라고 말하고 그 목록을 짧게 만들려고 시도합니다.

분명히, 프로그래머가 무엇을 해야하는지 결정하기 위해 무엇을 보는지는 중요하지 않으므로 인터넷 전체가 바로 그렇습니다. 팀이 손으로 작성된 것처럼 해당 도구의 출력 만 받아들이는 것을 신경 쓰지 않는 한 Magic (또는 랜덤 도구)에 의해 코드를 생성하는 경우도 중요하지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top