주니어 프로그래머가 시니어 프로그래머 프로젝트에서 코드 검토 자로 참여해야합니까?

주니어 프로그래머 인 저의 팀원 중 한 명이 그의 경험 수준에 대해 인상적인 프로그래밍 기술을 가지고 있습니다.

그리고 코드 검토 중에 실수를 지적하지 않고 학습을 강조합니다.

그러나 상급 프로그래머가 상급 프로그래머를위한 코드 검토에 참여해야합니까? 또는 해당 경험이있는 프로그래머 만 코드 검토에 참석해야합니까?

코드 검토의 기본 목적은 결함 또는 잠재적 문제를 찾는 것입니다. 검토에 필요한 참가자는 직함이나 연석에 관계없이 이러한 문제를 식별하는 데 가장 적합한 사람이어야합니다.

예를 들어, Python으로 응용 프로그램을 개발 중이고 주니어 엔지니어가 코드를 작성한 수석 엔지니어보다 Python 언어에 대한 경험이 더 많은 경우 다른 방법을 지적하는 데 귀중한 자산이 될 수 있지만 시스템 전체에 대한 지식이 부족할 수도 있습니다.

도구와 기술에 대한 경험 외에도 응용 프로그램 분야에 대한 경험도 고려하십시오. 20 년의 경험이 있지만 금융 업계에서 1 ~ 2 명만있는 사람은 전체 경험이 적은 개발자가 5 년의 경험을 가지고 금융 업계에서 자신의 작업을 검토함으로써 도움을받을 수 있습니다.

경험이 적은 직원이 코드 검토 프로세스를 최대한 많이 관찰하고 참여하도록 초대하면 코드 기반을 배우고 질문하고 코드 검토뿐 아니라 그들이 생성하는 코드. 그러나 프로세스에 너무 많은 사람들이 참여하는 것을 원하지 않을 것입니다 (대신 코드 검토 및 그 목적을 완전히 지원할 수있는 사람들에게 초점을 맞추십시오).

이것은 요구 사항, 디자인, 코드 등 모든 종류의 검토에 실제로 적용됩니다.

주니어 프로그래머가 상급 프로그래머의 프로젝트에서 코드 검토 자로 참여해야합니까?

그렇습니다. 다른 사람들의 코드를 읽는 것은 좋은 학습 경험입니다. (그리고 그것은 좋은 코드와 나쁜 코드 모두에 적용됩니다. 선임 개발자의 코드가 나쁘지 않기를 희망하지만 ...)

분명히, 주니어 들만 코드 검토를하는 것은 현명하지 않습니다 . 그리고 그들이 찾을 수있는 것의 측면에서 후배들에게 너무 높은 기대치를 두는 것은 현명하지 않습니다. 그러나 주니어 프로그래머가 테이블에 가져올 수있는 신선한 통찰력에 놀랄 수도 있습니다.

또 다른 답변은 주니어가 위협을 느끼고 있다고 언급했습니다. 그것은 리뷰어 또는 리뷰어들에 대한 코드 리뷰에 관한 것이 아닙니다. 그런 일이 발생하면 그룹은 코드 검토 방식을 변경해야하며 협박자를 끌어 당겨야 할 수도 있습니다.

나는 "주니어"프로그래머가 할 수 있다면 것을 추가 할 수 없습니다 후 노인 코드를 이해하고 자신의 코드의 좋은 척도이다. 모든 사람이 이해할 수있는 코드를 작성하는 것이 불가능할 수도 있지만 예외는 예외 일 것입니다. 1-2 명만 코드를 이해할 수 있다면 해당 사용자를 사용할 수없고 문제가있는 경우 어떻게됩니까? 그것?

사람들에게 새로운 도전을 주면 그들이 발전하는 데 도움이됩니다. 또한 모든 사람이 코드 검토를 위해 잘린 것은 아니지만 누군가가 검토에 도움을주기 전에 제목 ( HR 정치 및 게임에 의해 결정됨) 이 있다고 주장하는 것은 독단적 인 것으로 보입니다 .

다른 사람들이 지적했듯이 코드 검토는 양방향 프로세스가 될 수 있습니다. 모든 사람이 코드베이스를 이해하도록 돕고, 지식을 공유하고, 주니어가 노인으로부터 새롭고 더 나은 방법과 기술을 배우도록 도와 주며, 노인이 이해를 개선하고 글을 통해 모든 사람이 더 많은 시선을 가질 수있는 코드를 따라갈 수 있도록합니다. 실수를 잡아라.

코드 검토의 목적은 유지 관리 성 문제 및 코너 사례와 같이 테스트에서 파악할 수없는 문제를 파악하는 것입니다. 여러 가지면에서 주니어 프로그래머가 그 목적에 더 적합 하다고 주장합니다 .

• 그들은 일반적으로 더 많은 시간을 사용할 수 있습니다.
• 코드를 이해해야 할 때마다 한 줄씩 천천히 가져갈 가능성이 큽니다.
• 유지 관리가 가능한 코드에 대해 이야기 할 때, 이는 최고의 프로그래머뿐만 아니라 회사의 모든 사람이 의미합니다. 즉, 주니어 프로그래머는 코드를 이해하여 유지 관리 가능하다고 선언해야합니다.
• 그들은 종종 잘못된 가정을 할 가능성이 적으며, 어떤 것이 작동해야한다고 생각하는 방식으로 작동한다고 신뢰합니다.
• 프로그래밍 언어에 대한 그들의 교육은 최근에 이루어졌으며 다른 언어에 대한 수년간의 경험과 함께 혼동 될 가능성이 적습니다. 예를 들어, 상급자는 실수로 컴파일하지만 Java에서 미묘하게 다른 C ++에서 가져온 습관을 사용할 수 있습니다. 주니어는 이런 종류의 오류를 더 쉽게 찾아냅니다.
• 코드 검토자는 문제 를 식별 하기 만하면되고 더 나은 솔루션을 제안 할 필요는 없습니다. 그들은 종종 "나는 그것을 더 잘하는 방법을 알 수 없지만이 부분은 모든 반복으로 인해 실제로 혼란스러워한다"는 내용을 자주 언급 할 것입니다. 경험이 풍부한 프로그래머는 처음에는 문제를 눈치 채지 못하더라도 쉽게 개선 할 수 있습니다.

선임 프로그래머가 검토에 더 적합한 다른 방법은 없지만 내 요점은 팀의 다양성을 최대한 활용하지 않으면 장애를 겪고 있다는 것입니다.

주니어는 종종 코드를 유지하도록 요청 받게되므로 이해해야합니다.

때때로 주니어는 선임 개발자의 코드를 검토 할 수있는 유일한 사람들입니다. 선임의 상사가 휴가 중이기 때문에 코드가 QA로 이동하기 위해 기다려야합니까 (코드 검토가 없으면 개발자에게 아무것도 밀어 넣지 않으며이 유형의 코드 검토도 가정합니다)?

또한 주니어가 다른 고객을 위해 비슷한 작업을 수행한다는 사실을 알았을 때 또는 비슷한 기술이나 특정 기술을 보유한 다른 작업을 수행했다는 것을 알게되면 코드 검토를 요청했습니다.

코드가 매우 간단한 경우에는 종종 중급 직원에게 검토를 요청합니다. 후배가 일을 잘 할 수 있다면 왜 노인의 시간을 낭비합니까? 주니어가 시니어 코드를 검토하여 협박 감을 느낀다면 처음에 더 쉬운 부분을 보도록하십시오. 결국 협박 느낌을 멈출 때까지 주니어가 된 것은 아닙니다.

코드를 이해하지 못하는 후배에게 코드를 설명해야하는 경우, 내가 만든 오류 (보통 가정)에서 오류가 발생하고 코드가 실행되어 경험이 많은 코드 검토자가 발견하지 못하는 경우가 종종 있습니다. 그러나 의도 된 것을 정확하게하지 않습니다. 따라서 내용을 설명하는 행동만으로도 코드 검토자가 문제를 찾지 않고도 개발자가 문제를 파악할 수 있습니다. 경험이 많은 사람들이 단계별로 코드를 거치지 않는 경우가 많으므로 이러한 유형의 항목은 후배가 검토 할 때 더 쉽게 찾을 수 있습니다.

주니어가 리뷰에 참여하는 것은 몇 가지 좋은 효과가 있음을 알았습니다. 먼저, 노인의 코드를 이해할 수있을 때 자신감을 갖게됩니다. 해당 코드에서 버그를 찾을 수있을 때 더 자신감이 생깁니다.

그것은 외부의 사고 과정에 노출되어 다른 방법으로 물건을 다루게합니다. 고령자 일지라도 이런 일이 저에게 일어났습니다. 문제를 해결하는 다른 방법을 보는 것이 새로운 가능성을 열어 줄 수 있습니다.

다른 사람들의 코드를 읽는 법을 배우는 데 도움이되며, 코드가 저자의 마음에 새롭고 코드가 무엇을하고 있는지 물어볼 수있는 기회를 제공합니다. 6 개월 후 저자가 오래 갔거나 다른 프로젝트에 바쁘고 질문 할 시간이없는 경우를 유지하는 것보다 훨씬 낫습니다.

문제는 주니어가 약하고 멘토링이 필요한 잠재적 인 영역을 노출 시키므로 (책임자가 더 많은 책임을 맡고 다른 유형의 작업을 수행하는 데 더 많은 시간을 할애 할 수 있음) 코드가 명확하지 않은 영역이기 때문에 연장자에게 좋습니다. 저자를 제외한 모든 사람 (이는 변경이 필요한 시점부터 1 년이 지나서 저자에게 명확하지 않을 수도 있음을 의미) 또한 선배들이 후배들이 자신들에게 신용을주는 것보다 더 똑똑 할 수 있음을 깨닫도록 도와줍니다. 모든 사람이 전문적인 발판을 유지할 수 있도록 도와줍니다. 결국 주니어를 제외하면 심리적으로 불행한 코드를 이해할 수 없다고 생각한다는 것을 분명히 암시합니다.

상급자 코드를 검토하는 주니어는 조직에서보다 전문적인 존경을받을 수 있습니다. 선배들은 자신들이 후배를 과소 평가하고 있다는 것을 알게 될 수 있으며, 후배들은 선배들이 자신이 인정한 것보다 더 많은 것을 알고 있음을 알 수 있습니다. 주니어는 때때로 자신이 가진 것보다 더 큰 기술을 가지고 있다고 생각합니다. 그들이 작성할 수없는 코드에 노출되는 것은 그들이 배울 것이 더 많다는 것을 깨닫기 시작하기 때문에이 사람들에게 좋습니다. 또한 기술을 습득하기 위해 최선을 다할 것입니다. 학교에서 때때로 B 학생들은 누군가가 A 레벨의 작업 샘플을 보여줄 때까지 왜 A를 얻지 못했는지 이해하지 못합니다. 코드 검토에서 후배와 노인에게 동일합니다.

내 대답은 : 때때로 . 프로그래머마다, 작업마다 다릅니다.

에 대한:

• 그 후배들에게 효과적인 코드 검토 방법을 배우기를 원한다면, 선배들이 어떻게 그것을 하는지를 보는 것이 가장 좋은 방법입니다.
• 주니어 프로그래머는 특정 언어 / 도메인 등에서 상급자보다 더 많은 경험을 할 수 있습니다.
• 후배들에게 선배의 코드를 평가하게함으로써 불가피하게 일을 배우게됩니다. 쥬니어 프로그래밍은 주니어가 가질 수있는 모든 질문에 즉각적인 답변을 얻을 수 있기 때문에보다 효과적인 방법입니다.
• 누구의 코드도 신성하지 않으며 코드를 검토 할 정도로 좋은 사람은 없습니다. 이 작업을 수행하지 않으면 누가 최고 사용자 코드를 검토합니까?
• 모든 주니어가 평등하지는 않으며 모든 시니어가 평등하지는 않습니다. 간혹 별다른 차이가 없을 수 있으므로 직책에 매달리지 마십시오.

에 맞서:

• 주니어가 아닌 문제로 인해 리뷰가 엉망이 될 위험이 있습니다.
• 필요한 지식 / 기술 수준은 단순히 주니어의 능력을 넘어서는 것일 수 있습니다. 이것은 그들의 시간을 낭비 할뿐만 아니라 그들도 탈선 할 것입니다.

저는 팀의 모든 사람이 코드 검토의 양쪽에 관여해야한다고 강력하게 믿고 있습니다. 주니어는 시니어 코드를 검토해야하며 그 반대도 마찬가지입니다. 왜 둘 다? 일반적으로 코드가 "문제를 해결하는지"가 아닙니다. 나는 몇 번의 코드를 누군가에게 설명해야하고 설명이 끝날 때까지 훨씬 더 나은 방법을 생각해 냈습니다. 코드 검토는 아마도 3 가지 목적을 제공합니다.

1. 코드가 올바른지 확인하십시오
2. 작가가 다른 사람들이 자신의 코드를 볼 수있는 방법에 대해 생각하게하십시오
3. 개선 될 수있는 내용과 일반적인 두 번째 눈에 대한 독자의 피드백을받습니다.

저는 주니어이며 일반적으로 상급자 작성 코드를 검토합니다. "모든 사람이 코드를 검토하는"일반적인 회사 정책입니다. 나는 이것들을 통해 코드를 검토하고 왜 특정 방식으로 일을하는지에 대한 질문을하는 opporunity를 통해 많은 것을 배웁니다. 때로는 특정 코드를 수행하는 더 깨끗한 방법을 제안합니다. 사람들이 내 코드를 개선하는 방법을 알려주는 것보다 훨씬 드물지만 적어도 한 번은 발생했습니다.

또한 코드 검토의 형식이 중요합니다. 우리는 매우 비공식적이며 칸막이 또는 개인 IRC 채널에서 "내 코드를 볼 것입니다"로 구성됩니다. 좀 더 공식적인 환경에서 코드를 검토하면 주니어가 상급자의 코드를 검토하는 것에 대해 훨씬 더 친밀한 것으로 생각할 수 있습니다.

물론, 주니어 엔지니어는 적어도 때때로 수석 엔지니어의 코드를 검토해야합니다.

필자의 경험에 따르면 일대일 코드 검토에서 검토자가 실제로 검토자가 수석이든 하급이든 원래 코더가 놓친 오류를 보는 경우는 거의 없습니다. 리뷰어 는 인간 일 필요조차 없습니다 . 반면에, 원래의 코더는 코드를 설명하려고 시도하는 동안 실수를 인식하고, 검토자가 주니어가 많을수록 설명의 깊이가 필요하기 때문에 이것이 더 가능성이 높습니다.

제 생각에 오류를 잡는 것보다 장기적으로 더 중요한 코드 검토의 이점을 간과하는 경우가 종종 있습니다.

• 실제로 코드베이스에서 무슨 일이 일어나고 있는지에 대한 지식 공유- "Bill은 X를 수행하는 클래스를 가지고 있다고 생각합니다. 우리는 새로운 클래스를 작성할 필요가 없습니다."
• 좋은 기술과 프로그래밍 스타일에 대한 지식을 공유합니다.

이 두 가지 측면에서, 중급 검토자는 상급자보다 더 많은 혜택을 얻는 경향이 있습니다.

주니어 프로그래머는 반드시 선임 동료를 위해 코드 검토를 수행해야합니다!

그러나 그것들 이 유일한 검토자가되어서는 안됩니다 . 코드 검토마다 더 숙련 된 개발자와 연결하십시오.

수많은 혜택이 있습니다 :

• 저자는 더 많은 코드를 설명해야합니다. 코드를 통해 대화하는 것은 코드에서 문제를 찾는 가장 좋은 방법 중 하나 이거나 더 나은 방법입니다.

• 저자는 코드에서 약점을 발견 할 것입니다. 주니어 개발자는 고급 덩어리에 의해 혼동 될 가능성이 높습니다. 종종, 이것들은 그들 자신의 이익을 위해 "너무 까다로운"것이며, ​​단순화로부터 이익을 얻을 수 있습니다.

• 주니어 개발자는 더 나은 코딩 방법을 배울 것입니다. 코드 검토는 예제를 통해 배울 수있는 기회입니다.

• 주니어 개발자는보다 효과적인 코드 검토자가 될 것입니다. 코드 검토는 어렵다 . 경험이 많은 사람이 코드 검토에 익숙할수록 더 빠르고 효과적인 코드 검토가됩니다.

• 주니어 개발자는 코드베이스에 대해 더 깊이 알고있을 것입니다. 이기적으로 행동하십시오! 주니어 개발자를 일찍 잡아 당기면 더 빨리 전달할 수 있습니다.

• 주니어 개발자는 더 많은 참여를 느낄 것입니다. 주니어 개발자는 "상위"코드 (및 동료)가 덜 외롭고 위협적인 것으로보기 시작합니다. 이것은 코드 검토의 엄청나게 간과되는 이점입니다.

• 주니어 개발자는 신선한 눈입니다. 그들은 오랫동안 코드 기반 작업을 해 온 사람만큼 교리되지 않았습니다. 주니어 개발자는 질문을 할 때 다양한 방식으로 일을 수행 할 가능성이 높습니다. 적어도 약간의 고려없이 그들의 거친 의견을 으 sh하지 마십시오!

• 선임 개발자는 책임을진다. 나는 고위 개발자들이 서로의 코드 (신뢰, 게으름 등)를 선호하는 상황을 자주 보았습니다. 여분의 눈이 낙담하지 않도록 도와줍니다.

고려해야 할 단점은 관련된 모든 당사자가 코드 검토를 수행하는 데 상당한 시간을 소비한다는 것입니다. 따라서 경영진에게 판매하기가 다소 어려울 수 있습니다. 그러나이 혜택은 더 느린 속도보다 훨씬 뛰어납니다.

학습이 아닌 코드 검토를 위해 코드 검토가 수행됩니다. 만약 내가 주니어 프로그래머라면, 선배의 코드를 검토하는 것을 두려워 할 것입니다.

반면에, Senior가 모든 질문에 대답 할 수 있다면 Senior의 코드를 읽는 것이 좋은 학습 방법입니다.

두 가지 대안이 될 수 있습니다.

• 주니어가 코드 검토 회의에 참석하도록하고 모든 참석자가 강의 / 학습 토론에 참여할 수 있도록합니다.
• 연습 페어 프로그래밍