실제로 기술적 인 질문은 아니지만 소스 제어 및 모범 사례에 대한 몇 가지 다른 질문이 있습니다.
내가 일하는 회사 (익명으로 유지됨)는 네트워크 공유를 사용하여 소스 코드와 릴리스 된 코드를 호스팅합니다. 릴리스 여부와 버전 및 버전에 따라 소스 코드를 올바른 폴더로 수동으로 이동하는 것은 개발자 또는 관리자의 책임입니다. 파일 이름과 버전을 기록하는 위치와 변경된 사항에 대해 다양한 스프레드 시트가 점선으로 표시되어 있으며, 일부 팀은 각 파일의 맨 위에 다른 버전의 세부 정보도 표시합니다. 각 팀 (2-3 개 팀)은 회사 내에서 다르게 수행하는 것으로 보입니다. 당신이 상상할 수 있듯이, 그것은 “올바른 사람들”이 물건의 위치를 알고 있기 때문에 조직적인 혼란입니다. 모든 것이 다르기 때문에 혼란스럽고 한 번에 무엇을해야 하는지를 기억하는 사람들에 의존합니다.
한동안 일종의 관리되는 소스 제어를 시도했지만 회사 내에서 충분한 지원을받을 수없는 것 같습니다. 내 주요 주장은 다음과 같습니다
- 우리는 현재 취약합니다. 어떤 시점에서든 누군가 우리가해야하는 많은 릴리스 작업 중 하나를 잊어 버릴 수 있습니다. 이는 전체 버전이 올바르게 저장되지 않았 음을 의미 할 수 있습니다. 필요한 경우 버전을 다시 구성하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다.
- 버그 수정과 함께 새로운 기능을 개발하고 있으며 아직 일부 작업이 완료되지 않았기 때문에 릴리스 릴리스를 지연시켜야하는 경우가 종종 있습니다. 또한 버그 수정이 필요한 경우에도 고객이 새로운 기능이 포함 된 버전을 가져와야합니다. 실제로 우리가 작업중인 버전이 하나뿐이기 때문입니다.
- 여러 개발자가 같은 프로젝트를 동시에 사용하고 있기 때문에 Visual Studio에 문제가 있습니다 (동일한 파일은 아니지만 여전히 문제가 발생 함).
- 개발자는 15 명에 불과하지만 우리는 모두 다르게 행동합니다. 우리 모두가 따라야하는 표준 회사 차원의 접근 방식을 갖추는 것이 낫지 않습니까?
내 질문은 :
- 이 크기의 그룹에 소스 제어가없는 것이 정상입니까?
- 지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다.
위의 정보를 감안할 때 소스 제어를 구현 하지 않은 경우 어떤 이유를 제안 할 수 있습니까? - 무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유 가 있습니까?
나는 왜 내가 그렇게 많은 저항을 받았는지에 대한 느낌을 얻기 위해 주로 요청하고 있으므로 정직하게 대답하십시오.
가장 균형 잡힌 접근 방식을 취했으며 세 가지 질문에 모두 답변했다고 생각하는 사람에게 답변을 드리겠습니다.
미리 감사드립니다
답변
- 정상 이 아닐 수도 있지만 Treb가 말한 것처럼 아마도 비정상적이지 않을 것입니다.
-
다른 사람들이 말했듯이, 규모가 큰 회사에서 소스 제어를하지 않는 유효한 이유는 없습니다. 따라서 잘못된 이유 를 식별하고 공격해야합니다 .
a) 주된 현상 은 ” 현상이 깨지지 않으면 고치지 마십시오”라는 현상입니다. 이 방법은 어렵습니다. 작동하지 않고 작동하지 않는 모든 항목을 지적하기 시작하거나 ( ‘네거티브 사람’으로 빠르게 표시 될 수 있음) 폭발 할 때까지 기다릴 수 있습니다 ( 또는 잘못 될 수있는 모든 것을 강조 할 수 있습니다. 불행하게도 작은 회사를 담당하는 사람들은 실제로 때까지 ‘잘못 될 수있는 것들’비교적 불 침투성 있습니다 할 잘못 …
b) 무지 / 두려움 / 불확실성 : “우리는 실제로 소스 제어가 무엇인지 이해하지 못합니다. 사용 방법을 모릅니다. 어떤 도구를 선택해야할지 모르고, 우리의 스타일이 무너질 것입니다 . ” 이것이 내가 여기에 보내지 않을 이유 중 하나입니다.! 그것은 당신에게 꽤 큰 주문 일지 모르지만 너무 많은 변형이나 대안이 아닌 ‘턴키’솔루션을 제시해야 할 가능성을 극대화하려고 생각합니다. 주어진 도구로 작업하기 위해 작업 프로세스를 어떻게 맞추고 변형시키려는 지; 기존 코드를 백 포트하는 방법 / 방법; 얼마나 빨리 사용자를 ‘훈련’하고 실행할 수 있다고 생각하는지; 전환 기간을 관리하는 방법 (있는 경우); ‘비용’이 될 확률 (달러가 아닌 경우 몇 시간)
c) 다른 이유 (예를 들어, VSS에 대한 이전의 나쁜 경험 또는 지나치게 복잡한 도구에 대한 ‘공포 이야기’를 읽음)가있을 수 있지만 이러한 도구를 발견 할 때 개별적으로 배팅해야합니다.
-
다른 답변에 요약 된 소스 제어에 대한 충분한 이유가 있습니다 . 저의 조언은 귀사를 실질적으로 변화 시킬 수있는 2 번 또는 3 번 주를 골라 내고 다듬어 가능한 많은 동료들과의 회의에서 발표하는 것입니다. 토론을 자극하십시오. 즉각 설득하지 않더라도 고착 점에 대한 통찰력을 얻을 수 있습니다.
( 변경 기능 에 대해 읽었 습니까?)
답변
소스 제어없이 규모가 큰 그룹이 작동하는 것은 절대적으로 정상적이지 않습니다. 소스 제어없이 효과적으로 작동 할 수있는 가장 큰 프로그래머 그룹의 크기는 1보다 작거나 같습니다. 모든 규모 의 전문가 팀을 위해 버전을 제어하지 않고 작업하는 것은 절대적으로 용서할 수 없으며 창의력이 없지만 어쩌면 그것을 포기하고 싶은 이유를 찾을 수 없습니다.
버전 관리는 또 다른 도구, 특히 강력한 도구 이며 최소 비용에 비해 막대한 이점 을 제공 합니다. 브랜칭, 자동 병합, 태깅 등과 같은 기타 편리한 기능을 통해 모든 변경 사항을 체계적으로 관리 할 수 있습니다. 빈 버전 이전의 버전을 빌드해야하는 경우 해당 시점에서 코드를 확인하고 다른 후프를 거치지 않고도 빌드 할 수 있습니다 .
더 중요한 것은 버그 수정을 작성해야하는 경우 다른 지점에 있기 때문에 작업중인 새로운 기능을 제공하지 않고도 나머지 개발에 필요한 버그 수정을 업데이트에 병합 할 수 있다는 것입니다. 걱정하지 마십시오. 아직 존재하지 않습니다.
회사의 문화에 도전하고 있기 때문에 저항을 경험하고 있습니다. 당신이 무슨 말을하든 조정하는 데 시간이 걸립니다. 당신이 할 수있는 최선의 방법은 계속해서 추진하는 것입니다. 그리고 회사가 실제로 돈을 벌지 않는다면 개발자 수준에 더 적합한 다른 직업을 찾으십시오.
답변
이 크기의 그룹에 소스 제어가없는 것이 정상입니까?
내 경험상, 그것은 표준이 아니지만 여기의 다른 답변이 제안하는 것처럼 완전히 특이하지는 않습니다. 대부분의 소기업은 소스 제어를 사용하지만 불행히도 상당수는 그렇지 않습니다.
지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다. 위의 정보를 감안할 때 소스 제어를 구현하지 않은 경우 어떤 이유를 제안 할 수 있습니까?
좋은 토론을 위해 SO에 대한 이 질문을 참조하십시오 . 받아 들여진 대답은
“버전 관리를 사용하지 않는 좋은 이유는 없습니다.
무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유가 있습니까?
내가 만난 모든 개발자와 프로젝트 관리자 사이의 합의는 물론 프로그래머와 SO에 대한 소스 제어는 필수입니다. 허용되는 모범 사례 입니다. 누군가가 그것을 무시하기로 결정했다면, 이것이 왜 자신에게 올바른 결정인지에 대한 매우 강력하고 설득력있는 주장을 가져야합니다. 지금까지 제시 한 주장은 특정 문제에 중점을두고 있습니다. 아마도 ‘모두가하는 일’에 따라 더 넓은 접근법을 시도해야 할 것입니다. 왜 우리도 그렇지 않습니까?
답변
소스 제어는 단일 개발자 팀에게도 좋습니다. 모든 소스 제어 시스템은 기본적으로 변경 사항을 추적하는 버전 제어 시스템입니다. 일부 코드를 제거하고 코드가 필요하다고 생각하는 단일 개발자를 상상해보십시오. 그는 이전 코드를 다시 얻을 수 있습니까?
도움이되는 도구를 찾으십시오. 크기는 어디에나 중요하지 않습니다. 품질은 모든 곳에서 중요합니다.
답변
이미 버전 제어 시스템을 사용하고있는 것 같지만 그다지 좋지는 않습니다. 사람들은 이미 필요한 버전 관리를 인식하는 것 같습니다. 다음 버전 인 소프트웨어 버전 제어를 소개하면됩니다.
그것이 저라면, SCM을 그들이 이미하고있는 것의 개선 된 버전으로 소개 할 것입니다. 좋은 도구를 사용하면 이미 진행중인 많은 작업을 자동화하는 방법을 강조하겠습니다.
-
SCM 시스템은 스프레드 시트에서 변경 사항을 기록하는 대신 변경된 내용뿐만 아니라 누가 변경 한 이유와 이유를 추적합니다.
-
보너스로 코드 수명의 어느 시점으로 돌아가서 실제로 무엇이 있는지 확인할 수 있습니다.
-
다른 폴더에 서로 다른 코드 버전이 있고 변경 사항을 포트하기 위해 폴더간에 항목을 이동 / 병합해야하는 대신 모든 것을 동일한 위치에 보관할 수 있으며 도구가 병합을 수행하도록 할 수 있습니다.
다른 사람들이 이미 말했듯이, 나는 약간의 저항을 기대할 것이므로 시스템을 내가하고있는 것들에 사용하여 프로토 타입을 만들 것입니다.
(BTW, 실제로 이력서 및 기타 문서를 SVN 아래에 두었습니다. 다시 구성 및 통합 관리자의 역할을 여러 번 수행했습니다.)
답변
지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다.
위의 정보를 감안할 때 소스 제어를 구현 하지 않은 경우 어떤 이유를 제안 할 수 있습니까?
-
개발중인 제품은 버전 관리 시스템입니다. 관리자는 기존 제품이 새 제품의 설계 및 구현에 영향을 미치는 것을 방지하는 데 관심이 있습니다.
-
BASE 점프의 주말과 황소와 함께 달리는 스릴을 찾는 관리자는 모든 것이 아직 지옥에 빠졌는지 궁금해하는 운전을 즐깁니다.
-
적대적 인계를 피하십시오. 이런 방식으로 관리되는 소프트웨어 개발 복장을 누가 구매하고 싶습니까?
무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유가 있습니까?
-
이미 버전 제어를 수행하고 있지만 현재는 가장 효율적이고 노동 집약적이며 오류가 발생하기 쉬운 방식으로 수행하고 있습니다. VCS를 사용하면 비용을 절약하고 시간을 절약하며 품질을 향상시킬 수 있습니다.
-
디스크 공간을 절약합니다. 대부분의 버전 제어 시스템은 파일 간의 델타 만 저장합니다. 현재 모든 파일의 모든 버전의 전체 사본을 저장하고 있습니다. (모든 사본을 백업하려면 많은 시간과 공간이 필요합니다!)
-
여러 개발자가 같은 파일에서 동시에 작업하고 너무 많은 문제없이 차이점을 조정할 수 있습니다. VCS없이 변경 사항을 병합하는 것은 물론 가능하지만, 누가 언제, 왜, 왜 변경했는지 추적하는 것은 거의 불가능합니다.
-
개발자는 언제든지 모든 버전을 복구 할 수 있다는 것을 알고 새로운 아이디어를 자유롭게 시도 할 수 있습니다.
-
프로세스가 향상되면 재능있는 개발자를 쉽게 고용하고 유지할 수 있습니다.
답변
이 크기의 그룹에 소스 제어가없는 것이 정상입니까?
아닙니다. 현재 회사에서 시작했을 때 변경 한 코드를 보내야 할 사람이 한 명 있었는데이를 병합했습니다. SVN을 사용하도록 며칠 내에 모든 사람을 설득 할 수있었습니다 .
지금까지 소스 제어가없는 모호한 이유에 대해서만 설명했습니다. 위의 정보를 감안할 때 소스 제어를 구현하지 않은 경우 어떤 이유를 제안 할 수 있습니까?
모호한 이유 만 들었던 이유는 버전 관리를 사용하지 않는 유효한 이유가 없기 때문이라고 생각합니다.
무기고에 추가 할 수있는 소스 제어에 대한 더 이상의 이유가 있습니까?
예, 많은 이유가 있습니다.
- 분기는 다른 개발을 방해하지 않고 새로운 기능을 개발할 수있는 가능성을 제공합니다.
- 각 커밋은 정확히 변경된 사항, 변경 한 사람 및 변경시기에 대한 정보를 제공합니다.
- 버그 수정을 쉽게 커밋하고 고객에게 배포하고 완료되지 않은 새로운 기능을 생략 할 수 있습니다.
- 고객이 최신 버전으로 이동하는 것을 두려워하는 경우 다른 버전을 유지할 수 있습니다.
- 동일한 프로젝트 (같은 소스 파일까지도)에서 쉽게 작업 할 수 있습니다.
- 커밋 된 실수 후 변경 사항을 유지하여 실수를 쉽게 되돌릴 수 있습니다.