코드를 검토 할 때 일반적으로 문제를 해결하는 방법에 대한 특정 권장 사항을 만들려고합니다. 그러나 검토에 소비 할 수있는 시간이 제한되어 있기 때문에 이것이 항상 효과가있는 것은 아닙니다. 이 경우 개발자가 솔루션을 스스로 만들면 더 효율적입니다.
오늘 나는 몇 가지 코드를 검토 한 결과 클래스가 잘 설계되지 않았다는 것을 알았습니다. 특정 개체에만 할당되고 다른 개체에는 비워 두는 선택적 속성이 여러 개있었습니다. 이를 해결하는 표준 방법은 클래스를 분할하고 상속을 사용하는 것입니다. 그러나이 특별한 경우이 솔루션은 문제를 복잡하게하는 것처럼 보였습니다. 나는이 소프트웨어의 개발에 직접 관여하지 않았고 모든 모듈에 익숙하지 않다. 그러므로 나는 특정한 결정을 내릴만큼 충분히 지식이 없었습니다.
내가 여러 번 경험 한 또 다른 전형적인 경우는 분명히 의미가 없거나 오해의 소지가있는 함수, 클래스 또는 변수 이름을 찾지 만 좋은 이름을 스스로 얻을 수는 없다는 것입니다.
따라서 일반적으로 검토 자로서 “이 코드는 결함이 있기 때문에 …, 다르게 수행합니까?”라고 말하거나 괜찮은가?
답변
검토 자로서 귀하의 임무는 코드 (또는 문서)가 검토 전에 합의 된 특정 목표를 충족시키는 지 확인하는 것입니다.
이러한 목표 중 일부는 일반적으로 목표 달성 여부에 대한 판단 요청을 수반합니다. 예를 들어, 코드를 유지 관리 할 수 있어야한다는 목표에는 일반적으로 판단이 필요합니다.
검토 자로서 목표가 달성되지 않은 부분을 지적하는 것은 귀하의 직무이며, 그의 작업이 실제로 목표를 달성하는지 확인하는 것은 저자의 직무입니다. 이런 식으로 수정이 어떻게 이루어져야하는지 알려주는 것은 당신의 일이 아닙니다.
반면에 저자에게 “이것은 결함이있다. 고치 라”고 말하는 것이 팀의 긍정적 인 분위기를 조성하지는 않는다. 긍정적 인 분위기를 위해서는 최소한 왜 눈에 어떤 결함이 있는지를 표시하고 더 좋은 대안이 있다면 좋을 것입니다.
게다가 “잘못된”것으로 보이는 것을 검토하고 있지만 실제로 더 나은 대안이 없다면 “이 코드 / 디자인은 나와 잘 어울리지 않습니다.” 확실한 대안이 없습니다. 이에 대해 논의 할 수 있습니까? ” 그리고 더 나은 것을 얻으려고 노력하십시오.
답변
여기에 좋은 대답이 있지만 중요한 점이 하나 없다고 생각합니다. 코드를 검토하는 사람, 그 사람의 경험 및 그러한 제안을 처리하는 방법에 큰 차이가 있습니다. 팀원을 잘 알고 있고 “이 코드에 결함이 있기 때문에 다른 방법으로 수행하십시오” 와 같은 메모가 더 나은 솔루션을 제시하기에 충분할 것으로 예상되는 경우 이러한 주석은 괜찮을 수 있습니다. 그러나 그러한 의견이 충분하지 않고 코드를 개선하는 방법을 정확하게 알아야하는 사람들이 있습니다. 따라서 IMHO는 개별 사건에 대해서만 할 수있는 판결 요청입니다.
답변
따라서 일반적으로 검토 자로서 “이 코드에 결함이 있거나 다르게 표시됩니다”라고 말하는 것이 좋습니까, 아니면 특정 솔루션을 생각해 내야합니까?
둘 중 어느 것도 이상적인 IMO가 아닙니다. 가장 좋은 방법은 저자와 대화하고 문제를 공동으로 해결하는 것입니다.
코드 검토는 비동기식 일 필요는 없습니다. 관료적 절차로보고 중단하고 실시간 의사 소통에 약간의 시간이 걸리면 많은 문제가 해결 될 것입니다.
답변
코드 검토에서 검토자가 항상 문제에 대한 솔루션을 제시해야합니까?
아니요. 검토자가 아닌 경우 다음 코더입니다.
코드 리뷰에서 검토는해야 결코 문제에 대한 해결책을 제시하지?
아닙니다. 귀하의 임무는 당면한 문제를 알리는 것입니다. 해결책을 제시하면 문제가 명확 해지면 해결하십시오. 내가 당신의 해결책을 따르기를 기대하지 마십시오. 당신이 여기서해야 할 것은 포인트를 만드는 것입니다. 구현을 지시하지 않아도됩니다.
검토자는 언제 문제에 대한 해결책을 제시해야합니까?
그것이 가장 효과적인 의사 소통 방법 일 때. 우리는 영어 전공이 아닌 코드 원숭이입니다. 때로는 코드가 빠는 것을 보여주는 가장 좋은 방법은 최적보다 적다는 것입니다.
답변
주요 문제는 사람들이 코드를 더 잘 작성하는 방법을 알고 있다면 대개 처음부터 그렇게했을 것입니다. 비판이 충분히 구체적인지 여부는 저자의 경험에 달려 있습니다. 경험이 많은 프로그래머는 “이 수업은 너무 복잡합니다”와 같은 비판을받을 수 있고 드로잉 보드로 돌아가서 더 좋은 무언가를 생각해 낼 수 있습니다. 두통 때문에 쉬는 날이 있었거나 너무 느슨해 졌기 때문입니다. 서두르다.
그러나 일반적으로 합병증의 원인을 적어도 식별해야합니다. “이 클래스는 데메테르의 법칙을 깨뜨리기 때문에 너무 복잡하다.” “이 수업은 프레젠테이션 계층과 지속성 계층 책임을 혼합합니다.” 이러한 이유를 파악하고 간결하게 설명하는 것을 배우는 것이 더 나은 검토자가되는 것의 일부입니다. 솔루션에 대해 자세히 설명 할 필요는 거의 없습니다.
답변
불량 프로그래머에는 두 가지 유형이 있습니다. 표준 사례를 따르지 않는 표준과 표준 사례를 “만”따르는 것입니다.
작업 접촉이 제한되거나 누군가에게 피드백을 제공했을 때 “이것은 잘못된 디자인입니다.”라고 말하지 않을 것입니다. “이 수업에 대해 설명해 주시겠습니까?” 당신은 그것이 좋은 해결책이라는 것을 알 수 있습니다. 개발자는 그가 최선을 다했거나 나쁜 해결책이라는 인식을 진지하게 받아 들였지만 충분합니다.
응답에 따라 각 상황과 사람에게 접근하는 방법을 더 잘 이해할 수 있습니다. 문제를 신속하게 인식하고 스스로 해결책을 찾을 수 있습니다. 도움을 요청하거나 직접 해결하려고 시도 할 것입니다.
우리 사업에는 제안 된 관행이 있지만 거의 모두 예외가 있습니다. 프로젝트와 팀이 접근하는 방식을 이해하면 코드 검토의 목적과 문제 해결 방법을 결정할 수 있습니다.
나는 이것이 명백한 해결책보다 문제에 대한 접근 방식이라는 것을 알고 있습니다. 모든 상황을 다루기에는 너무 많은 변동성이있을 것입니다.
답변
코드를 검토 할 때 약간의 노력으로 그렇게 할 수 있는지 확인한 문제에 대한 해결책 만 제공합니다. 가능한 경우 기존 문서를 참조하여 문제가 무엇인지 생각합니다. 검토자가 식별 된 모든 문제에 대한 솔루션을 제공 할 것으로 예상하면 잘못된 인센티브가 발생하여 검토자가 문제를 지적하지 못하게합니다.