일반적인 코드 검토 프로세스 란 무엇이고 나쁜 것으로 간주되는 것은 무엇입니까?

우리 회사는 최근 공식적인 코드 검토를 시작했습니다. 프로세스는 다음과 같습니다. github에 제출하고, 풀 요청을 요청하고, 약 세 사람이 코드를 검토 한 다음, 모두 통과하면 코드가 입력됩니다.

프로세스는 공정한 것처럼 보이지만 코드 검토를 수행하는 세 사람은 공정하지 않은 것 같습니다. 검토를 위해 코드를 넣을 때 100-200 개의 댓글 사이에 도착합니다. 나를 위해 가장 큰 숫자는 한 번 300 댓글이었습니다. 물론 큰 변화라고 생각할 수도 있지만 50 줄 미만의 코드 (단위 테스트 포함)를 사용하면 매우 작은 변화 일 수 있습니다. 모든 의견은 "해야 할 것"으로 간주되며 논쟁의 여지가 없습니다.

그것을 염두에두고, 여기서 나의 주요 문제는 조금 과도하게 보인다는 것입니다. 나는 그룹과 이야기를 나 basically 다. 그리고 그들은 기본적으로 내가 PHP에서 수년간의 개발을했다고해서 내가 "개발자"라는 의미는 아니라고 말했다. 물론 이것은 아프지 않은 것보다 더 아프다. 또한 그룹 내에서 그들은 많은 의견을 제시하지 않는 것으로 보이며 대부분의 경우 다른 의견이나 제안을 무시하거나 무시하여 무언가가 깨져도 유효한 의견으로 거의 받아들이지 않습니다.

내 질문은 이것이 공정한가요? 아니면 흔한가요?

모든 의견은 "해야 할 것"으로 간주되며 논쟁의 여지가 없습니다.

우선 순위가 없으므로 IMHO는 실제 문제입니다. 당신이 100-300 의견을 얻을 때, 거기 있어야 그들 중 일부는, 그들 중 일부는 프리 오 B (가능성이 나중에 버그로 이어질) 우선 순위 A (실제 버그)를 가진 그들 중 일부는 (다른 모든) C를 프리 오합니다. 동료에게 자신이 원하는 바를 모두 기꺼이 존중하지만 변화를 효과적으로 적용하고 시간이 제한적이라고 우선 순위를 주장하십시오. 그런 다음 prio A 주석을 먼저 수정하여 시작하고 그 후에 더 많은 시간을 보낸다면 B로 시작할 수 있습니다 (행운이 있다면 상사는 prio B와 C를 고정하는 것이 그렇게 중요 하지 않다는 것을 이해하고 당신에게 줄 것입니다 시간을 낭비하는 대신 몇 가지 더 중요한 작업).

코드 검토는 분열 과정이 될 수 있습니다.

하지만 당신은 중요한 교차점에 있습니다. 그들의 검토에 대해 신중한 분석을하십시오. 그들은 nit-picking 문제를 식별하거나 스타일과 논리의 심각한 결함을 강조하고 있습니까?

전자의 경우 해결을 위해 노력하는 것이 좋습니다 (새로운 직업 또는 새로운 코드 검토 프로세스).

후자라면 코드를 전문적인 품질로 끌어 올리기 위해 많은 코드를 읽고 공부하는 것이 좋습니다.

동료들이 코드 검토 프로세스를 사용하여 방법론에 동의하거나 코드를 연마하는 것으로 보입니다. 방금 당신과 같은 코드 검토를 시작했으며 때로는 구현 방식이나 개선 사항에 대해 많은 것을 논의합니다. 이것은 합리적 인 한 전혀 나쁘지 않습니다 (300 개의 댓글이 너무 많이 보이므로 reddit 스레드처럼 보일 것입니다)

코드를 구현하기 전에 코드에 대한 일부 아키텍처 결정에 동의해야하거나 명명 규칙, 패턴 및 모범 사례에 동의하는 것만으로도 "좋은 코드"로 간주되는 항목을 모두 알 수 있습니다.

말한대로 코드 표준을 준수하고 코드가 의도 한대로 작동하는 경우 주석이 너무 많아서 코드를 포럼으로 사용하거나 사용자가 가리키는 것처럼 사용자를 트롤링하고 있습니다.

나는 나 자신에게 비판하려고 노력하고, 대화에 참여하고,이 모든 의견의 이유를보고, 그들이 당신의 코드에 왜 그렇게 불행한지, 그리고 가능하다면 모든 사람을 행복하게하고 코드를 검토하는 데 방해가되지 않는 방식으로 코드를 작성하십시오.

나는 단지 마지막 주석을 읽습니다. 때로는 코드에 동의하지 않으면 코드를 100 번 넘겨보고 다른 아키텍처 결정을 한 이유 때문에 행복하지 않은 모든 곳에서 변경을 제안 할 수 있습니다. 리팩토링 횟수에 관계없이 해당 코드가 마음에 들지 않습니다. 위에서 말했듯이 미리 코드에 대한 접근 방식에 동의해야하므로 코드를 작성할 때 코드에서 기대하는 것을 알 수 있으므로 코드가 더 합리적입니다.

당신이 말하는 것에서, 그들은 PHP 개발자에 대한 편견이있을 수 있으므로, 그들의 요점을 입증하기 위해 코드에 잘못된 모든 것을 찾으려고 노력하고 있습니다 .¹

코드 검토 자체에 관해서는, 이미 말했듯이, 그렇게 많은 양의 사소한 의견은 몇 가지 좋고 유효한 비판보다 덜 도움이된다고 생각합니다. 코드 검토와 관련하여 경험이 제한적이지만 다음 기술은 과거에 근무했던 팀에게 효과적이었습니다.

• 우선, 코드 검토가 수행되기 전에 정적 코드 분석기를 사용하여 대부분의 문제를 식별해야합니다. 예 : Sonar, Lint 또는 기타 우수한 코드 분석기를 통해 코드를 실행하면 대부분의 사소한 문제를 제거하는 데 도움이됩니다. 특히 검토자는 괄호 배치, 공백, 주석, 적절한 변수 이름 지정 등을 보장하기 위해 사용자 정의 프로파일을 정의 할 수 있기 때문에 ...
• 둘째, 의견을 다른 범주로 나누면 잘 작동하는 것 같습니다. 예를 들어, 하나의 그룹에 나중에 주목하고 적용해야 할 작은 것들이 포함 된 두 가지 범주가 있습니다. 또 다른 커밋 및 후속 검토가 필요한 코드를 즉시 수정해야하는 의견에 대한 두 번째 그룹입니다. 물론 후자 그룹의 의견 수는 더 작아야합니다.

또한 첫 번째 실제 코드 리뷰에도 원래 예상보다 많은 주석이 포함되어 있다고 말해야합니다. 그러나 나는 이것을 나쁜 것으로 간주하지 않았습니다. 주석에서 계속 배우고 향후 코드 제출에 새로 배운 기술 / 모범 사례를 적용 할 의사가 있다면 주석은 작아 져야합니다. 그것은 확실히 나를위한 사건이었다 ;-)

¹ 내 경험상 많은 프로그래머가 PHP가 가장 악한 프로그래밍 언어이며 가장 경험이 부족한 프로그래머가 사용한다고 주장함에 따라 많은 일이 발생합니다. 나는 훌륭한 소프트웨어가 어떤 언어로도 작성 될 수 있다고 생각하기 때문에이 진술과는 거리가 멀다!

² 의견이 과도하지만 그 가치가 있다고 가정

누구나 정기적으로 코드 검토에서 100 개 이상의 댓글을받는 것이 일반적입니까? 나는 말하지 않을 것입니다. 코드 품질이 "많이 요구되는"사람들이 많은 의견을 얻는 것이 일반적입니까?

그러나 코드 검토 프로세스의 "규칙"에 따라 다릅니다. 모든 사람은 어떻게해야했는지에 대한 자신의 아이디어를 가지고 있습니다. 코드 검토 프로세스에서 주석이 "이러한 방식 대신이 방식으로 수행해야합니다"형식으로 허용되는 경우 적절한 코드에 대해서도 많은 주석이 표시 될 수 있습니다. 프로세스가 "결함"을 찾으려면 주석 수는 훨씬 작아야합니다.

내 경험상 대체 방법에 대한 "제안"을 허용하는 리뷰는 시간 낭비 자입니다. 이러한 "제안"은 검토 프로세스 외부에서 하나씩 처리해야합니다. 결함 검토는 사람들이 "내가했던 것처럼 왜하지 않았습니까?"대신 버그에 집중할 수있게함으로써 더욱 유용합니다. 또한 누군가가 버그를 발견하면 버그를 거부하지 않기 때문에 더 유용합니다. 따라서 상처받는 감정은 없지만 대신 감사 할 것입니다.

업데이트 : 모든 말로, 일부 코드는 결함이 없어도 평범하지 않습니다. 이 경우 검토 의견은 다음과 같은 단일 의견이어야합니다. "이 코드는 정리해야합니다. 코드가 [여기에서 귀하의 이름으로] 논의 될 때까지 검토를 연기하십시오." 이 경우 주석이 수정 될 때까지 코드에 대한 추가 검토가 중지되어야합니다.

UPDATE2 : @User : 코드 / 디자인을 개발하는 동안 코드 / 디자인에 대해 논의하여 멀리 나아 가기 전에 원하는 것을 구현할 수 있습니까? 제안을 기반으로 코드를 개발하는 방법에 대한 내용을 바꾸고 있습니까? 그들의 의견에서 무엇을 배우고 있습니까?

프로젝트의 리더 인 경우 모든 작업 제품에 대한 책임은 본인에게 있습니다. 작업 제품을 승인하면 제품이 허용된다고 주장합니다. 양질의 제품을 만드는 것으로 유명합니다. 따라서 나는 기대가 있고 만족스럽지 못합니다. 동시에 저는 선호하는 이유를 가르치고 설명하려고합니다. 그러한 선호가 항상 이상적이지는 않지만 (특히 다른 사람들의 눈에) 이러한 선호의 대부분은 경험에서 비롯된 것입니다. 일반적으로 나쁜 것들을 반복하지 않기위한 반응. 따라서 푸시 백에 관계없이 승인을 받기 위해 필요한 몇 가지 개인 "스티커"가 있습니다.

다른 한편으로, 당신은 당신의 작업 제품을 승인하는 데 필요한 기대치를 배워야합니다. 당신은 동의하지 않을 수 있지만, 당신은 규칙을 지배 할 권한이없는 것으로 보이므로 예상되는 것을 배우십시오. 팀이 당신을 실패하게 만들려고 의심합니다. 그렇게하면 그것들도 나빠 보이게됩니다. 그런 점에서, 배우기를 열망하고 있다는 것을 보여주십시오 (아직 그렇지 않더라도). 그들이 말한 것을 취하고 그들의 선호에 적응하기 위해 최선을 다하면, 그것들을 꽤 많이 다시 보게 될 것입니다. 어쩌면 당신이 적어도 견딜 수있는 것을 찾아서 그들이 당신에게 그들의 길을 가르치기 위해 약간의 손을 잡고 있는지 볼 수도 있습니다. 그 과정에서 당신은 실제로 당신의 기술을 다음 단계로 끌어 올릴 수있는 것을 배울 수 있습니다.

팀 검사 프로세스와 몇 가지 중요한 차이점 :

• 검사의 기초는 전체 팀이 수집 한 점검표입니다.
• 초점은 스타일을위한 스타일이 아니라 결함 (현재와 미래)입니다.
• 3 명의 조사관 (저자 포함)은 의견을 정리하기 위해 함께 앉아 있습니다. 다수결의 의견 만 남습니다.

50 LOC에 대해 300 건의 의견은 약간 과도하며, 풀 풀 요청마다 3 명의 리뷰어가 있습니까? 회사에는 많은 리소스가 있어야합니다.

유용한 코드 검토 프로세스에 대한 나의 경험에는 몇 가지 규칙 및 / 또는 지침이 있어야합니다.

• 의견의 우선 순위
• 주석 분류 (버그, 코드 스타일 등)
• 합의 된 아키텍처 / 디자인
• 합의 된 코드 스타일

검토 자로부터 우선 순위를 얻지 못하면 담당 프로젝트 관리자 / 팀장에게 문의하십시오. 비용에 대한 책임자는 우선 순위에 대한 의견을 가져야합니다.

정의 된 아키텍처, 프로젝트에서 사용하는 디자인 패턴 및 동의 한 코드 스타일에 대한 공통된 이해가있는 경우 검토 의견은 보안 문제, 의도하지 않은 버그, 지정된 경우에서 다루지 않는 코너 케이스와 같은 "실제 문제"에 대해서만 표시되어야합니다. 건축 등

개발 팀이 "맛 문제"에 동의하지 않은 경우 (예 : 멤버 변수가 "m_"로 시작해야 함) 모든 검토자는 강제로 시간 / 돈 낭비라는 그의 스타일을 따르도록합니다.

이것은 실제로 의사 소통 문제처럼 들립니다. 코드가 300 개의 댓글을 달기에 충분하지 않을 것으로 예상합니다. 검토 자들은 많은 피드백이 필요하다고 생각합니다. 비동기 방식으로 앞뒤로 논쟁하면 많은 시간이 낭비됩니다. 대체로 300 개의 댓글을 작성하는 것은 엄청난 시간 낭비입니다. 이것이 모두 결함이 아닌 경우, 새로운 팀원으로서 팀의 스타일을 아직 모를 가능성이 있습니다. 그것은 정상이며 전체 팀을 가속화하기 위해 배워야 할 것입니다.

내 제안은 시간을 절약하는 것입니다. 피드백을 가속화하십시오. 나는 :

• 같은 실수를하지 않고 같은 코멘트를 50 번 생성하지 않도록 더 많은 중간 검토를 수행하십시오.
• 검토자가 코드를 검토 할 때 문제가 발생하면 이에 대해 이야기 할 수 있으므로 다음 커밋에서 제거 될 300 개의 "문제"를 피할 수 있습니다.
• 코드를 작성할 때이 "실제"개발자 중 한 명이 한동안 다른 방식으로 어떻게 작동하는지 확인하십시오

사람들은 "시간이 더 걸릴 것"이기 때문에 페어링에 반대 할 수도 있지만 여기서는 문제가되지 않습니다.