훌륭한 프로그래머가 버전 제어를 사용한 적이 없습니까? [닫은]

어려운 상황을 해결하는 데 도움이되는 전문 프로그래머를 찾고 있습니다.

지금까지의 인터뷰는 놀라 울 정도로 실망 스러웠다. 지금까지 가장 좋은 후보자는 버전 제어 소프트웨어를 사용한 적이없는 숙련 된 프로그래머입니다.

짧은 시간 안에 배울 수있는 문제이기 때문에 문제 자체는 그다지 심각하지 않을 수 있습니다.

그러나 더 걱정되는 부분이 있습니다.

버전 관리없이 10-15 년 동안 소프트웨어를 적극적으로 개발할 수 있습니까?

변경 추적 문제에 대한 해결책을 찾지 않는다는 사실 자체가 프로그래밍에 대한 잘못된 태도의 표시입니까?

소스 제어를 사용하지 않는 회사에서 약 11 년간 일했습니다. 우리는 (주로 변경 사항에 주석을 달고 날짜에 상관없이 복구 할 수있는 중앙 서버에 코드를 유지함으로써) 관리했습니다. 더 좋은 방법이 있는지 묻지 않았습니다. 즉, 전체 MSDN 라이브러리를 내 책상에 책 형태로 두었던 시절에도 마찬가지였습니다.

예, 인터넷 전에 프로그래밍이있었습니다.

나는 소스 제어에 얽매이지 않고 지금 업계에서 10 년 이상을 어떻게 보낼 수 있는지 고민하고 있습니다. 그러나 나는 약간의 동정심을 가질 것입니다. 나는 그것이 가능하다고 믿었고, 그 한 가지 세부 사항에 대한 후보 만 거부하지는 않을 것입니다. 후보자가 이것을 어떻게 관리했는지 조사하고 알아낼 것입니다.

또는 인터뷰 프로세스가 문제인지 여부에 대해 의문을 가질 수 있습니다. 그는 어떤면에서 가장 좋은 후보였습니까? 그가 올바른 질문을하지 않는 다른 현대 프로그래밍 기술이 있습니까? 내가 올바른 질문을한다면 다른 후보가 빛날 것입니까?

마지막으로, 우려 사항이있는 경우 모든 후보자를 거부하는 것을 두려워하지 마십시오. 다시 시작하는 데 시간이 걸리지 만 잘못된 사람을 고용하는 데 시간이 더 걸립니다.

나는 그것이 그의 태도에 달려 있다고 생각합니다. 그가 경험이 풍부한 프로그래머이고 좋은 프로그래머라면, 버전 관리 시스템을 빨리 선택할 수있을 것입니다. 그는 두 가지 방식으로 그것에 대해 이야기 할 수 있습니다.

• 좋은

  나는 버전 컨트롤을 사용해 본 적이 없지만, 배우게되어 매우 기쁩니다. 개발의 효율성을 높이는 데 도움이 될 것 같습니다. 프로젝트만으로 작업했기 때문에 많이 필요하지 않았습니다.

• 나쁜

  버전 관리는 업계에서 천천히 죽어가는 유행어입니다. 버전 관리 이상입니다.

20 년 이상 DOS와 Windows에서 소프트웨어 개발을 수행하는 데 대한 관점을 알려 드리겠습니다.

Windows / PC 세계의 버전 제어 소프트웨어는 90 년대 초반에 종종 신뢰할 수 없었습니다. VSS (Visual Sourcesafe)는 최고의 Windows 기반 제품에 관한 것이었지만 기발하고 많은 프로그래머가 싫어했습니다. 일부 팀은이 상황을 처리 한 후 사용을 즐겁게하지 않을 것입니다.

당시 대부분의 다른 VCS 옵션은 Windows를 기반으로하지 않았으므로 Windows 개발 팀에서는 거의 사용되지 않았습니다. 이들 중 일부는 고가의 솔루션이었으며 오픈 소스 솔루션은 오늘날처럼 쉽게 받아 들여지지 않았습니다.

많은 경우에, 90 년대 후반, 00 년대 초에 Windows 팀이 VSS를 사용하지 않았다면 사내 컨벤션 외에는 소스 제어를 위해 아무것도 사용하지 않았습니다. 많은 사람들이 Team Foundation Server (TFS)의 정교함과 git 및 SVN과 같은 훌륭한 무료 옵션에도 불구하고 여전히 VCS를 사용하지 않습니다.

소규모 Windows 개발 팀에서 수년간 일한 사람이 VCS를 사용하지 않았을 가능성이 있습니다. 나는 그것을 사용하지 않았거나 사용에 매우 우호적 인 곳에서 인터뷰 작업을하고 심지어 계약 작업을 수행했습니다.

따라서,이 분야에 대한 지원자의 경험 부족이 확실한 '아니오'라고 생각하지는 않지만 이전 경험에 대해 더 깊이 탐구하여 왜 이것이 경험에서 누락되었는지를 알고 싶을 것입니다. 또한 버전 관리에 대한 그들의 태도를 탐구하고 싶을 것입니다. 그들은 그것이 좋은 생각이라고 생각하지만 이전의 위치에서 그것을 추구하는 것이 허용되지 않았거나 시간 낭비라고 생각합니까?

버전 관리 소프트웨어없이 버전 관리를 할 수 없습니까? 그들이 어떻게 코드를 관리했는지 물어보십시오. 이미 자체 개발 한 시스템이있을 수 있습니다.

수동으로 작업하고 싶고 휠을 재창조하고 변화에 저항하는 것은 프로그래밍에 새로운 것이 아닙니다. Visual Source Safe 및 "전용"VSS를 사용하는 후보자에 대해 잠을 하시겠습니까?

재능을 찾으려고 할 때, 할 수없는 것과 할 수없는 것과 그렇지 않은 것의 차이를 알 수 있어야합니다 .

단일 개발자가 개발 한 소규모 프로젝트의 경우에도 버전 제어를 사용하지 않는다는 변명의 여지가 없습니다. 로컬 버전 제어를 설정하는 것은 사소한 일이 아니며 큰 이점이 있습니다. 잘 모르거나 경험이없는 개발자라면 알 수 없습니다.

버전 관리를 "참 신성"으로 인식하는 회사는 다음과 같이 소개하지 않습니다.

• SCCS는 1972 년에 출시되었습니다 ( 40 년 전 ).
• RCS는 1982 년에 출시되었으며 ( 30 년 전 ) 완전히 오픈 소스이며 무료입니다.
• CVS는 1990 년에 출시되었으며 ( 21 년 전 ), 완전히 오픈 소스이며 무료입니다.

버전 제어를 사용한 적이없는 프로그래머는 다른 프로그래머와 협력 한 적이 없습니다. 다른 자격 증명에 관계없이 그러한 프로그래머를 고용하는 것을 고려하지 않을 것입니다.

붉은 깃발처럼 보이지만, 왜 그것을 사용하지 않았는지 더 깊이 파헤쳐보십시오. 솔로 개발자는 특히 10 년 동안 버전 제어를 사용할 것으로 예상하지만 팀에서 일하면서 버전 관리를 시도하지 않은 경우보다 더 용서할 것입니다.

나는 버전 관리 경험의 부족에 대해 종교적이지 않을 것이다. 도구 일뿐입니다. 결국 svn 또는 git의 기본 사항을 하루나 이틀 안에 선택할 수 있습니다. 나머지는 시간이 지남에 따라 올 것이다. 그리고 소스 제어를 사용하는 환경에서 일할 경우 절반 정도의 후보자가 적합하지 않을 것이라고 믿을 수 없습니다.

소스 제어를 사용하는 것은 기술보다 습관입니다. 그것을 사용하지 않은 사람은 필요한 노력을 과장하고 얻은 이익을 과소 평가할 수 있습니다. 결국, 그는 지금까지 훌륭했습니다. 그가 실제로 소스 컨트롤을 사용한 후에야 그는 그것을 높이 평가할 것입니다.

당신이 물어봐야 할 질문은 소스 제어가 없을 때 어떻게 관리 했는가입니다. 이것은 그에 대한 정보와 그가 자신의 작업을 관리하는 방법을 알려줄 수 있습니다.

당신은 그의 경험에 대해 많은 정보를 남깁니다.

기본적으로 프로그래머가 버전 제어에 대해 알 필요없이 10-15 년의 경험을 가질 수 있다고 말할 수 있습니다. 10 년간의 코딩은 10 년 동안 새로운 프로그래밍 기술을 지속적으로 배우는 것과 같지 않습니다.

저는 아주 어리 며 코드를 다루고 싶지 않은 오래된 "경험이 풍부한"소프트웨어 엔지니어를 보았습니다. 즉, 그는 매우 재능이있을 수 있지만, 그가 아닌 정보는 작은 정보에서 추측 할 것입니다.

행운을 빕니다.

개인적으로 나에게 가장 놀라운 것은 후보자가 개념으로 버전 제어 시스템을 경험 한 적이 없거나 사용할 가치가 없다고 결정했다는 것입니다. 첫 번째 시나리오는 거의 없을 것 같지만, 그 경우에는 후보생이 경력 기간 동안 크게 격리되어 팀의 일원으로서의 가치에 대해 심각한 의문을 제기한다고 가정합니다. 특히, 그들은 어떤 일을하는 방법에 대해 매우 기괴한 개념을 할 수 있고 일을하는 "올바른"방법을 모른다.

그들이 버전 관리에 대해 적극적으로 결정한 두 번째 경우라면, 그들이 중요한 일을 한 적이 없거나 극도로 거만하다고 가정합니다. 또는 블록을 주석 처리하고 모든 코드 줄을 작성자, 날짜 및 버그 번호에 부여하는 것과 같은 코드를 유지하는 정말 끔찍한 방법이 있습니다.

나는 실제로 심판받는 사람을 고려하지 않은 다소 판단적인 답변을보고 있습니다.

저는 개인적으로 버전 관리 소프트웨어가 매우 귀중한 도구라는 것을 알고 있습니다. 그러나 우리는 모두 업무 환경에서 사용되는 도구와 프로세스에 대한 선택과 통제를 가지고 있지 않습니다. 저는 1990 년부터 Windows 개발 분야에서 일해 왔습니다. 다른 사람들이 게시 한 것처럼, 당시에는 Windows에서 VCS를 사용할 수 없었습니다. VCS를 얻기 위해 UNIX 서버를 가져 오지는 않았습니다. 저를 나쁜 프로그래머로 만들었습니까? 나중에 경력을 쌓기 위해 버전 관리가 도구가 아닌 수직 시장 상용 제품을 가진 회사에서 일했습니다. 저를 나쁜 프로그래머로 만들었습니까? 마지막 세 작업은 모두 VCS 도구에 크게 의존했습니다. 저를 좋은 프로그래머로 만드나요?

우리 모두가 최신의 가장 위대한 도구, 언어 및 기술 만 사용한다면 좋을 것입니다. 그러나 소프트웨어 개발 직업이 항상 그런 식으로 작동하는 것은 아닙니다. "사용하지 않으면 즉시 일을 그만두겠다"또는 "사용하지 않은 일을 절대로하지 않겠다 ..."또는 "사용하도록 강요 할 것"이라고 말하는 것이 이상적입니다. .. ". 우리 모두가 원하는대로 모든 것이 작동하는 무한한 일자리 기회에 둘러싸여있는 것은 아닙니다. 우리는 지불해야 할 청구서가 있고 일자리가 필요하기 때문에 우리 주변의 상황을 처리합니다.

결국, 당신의 질문에 대한 답은 이것입니다 :이 프로그래머를 그의 직무에서 담당하는 사람들이 내린 결정 (아마도 잘못된 결정)이 아니라 그의 기술, 그의 철학 및 그의 결정으로 판단하십시오.

나는 전문적으로 돈을 벌기 시작할 때까지 자신을 "프로그래머"라고 생각하지 않았다.

고객에게 더 많은 돈을 벌 수있는 시스템을 만드는 데 많은 돈을 벌었습니다. 내가 "좋은"개발자인지 아닌지는 주관적입니다.

웹 개발을 위해 일반적으로 고객을 기쁘게하는 GSD (Get Something Done)를 신속하게 수행 할 수 있습니다. 장면 뒤의 추악한 코드, 주석 부족 등을 보지 못할 수 있습니다.

나는 Git을 사용하지 않았고 올해까지 Github 프로파일을 가지고 있지 않았다. 나는 현대 프로그래머 표준의 관점에서 "시간 뒤"라고 느끼고있다. 또한 과거에 PHP, Flash 및 iOS 만 수행 한 후 Rails 및 Django 프로젝트를 시작했습니다. 나는 클라이언트와 저를 위해 사이트를 개발하는 계약을 체결 한 이래로 30 세와 프로그래밍을 통해 몇 년 동안 새로운 것을 배우는 것이 너무 고통스럽지 않았습니다.

현대 사회에서 너무 많은 것은 존스를 따라 가고 다른 사람들의 생각을 돌보는 데 중점을 둡니다. 이러한 족쇄를 풀고 소프트웨어 개발에 필요한 것 (시장 출시 속도 / 시간, 최적화 된 리소스 관리, 잘 문서화 된 코드, 확장 성 등)을 고려할 수 있다면 누군가 Mercurial, SVN을 아는 것보다 훨씬 중요 할 수 있습니다 , Git 또는 기타 버전 관리 시스템.

저는 개발자 후보에게 자신의 열정, 자신의 의견에 따라 가장 멋진 시스템이 무엇인지, 그리고 자신의 기술을 개발하는 데 자유 시간을 보내는 것에 대해 질문하고 싶습니다. 사람들이 자신의 시간에 기술을 발전시키지 못하면, 다른 것들보다 더 무서워하지만 그것이 당신을 놀라게하는 것은 아닙니다.

나는 당신이 여기 사람들로부터 이미이 질문에 대한 훌륭한 답변을 가지고 있다고 생각합니다.

소프트웨어 전문가가 소스 컨트롤을 사용한 적이 없다는 것이 놀랍습니다. 저는 그를 고용하는 것에 대해 매우 긴장했습니다.

그는 어떤 경험을 가지고 있습니까. 나는 당신이 지금까지 발견하지 못했다는 것을 그가 모르는 것이 무엇인지 궁금합니다.

소프트웨어 개발 경험은 무엇입니까? 아키텍처, 디자인 패턴, 일반적인 소프트웨어 개발 문제, 시스템 성능 질문, 시스템 보안 질문 등에 대해 물어볼 수 있습니까?

그가 이런 종류의 것들에 대해 강하게 나왔다면 아마도 소스 컨트롤 지식의 부족을 간과 할 수있을 것 입니다.

훌륭한 프로그래머가 버전 제어를 사용한 적이 없습니까?

예. 자체 학습 프로그래머가있는 많은 소규모 회사에서는 사용하지 않습니다.

버전 관리없이 10-15 년 동안 소프트웨어를 적극적으로 개발할 수 있습니까?

나는 개인적으로 2 개의 소규모 회사에 버전 제어를 도입하고 1 개의 중소 기업을 신에서 끔찍한 것에서 SVN (당시 최고의 옵션)으로 업그레이드했으며 일부 VC 만있는 다른 소규모 회사에서 근무했으며 코드에 대한 자체 VC 솔루션을 작성했으며 VC에는없는 많은 코드가 있습니다.

변경 추적 문제에 대한 해결책을 찾지 않는다는 사실 자체가 프로그래밍에 대한 잘못된 태도의 표시입니까?

글쎄, 그것은 즉각적인 실패는 아니지만, 나는 많은 후속 질문을 확실히 할 것입니다. 같은 것들:

VC 소프트웨어를 사용해 본 적이 있습니까? 뭐? 어떻게 생각해? 사용하지 않을 이유가 있습니까? 코드를 관리하기 위해 무엇을 사용 했습니까? 같은 코드 기반에서 다른 사람과 함께 일한 적이 있으며 충돌을 피하기 위해 어떤 방법을 사용 했습니까?

Explosion Pills에 동의하고 싶습니다 (그러나 담당자가 너무 낮습니다. atm ...) ... 태도가 훨씬 더 중요합니다.

프로그래밍 우수성을 위해 믿어야 할 몇 가지 사항이 있습니다.

1. 통신
2. 창의성
3. 동정심 (무엇을 말합니까?)

그리고 종종 작은 OCD 이상입니다.

당신은 유형을 알고 있습니다 ... 문제를 망치고 거기에 앉아있는 사람들은 옵션을 탐색 할 때 코드에서 완전히 잃어 버립니다. 이들은 진행하면서 메모를하고 코드에 주석을 달아 자신의 논리적 경로를 이해하고 자신이나 미래의 코드를 다루어야 할 다른 프로그래머를위한 길을 밝히는 사람들입니다. .. 따라서 위의 목록에서 "연민"!)하고 복잡한 아이디어를 신속하고 명확하게 의사 결정자에게 신속하게 전달하여 문제를 효율적으로 해결할 수 있습니다.

VCS에 대한 아이디어를 사지 않았거나 VCS (la VSS)에 대한 나쁜 경험이있어 새로운 시스템을 시험해보기에는 수줍음이었던 환경에서 수년간 훌륭한 프로그래머가 갇혀 있었을 것입니다. 이러한 상황에서 뛰어난 프로그래머는 여전히 몇 가지 나쁜 설계 반복으로 모든 작업을 잃지 않도록 보호하기 위해 일종의 루틴을 설정했을 것입니다.

따라서 VCS 는 결코 필요 하지 않다고 주장하는 프로그래머 나 피할 수없는 실수로부터 보호 조치 를 취해야하는 프로그래머 입니다. 그들의 태도는 "글쎄, 나는 그것을 지었고, 따라서 틀릴 수는 없다." VCS의 강점을 인식하는 법을 배울 수 있기 때문에 실제로 아는 사람이 거의 없다는 사실을 알기 때문에 대학 밖에서 가장 많은 경험을 가진 사람들보다 내가 두려워하는 사람들입니다.

버전 관리없이 10-15 년 동안 소프트웨어를 적극적으로 개발할 수 있습니까?

소규모 프로젝트를 한 사람이 관리하는 구식 학교 팀에서 온 경우 매우 가능합니다. 그는 자신을 배우고 개선하지 않고 동일한 기술 세트에서 10 년의 경험을 가지고있을 수 있습니다.

변경 추적 문제에 대한 해결책을 찾지 않는다는 사실 자체가 프로그래밍에 대한 잘못된 태도의 표시입니까?

후보자가 팀 개발 환경 (최소한 4 명 이상의 프로그래머) 환경에 있다면 사소한 문제입니다. 그러나 프로그래머간에 작업 부서가있을 수 있으며, 그들에게만 할당 된 모듈에서 작업하여 코드를 소스 제어 할 필요성을 줄일 수 있습니다.

그러나 인터넷 시대의 소스 제어 에 대해 듣지 못하는 것은 정말 놀라운 상황입니다. 따라서 나는 새로운 것을 배우고 자하는 의지 (개발 환경을 고려)와 그가 역동적 인 작업 환경에 얼마나 개방되어 있는지 살펴볼 것입니다.

중요한 경험이 있고 소스 제어 도구를 사용하는 메커니즘을 매우 빠르게 배울 수 있습니다. 그러나 당신은 적기를 볼 권리가 있습니다.

• 지원자가 직업 및 트렌드와 분리되어 있습니까?
• 팀에서 일하는 다른 많은 측면도 배워야합니까?

나에게 버전 관리에 관한 문제는 질병보다 더 많은 증상입니다. 원인이 다를 수 있으며 매우 양성일 수 있습니다. 많은 임시 프로그래머들이 프로그래밍에 관한 몇 권의 책으로 시작하여 자신이 생각한대로 행동하기 시작했으며 소프트웨어 개발에 대한 체계적인 연구를하지 않았습니다. 때때로, 과거에는 컴퓨터 과학 전공이 모든 프로젝트가 개별 프로젝트 였고 소프트웨어 프로세스가 미숙 한 회사에 갔기 때문에 소스 제어 시스템을 사용하지 않고 졸업했을 때가있었습니다.

그러나 그는 그곳에 도착했는데, 그가 10 년 이상 고독한 늑대 였다면 사람들과 함께 사는 것이 어려워 질 수 있습니다.

응시자에게 몇 가지 추가 질문이 있는지 물어볼 가치가 있습니다.

• 팀의 일원으로 일한 시간에 대해 알려주세요.
• 작업 한 팀이 팀 구성원간에 충돌을 일으킨 시간에 대해 알려주세요.
• 다른 개발자로부터 코드를 받아 프로젝트를 진행 한 시간에 대해 알려주세요.
• 코드를 만들 때 당신과 다른 팀원들이 어떻게 서로를 막았는지 알려주세요.
• 고객이 작동하던 기능과 관련된 문제를보고했지만 이후 버전에서는 작동하지 않았다고 알려주십시오. 어떻게 해결 했습니까?
• 팀에서 일하면서 어떤 점이 마음에 드십니까?

또한 자신의 방법, 프로세스를 거의 완벽하게 제어하고 자신이 유일한 소프트웨어 전문가 역할을 수행하는 데 익숙 할 수 있습니다. 새로운 방식으로 일할 수있는 사람을 원할 것입니다. 추가 질문:

• 코딩 표준을 작성하거나 사용하는 데 도움이 된 시간에 대해 알려주십시오.
• 코딩 표준에서 어떤 종류의 것들을보고 싶습니까?
• 다른 사람의 코드를 다시 작성하는 것에 대해 어떻게 생각하십니까?
• 소프트웨어 또는 문서의 동료 검토에 참여한 시간에 대해 알려주십시오.
• 서면으로 작성한 소프트웨어 개발 제안 또는 계약에 대해 말씀해 주시겠습니까?
• 좋아하는 소프트웨어 관리자 또는 감독자에 대해 알려주십시오.
• 가장 좋아하는 동료 또는 부하 직원에 대해 알려주십시오.

2012 년에 15 년의 업계 경험을 가진 사람에게 결코 버전 관리를 사용하지 않은 사람은 적기입니다. 1982 년, 심지어 1992 년이되었을 때 그것은 적지 않을 수 있습니다. 그러나 오늘날, 그 개발자의 배경에서이 수수께끼의 격차에 대한 훌륭한 설명이있었습니다.

특별한 상황에는 특별한 설명이 필요합니다.

이것은 15 년 동안 자동차를 수리 해 왔다고 주장하는 자동차 정비공과 다소 비슷하지만, 결코 그리스를 바르지 않습니다.

물론, 그리스로 몸을 문지르면 변속기가 해결되지 않으며 수리 설명서의 단계 중 어느 것도 그러한 것을 요구하지는 않지만 요점이 아닙니다. 요점은 삐걱 거리는 청소가 자동차 정비공이 실제로 작동하는 모습과 크게 일치하지 않는다는 것입니다. 그 일에서, 당신은 자신에게 기름칠을합니다.

버전 관리 경험이 없다고 인정한 경험이있는 사람을 인터뷰하는 경우, 아마도 자신의 경험 중 일부를 과장하거나 조작하고있을 것입니다 (버전 관리가 널리 사용되고 중요하며 자신이 거짓말해야 할 내용인지조차 모릅니다)! )

인터뷰에서 모든 종류의 조커를 볼 수 있습니다. 링크 된 목록의 다이어그램을 그리거나 링크 된 목록의 머리에 노드를 삽입하는 함수를 작성할 수없는 사람들을 보았습니다. 그러나 그들은 20 년의 근무 경험을 주장했다.

컴퓨터 과학의 새로운 졸업생조차도 아직 광범위하게 사용하지 않더라도 버전 제어에 수동적 인 친숙 함을 기대할 수 있습니다 .

경험이 많은 프로그램이 전용 소스 제어를 사용한 적이 없다는 것은 이상하지는 않지만 불가능하지는 않습니다. 내가 함께 일한 한 회사에서 그들은 전통적인 C # 및 VB 코드에 광범위하게 소스 제어를 사용했습니다. 그러나 순수한 데이터베이스 코드 (저장 프로 시저 및 스크립트와 테이블 정의)는 순수한 데이터베이스 코드를 작성, 유지 관리 및 실행하는 주요 전문 SQL 개발자 두 명에도 불구하고 소스 제어에 포함되지 않았습니다. 나는 데이터베이스 엔터티에 대한 소스 제어를지지했으며 부분적으로 만 성공했습니다.

다른 회사에서는 개발 팀이 작았습니다 (한 사람이 오랫동안 쇼핑 한 다음 두 사람). 이전 개발자의 소스 컨트롤에는 끝에 날짜가 추가 된 소스 파일의 여러 복사본이있었습니다. 더 나은 소스 제어 시스템이없는 것 외에도 제 전임자에게는 유능하고 똑똑한 사람이있었습니다.

내가 전문가가되기 전에는 취미가되었고 소스 컨트롤을 전혀 사용하지 않았으며, 그것이 무엇인지 모호하게 알지 못했습니다.

요컨대, 전문가가 그것에 익숙하지 않은 것이 이상하다고 생각하지만, 특히 소규모 팀에 익숙한 경우 전문가 없이는 유능한 사람이 될 수 있습니다. 고용하면서 나는 그에게 반대하지 않았습니다. 나는 그를 상대로 직장에서 배우고 그것을 사용하기 시작하는 것을 절대적으로 꺼릴 것입니다 ...

내 자신의 2c는 VC에 대한 질문에 그가 어떻게 반응했는지에 달려 있다는 것입니다. 가능한 반응은 다음과 같습니다.

1. 응? 그게 뭐야
2. 아니 우리는 대신했다
3. 당황스러운 셔플 없음 , 경영진은 우리를 허용하지 않습니다
4. 어떤 당황 셔플 ,하지만 난 조금 나 자신을 조사하지 않고 우리가 일을해야 뭔가처럼 보였다 생각했다.

4의 경우, 그 사람은 나에게서 패스를 얻을 것이고, 그는 올바른 태도를 가지고 아마도 그것을 잘 선택할 것입니다. 3의 경우, 그는 수행해야하지만 4만큼 많은 크레딧이 아니라는 것을 이해 한 것에 대한 신용을 얻습니다. VC에 대한 몇 가지 사실을 말할 수 있다면 (VC 패키지 중 일부를 나열하십시오) d 그것을 호기심의 증거로 받아 들여 그를 통과시킬 수 있습니다.

그가 1 또는 2로 대답했다면, 즉 그가 VC에 대해 알고 알지 못했을 경우, 나는 후보자의 판단에 진지하게 질문 할 것입니다. 그가 작업해야 할 다른 도구 (버그 추적, 품질 측정 항목, 빌드 자동화 등)가있을 것이며, 그가 새로운 시도를 시작하지 않으면 이러한 모든 문제에 대해 오르막 전투를 벌이게 될 것입니다 구혼.

여기에있는 대부분의 사람들처럼, 나는 그들의 고용주가 속도를 늦 췄기 때문에 후보자를 불이익을주는 것은 불공평하다고 생각합니다. 나를 위해, 그것은 모두 그들이 어떻게 반응했는지에 달려 있습니다.

되돌아 볼 때 변경된 내용을 작성하는 것이 좋습니다. 내가 잘못한 것을 파악하고 많은 문제가 신속하게 해결되어 많은 시간을 절약했습니다. 제 생각에는 통나무를 보관하는 것이 좋습니다. 특히 자신보다 더 많은 사람들과 프로그래밍하는 경우.

웹앱을 작성하는 경우 지속적으로 새로운 것을 추가하기 때문에 버전 관리없이 기능을 계속 추가 할 수 있습니다. 그러나 새로운 내용이 담긴 로그 나 뉴스 게시물을 작성할 수 있습니다.

그것은 당신이 프로그래밍하는 것에 관한 것입니다.

소프트웨어 승인 절차가 12 개월에서 18 개월이었던 곳에서 근무했습니다. 승인 된 소프트웨어 목록에없는 경우 시스템에서 소프트웨어를 가져올 수있는 방법이 없습니다. CD / DVD 드라이브가 잠겨 있고 컴퓨터가 인터넷에 연결되지 않았습니다.

솔루션을 소스 제어에 사용한 첫 번째 장소는 개발자가 다년간 프로젝트를 테스트 할 준비가되었을 때 자체적으로 작성하도록하는 것이 었습니다. 그들은 처음부터 그것을 작성하는 것이 승인 과정보다 빠르다고 도박했다.

이 문제에 부딪친 2 위는 처음 몇 달 동안 소스 제어를 사용했지만 고객은 모든 개발을 내부 네트워크에서 수행하기를 원했습니다. 그들은 다시 모든 것을 잠갔으므로 많은 압축 폴더로 돌아갔습니다.

이러한 조건에서만 일한 개발자를 알고 있습니다. 그들은이 도구들을 사용하기를 원하지만이 도구들을 사용하고 싶지만이 도구들을 사용할 수는 없습니다.

왜 그것들을 사용하지 않았는지 조사하십시오. 경험이 없기 때문에 절차를 이해하지 못하는 것은 도구를 거부하는 것과 크게 다릅니다.

지난 15 년간 개발 중입니다. 버전 관리를 몇 번만 사용했습니다. 여전히 자체 개발 한 스크립트 및 프로그램을 사용하여 모든 개발 폴더를 증분 백업합니다. 어떻게해야할지 모르겠습니다. 누군가 버전 관리를 사용하는지 묻습니다. 나는 버전 제어 시스템이 필요하지 않았으며 항상 작은 프로젝트를 수행했습니다. 나는 내가 최고의 프로그래머는 아니지만 내가 최악이 아니라는 것을 확신한다. 대부분의 경우 사람들에게 버전 관리 시스템을 정기적으로 사용하지 않는다고 말하는데 당황 스럽지만 그것이 바로 그 방법입니다.

IBM MVS 시스템에서 프로그래머로서의 경험으로 말하면, 근무 경력의 처음 10 년 동안 필자가 작업 한 운영 체제에는 프로그래머가 사용할 수있는 버전 화 가능한 파일 유형이 정확히 하나 있습니다. 세대 데이터 세트입니다. 이것은 본질적으로 고정 된 버전의 파일이며, 어떤 버전이 무엇인지 기억해야했습니다. 최신 버전 제어에는 거의 쓸모가 없습니다. 실제 디렉토리가 없거나 거의 (8 자) 한정자가없는 파일 시스템과 함께 소스 코드 관리 시스템의 개념은 해당 환경에서 일하는 모든 사람에게 완전히 이질적이었습니다.

SunOS 3으로 이동하여 RCS를 사용할 때까지 실제로 소스 코드 제어 시스템을 보지 못했습니다. 그 시점에서 저는 매우 손쉬운 IBM 시스템 프로그래머 였고 생산성이 높았으며 업무에 능숙했습니다. 모든 버전 관리는 백업을 테이프에 복사하고 현재 위치를 기록하여 처리되었습니다.

이 시점에서 여전히 메인 프레임 작업을하고 있다면 공식적인 버전 관리 시스템에 노출 된 적이 없었을 것입니다. 구체적으로 지원되는 대안은 ClearCase 및 Rational이며, 둘 다 무료가 아니며 실제로는 상당히 비쌉니다.

따라서 누군가가 버전 관리를 사용한 적이 없기 때문에 정의 상으로는 무능하다고 말하는 것은 의심의 여지가 있습니다. 자세히 조사하고 자세히 살펴볼 필요가 있습니다. Linux / Unix / Mac OS 개발자라고 주장하지만 버전 제어를 사용한 적이없는 경우에는 덜 익숙하며 전반적인 경험이 귀하가 기꺼이 만족할만한 수준인지 판단해야합니다. 현대 소프트웨어 공학을 훈련 시키십시오. 이들이 메인 스쿨 프로그래머이고 그것이 필요한 것이라면, 원하는 프로그래밍 기술을 정확하게 갖추 었는지에 집중하고,이를 가르쳐야한다는 사실에 자신을 사임하십시오. 다른 사람들이 말했듯이, 그 개념에 대한 그들의 반응은 그 경우 결정 요인이 될 것입니다.

예뻐요! 우리 사회 전체는 괴짜 행 아웃과 해키 이벤트가 너무 많은 고도로 발달 된 사회 공동체에 살지 않습니다. 우리 모두 소프트웨어 개발 회사에서 일하지 않으며 우리 중 일부는 관련이 있거나 최신의 게시 된 자료를 찾을 수도 없습니다. 우리의 모국어로 인쇄 또는 온라인으로 육체에서 동료 프로그래머를 만날 수 있습니다.

내가 알 수 있듯이, 만약 당신이 말한 것처럼 경험이 풍부한 소프트웨어 개발자라면, 그는 소규모 기업의 프리랜서로 일하는 외로운 늑대 일 것입니다.

버전 관리를 사용하지 않는 데는 몇 가지 이유가 있습니다.

1. 주요 비즈니스 라인으로 소프트웨어 개발을하지 않는 회사에서 일합니다.
2. 또는 개발자가 다른 시스템을 사용하기로 결정한 경우 숙련 된 시스템에만 유효합니다.
3. 또는 개발자가 각 시스템의 작동 방식을 아직 배우지 못한 경우
4. 또는 익숙하지 않은 도구에 대한 태도 문제

그러나 다음과 같은 가정을하는 사람들을 만날 때는주의해야합니다.

1. 무언가를하는 유일한 방법이 있다는 것
2. 또는 모든 프로그래머가 수행하는 방식과 동일하게 수행해야합니다.
3. 또는 사람들이 사용하는 관행이 변경하기 쉽다는

가난한 프로그래머가 버전 관리 전문가가 될 수있는 한 가능합니다. 내 요점은, 당신의 프로그래밍 기술이나 문제 해결 능력에 대한 버전 관리가 무엇인지 모른다는 것입니다. 경험의 문제입니다. 많은 소규모 상점은 그것을 사용하지 않거나 스스로를 위해 그것을 알아 내기 위해 그것을 자주 사용하지 않는 부주의 자에게 맡깁니다.

나는 그것이 너무 많은의 문제가 아니라 생각하는 방법이 적극적으로 소프트웨어를 개발할 수있다 ""그것은 가능 적극적으로 적 버전 제어를 필요로?없이 10~15년을위한 소프트웨어를 개발하는 방법 "하지만 마지막 적없이 10~15년 버전 관리가 필요하십니까? "

버전 제어 없이도 프로그래밍이 가능하지만 전문가는 현재의 최신 기술에 익숙해야하며 작업을 수행하는 데 적합한 도구를 선택할 수 있어야합니다. 적절한 버전 관리 소프트웨어를 사용하지 않으면 작업이 위험하고 신뢰할 수 없게되며 전문 개발자를 고용하려는 이유 중 하나는 위험을 관리 할 수 ​​있어야하기 때문입니다.

VCS에 올바르게 주석이 달린 코드베이스는 그렇지 않은 코드베이스보다 훨씬 가치가 있습니다. 모든 변경의 이유를 추적하고 이해할 수 있으므로 유지 보수 담당자가 알아야 할 사항을 더 깊이 이해할 수 있습니다. 이를 수행하지 못하는 것은 비전문적 인 것이며, 그에 대한 유일한 변명은 이전 직장에서 가난한 관리자에 의해 제약을 받았을 때입니다. 그렇더라도 개인 프로젝트에 버전 관리를 사용해서는 안됩니까?