최고의 프로그래머가 다른 사람의 코드를 소스 제어로 확인해야합니까?

svn과 git 의 차이점 중 하나 는 저장소에 대한 액세스를 제어하는 ​​기능입니다. 누가 변경을 커밋해야하는지에 대한 관점의 차이가 있기 때문에 둘을 비교하기는 어렵습니다!

이 질문은 git을 회사의 팀을위한 중앙 저장소로 사용하는 것에 관한 것입니다. 팀 구성원이 대부분의 회사에서와 같이 기술 수준이 다양하다고 가정합니다.

Git은 유일하게 최고의 (가장 생산적이고 경험이 많은) 프로그래머가 코드를 체크인 할 수 있다고 가정합니다. 이 경우 실제로 코드를 작성하는 데 시간을 들여 다른 사람의 코드를 검토하여 체크인해야합니다. 저는이 질문을 일반적인 버전 관리 방법이 아닌 최고의 프로그래머의 시간을 가장 잘 활용하는 것에 초점을 맞추고 싶습니다 . 직업의 상당 부분이 다른 사람의 코드를 검토하는 것이라면 좋은 프로그래머가 그만두는 것일까 요? 나는 두 가지 질문이 다음과 같이 요약된다고 생각한다.

귀하의 질문에서 명확하지 않기 때문에 게이트 키퍼 워크 플로우가 결코 git에 필요하지 않다는 것을 지적하고 싶습니다. 신뢰할 수없는 기여자가 많기 때문에 오픈 소스 프로젝트에 인기가 있지만 조직 내에서는 그다지 의미가 없습니다. 원하는 경우 모든 사람에게 푸시 액세스 권한을 부여 할 수 있습니다.

이 분석에서 사람들이 무시하는 것은 좋은 프로그래머는 다른 프로그래머의 깨진 코드를 처리하는 데 많은 시간을 소비한다는 것입니다. 모든 사람이 푸시 액세스 권한을 가지면 빌드 가 중단되고 최고의 프로그래머는 문제가 발생했을 때 범인을 자주 통합하고 추적하는 경향이 있습니다.

푸시 액세스 권한을 가진 모든 사람은 문제가 발생하면 문제가되는 커밋이 되돌려 지거나 수정 될 때까지 당기는 사람이 모두 빌드를 깨뜨립니다. 게이트 키퍼 워크 플로에서는 게이트 키퍼 만 영향을받습니다. 다시 말해, 최고의 프로그래머 중 하나에 만 영향을주는 것은 아닙니다.

코드 품질이 상당히 높고 게이트 키퍼의 비용-이익 비율은 여전히 ​​가치가 없지만 친숙한 비용을 무시하지는 않습니다. 생산성 손실에 익숙하다고해서 발생하지 않는다는 의미는 아닙니다.

또한 하이브리드 옵션을 탐색하는 것을 잊지 마십시오. git을 사용하면 누구나 푸시 할 수있는 저장소를 설정 한 다음 수석 개발자, 테스터 또는 자동화 된 연속 통합 서버와 같은 게이트 키퍼가있어 변경이 두 번째보다 안정적인 저장소로 변경되는지 여부를 결정합니다. 그렇게하면 두 세계를 최대한 활용할 수 있습니다.

체크인이 팀 리더로만 제한되어 있고 팀 리더가 자체 코드를 체크인 할 수없는 직장에서 근무했습니다. 이는 게이트 된 체크인 및 정적 분석을 중심으로 나쁜 커밋이 코드베이스에 들어간 여러 가지 사건으로 인해 코드 검토를 시행하는 메커니즘으로 사용되었습니다.

한편으로는, 그것은 일을했다. 코드베이스에 들어가기 전에 여러 가지 잘못된 커밋이 발견되었습니다 (그리고 누군가가 넘어 질 때까지 1 주일 동안 즉시 잊어 버렸습니다). 이로 인해 코드베이스의 중단이 줄었습니다. 또한 기술 채무가되기 전에 일부 서식 / 구조를 철회 할 수있었습니다. 그들이 버그가되기 전에 몇 가지 버그를 잡아라. 그리고 그것은 우리 팀이하고있는 일에 대해 큰 느낌을주었습니다.

반면에, 다른 리드를 추적하고 커밋을 수행해야했기 때문에 3 라인 변경이 커밋하는 데 4 시간이 걸렸을 때 자발적으로 살인의 분노에 빠지게되었습니다. 필자는 모범 사례보다 훨씬 적은 빈도로 커밋을 수행했으며 때로는 개발자의 변경 사항을 추적하려는 문제가 발생했습니다.

가장 필요한 환경을 제외하고는 일반적으로 권장하지 않습니다. 리뷰와 커밋은 실제로 그렇게 나쁘지 않았습니다. 내 자신의 프로세스를 다른 사람들의 변덕에 의존하게 만드는 것은 화를 냈다. 개발자가 코드를 체크인하도록 신뢰할 수없는 경우 더 나은 개발자를 확보하십시오.

아니요. 누구나 커밋 할 수 있어야합니다.

커밋되는 버그에 문제가있는 경우 잘못된 소스 제어 정책이 아닙니다. 커밋 한 것이 제대로 작동하는지 확인하지 못하는 것은 개발자입니다. 따라서해야 할 일은 커밋 대상과시기에 대한 명확한 지침을 정의하는 것입니다.

또 다른 위대한 것은 단위 테스트라고합니다.)

그래도 대안이 있습니다.

a) 분산 버전 제어를 사용하는 경우 풀 요청 만 수행 할 수있는 기본 저장소를 작성할 수 있습니다. 이런 식으로 모든 개발자는 메인 브랜치를 제어하면서 자신의 코드 버전을 얻을 수 있습니다.

b) Subversion 및 이와 유사한 경우 각 개발자가 패치를 만들어 기본 분기로 가져와야하는 분기를 사용할 수 있습니다.

모든 개발자가 자신의 코드를 '검토'지점으로 푸시 할 수있는 Gerrit 와 같은 프로젝트를 살펴 봐야합니다. 일단 수석 / 선임 개발자가 이러한 변경 사항에 만족하면 마스터 / 릴리스로 푸시 할 수 있습니다.

그들이 마음에 들지 않으면 코드 줄 옆에 주석을 남기고 업데이트 된 패치 등을 요청할 수 있습니다.

이런 식으로 변경 보류중인 사람은 준비가 되 자마자 그것을 얻을 수 있으며 자격이있는 사람 (Gerrit에서 올바른 +2 권한을 가진 사람)만이 코드를 테스트하고 나중에 프로덕션으로 푸시 할 수 있습니다.

아니요, 최고의 인재를 제대로 사용하지 않습니다. 출판사에서 가장 성공적인 작가를 고용하여 편집하게한다고 상상해보십시오. 나쁜 생각.

코드 검토가 있어야하지만 그것이 항상 JR 코드를 검사하는 Sr.은 아닙니다. 결국 팀의 모든 직원은 최소한의 안내만으로 코드를 제공 할 수있는 수준에 도달해야합니다. 그들은 세 가지 신뢰 수준을 거칩니다.

1. 없음-체크인하기 전에 모든 코드 줄을보고 싶습니다.
2. 일부-내가하고있는 일을 알려 주시면 의견을 보내 드리겠습니다.
3. 대부분-작업을 수행하고 필요할 때만 도움을 요청하십시오.

인재 확보의 장점 :

• 디자인에 집중
• 코딩 표준 및 시행 전략 수립에 관여 (수동으로 직접 수행하지 않고)
• 까다로운 코딩 문제 해결
• 멘토링 제공 (모든 코드 라인을 승인하지 않고)

하루 종일 코딩하지 않는 관리 경로에 관심이있는 개발자가 있습니다. 다른 사람들을 내버려 두십시오.

리뷰는 생산성에 영향을 줄만한 가치가 있습니까?

팀 "균형"및 검토 설정 방법에 따라 다릅니다. 둘 다 관리와 팀워크의 문제이며, 많은 버전 제어 기술 마법 (중앙 집중식 또는 분산 식)이 그에 상당한 영향을 줄 수는 없습니다.

잘못한 경우 , 생산성 저하는 물론 검토의 이점을 없애줍니다. 답은 리뷰에 대한 아이디어를 포기하는 것이 아니라 올바른 방법을 찾는 것 입니다.

검토가 올바른지 확인하는 한 가지 방법은 문제 추적 도구 를 사용 하여 검토에 소요되는 시간을 추적하는 것입니다 (일부 코드 검토 도구에서도 가능). 리뷰에 많은 시간이 걸리는 것을 발견하면 개선해야 할 이유와 방법을 찾는 데 몇 가지 노력을 투자하십시오. 또한 코드 검토와 관련된 잠재적 인 문제를 발견하기 위해 팀원들과 정기적으로 1 : 1 을하는 것이 문제가되지 않습니다 .

팀의 "최고의"프로그래머가 엉터리 코더가 생산하는 이해할 수없는 쓰레기를 파헤쳐 몇 시간을 보내야한다면 해결책은 VCS 기술에 호소하지 말고 쓰레기 제작자를 해고하는 것입니다.

• ^{과거 프로젝트 중 하나에서 테스트를 빌드하고 실행하는 데 거의 1 시간이 걸리는 구성 요소에서 성능이 저조한 팀 구성원이 수행 한 코드 변경 사항을 검토하도록 지정되었습니다. 나는 diff를 읽기 시작했으며 컴파일 할 수없는 변경을 발견했을 때 간단히 검토를 완료하고 필요한 주석을 게시하고 관리 부서에 요청하여 추가 검토 요청이 코드가 컴파일되었다는 서면 확인을 받도록했습니다. 그 남자는 떠난 이후로 "검토 요청"이 없었습니다.}

다른 한편으로, 팀이 합리적으로 균형을 잡으면 코드 검토는 재미 있고 교육적입니다. 이전 프로젝트에서는 100 % 코드 검토가 필요했으며 시간이 많이 걸리거나 산만하지 않았습니다. 리뷰를 통해 발견 된 버그가 있었으며 코딩 스타일과 디자인 선택에 대한 논쟁이 있었지만, 그것은 단지 정상적인 느낌 이었습니다.

"검토로 인해"테스트를 위해 QA에 도달 한 후 며칠 동안 코드 변경이 차단되는 경우 VCS 트릭에 대해 연구하는 것이이 문제를 해결할 가능성이 가장 낮습니다. 대신 검토 프로세스가 구성되는 방식에서 문제를 찾는 데 더 집중해야합니다.

• <sup>-오, 검토자가 갑자기 아프게 되었기 때문에이 변경의 통합이 많이 지연되었습니다.
  - 안녕하세요! Hell-lo-oo, 백업 검토자가 그런 경우를 처리하도록 생각한 적이 있습니까?</sup>

예. 그러나 분산 소스 제어에 대해 이야기하는 경우에만 가능합니다. 중앙 집중식으로-그것은 달려 있습니다.

프로그래머가 거의 없다면 시간이 거의 걸리지 않습니다. 나중에 버그와 기술 부채를 제거하는 데 필요한 수정 사항보다 확실히 적습니다.

프로그래머가 매우 많은 경우 실제 코드 검토 작업을 중위에게 위임하고 수석 개발자가 변경 사항을 거의 (거의) 당길 수 있습니다. Linux 커널에서 작동하지만 더 큰 소프트웨어 프로젝트가 없다고 생각합니다 ...

다시 말하지만, 프로젝트 규모가 작 으면 누가 좋은 코드를 제공하고 누가 나쁜 코드를 생성하는지 신속하게 확인할 수 있습니다. 그는 J.Random이 아키텍처 결정을 확인하는 데 필요한 좋은 코드를 작성하는 반면 인턴은 병합하기 전에 한 줄씩 검토해야하는 잘못된 코드를 작성한다는 것을 곧 알 수있을 것입니다. 이러한 방식으로 생성 된 피드백은 유지 보수 부담을 줄이며 인턴이 실제로 배우고 회사에서 유지해야하는 모든 것에 대한 직접적인 경험을 제공합니다. 다른 git리포지토리 에서 브랜치를 가져오고 병합 하는 데 문자 그대로 (커플) 수십 초가 걸리며 일반적으로 커밋 메시지의 제목을 읽는 데 더 많은 시간이 걸리므로 다른 사람들의 코드를 병합하는 좋은 코드를 작성할 수있는 사람을 알면 문제가 아닙니다.

코드 검토에 반드시 최고의 프로그래머 만주의를 기울일 필요는 없습니다. IMO는 비공식적이어야합니다. 프로덕션에 들어가기 전에 신인이 아닌 사람이 작성한 코드 조각에 대한 두 번째 의견 또는 두 번째 눈. 주요 감독을 완화하는 동시에 다른 개발 관점에 노출되어 사람들이 공예로 코딩하는 데 도움이됩니다.

덜 독창적 인 페어 프로그래밍 라이트의 일종. 다시 말해 시간이 오래 걸리지 않으며 몇 시간 동안 누군가를 기다릴 필요가 없습니다. 개발 과정에서 사람들이 물건을 기다리는 것과 관련이있는 것은 돈 낭비이며 IMO 모멘텀 / 파손에 치명적입니다.

코드 검토가 처음에 코드베이스에 들어가기 전에 99.5 %의 버그를 막으려 고한다면 정교한 버전 관리에 대한 실질적인 요점은 없습니다. 즉, git은 처음에는 위협적이지만 기본적인 일반적인 사용은 그렇게 복잡하지 않으며 매우 구성 가능합니다. 모든 사람에게 사용 방법을 가르치기 위해 몇 시간 동안 멈출 수 있어야합니다. 모두 커밋합니다. 가장 신참을 제외한 모든 신인은 무언가에 대한 전문 지식을 보여줄 때까지 검토합니다.

제출 된 변경 사항이 '최고의 프로그래머'에 의해 검토되는 한, 누구나 코드 제출이 허용되어야합니다. 저장소에 대한 제어 권한을 부여 할 수있는 유일한 사람은 해당 직원이있는 경우 Release Engineer입니다.

개인적으로, 다른 사람들의 코드를 확인해야한다면 화가 났을 것입니다.

편집에 대한 일부 입력 : 아니오, 안됩니다. 리뷰는 필요한 악이며, 해보다 더 잘하며 좋은 프로그래머는 이것을 고맙게 생각할 것입니다. 코드를 비판하는 '더 적은 프로그래머'라는 아이디어가 마음에 들지 않기 때문에 리뷰에 참여하는 것을 꺼려 할 수도 있습니다. 너무 나쁘다. 코드 라인이 지속적으로 버그가 있고 다른 사람들의 반 구운 제출 후 정리하는 데 시간을 소비하면 훨씬 더 종료 될 것입니다.

예, 검토 할 가치가 있습니다. 다음과 같은 이유로 검토 프로세스가 비례하는 경우 생산성 적중이 있는지 확실하지 않습니다.

• 프로그래머가 정직하게 유지합니다-검토 될 것이라는 것을 알면 사람들은 지름길이 줄어 듭니다.
• 새로운 프로그래머가 더 많은 경험을 가진 프로그래머로부터 배우는 데 도움이됩니다.
• 도메인 특정 지식을 이전하는 데 도움이됩니다.
• 검토는 버그 및 잠재적 문제를 찾아서 수정할 수있는 또 다른 문입니다.

모든 프로그래머가 소스 제어를 사용하지 못하게함으로써 변경 사항을 추적하고 실수를 취소하며 합리적인 변경 내역을 볼 수 없게됩니다. "최고의"프로그래머 만 git에 체크인 할 수 있기를 바랍니다.

그런 말을하더라도 릴리스 지점과 같은 특정 키 지점을 담당하는 사람이있는 것이 합리적이라고 생각합니다. 이 경우 모든 사람이 git 저장소를 사용할 수 있지만 특정 사람 만 릴리스 브랜치에 병합한다고 상상할 수 있습니다. git에서 이것을 시행하는 방법이 확실하지 않지만 프로세스로 수행 할 수 있어야하며 다른 사람이 체크인하지 않았습니다.

릴리스 브랜치로의 병합은 "최고의"프로그래머가 수행하거나 충분한 검토가 완료된 후 유능한 사람들이 수행 할 수 있습니다.

직업의 상당 부분이 다른 사람의 코드를 검토하는 것이라면 훌륭한 프로그래머가 종료합니까?

그들이 일을 즐기지 않고이 활동을 강요 받았다면 그렇습니다. 일어날 가능성이 매우 높습니다. 좋은 개발자를위한 다음 흥미로운 작업을 찾는 것이 요즘 큰 도전이 아닙니다.

최고의 프로그래머가 다른 사람의 코드를 소스 제어로 확인해야합니까?

절대 안돼. 견고한 상태 에 있어야하는 일부 중요한 논리를 제외하고는 시간 낭비가 확실 합니다.

그러나 주니어 또는 경험이없는 개발자는 아마도 코드 품질 에 대한 보호 관찰 시간을 거쳐야합니다 . 안전을 유지하고 코드가 팀 개발 가이드 라인을 따르는 지 확인해야합니다.