코드 검토에서 검토자가 항상 문제에 대한 솔루션을 제시해야합니까? [닫은]

코드를 검토 할 때 일반적으로 문제를 해결하는 방법에 대한 특정 권장 사항을 만들려고합니다. 그러나 검토에 소비 할 수있는 시간이 제한되어 있기 때문에 이것이 항상 효과가있는 것은 아닙니다. 이 경우 개발자가 솔루션을 스스로 만들면 더 효율적입니다.

오늘 나는 몇 가지 코드를 검토 한 결과 클래스가 잘 설계되지 않았다는 것을 알았습니다. 특정 개체에만 할당되고 다른 개체에는 비워 두는 선택적 속성이 여러 개있었습니다. 이를 해결하는 표준 방법은 클래스를 분할하고 상속을 사용하는 것입니다. 그러나이 특별한 경우이 솔루션은 문제를 복잡하게하는 것처럼 보였습니다. 나는이 소프트웨어의 개발에 직접 관여하지 않았고 모든 모듈에 익숙하지 않다. 그러므로 나는 특정한 결정을 내릴만큼 충분히 지식이 없었습니다.

내가 여러 번 경험 한 또 다른 전형적인 경우는 분명히 의미가 없거나 오해의 소지가있는 함수, 클래스 또는 변수 이름을 찾지 만 좋은 이름을 스스로 얻을 수는 없다는 것입니다.

따라서 일반적으로 검토 자로서 "이 코드는 결함이 있기 때문에 ..., 다르게 수행합니까?"라고 말하거나 괜찮은가?

검토 자로서 귀하의 임무는 코드 (또는 문서)가 검토 전에 합의 된 특정 목표를 충족시키는 지 확인하는 것입니다.

이러한 목표 중 일부는 일반적으로 목표 달성 여부에 대한 판단 요청을 수반합니다. 예를 들어, 코드를 유지 관리 할 수 ​​있어야한다는 목표에는 일반적으로 판단이 필요합니다.

검토 자로서 목표가 달성되지 않은 부분을 지적하는 것은 귀하의 직무이며, 그의 작업이 실제로 목표를 달성하는지 확인하는 것은 저자의 직무입니다. 이런 식으로 수정이 어떻게 이루어져야하는지 알려주는 것은 당신의 일이 아닙니다.

반면에 저자에게 "이것은 결함이있다. 고치 라"고 말하는 것이 팀의 긍정적 인 분위기를 조성하지는 않는다. 긍정적 인 분위기를 위해서는 최소한 왜 눈에 어떤 결함이 있는지를 표시하고 더 좋은 대안이 있다면 좋을 것입니다.
게다가 "잘못된"것으로 보이는 것을 검토하고 있지만 실제로 더 나은 대안이 없다면 "이 코드 / 디자인은 나와 잘 어울리지 않습니다." 확실한 대안이 없습니다. 이에 대해 논의 할 수 있습니까? " 그리고 더 나은 것을 얻으려고 노력하십시오.

여기에 좋은 대답이 있지만 중요한 점이 하나 없다고 생각합니다. 코드를 검토하는 사람, 그 사람의 경험 및 그러한 제안을 처리하는 방법에 큰 차이가 있습니다. 팀원을 잘 알고 있고 "이 코드에 결함이 있기 때문에 다른 방법으로 수행하십시오" 와 같은 메모가 더 나은 솔루션을 제시하기에 충분할 것으로 예상되는 경우 이러한 주석은 괜찮을 수 있습니다. 그러나 그러한 의견이 충분하지 않고 코드를 개선하는 방법을 정확하게 알아야하는 사람들이 있습니다. 따라서 IMHO는 개별 사건에 대해서만 할 수있는 판결 요청입니다.

따라서 일반적으로 검토 자로서 "이 코드에 결함이 있거나 다르게 표시됩니다"라고 말하는 것이 좋습니까, 아니면 특정 솔루션을 생각해 내야합니까?

둘 중 어느 것도 이상적인 IMO가 아닙니다. 가장 좋은 방법은 저자와 대화하고 문제를 공동으로 해결하는 것입니다.

코드 검토는 비동기식 일 필요는 없습니다. 관료적 절차로보고 중단하고 실시간 의사 소통에 약간의 시간이 걸리면 많은 문제가 해결 될 것입니다.

코드 검토에서 검토자가 항상 문제에 대한 솔루션을 제시해야합니까?

아니요. 검토자가 아닌 경우 다음 코더입니다.

코드 리뷰에서 검토는해야 결코 문제에 대한 해결책을 제시하지?

아닙니다. 귀하의 임무는 당면한 문제를 알리는 것입니다. 해결책을 제시하면 문제가 명확 해지면 해결하십시오. 내가 당신의 해결책을 따르기를 기대하지 마십시오. 당신이 여기서해야 할 것은 포인트를 만드는 것입니다. 구현을 지시하지 않아도됩니다.

검토자는 언제 문제에 대한 해결책을 제시해야합니까?

그것이 가장 효과적인 의사 소통 방법 일 때. 우리는 영어 전공이 아닌 코드 원숭이입니다. 때로는 코드가 빠는 것을 보여주는 가장 좋은 방법은 최적보다 적다는 것입니다.

주요 문제는 사람들이 코드를 더 잘 작성하는 방법을 알고 있다면 대개 처음부터 그렇게했을 것입니다. 비판이 충분히 구체적인지 여부는 저자의 경험에 달려 있습니다. 경험이 많은 프로그래머는 "이 수업은 너무 복잡합니다"와 같은 비판을받을 수 있고 드로잉 보드로 돌아가서 더 좋은 무언가를 생각해 낼 수 있습니다. 두통 때문에 쉬는 날이 있었거나 너무 느슨해 졌기 때문입니다. 서두르다.

그러나 일반적으로 합병증의 원인을 적어도 식별해야합니다. "이 클래스는 데메테르의 법칙을 깨뜨리기 때문에 너무 복잡하다." "이 수업은 프레젠테이션 계층과 지속성 계층 책임을 혼합합니다." 이러한 이유를 파악하고 간결하게 설명하는 것을 배우는 것이 더 나은 검토자가되는 것의 일부입니다. 솔루션에 대해 자세히 설명 할 필요는 거의 없습니다.

불량 프로그래머에는 두 가지 유형이 있습니다. 표준 사례를 따르지 않는 표준과 표준 사례를 "만"따르는 것입니다.

작업 접촉이 제한되거나 누군가에게 피드백을 제공했을 때 "이것은 잘못된 디자인입니다."라고 말하지 않을 것입니다. "이 수업에 대해 설명해 주시겠습니까?" 당신은 그것이 좋은 해결책이라는 것을 알 수 있습니다. 개발자는 그가 최선을 다했거나 나쁜 해결책이라는 인식을 진지하게 받아 들였지만 충분합니다.

응답에 따라 각 상황과 사람에게 접근하는 방법을 더 잘 이해할 수 있습니다. 문제를 신속하게 인식하고 스스로 해결책을 찾을 수 있습니다. 도움을 요청하거나 직접 해결하려고 시도 할 것입니다.

우리 사업에는 제안 된 관행이 있지만 거의 모두 예외가 있습니다. 프로젝트와 팀이 접근하는 방식을 이해하면 코드 검토의 목적과 문제 해결 방법을 결정할 수 있습니다.

나는 이것이 명백한 해결책보다 문제에 대한 접근 방식이라는 것을 알고 있습니다. 모든 상황을 다루기에는 너무 많은 변동성이있을 것입니다.

코드를 검토 할 때 약간의 노력으로 그렇게 할 수 있는지 확인한 문제에 대한 해결책 만 제공합니다. 가능한 경우 기존 문서를 참조하여 문제가 무엇인지 생각합니다. 검토자가 식별 된 모든 문제에 대한 솔루션을 제공 할 것으로 예상하면 잘못된 인센티브가 발생하여 검토자가 문제를 지적하지 못하게합니다.

필자의 의견은 여러 가지 이유로 코드를 제공하지 않는쪽으로 향하고 있습니다.

• 그 자체로 설명이 충분하지 않으면, 항상 당신이 생각하고있는 샘플을 요구할 수 있습니다.
• 오랫동안 만지지 않은 일부 코드에 익숙해지기 위해 약간의 수정 만하는 반면 다른 누군가가 방금 시간을 보내면서 시간을 낭비하지 않습니다.
• 그들이 이미 코드 조각에 익숙하고 당신이 모르는 경우, 피드백 만 주면 작성하는 것보다 더 나은 코드를 얻을 수 있습니다. 누군가에게 준비된 솔루션을 제공하면 추가 개선을 고려하지 않고 종종 사용하게됩니다.
• 항상 솔루션을 제공하는 것은 결여에 접해 있습니다. 당신은 누군가를 고용하기에 충분했기 때문에 누군가와 함께 일하고 있습니다. 왜 나쁜 아이디어를 배우게된다면, 피드백을 듣고 스스로 실천함으로써 왜 배우지 않겠습니까?
• 항상 솔루션을 제공하는 것은 이상합니다. 자신의 책상에서 페어 프로그래밍을하고 있다고 상상해보십시오. 발견 한 이유와 이유를 알려주거나 키보드를 잡고 즉시 버전을 표시합니까? 이것이 항상 다른 사람들에게 귀하의 솔루션을 제공 할 수있는 느낌입니다.
• 실제로 작성하는 데 시간을 소비하지 않고 항상 대신 무엇을할지 말할 수 있습니다. 질문의 첫 번째 문제를 설명 할 때 그렇게했습니다.
• 음식을 나눠주지 말고 낚시하는 법을 가르치십시오.)

물론, 특정 대안을 생각하고있는 경우도 있습니다. 그러나 그것은 내 경험상 정말 드 rare니다. (많은 리뷰, 큰 프로젝트) 원저자는 항상 필요한 경우 샘플을 요청할 수 있습니다.

그럼에도 불구하고, 세 번째 이유 때문에, 샘플을 제공 할 때, 예를 들어 "사용 x.foo()하면 완전한 솔루션 이라기보다"이것이 더 간단 해집니다 " 라고 말할 가치가 있습니다 . 또한 시간도 절약됩니다.

코드 검토의 핵심은 검토 전에 규칙에 동의하는 것입니다.

명확한 규칙 집합이 있으면 솔루션을 제공 할 필요가 없습니다. 규칙을 준수했는지 확인하고 있습니다.

대체 개발자의 질문이 나온 유일한 시간은 원래 개발자가 규칙에 맞는 기능을 구현하는 방법을 생각할 수없는 경우입니다. 성능 요구 사항이 있지만 여러 번의 최적화 시도 후 기능이 임계 값보다 오래 걸립니다.

하나! 규칙이 주관적인 경우 "이름은 본인이 승인해야합니다!" 그렇다면 네가 방금 자신의 이름을 지명했으며 허용 가능한 이름 목록을 요청해야합니다.

상속 (선택적 매개 변수) 예제가 더 좋을 것입니다. 긴 메서드와 '너무 많은'함수 매개 변수를 금지하는 코드 검토 규칙을 보았습니다. 그러나 일반적으로 분할하여 사소하게 해결할 수 있습니다. "이 솔루션은 사물을 지나치게 복잡하게 만드는 것"으로, 객관성이 방해를 받고 정당화 또는 대체 솔루션이 필요할 수 있습니다.

잠재적 인 솔루션이 빠르고 쉽고 타이핑하기 쉬운 경우 동료 리뷰 의견에 포함하려고합니다. 그렇지 않다면, 나는 적어도 내 관심사와 왜 그 특정 항목이 문제가되는지 열거합니다. 더 나은 것을 생각할 수없는 변수 / 함수 이름의 경우, 나는 보통 더 나은 아이디어가 없다는 것을 인정하고 누군가가 할 수있는 경우를 대비하여 개방형 질문의 형태로 주석을 끝내십시오. . 이렇게하면 더 나은 옵션을 찾지 못하면 리뷰가 실제로 보류되지 않습니다.

예를 들어, 디자인이 잘못 된 수업으로 질문을했습니다. 과도하게 보일 수도 있지만 상속이 코드가 해결하려고하는 문제를 해결하는 가장 좋은 방법 일 것이라고 의견을 남기고 그대로 두십시오. 나는 그것이 쇼 스토퍼가 아니며 고칠 지 여부에 대한 개발자의 재량에 달려있는 방식으로 문구를 표현하려고합니다. 또한 코드의 해당 부분에 익숙하지 않다는 인정을 받고 더 지식이 풍부한 개발자 및 / 또는 검토자를 초대하여 그 방식대로 된 이유가 있는지 명확하게 설명합니다.

가서 코드를 검토중인 사람과 대화하십시오. 친근한 태도로 이해하기가 다소 어렵다고 말한 다음 어떻게 명확하게 할 수 있는지 토론하십시오.

서면 의사 소통은 많은 시간을 낭비하고 분개하고 오해하게합니다.

대면, 대역폭이 훨씬 높고 적대감을 막기 위해 감정적 인 사이드 채널이 있습니다.

실제로 그 남자와 대화하면 훨씬 빠르며 새로운 친구를 사귀고 더 즐겁게 일할 수 있습니다.