점차 코드 검토를 도입하는 방법은 무엇입니까?

저는 수석 엔지니어 6 명과 팀을 이끌고 있습니다. 모든 표준 이유로 코드 검토를 수행하면 큰 도움이 될 것입니다. 모든 변경이 반드시 필요한 것은 아니지만 최소한 꾸준한 배경 검토 흐름이 필요합니다. 그래서 사람들은 적어도 다른 사람들의 변화를보고 그것에 대해 이야기하기 시작합니다.

리뷰를 소개하는 좋은 방법이 있습니까? 한 가지 더 할 일이 있고 대화가 고통 스러울 수 있기 때문에 팀의 큰 꺼려를 느낍니다. 모든 변경 사항을 검토하는 것은 적어도 첫 단계로 시작하는 것이 아닙니다. 나는 사람들이 리듬에 들어가서 양을 늘리기 전에 저주파수로 리뷰를하는 연습을하고 싶습니다.

누구나 코드 검토를 점진적으로 도입 했습니까? 방법? 그래도 "핫"파일이나 라이브러리에 대한 리뷰가 필요합니다. 또는 무작위로 따기. 또는 "선택"변경 사항을 선택해야합니다. 아니면 급락하고 모든 변화를 행하는 유일한 길입니까?

이것은 툴링이나 프로세스의 문제가 아닙니다. 문화에 관한 것입니다. 당신은 비판에 민감하고 자신의 일을 보호하는 사람들로 구성된 팀을 설명합니다. 그것은 아주이다 매우 일반적인. 그러나 그것은 전문적이지 않습니다.

나의 조언은 모범을 보이도록 시작하는 것입니다. 검토를 위해 커밋을 제공하십시오. 사람들이 접근 방식의 문제를 강조하도록 요구하는 것에 대해 공개하십시오. 피드백을 수용하십시오. 방어 적이 지 말고 피드백의 이유를 탐색하고 팀으로서의 행동에 동의하십시오. 열린 대화의 분위기를 장려하십시오. 당신의 팀에서 이것을 할 의향이있는 챔피언을 찾으십시오.

힘든 일입니다.

첫 번째 단계는 누군가에게 걸어 가서 "이봐, 내 코드를 검토하겠습니까?"라고 말하는 것입니다. 조직에서보고 싶은 변화가 되십시오. 기꺼이 그렇게 할 수있는 개인을 찾지 못하면 전체 팀을 설득 할 수 없습니다. 두 사람이 성공하면 팀에 다시보고하십시오.

당신이 당신의 코드를 검토하는 사람을 발견하면 당신은 몇 가지 검토하면 그들이 마음 경우, 물어 자신의 코드를. 에 대한 학습 기회로 구문을 당신 과하지의 기회를 그들 자신의 코드를 개선하기 위해.

팀 리더로서 코드 검토 프로세스에서 얻는 가장 큰 가치 는 진행중인 작업에 대한 인식 입니다. 개발자에게 변경 사항이나 제안 사항이 없더라도 각 변경 세트를 볼 수있는 기회를 얻고 싶습니다. 나는 이것을 "인식 리뷰"라고 부릅니다. 병목 현상이 발생하지 않도록 30 분 이내에 전환 할 수 있습니다.

나는 당신이 그로 시작 제안합니다. 코드 검토 제출 프로세스를 정의하고 (TFS를 사용하는 경우 꽤 잘리고 건조됩니다) 체크인하기 전에 모든 사람이 변경 세트 제출에 참여하도록하십시오. 그들에게 그것이 단지 인식을위한 것이며 그들의 코드를 비판하지 않을 것이라고 말하십시오.

인식 검토를 두 번 반복 한 후 팀의 다른 구성원이 서로의 코드를 검토하도록 다시 시작하십시오. 믿거 나 말거나, 이것만으로 팀 응집력과 코드 균일성에 도움이 될 수 있습니다.

팀 전체가 참여하면 개발자가 서로의 코드에 대한 제안을 거부 할 수 없다는 것을 알게 될 것입니다. 자연스럽고 유기적으로 일어날 것입니다 (엔지니어는 스스로 도울 수 없습니다!) 그런 다음 설정하십시오. 축하합니다. 이제 전체 코드 검토 모드에 있습니다.

리뷰를 소개하는 좋은 방법이 있습니까?

팀과 검토를 통해 얻을 수있는 이점에 따라 몇 가지 좋은 방법이있을 수 있지만 모든 접근 방식에는 몇 가지 공통된 기능이 있습니다.

• 예상 사항 설명 : 이는 팀을위한 새로운 프로세스이거나 최소한 기존 프로세스를 변경 한 것이므로 변경을 제기 한 이유, 팀의 이점을 팀에 알리는 것은 공정합니다. 어떻게 작동하는지 알 수 있습니다.

• 프로세스 정의 : 팀원 모두 가 진행 방법 을 알 수 있도록 코드를 검토하고 변경 사항을 논의하기 위해 따라야하는 프로세스를 사람들에게 안내 합니다.

• 기준을 정의하십시오 . 개선이 필요한 것으로 사람들이 부르거나 말아야 할 종류의 변화를 배치하십시오. 예를 들어, 버그와 성능이 크게 향상되는 것이 좋습니다. 코딩 표준, 가독성 및 유지 보수성 문제에 주목해야하지만 그렇지는 않다. 개인적인 취향이나 스타일의 문제는 혼자 두어야합니다.

• 행동에 대한 토론 : 목표는 코드를 개선하고 팀이 전반적으로 더 나은 코드를 작성하는 데 도움이되는 공통된 이해를 장려하는 것임을 지적합니다. 몇 가지 기본 규칙을 마련하면 코드 검토에 대한 자격을 완화 할 수 있습니다.

• 먼저 뜨거운 자리에 자신을 넣어 : 개별 리뷰 또는 그룹 리뷰가 계획 여부, 아마 그룹으로 처음 몇 통과하는 것이 좋습니다. 첫 번째 검토는 다른 팀 구성원이 프로세스가 그렇게 나쁘지 않고 사용자가 직접 처리 할 수 ​​있음을 알 수 있도록 자신의 코드로 작성해야합니다.

시작 회의를 시작하여 위의 모든 사항을 설명하고 팀원의 우려를 해결하십시오. 프로세스를 문서화 한 이메일로 후속 조치를 취하십시오.

한 가지 더 할 일이 있고 대화가 고통 스러울 수 있기 때문에 팀의 큰 꺼려를 느낍니다.

이것들은 두 가지 분명한 관심사입니다. 검토가 도움이 될 것이라고 생각되면 일정에 시간을 들여 검토해야합니다. 팀 구성원은 검토가 다른 작업과 동일한 작업이며 다른 작업을 동일한 속도로 계속 완료하면서 수행해야하는 추가 작업이 아니라는 점을 이해해야합니다.

그룹 검토 회의는 토론을 계속 진행하고 회의 시간을 제한하며 상황을 건설적으로 유지하는 진행자가 주도해야합니다. 그것은 고통스러운 대화를 피하기 위해 먼 길을 가야합니다. 개별 검토를 시작할 준비가 될 때까지 팀은 상황을 스스로 구성하는 데 도움이되는 행동을 취했을 것입니다.

또한 검토 프로세스를 때때로 검토해야합니다. 프로세스가 얼마나 잘 작동하는지, 개선 될 수있는 방법, 포기해야 할 관행 등 프로세스를 논의하기 위해 팀을 너무 자주 모으십시오. 프로세스에 대한 소유권을 부여하고 새로운 일을 할 수있는 자유를 팀에 부여하십시오.

이를 수행하는 한 가지 방법은 각 스프린트 후 코드 검토 세션을 수행하고 팀의 모든 사람이 참여할 수 있도록 코드가 일종의 대형 화면으로 투영되는 모든 사람의 변경 사항을 수행하는 것입니다. 모든 개선 사항은 백 로그에 기술적 부채로 추가 될 수 있습니다.

이 방법은 효과가 있지만 완벽하지는 않습니다.

궁극적 인 목표는 풀 요청을 사용하여 코드를 다시 마스터로 병합하거나 각 코드 행을 검토해야하는 분기를 개발하는 것입니다.