주니어 개발자가 코드 검토에 참여하도록 권장하는 방법은 무엇입니까?

저는 현재 아래에 3 명의 주니어가있는 선임 개발자로 일하고 있으며 코드 검토 프로세스를 도입하여 코드 품질을 관리하는 데 도움이되었습니다.

나는 우리 모두가 서로의 작업을 검토하는 것이 매우 유익하다고 생각하지만 프로세스 약 5 주 후에 도구 (BitBucket)에 의견을 남길 수있는 유일한 사람입니다.

나는 직장에서 문화적 문제가 일부 있다고 생각하고, 그들의 의견이 틀릴 경우 자연스럽게 꺼릴 수 있다고 생각하지만, 방법이 있습니까?

나에게, 여기서 질문은 "당신은 주니어 개발자가 코드 리뷰에서 무엇을 찾고 있습니까?"입니다. 저에게 잠재적으로 가장 중요한 것은 주니어 개발자가 희망적으로 좋은 코드를보고 배우는 것입니다. 그들이 코드에서 문제를 발견하면 보너스입니다.

코드 검토에서 학습 할 주니어 스태프를 찾는 경우 가장 중요한 것은 학습이 가치가 있고 시간 낭비로 간주되지 않는 환경을 만드는 것입니다. 이것은 여러 가지를 의미합니다.

• 바보 같은 질문은 없습니다 . 누군가가 약간의 코드를 이해하지 못하면 왜 특정 패턴을 사용했는지, 왜 다른 개발자의 시간이나 다른 시간을 낭비한다고 느끼지 않고 자유롭게 물어볼 필요가 있습니다. .
• 학습 시간은 잘 보냈다 . 당신이 원하는 것이 미래에 더 잘 만들기 위해 더 생산 직원 무슨 일 때문에 주니어 개발자들이 코드를 찾고 그것에 학습 시간을 보내고. 지금 검토해야 할 중요한 수정 사항이 아니라면 코드 검토에 더 많은 시간을 투자하도록 권장하십시오.
• 고위 직원이 항상 옳은 것은 아닙니다 . 오랫동안이 일을했다고해서 옳다는 것을 의미하지는 않습니다. 그들이 버그를 발견했다고 생각한다면 아마도 맞을 것입니다. 이 코드에 다른 디자인 패턴이 적합하다고 생각되면 부정적인 피드백을받지 않고 자유롭게 말할 수 있어야합니다.

매주 정해진 시간에 직접 코드 검토 회의를 갖습니다. 나는 이것을 다음과 같이 내 동료에게 팔았습니다 (실제로 두 수석 개발자이지만 무엇이든).

"코드 검토는 코드를 조금 더 잘 이해하고 언젠가 트럭에 부딪 히고 스프린트를 끝내라는 명령을 받았을 때 사물의 측면에서 무슨 일이 일어나고 있는지 알 수 있도록 부분적으로 있습니다. 코드를 다른 사람에게 설명 할 수 있습니다. 그렇게하면 코드가 뇌의 다른 부분에 관여하고 종종 설명이나 질문이나 의견에 대해 잊어 버린 것을 기억하게 할 수 있기 때문에 코드를 작성하거나 더 읽기 쉽게 만들거나 더 잘 만들 수있는 더 좋은 방법을 깨닫게 할 수 있습니다. 이는 더 아름다운 코드로 이어집니다. "

나는 그것을 쇼와 대화로 생각하고 싶다. 사람들은 동료들에게 자신의 작업을 과시합니다. 동료가 당신의 일에서 잘못된 것을 발견하는 것에 관한 것이 아닙니다. 그것은 모두가 좋아하는 멋진 코드로 동료들에게 감동을주는 것입니다.

그러나 인간 상호 작용이없고, 회의실에서 회의가없고, 화이트 보드가없는 곳에서 코드 검토 도구를 사용한다고 생각합니다. 그러한 도구가 없어야하는 것은 아니지만 코드 검토 회의에서 특정 코드 섹션에 대한보다 심층적 인 검토가 필요할 수 있다는 점에 의지해야합니다. 그런 다음 주니어 개발자 중 한 명을 지정하여 특정 영역에서 다른 사람의 코드를 검토 할 수 있습니다.

좋은 모범을 보이면 도움이 될 수 있습니다. 누군가가 실수를 지적하면 방어 적이 될 수 없습니다. 자신의 코드에서 코드를 검토하고 개선 영역을 확인하십시오. 이것을 팀과 공유하십시오. 결국, 그들은 이것이 장려되고 아무도 그들의 코드에 버그가 있다는 이유로 구타를 당하지 않을 것임을 알게 될 것입니다.

일을한다는 것은 일에 책임과 자부심을 갖는 것을 의미합니다. 코드 검토가 그 일부인 경우 코드 검토 참여가 평가에 포함되어야합니다. 온라인 토론에 참여하는 것이 등급의 일부인 온라인 수업을 수강했습니다. 의견을 구체화해야합니다. "동의합니다"는 허용되지 않습니다.

코드 검토는 코드를 개선해야합니다. 내부 상황에 따라 코드를 작성하는 경우 상황에 따라 판매 번호, 사용자 불만 또는 기타 등급으로 측정 할 수 있습니다. 현실은 코드가 어떤 목적을 달성한다는 것이며 팀은 그 목적을 얼마나 잘 수행하는지 측정해야합니다. 당신이 성공에 기여한다고 생각하는 사람들은 보상에 비례하여 공유하게됩니다.

품질 코드 공개에 중점을 둡니다. 모든 사람들이 버그를 피하면서 자신에 대해 기분이 좋은 것은 아닙니다. 잘못된 코드를 작성합니다. 잘못된 코드를 수정해야합니다. 그것은 일과 삶입니다. 나는 버그를 수정하는 것을 싫어하므로 피하려고합니다. 나는 일에 자부심을 가지고 있으므로 코드가 작동하지 않을 때 나를 귀찮게합니다. 나는 사용자 또는 이러한 것들을 지적하기 위해 시간을 내야하는 다른 사람들에게 기분이 좋지 않으며 그것을 고치려는 동기가됩니다.

참고로, 건설적인 비판을하거나 받아 들일 수있는 환경이 없다면 문제가있는 것입니다.

프로세스 : 누군가가 자신의 변경 사항을 커밋하려고합니다. 누군가 검토 자로 지정되어 변경 사항을 검토합니다. 그런 다음 검토 및 수정 된 변경 사항이 테스트로 이동합니다.

테스트 결과 변경 사항에 도입 된 버그가 발견되면 작성자와 검토자가 모두 책임을 져야합니다.

따라서 주석없이 검토하면 코드가 완벽하지 않으면 문제가 발생할 수 있습니다.