검토를 기다릴 때 어떻게해야합니까?

질문을하기 전에 상황을 설명해야합니다.

저는 주니어 소프트웨어 엔지니어로 회사에서 일하고 있습니다. 선배 중 한 명은 개발을 마치고 헌신하고 싶을 때 항상 나를 막습니다.

그는 항상 내가 그것을 검토하기를 기다리기를 원합니다. 일반적으로 그는 몇 가지 버그를 발견하고 일부 최적화를 수행하기 때문에 괜찮습니다.

그러나 마감일 전에 코드를 커밋해야합니다. 내가 끝났을 때 나는 그를 불러서 끝났다고 말한다. 그는 보통 늦게옵니다. 그래서 내 코드도 늦었습니다.

제 질문은 어떻게해야합니까? 검토를 기다려야합니까?

편집 : 질문에 추가. 하나 더 문제가 궁금합니다.

코딩 할 때 자유롭고 싶습니다. 개발의 자유에 대한 신뢰를 얻으려면 어떻게해야합니까?

_{몇 가지 설명 : 나는 이것에 대해 그와 이야기했습니다. 그러나 도움이되지 않았습니다. 이미 이슈 트래커를 사용하고 있지만 검토 할 작업이 없습니다. 개발 및 테스트 작업 만 있습니다.}

그래서 내 코드도 늦었습니다.

아니요, 귀하의 코드 가 아닙니다. 귀하 와 노인 의 코드입니다 . 당신은 팀으로 일하고 있으며, 책임을 분담하고 있으며, 두 사람이 마감일을 놓치면 둘 다의 잘못입니다. 마감일을 정한 사람이 그 사실을 알고 있는지 확인하십시오. 그 사람도 그 점을 문제라고 생각하면, 반드시 당신과 함께 둘 다 이야기 할 것입니다. 동료와 한 번 이상 이야기하는 데 도움이 될 수도 있습니다.

그리고 당신의 편집에 :

코딩 할 때 자유롭고 싶습니다. 개발 자유에 대한 신뢰를 얻으려면 어떻게해야합니까?

코드 검토는 가장 중요한 품질 보호기 중 하나입니다. > 20 년 이상의 프로그래밍 경험이 있더라도 두 번째 시선없이 훌륭한 코드를 작성하는 것은 사실상 불가능합니다. 따라서 좋은 팀에서는 모든 사람의 코드 (상위 코드와 코드)를 지속적으로 검토해야합니다. 이것은 당신에 대한 불신 과는 아무런 관련이 없습니다 (적어도 그렇게해서는 안됩니다). 두 번째 눈이없는 "자유 코딩"이 더 좋다고 생각하는 한, 여전히 주니어 프로그래머입니다.

좋은 팀에서는 이슈 트래커 에 개발 작업 대기열 이 할당되어 있어야합니다 .

그런 식으로, 당신은 검토를 기다리는 동안, 당신은 수 ( 해야 해당 대기열에서 대기 다음 작업에 대한) 작동합니다. 그런 식으로 일하는 데 익숙해지면 변경 사항을 "배치"로 검토하여 지연을 줄일 수 있습니다.

• ^{이러한 "대기열"이없는 경우 관리자와 논의하거나 더 나은 검토 자와 논의하십시오. 팀이, 그런 것들에 대한 합리적 편리 이슈 트래커가 더 나은 팀을 찾기 위해 작업 보드 또는 회사 내부 작업의 기회를 공부 고려하지 않는 경우 (당신은 또한 관리자와상의 할 수 / 검토하지만, 도움이 기대하지 않는다 - 부족 좋은 이슈 트래커 는 종종 팀에서 심각한 문제 가 발생하는 증상입니다.}

코딩 할 때 자유롭고 싶습니다. 개발 자유에 대한 신뢰를 얻으려면 어떻게해야합니까?

알아 보려면 먼저 코드 검토의 목적을 이해해야합니다. 당신은 신뢰를 언급했습니다. 그것은 좋은 "근사치"이지만 완전히 정확한 것은 아닙니다.

• ^{예를 들어, 최근 프로젝트 중 하나에서 저와 제 동료 팀이 개발했습니다. 우리는 서로를 완전히 신뢰하고 존중했습니다. 그럼에도 불구하고 우리는 코드의 100 %를 검토했습니다. 이를 통해 버그를 찾아서 신속하게 수정할 수 있었으며 , 검토에 많은 시간이 걸리지 않았고 업무를 차단하지 않았기 때문에 매우 중요했습니다.}

특정 위험을 방지하기 위해 투자 한 노력의 관점에서 코드 검토를 생각하는 것이 더 정확할 것입니다 . 좋은 팀에서는 이것을 "적절하게 균형을 잡는"방법에 대한 공유 지식을 기대할 수 있습니다. 하나의 크기에 맞는 적절한 균형이 없으며, 프로젝트에 크게 의존합니다. 미션 크리티컬 소프트웨어 의 버그의 영향과 영향은 중요 하지 않은 응용 프로그램 의 버그와 자연스럽게 다릅니다.

예제를 사용하면 코드를 커밋하기 전에 해결해야 할 버그와 개선 사항을 찾아 검토자가 투자 한 노력이 정당화 되는 한 "검토 차단"을 기대할 수 있습니다.

그들은 연습과 리뷰에서 안내를 받으면 코딩을 더 잘 할 수 있기 때문에 커밋하기 전에 해결해야 할 문제를 찾을 수 있습니다. 귀찮은 "위험 예방 조치"를 허용하기 위해 코드가 "충분히 안전"하다는 것을 알게 되 자마자 커밋 후 검토 와 같이 프로세스가 변경 될 것으로 예상 할 수 있습니다 .

프로젝트에 따라 언젠가 코드가 리뷰를 건너 뛸 정도로 안전하다고 간주되어 테스터에게 버그를 발견 할 수 있습니다 (그러나 반드시 그런 것은 아닙니다. 위의 예제를 참조하십시오).

문제의 정확한 내용에 따라 여기에 여러 가지 가능한 답변이 있습니다.

• 귀하의 주요 관심사가 "기한이 없습니다"입니다. 두 사람이 함께 마감 기한이 지났습니다. 당신은 (자신감있게) "1 시간 후에 끝낼 것입니다. 그러면 코드 검토를 할 수 있습니까?"라고 말할 수 있습니까? 충분할 것입니다. 마감일 전날 코드를 완성 할 수 있습니까? 충분한 버퍼 여야합니다. "반드시 검토하십시오"와 마감일 사이에 많은 버퍼를 사용하여 코드를 완성하고 있습니까? 후자가 공동 결함이 아니라면 말하고 싶습니다.

• 코드는 항상 검토해야합니다. 나는 (적어도) 두 번째 눈과 다른 인간이 "괜찮아"없이는 아무것도 확인할 수 없습니다. 그것은 내가 리드 프로그래머 인 프로젝트뿐만 아니라 내가 정상적으로 기여하지 않는 프로젝트에도 적용됩니다 (그러나 내가 고치고 싶은 버그를 발견했습니다). 그러나 검토의 엄격 성은 신뢰를 바탕으로합니다. 코드를 제출하려는 사람이 코드베이스를 잘 알고 있다고 믿으면 코드베이스를 얼마나 잘 알고 있는지를 모르는 것처럼 엄격하지 않습니다.

제 질문은 어떻게해야합니까? 검토를 기다려야합니까?

아니, 당신은 그냥 유휴 앉아해서는 안됩니다. 항상해야 할 일이 있습니다. Gnat이 제안했듯이 작업 대기열이 있어야합니다. 또는 민첩한 개발 방식으로 현재 반복에 할당 된 작업 목록입니다. 유휴 상태 인 경우 회사 또는 팀의 조직에 문제가 있습니다.

또 다른 것은 : 상급 관리자가 실제로 모든 코드를 확인하고 있습니까? 그렇다면 쌍 프로그래밍을 할 수도 있습니다.

코딩 할 때 자유롭고 싶습니다. 개발 자유에 대한 신뢰를 얻으려면 어떻게해야합니까?

선배가 후배의 작업을 점검하도록 요구하는 규정이 있습니다 (의료 iso 62304가 이것을 요구한다고 생각합니다). 그렇다면 아무 것도 할 수 없습니다.

변경할 수있는 것은 선임자에게 말 그대로 모든 것을 확인하지 않도록 요청하는 것입니다. 코드 검토 프로세스를 설정하고 중요한 사항을 확인할 수 있습니다.

로컬로 git을 사용하고 지점에 변경 사항을 커밋하고 대기하는 동안 작업 2에서 시작하십시오. 그런 다음 그가 완료되면 변경 사항을 새 작업에 병합 할 수 있으며 다음 작업에서 이미 앞서고 있습니다.

이것을 충분히 오래 그리고 곧, 그는 한 번에 두 개 이상의 것을 검토 할 수 있습니다. 충돌을 최소화하기 위해 선이 겹치지 않는 것을 선택하십시오.

이에 대한 한 가지 해결책은 선임 개발자가 작업에 페어 프로그래밍 (Pair Programming) 을 통해 훨씬 일찍 참여하게하는 것 입니다.

페어 프로그래밍의 Wikipedia 페이지

가장 확실한 이점은 검토가 프로세스의 초기에 이루어 지므로 더 이상 선임 개발자를 기다릴 필요가 없다는 것입니다.

뿐만 아니라 수석 개발자가 코드를 작성할 때 사고 과정과 기술을보고이를 통해 배울 수 있습니다.

선임 개발자의 문제가 귀하와 페어링하고 싶지 않을 수 있습니다. 어려울 수 있지만, 저 자신의 경험은 상급 개발자와 후배 개발자 모두 페어 프로그래밍을 통해 많은 경험을 얻는 것입니다.

또한 2 명의 개발자가 동일한 작업을 수행하도록함으로써 생산성이 절반으로 떨어질 것이라는 우려가 있습니다. 생산성에 미치는 영향을 페어 프로그래밍으로 측정하는 것은 어렵습니다. 내가 들었던 가장 일반적인 반응은 짝을 이루는 팀과 그렇지 않은 팀의 생산성이라는 것입니다. (누구든지 이것에 대한 좋은 연구를 알고 있다면 그것에 대해 듣고 싶습니다.)

완전한 답변이 아니라 위의 훌륭한 답변에 추가 된 것입니다 ...

체크인하기 전에 자신의 코드를 검토하십니까? 나는 그것이 가장 재미 있지 않다는 것을 알고 있지만, 나는 대부분 그것을 스스로 할 수 있도록 노력합니다. 나는 전문적으로 20 년 동안 프로그래밍을 해왔지만 (총 34 년), 나는 적어도 하나 이상의 버그 나 잊어 버린 것을 찾거나 적어도 더 나아질 수있다. 본인의 코드를 항상 검토해야하며 두 번째 눈 세트가 한 쌍보다 낫다는 정서에 동의합니다. 그러나 코드를 두 번 통과하는 동일한 쌍조차도 한 번보다 낫습니다.

코드에 대한 단위 테스트를 작성합니까? 단위 테스트 외에도 개인적으로 저지르는 가장 일반적인 실수를 검색하는 작은 쉘 스크립트도 있습니다. 그중 일부는 영어 문법과 철자이며, 일부는 컴파일러가 포착하지 못하는 코딩 문제입니다. 나는 모든 다운 스트림 사람들에게 예의 바르게 큰 변화를 확인하기 전에 그것을 실행합니다.

나는 일반적으로 사람들이 코드를 작성하고 나중에 코드에 대해 불평하도록하지만 모든 단일 체크인을 검토하지는 않습니다. 나는 한 번 매우 코드를 검토하고 실수를 많이했기 때문에 실행 취소해야하는 매우 주니어 프로그래머와 함께 일한 적이있다. 그것은 잘 끝나지 않았다. 당신은 제때에하는 것보다 올바르게하는 것이 더 중요한 직업에 있습니다. 실수를 통해 배우면 멀리 갈 것입니다.

검토자가 코드를 변경해야하는 횟수를 최소화 할 수 있으면 항상주의 깊게 검토 할 필요는없는 코드를 작성할 것을 신뢰할 수 있습니다. 리뷰를받지 않으려면 자신의 출력 품질에 대해 최대한의 책임을 져야합니다.

다른 사람이 귀하의 코드를 검토하기를 기다리는 동안 이러한 제안 중 일부 또는 전부를 수행 할 수 있습니다.

수동 코드 검토를 수행하는 것은 ... 음 ... 80 년대입니다. 아마 90 년대

현대의 지속적인 통합 및 온라인 코드 검토 시스템 시대에서 "소스 제어가 중단 될 수 있습니다"라는 두려움 때문에 코드 커밋을 보류하고 싶지 않습니다.

어서 이것이 바로 변경 세트 (또는 변경 목록)의 목적입니다. 프로그래머가 소스 제어 시스템의 굶주린 턱에 먹이를 주도록합니다. 그런 다음 지속적인 통합 서버는 대상이 된 빌드를 제공합니다 (매일, 매일 빌드하지만 일부는 제거됩니다). 문제가 발생하면 가해자 책상에 코드 원숭이 트로피 (일반적으로 누군가가 럭키 참 시리얼 상자에서 찾은 플라스틱 장난감)를 넣고 침입 변경 목록을 롤백하십시오. 글쎄, 일부 지속적인 통합 시스템은 팀 / 부서 / 조직의 모든 사람에게 빌드가 손상되었다는 이메일 / IM / 데스크톱 알림을 자동으로 표시하고, 파일 또는 테스트에서 빌드를 정확히 중단 한 모든 사람을 보여주는 멋진 하이퍼 링크를 제공합니다. 이제는 불운 한 프로그래머입니다. '

이 프로세스가 실행되면 코드 검토 시스템이 시작됩니다 (다시 체크인에 의해 트리거 됨). 자격을 갖춘 팀 구성원의 목록은 소스 제어를 위해 변경 목록이 변경되었음을 알리고 검토 시스템에서 검토가 시작되며 모든 사람이 변경 목록의 변경 사항에 주석을 달기 시작합니다. 모두가 "LGTM"이라고 말하길 바랍니다. 프로그래머가 똑똑하다면,기도 / 뇌물 / 숨기기를 기억할 것입니다. 심각한 문제가있는 경우 검토자는 결함을 생성하거나 (버그 추적 시스템에 연결될 수 있음) 변경 목록을 취소해야 할 수도 있습니다. 그렇습니다. 변화를 철회하면 자아뿐만 아니라 마음도 아프게됩니다. 거부 된 변경 목록을 다시 통합하는 것은 주니어 개발자에게 좋은 양념입니다.

개발 환경에 CI 또는 코드 검토 시스템이 부족한 경우이를 심각하게 조사해야합니다. 몇 가지 링크가 도움이 될 수 있습니다.

Atlassian Crucible
JetBrains TeamCity
reitveld
크루즈 컨트롤

CI 서버를 얻으려면 단위 테스트 프레임 워크에 대해서도 진지하게 고려해야합니다. C # 개발자라면 시작하려면 NUnit 과 같은 것을 살펴보십시오 .

당신은 그에게 사전에 당신이 일을 끝낼 때 코드가없는 순간에, 준비가되어있을 때. 대략적으로 결정할 수 있어야합니다. 일주일 앞서 요 이를 통해 검토를 준비하고 계획하여 두 계획에 모두 맞출 수 있습니다.