코드 리뷰, 장점은 무엇입니까? [닫은]

우리 팀에서는 공식 코드 검토를 수행하지 않습니다. 우리는 쌍 프로그래밍과 회전 쌍으로 충분하다고 생각하는 경향이 있습니다.

공식 코드 검토를 고려해야합니까? 장점은 무엇입니까?

코드 리뷰는 약간 다릅니다 (아마도).

우리는 모든 프로그래머들을 모아서 (매주 금요일) 일주일 동안 한 일을 살펴 봅니다. 그런 다음 우리는 검토 할 프로젝트를 선택하여 모든 완료 / 진행중인 프로젝트가 최소한 한 명 또는 소수의 사람들을 갖도록합니다. 그런 다음 몇 시간 안에 변경 사항을 확인하고 실수를 검색하고 다른 프로젝트가 작동하는 방식 등을 살펴 봅니다. 나중에 논의하고 실수를 말하고 어떻게해야하는지 (버그를 수정하지는 않습니다) FIXME로 코드를 스팸으로 분류하십시오). 일반적으로 우리 (10 프로그래머)에게는 약 2 시간이 걸립니다.

장점 :

• 모든 회원은 회사에서 어떤 일이 일어나는지 알고 있습니다
• 버그가 더 빨리 발견됩니다
• 읽을 수있는 코드 (설명이나 소개없이 읽을 수있는 코드)를 작성해야합니다.
• 최적화 방법 / 트릭 / 생산적인 프로그램이 더 빠르게 확산
• 전문가로서의 프로그래머는 더 빨리 진화한다
• 재밌다

언급 한대로 페어 프로그래밍에 대해 내가 가지고있는 것은 팀이 더 오래 함께 일할수록 더 빠르다는 것입니다.

나는 그것이 생각을위한 음식을 가져 오기를 바랍니다. 행운을 빕니다.

이 무료 책을 읽으십시오.

http://smartbear.com/best-kept-secrets-of-peer-code-review/

물론, 그들은 푸시 할 제품이 있지만 여전히 유용한 정보가 많이 있습니다.

또한 페어 프로그래밍이 동일한 이점을 제공하는 방법에 대해 설명하므로 페어 프로그래밍의 경우 코드 검토가 전혀 필요하지 않을 수 있습니다.

귀하의 환경을 검토 한 경험이 많지 않습니다. 우리는 팀에서 소프트웨어에 대한 지식을 전파하기 위해 코드 검토를 수행하고, 실수를 찾아 내고 소프트웨어가 코딩 지침을 고수하는지 공식적으로 확인할 수 있도록 또 다른 쌍의 프로그래밍을 수행합니다. .

첫 번째 2 점은 페어 프로그래밍에 의해 상당히 잘 적용되며, 세 번째는 페어에 크게 의존하며 공식 코드 검토를 통해 더 나아질 수 있습니다.

공식적인 코드 검토를해야합니까?

물론

그냥 빨리 보조 노트로, 나는이 매우 짝 프로그래밍에 약간의 경험을,하지만 난 리뷰 이러한 방법과 충돌 할 것이라고 생각하지 않는다.

두 가지 형태의 코드 검토를 소개하겠습니다.

동료 코드 검토

짝을 이루는 프로그래밍이 효과가 있어도 코드를 다시 한 번 눈에 띄게 해치지 않습니다 . 이것의 이점은 다음과 같습니다.

1. 코드에 대한 새로운 시각을 갖게됩니다. 코드베이스의 영역에 대해 더 잘 아는 사람은 귀하 (및 / 또는 파트너)가 친숙하지 않을 수 있습니다. 이로 인해 노크 문제가 발생할 수 있습니다.
2. 제출하기 전에 솔루션 쌍을 다시 확인합니다. 검토자가 작성한 내용에 대해 아무것도 모르므로 전체적으로 설명해야합니다. 이것은 당신이 생각하지 않았거나 논리가 잘못된 경우를 노출시킬 수 있습니다.

피어 코드 검토 (내 세상)는 모든 제출 전에 수행 됩니다 . 이것이 쌍을 이루는 프로그래밍 세계에서 어떻게 전달되는지 확실하지 않습니다.

그룹 코드 검토

이는 피어 코드 검토보다 덜 자주 발생합니다. 나는 비공식적 인 코드 검토를 위해 회의실에서 내 그룹 (또는 그룹의 하위 섹션)을 가져옵니다. 나는 일반적으로 팀에서 임의의 사람이 작성한 일부 코드, 바람직하게는 처음부터 작성된 코드를 선택합니다. 리팩토링 된 코드는 새로운 코드와 같은 문제를 나타내지 않습니다.

모든 사람이 이러한 리뷰가 불쾌감을주기위한 것이 아니며 성과를 반영하는 데 사용 되지 않음을 알고 있어야 합니다. 그들은 단지 팀 코딩 표준을 준수하고 모든 사람 이 더 나은 엔지니어가되어 팀에 더 유용 해 지도록 (그리고 경력 성장 등) 도움을주고, 이것이 검토의 진정한 의도인지 확인하기위한 것입니다. . 누군가가 다른 것을 의심한다면, 이들은 두려워하고 생산적이지 않을 것입니다.

나는 코드를 약간 비공식적으로 살펴보고, 방의 모든 사람들이 가지고있는 다른 솔루션이나 그들이 직면 한 논리적 인 결함을 지적하게했다. 이것은 모든 사람에게 코딩 방법을 알려주는 리더보다 그룹 토론에 가깝습니다.

이 두 가지 방법을 사용하면 엔지니어의 진행 속도가 빨라지고 버그 수는 상당히 줄어 듭니다. :)

실제로 페어 프로그래밍을 한 적이 없으며 (바람직한 경우에만) 두 연습을 직접 비교할 수는 없습니다. 그러나 공식 코드 검토에 대한 경험을 말할 수 있습니다.

이전 프로젝트에서 레거시 코드에 대한 공식 코드 검토를 이끌었습니다. 이 프로젝트는 완전한 혼란에 빠졌고 경영진은 질서를 혼란에 빠뜨리려는 희망으로 모든 이니셔티브를 환영했습니다. 당시에는 공식 코드 검토가 좋은 생각이라고 생각했습니다. 우리는 버그를 발견했으며, 새로 작성된 코드의 품질이 이전 코드의 품질보다 훨씬 우수하다는 것을 알았습니다. 이를 증명하기 위해 통계, 버그 수 등을 수집했습니다.

우리는 주당 평균 한 세션을 3-5 명 정도 참여했습니다. 각 세션은 1 인당 약 3-4 시간 (준비 포함) 소요되었으며 200-300 줄의 코드 (LOC) *를 검토했습니다. 이 속도로 6 개월이 넘는 기간 동안 약 5 만 개 중 약 5 만 개 LOC를 검토했습니다.

돌이켜 보면 비용이 많이 든다고 생각합니다. 이러한 속도로 레거시 코드베이스 전체를 검토하는 데 5 년이 걸렸습니다. 일주일에 두 번 이상의 세션을 갖는 OTOH는 개발에서 자원을 빼앗 았을 것입니다. 물론 이것은 레거시 코드의 일반적인 딜레마입니다. 그러나 새로 작성된 모든 코드를 공식적으로 검토하더라도 시간이 많이 걸리므로 개발 속도가 크게 느려집니다.

필자의 결론은 공식 코드 검토는 코드의 가장 중요한 부분에 초점을 맞춘 새로 작성된 코드에서 가장 잘 수행된다는 것입니다. 나머지는 페어 프로그래밍을 통해보다 비공식적 인 방식으로 더 잘 처리됩니다. 이것은 내 현재 의견 일 뿐이며 변경 될 수 있습니다. 코드 검토 전문가 또는 다른 사람이라고 주장하지 않습니다.

* 정식 코드 검토의 일반적인 속도입니다.

일반적인 코드 검토 속도는 시간당 약 150 줄입니다. 중요한 소프트웨어 (예 : 안전 핵심 내장 소프트웨어)에 대해 시간당 수백 줄 이상의 코드를 검사하고 검토하는 것이 너무 빠르기 때문에 오류를 찾을 수 없습니다.

Wikipedia 에서 인용 (나에 의해 강조).

코드 검토가 존재하는 근본적인 이유는 격리 된 프로그래머가 코드를 만나서 논의하고 표준에 맞는지 확인해야하기 때문입니다.

품질 문제는 언급하지 않았으므로 팀에서 이미 쌍 프로그래밍을 통해 충분한 코드 검토를 수행하는 것 같습니다. 대박!

올바르게 수행 된 페어 프로그래밍은 공식 코드 검토를 불필요 하게 만듭니다 . 그러나 몇 주 동안 시도해보고 어떻게 작동하는지 확인하십시오.하지만 개선 된 점을 알지 못할 것입니다.

코드 검토는 피곤하고 비용이 많이 드는 과정이며 가볍게 수행 할 수는 없습니다. 본질적으로 프로젝트에 핸드 오버가 도입되어 비용이 많이 들고 모든 것이 느려집니다 . 나중에 문제를 찾으려고하는 것보다 먼저 코드가 올바른지 확인하는 것이 훨씬 좋습니다.

아마도. 코드 검토에는 시간이 걸립니다. 검토에 소요되는 시간이 프로세스의 다른 시점에 저장되는 경우에만 가치가 있습니다. 코드 검토를 통해 어떤 비용을 절감 할 수 있습니까? 코드 검토로 방지 할 수있는 어려움이 있습니까?

페어 프로그래밍을 수행하는 경우 코드 검토의 필요성이 크게 감소하지만 동료 검토의 이점이 있습니다. 이것이 유익하기 위해서는 페어 멤버보다 선배와 경험이 많은 사람이해야합니다.

장점은 무엇입니까? 글쎄, 그것을하지 않을 위험을 고려하면 더 좋을 것입니다.

• 쌍이 잘못했거나 차선책 일 수 있습니다.
• 코딩 표준을 따르지 않거나 코드를 올바르게 문서화하지 않았을 수 있습니다. 동료 리뷰는 실제로 이것을 찾는 데 능숙합니다.
• 쌍 이외의 어느 누구도 특정 코드를 이해하지 못합니다. 쌍 멤버가 남았고 코드가 제대로 문서화되지 않으면 어떻게됩니까? 다른 사람들은 상황을 파악하는 데 시간을 낭비 할 것입니다. 당신이 한 일을 아는 제 3의 사람이 있으면 위험이 줄어 듭니다.

사람들이 코드 검토가 시간 낭비라고 말한 것을 기쁘게 생각합니다. 예, 시간이 걸립니다. 어쩌면 코드에서 변경 사항이 생성되지는 않지만 코드가 낭비되는 것은 아닙니다. 소방 시스템은 시간 낭비이므로 정기적으로 점검 할 필요가 없다고 말하는 것과 같습니다.

나에게 코드 검토의 주요 장점은 사람들이 더 나은 코드를 작성할 수 있다는 것입니다.

코드를 읽고 검토한다는 사실을 알면 가독성과 코드의 "정확성"을보다 잘 인식하게됩니다. 코드가 저장소에 곧바로 들어가고 결함을 수정하지 않는 한 아무도 읽지 않으면 사용법이 변경 될 때 필드 이름을 리팩터링하지 않는 것처럼 미끄러 져 경향이 있으므로 사용하지 않는 메소드는 중단 될 수 있습니다. 등으로 다시 고려됩니다.