개발자로서 코드 검토를 준비하고 있습니까?

나는 여기에 몇 가지 아이디어를 찾고 있습니다.

코드 검토를 어떻게 수행 하고 코드를 검토해야합니까? 라는 기사를 읽었습니다 . 장점은 무엇입니까? 매우 유익하지만 아래 질문에 대해 더 명확해야합니다.

내 질문은

1. 대상 개발자는 개발자가 코드를 검토하기 전에 통합 할 수있는 모범 사례를 제안 할 수 있습니다.

   • 현재 저는 다음과 같은 방법을 연습합니다

     • 논리적 흐름을위한 PPT
     • 자세한 의견.

문제 : 위의 사례를 구현했지만 검토에 도움이되지 않습니다. 내가 직면 한 문제는 특정 논리가 참조 될 때 구현을 계속 검색하고 프로세스에서 흐름과 너무 많은 시간을 낭비하고 사람들의 신경을 얻는 것입니다.

많은 개발자들이 내가 겪고있는 일을 겪고 있다고 생각합니다.

따라서 OP가 제공 한 세부 정보에 따라 "X를 찾거나 Y를 설명 할 때 신속하게 응답 할 수 있도록 내 코드를 어떻게 배울 수 있을까요?"라는 질문처럼 들립니다.

내가 생각할 수있는 몇 가지 제안 :

• 코딩 할 때 시간을내어 자신의 코드를 배우고 이해해야합니다. 이것은 당신의 TL이 그렇게 많은 단어로 당신을 만나려고하는 것일 수 있습니다. 현재 프로젝트에서 TL이기 때문에 지난 11 개월 동안 많은 코드 검토를 수행했으며 일부 개발자가 자체 코드베이스 또는 다른 곳에서 "예제 코드"를 검색하는 관행을 발견했습니다 (Google , 등 ...) 복사하여 붙여 넣습니다. 개인적으로 코드가 간단한 단위 테스트를 통과하지만 실제로 수행중인 작업을 이해하지 못하기 때문에 참을 수 없습니다. t 발생할 수있는 경계 사례 또는 예상 실패 조건.

• 이전 진술의 결과로, 복사 / 붙여 넣기를해야하는 경우 이전에 작성했고 이해 한 코드 만 복사 / 붙여 넣기를 시도하십시오. 다른 사람들의 아이디어를 "빌려"는 것은 괜찮지 만,이 경우 코드를 한 줄씩 다시 작성하면 작성하는 동안 자신이하는 일에 대해 더 잘 이해할 수있게됩니다. 외부 API를 사용하는 경우 해당 API를 사용하는 예제가 있더라도 몇 분 동안 참조를 찾고 API 작동 방식을 학습하십시오. 이전에 작동했다면 상황에서도 작동한다고 가정하지 마십시오.

• DRY 원칙 을 읽고 사랑하는 법을 배우십시오 . 복사 / 붙여 넣기를하려는 많은 경우를 공통 위치 (별도 기능, 별도 클래스, 별도 라이브러리 ...)에 배치 할 수 있습니다.

• SOLID 원칙 을 읽고 사랑하는 법을 배우고 그 자리에있는 동안 mouviciel이 이미 언급 한 KISS 를 검토 하십시오. 이 원칙들은 모두 매우 간결하고 깨끗하며 모듈 식 코드를 만드는 데 중점을두고 있습니다. 그 안에 큰 클래스와 큰 함수가 있다면, 물건을 찾기가 훨씬 더 어려워지고 그 위에 코드가 무엇을 설명하는지 시도하십시오. 반면에 SRP를 따르거나 적어도 따르려고하면 각 클래스 / 함수가 한 가지만 책임지게하면 코드가 작고 읽기 쉽습니다.

• Clean Code 사본을 선택하십시오 . 아주 좋은 책입니다. 자체 설명이 있고 읽기, 유지 관리 및 확장이 쉬운 코드 작성에 대해 설명합니다. 읽기 쉬운 코드 작성을 연습하면 코드 검토에서 자신의 코드를 읽는 데 문제가 없어야합니다. 그리고 이것은 재미있는 부분입니다. 사람들에게 자신의 코드를 읽거나 변수가 무엇을 나타내는 지 말해달라고 요청했으며 일주일 전에 코드를 작성했지만 응답 할 수 없었습니다 (레거시가 아닌 새로운 클래스). . 좋은 이름은 먼 길을갑니다.

• 모든 단순화 및 리팩토링 후에도 여전히 명확하지 않은 일종의 알고리즘을 수행 해야하는 기능이 있다면 시간을내어 알고리즘을 설명하는 주석 블록을 작성하십시오. 2 개월 후 해당 기능을 수정해야 할 때 도움이 될뿐만 아니라 코드 검토에서 매복 된 경우 작성한 내용을 간단히 읽을 수 있습니다.

• 위의 모든 항목을 수행 한 후에도 여전히 문제가 있습니까? 팀에 익숙하지 않고 많은 레거시 코드로 작업하도록 요청 했습니까? 이 경우, 귀하의 TL이 A $$가 될 수 있으며 회의 전에 쉽게 참여할 수 있고 관련된 모든 사람의 시간을 낭비하지 말고 적극적으로 요청할 수 있습니다. 새로운 사람들이 팀에 합류 할 때, TL은 새로운 플랫폼, 새로운 제품, 새로운 사람들, 새로운 환경에서 일할 때 새로운 환경에서 많은 집중을 필요로하기 때문에 충분한 인내심을 가져야합니다. 설계대로 작동하고 TL이이를 수락해야합니다.

• 위의 모든 항목 후에도 여전히 끔찍한 코드 리뷰가 있다고 생각합니다. TL과 대화하십시오. 실제로 TL이 당신에게 완전히 만족할 때 코드 검토 회의의 특성으로 인해 사람들이 기분이 좋지 않을 때가 있습니다. 코드 검토를 수행 할 때 변경해야 할 사항을 강조하고 변경 사항을 이해하고 계속 진행해야합니다. 많은 시간을 정중하게 할 시간이없고 어떤 사람들은 방어 적이며 내 의견 하나 하나에 답하려고합니다. 이러한 상황에서 코드 검토 회의가 중단되어 중단하고 중단하는 경향이 있습니다. 일반적으로 회의가 끝난 후 나는 새로운 사람들과 대화를 통해 과정을 이해하고 개인적인 것이 아님을 확인했습니다. 몇 가지 코드 검토 후 사람들은 일반적으로 훨씬 더 편안합니다.

연습은 다양하지만 내 경험에 따르면 :

• 코드에 특별한 작업을 수행하지 마십시오. 코드가 검토 될 것임을 알면 코드를 조금 더 알아내는 것이 당연하며 철자 오류와 같은 명백한 사항을 수정해도 아무런 해가 없습니다. 그러나 검토가 예정되어 있기 때문에 자세한 설명을 많이 추가하거나 코드를 변경하지 마십시오.

• 검토 전에 코드를 준비하고 검토 자에게 배포합니다. 이것은 일반적으로 코드 검토 촉진자 인 중립적 인 제 3 자에 의해 수행됩니다. 인쇄 된 코드는 줄을 너무 자주 감쌀 수있을 정도로 작아야하지만 모든 사람이 쉽게 읽을 수있을 정도로 커야합니다. 그것이 필요한 경우 가로 형식으로 인쇄하십시오.

• 코드는 줄 번호 와 함께 인쇄되거나 표시되어야합니다 . 번호는 한 파일에서 다음 파일로 계속되어야합니다. "foo.c의 238 행"보다 "3502 행"을 참조하는 것이 훨씬 쉬우 며 숫자를 사용하면 모든 행을 찾는 데 시간을 낭비하지 않고 특정 행에 대해 이야기 할 수 있습니다.

• 확실히 촉진제가 있어야한다 . btw. 그의 임무는 리뷰가 미미한 상황에 빠지지 않도록하고, 개인적이거나 열이 나지 않도록하며, 리뷰 기간을 엄격히 제한하는 것입니다.

• 작성자 는 검토 회의 전에 코드를 직접 검토 해야합니다 . 이것이 다른 사람의 코드 인 경우 제안한 변경 사항을 기록하십시오. 이것은 며칠 안에 보지 못했던 코드에 대한 기억을 자극하고, 중요한 눈으로 자신의 코드를 보는 연습을 도와줍니다. 검토 자 및 작성자로서 몇 가지 검토를 거친 후에는 자신의 메모가 그룹의 나머지 메모와 더 밀접하게 일치한다는 것을 알 수 있습니다.

• 검토 중에 메모 할 준비를하십시오 . 이는 주요 관심사가되어서는 안됩니다. 다른 사람이 그룹이 동의 한 작업 항목을 기록하여 코드를 설명하고 피드백을 듣는 데 집중할 수 있도록해야합니다. 그러나 행동 항목이 아닌 귀중한 피드백을받는 경우가있을 수 있습니다.

• 개인적이 아님을 기억하십시오. 검토하는 동안 방어적인 느낌 (및 행동)을 피하기는 어렵습니다. 코드가 잘못 이해되었다고 생각되면 코드를 설명하는 것이 좋지만, 무엇보다도 듣기 만하면됩니다.

한가지 더 다른 답변에 추가 : 만드는 형식 의, 행동 로트 코드 검토 쉽게 비공식적 코드 리뷰! 예를 들어 :

"이봐 밥, 내가 foo () 함수를 어떻게 구현했는지 보여줄 수 있니?" "스티브,이 수업 다이어그램을보고 어떻게 생각하는지 알려줄 수 있습니까?" "카렌,이 문제에 대해 생각하도록 도와 주실 수 있습니까? 좋은 해결책이 있다고 생각하지만 도움을받을 수 있습니다 ..."

이것을 규칙적인 습관으로 만드십시오. 설계 프로세스 초기에 동료를 참여 시키면 다음과 같은 이점이 있습니다.

• 관계 구축
• 문제에 대한 새로운 통찰력 확보
• 현재 문제 / 해결책을 설명 할 수있는 능력 향상
• 공식 코드 검토에서 나중에 시간을 절약하십시오