업데이트
나는 4 명의 작은 개발자 팀에서 일하고 있습니다. 그들은 모두 소스 컨트롤을 사용했습니다. 대부분은 소스 제어를 견딜 수 없으며 대신 사용하지 않도록 선택합니다. 저는 소스 컨트롤이 전문 개발의 필수 부분이라고 믿습니다. 몇 가지 문제로 인해 소스 제어를 사용하도록 설득하기가 매우 어렵습니다.
- 이 팀은 TFS 사용에 익숙하지 않습니다 . 나는 두 번의 훈련 시간을 가졌지 만 1 시간 밖에 할당되지 않아서 충분하지 않았다.
- 팀 구성원은 서버에서 코드를 직접 수정합니다. 이렇게하면 코드가 동기화되지 않습니다. 최신 코드로 작업하고 있는지 확인하기 위해 비교가 필요합니다. 복잡한 병합 문제가 발생합니다
- 개발자가 제공 한 시간 추정치는 이러한 문제를 해결하는 데 필요한 시간을 제외합니다. 따라서, 내가 nono라고 말하면 10 배 더 오래 걸릴 것입니다 …이 문제를 지속적으로 설명하고 위험을 감수해야합니다. 이제 경영진이 나를 “느린”것으로 인식 할 수 있기 때문입니다.
- 서버의 실제 파일은 ~ 100 개의 파일에서 알 수없는 방식으로 다릅니다. 병합에는 현재 프로젝트에 대한 지식이 필요하므로 개발자가 얻을 수없는 개발자 협력이 필요합니다.
- 다른 프로젝트가 동기화되지 않습니다. 개발자는 소스 제어에 대한 불신을 계속 유지하므로 소스 제어를 사용하지 않음으로써 문제를 복잡하게 만듭니다.
- 개발자들은 병합이 오류가 발생하기 어렵고 소스 제어를 사용하는 것이 낭비라고 주장합니다. 소스 제어가 잘못 잘못 사용되고 소스 제어가 계속 우회 될 때 오류가 발생하기 쉽기 때문에 이는 논란의 여지가 없습니다. 그러므로 그 증거는 그들의 견해에서 “자체를 말한다”.
- 개발자는 TFS를 무시하고 서버 코드를 직접 수정하면 시간이 절약된다고 주장합니다. 이것 또한 논쟁하기 어렵다. 병합 코드 동기화하는 데 필요한 때문에 시작하는 시간이 소요입니다. 우리가 관리하는 10 개 이상의 프로젝트에 이것을 곱하십시오.
- 영구 파일은 종종 웹 프로젝트와 동일한 디렉토리에 저장됩니다. 따라서 게시 (전체 게시)는 소스 제어에없는 파일을 지 웁니다. 또한 소스 제어에 대한 불신을 유발합니다. “게시하면 프로젝트가 중단됩니다”. 이 위치를 수정하면 (저장된 파일을 솔루션 하위 폴더에서 제거)이 위치가 web.config에 설정되어 있지 않고 여러 코드 포인트에 존재하기 때문에 디버깅하는 데 많은 시간과 시간이 걸립니다.
따라서 문화는 계속 유지됩니다. 나쁜 습관은 더 나쁜 습관을 낳습니다. 나쁜 솔루션은 새로운 핵을 만들어 훨씬 더 깊고 시간이 많이 걸리는 문제를 “수정”합니다. 서버, 하드 드라이브 공간은 오기 어렵습니다. 그러나 사용자의 기대치는 높아지고 있습니다.
이 상황에서 무엇을 할 수 있습니까?
답변
그것은 훈련 문제가 아니라 인적 요소 문제입니다. 그들은 원하지 않고 도로 블록을 만들고 있습니다. 부서진 집단의 역학을 다루는 것은 그들의 반대의 근본 원인 인 것입니다. 일반적으로 두려움은 변화에 대한 두려움 일뿐 아니라 더 사악한 것입니다.
오늘날 또는 지난 20 년 동안 전문 개발자는 소스 제어에 저항하지 않았습니다. 약 30 년 또는 40 년 전, 컴퓨터가 느리고 소스 제어가 느리고 프로그램이 하나의 500 줄 파일로 구성되어 있었을 때 고통스럽고 사용하지 않는 정당한 이유가있었습니다. 이 반대는 내가 생각할 수있는 최악의 카우보이에게서 나올 수 있습니다.
어떤 식 으로든 그들의 삶이 어려워 지도록 시스템이 강제되어 있습니까? 내용을 확인하고 이의를 무효화하도록 시스템을 변경하십시오. 끝날 때까지 반복하십시오.
GIT 또는 Mercurial을 살펴볼 것을 제안합니다. 각 소스 코드 트리에 리포지토리를 만들 수 있으며, 지금도 눈치 채지 못하고 해킹을 계속할 수 있습니다. 코드베이스에 해킹 한 변경 사항을 추적하고 커밋하고 다른 소스 트리에 병합하는 등의 작업을 수행 할 수 있습니다. 몇 초 동안 다른 제품에 몇 주 간의 노력을 기울이면 아이디어가 바뀔 수 있습니다. 하나의 명령으로 나사 업 중 하나를 롤백하고 엉덩이를 저장하면 감사 할 수도 있습니다 (믿지 마십시오). 최악의 경우, 당신은 상사 앞에서 좋아 보이고 보너스로 그들이 카우보이처럼 보이게합니다.
합병은 프로젝트에 대한 훌륭한 지식뿐만 아니라
이 경우, 당신이 노를 쓰지 않고 잠정적 인 개울에 올라가는 것이 두렵습니다. 병합이 옵션이 아닌 경우 옵션도 구현하지 않으므로 한 지점에 이미있는 기능 (느슨하게 사용 된 용어)을 다른 지점에 더 이상 추가 할 수 없습니다.
내가 너라면 내 직업 전망을 재고 할 것이다 …
답변
때로는 실제 문제로 인해 사용하기가 불가능한 경우가 있습니다.
그릇된.
팀이 소스 제어를 사용하는 데 익숙하지 않으면 훈련 문제가 발생할 수 있습니다
그것은 소스 코드 제어와 관련이 없으며 교육과 관련이 있습니다. 교육은 쉽고 저렴하며 효율적이며 몇 시간 안에 완료됩니다. 소스 코드 제어를 사용하지 못하는 것은 비용이 많이 들고 위험하며 비효율적이며 문제는 영원히 지속 됩니다 .
팀원이 서버의 코드를 직접 수정하면 다양한 문제가 발생할 수 있습니다.
이것이 훈련 문제입니다. 다시. 소스 코드 제어와 관련이 없으며 교육과 관련이 있습니다.
개발자는 소스 제어에 대한 불신을 계속하여 소스 제어를 사용하지 않음으로써 문제를 복잡하게합니다.
소스 코드 제어를 사용하는 방법에 대해 교육을 받아야합니다. 비용을 줄이고 위험을 줄이며 업무를 단순화하고 더 효율적입니다. 매 순간 배당금을 지불하는 일회성 투자입니다.
이런 상황에서 무엇을 할 수 있습니까?
소스 코드 제어를 사용하는 방법에 대한 모든 사람을 교육하십시오.
최신 정보
개발자는 소스 제어를 직접 수정하면 시간이 절약된다고 주장합니다.
그것들이 틀리기 때문에, 이것이 얼마나 잘못되었는지를 정확하게 나타 내기 위해 데이터를 수집하는 것이 중요합니다.
그러나 안타깝게도 경영진은 장기적으로 비용이 많이 드는 즉각적인 대응을 보상하는 것으로 보입니다.
이 보상 시스템을 극복하는 유일한 방법은
A) 장기 비용이 명백한 단기 가치보다 높다는 것을 식별하십시오 .
B) 단기적인 손상 (즉, 직접 변경)이 장기적인 올바른 소스 코드 제어보다 더 가치있는 것처럼 보이게하는 실제 보상을 식별하십시오. 누가 잘못된 일을해서 머리를 두드리는가? 그들은 머리에 어떤 종류의 팻을 얻습니까? 누가 그것을 제공합니까? 사물을 고치려면 잘못한 사물과 실제로 사람들을 격려하는 특정 관리자의 이름을 지정해야합니다.
C) 단기적인 빠른 대응 대신 장기적인 가치를 중시하는 수정 된 보상 시스템을 권장합니다. 다른 이유로 머리에 다른 pats.
D) 장기적인 가치에 대한 보상으로 사람들을 훈련시킨다. 단기 빠른 응답보다 분명히 큰 가치.
답변
소스 / 버전 제어 사용을 거부하는 개발자는 그렇게 간단하게 해고되어야합니다. 이미 지적했듯이, 사용하지 않을 때의 고유 한 위험과 비용은 많은 규모의 오버 헤드보다 더 큽니다. 이 문제에 반대하는 사람은 단순히 소프트웨어 개발에 관여해서는 안되며 그러한 사람들과 일하기를 거부 할 것입니다.
답변
먼저 소스 제어를 개발에 적용하기 위해 지속적인 통합 서버를 설정하여 문제를 해결했습니다. 둘째, 사람들이 소스 제어를 피하고 파일을 직접 수정하지 못하도록 폴더 액세스를 읽기 전용으로 잠급니다.
현지에서 버그를 재현 할 수없는 요일의 PITA이지만 CI 서버가 자동으로 개발자에게 푸시한다는 사실을 알고 작업, 체크인 및 이동이 더 좋습니다.
답변
당신의 고통이 들립니다. 나는 ‘소스 제어’가 네트워크 드라이브의 공유 폴더라는 것을 알기 위해 두 곳의 작업장으로 들어갔습니다. 문제는 일반적으로 접근 방식이 다른 방법보다 우수하다고 생각하기 때문에 발생하지 않으며 단순히 작동하며 소스 제어를 성공적으로 통합하는 워크 플로에 도입 된 적이 없습니다.
평평한 지구 팀 구조를 사용하면 위에서 아래로 밀어 넣는 것이 상황에 접근하는 가장 좋은 방법이 아닐 수 있다고 설명했습니다. 시도해 볼 가치가있는 방법 중 하나는 다른 개발자 중 한 명 또는 두 명으로부터 직접 구매하여 개념이 모멘텀을 모을 수 있도록하는 것입니다. 보드에 다른 개발자가 있으면 팀의 나머지 팀에게 배포하는 것이 훨씬 쉽습니다. 개념을 천천히 소개하고, 작은 프로젝트에서 작업을 시작 하거나, Git 에서 시작하고 , GitHub에서 호스팅되는 것을 분기한다고 말합니다 .
간단하게 시작하고 개념을 일상적인 워크 플로와 느리고 개별적으로 소개하십시오. 인간은 사물을 배우고 변화에 적응하는 데 능숙합니다. 특히 그러한 변화가 그들에게 직접적인 이익을 제공 할 때 (진화를 생각하십시오). 그러나 한 번에 많은 작은 변화가 나타나면 소외됩니다. 소스 제어의 작동 방식과 장점을 파악한 후에는 내부 프로젝트 중 하나에 통합을 시도해보십시오 (새 프로젝트를 시작하는 경우이 프로젝트를 소개하는 것은 사악한 시간입니다). 원하는 경우 다른 프로젝트가 기존 방식으로 작동하게하십시오. 이는 적절한 코드 제어의 장점을 강조하는 데 특히 효과적입니다.
실패하면 실행하십시오.
답변
당신은 분명히 당신의 상황을 식별하고 고칠 수있는 기술적 인 능력을 가지고 있으며, 당신의 문제는 인간적이고 프로세스와 관련이 있습니다.
사람들은 비전보다 모범에 훨씬 더 잘 반응하는 경향이 있으므로 직접 “고정”하는 것이 좋습니다.
최신 소스의 사본을 가져 와서 버전 관리에 적합하도록 재구성하고, 유용하고 미래 지향적 인 구조로 새 프로젝트를 만듭니다 (분기를 처리하는 방법, 타사 종속성을 배치하는 방법 등). 당신은 아마 당신 자신의 시간에 그렇게해야 할 것입니다.
그런 다음 동료와 관리자를 회의실로 끌어서 21 세기의 소프트웨어 개발 모습을 보여 주십시오. 현재 시스템의 고장을 설명하고 새로운 구조로 어떻게 제거되는지 보여줍니다.
당신은 또한 자신을 근원의 수호자로 설정해야합니다-당신이 걱정하는 유일한 사람 인 것처럼 보이기 때문에, 사람들을 (기술적 또는 심리적 수단으로 처분 할 수있는) 강제로 지키는 것은 당신에게 달려 있습니다. 계획. 있는지 확인 에만 고객에가는 일이 소스 제어에서 빌드 시스템에서왔다. 규칙을 어 기고 혼란을 일으키는 사람들을 의식적으로 굴욕하십시오. 도넛으로 뇌물을주세요.
그 모든 것이 너무 많은 노력으로 보인다면 (다른 모든 답변에서 언급했듯이) 다른 직업을 얻으십시오. 그들은 당신의 시간 가치가 없습니다.
답변
1 단계-무능한 관리자를 해고하십시오!
1 단계를 수행 할 수 없으면 관리자가 소스 제어에서 가져온 스크립트로만 배치하도록 배치를 제한하도록하십시오. prod에 대한 제작 권한이 없어야하는 개발자가 배포하려면 1 단계를 참조하십시오. 개발자는 소스 제어에서 가져와야합니다. 이를 통해 소스 컨트롤을 사용하지 않는 문제를 C # 코드뿐만 아니라 데이터베이스 항목에 처음 사용할 때 문제를 해결했습니다.