코드를 검토하는 것이 좋습니다?

내가 채용 한 새 관리자를 고용 한 회사는 모든 회의에서 누군가의 코드를 개괄하도록 제안했습니다. 우리는 2 주마다 회의를 가졌기 때문에 개발자 중 한 명이 프로젝터에 자신의 코드를 보여줄 때마다 다른 사람들이 토론 할 것입니다.

나는 이것이 좋을 것이라고 생각했다. 코드를 작성할 때 각 개발자가 더 조심할 것이며 우리의 경험을 더 잘 공유 할 수있다. 그러나 어떻게 든 우리는 이것에 대해 잊어 버렸고 제안은 제안으로 남아있었습니다.

이것의 장점은 무엇이며 단점이 있습니까?

코드 검토는 좋은 습관입니다.

실수로부터 배우고 다른 사람들이 특정 문제를 어떻게 해결하는지 보는 것이 가장 좋은 방법 일 것입니다. 또한 코드 기반에서 품질을 유지하는 가장 좋은 방법 중 하나입니다.

코드 검토는 많은 회사에서 이루어 지지만 모두 따르는 특정 프로세스가 있다고 말하기는 어렵습니다.

보다 공식적인 코드 검토에서 상급자 (또는 여러 명의 노인)는 개발자와 함께 코드를 검토하여 제안과 교육을 동시에 제공합니다.

코드 검토에 대한 추가 혜택 (이 질문에 대해 언급 된)은 다음과 같습니다.

• 가르치고 배우는 좋은 방법
• 그것들은 코드베이스 (스타일과 숙어)의 일관성을 향상시키고 유지하는 가장 좋은 방법 중 하나입니다
• 모든 팀 구성원이 프로젝트에 사용 된 스타일과 관용구 및 사용 방법을 이해하도록합니다.
• 코드 검토를 통해 버그를 발견하고 결함을 조기에 설계함으로써 개발 속도를 높일 수 있습니다 (초기 개발 속도를 늦출 수는 있지만 이후 개발주기에서 배당금을 지불 함)
• 코드 검토 프로세스를 간소화하는 데 도움이되는 툴링 지원이 있습니다.

코드 검토는 특히 새로운 팀원이 보드에있을 때 학습에 매우 유용한 도구입니다 . 글쎄, 그것은 피어 리뷰 프로세스라고도합니다 :)

코드 검토에는 여러 유형이 있습니다.

• 어깨 너머 – 한 개발자가 코드 작성자의 코드를 살펴볼 때 개발자가 코드를 살펴 봅니다.
• 이메일 전달 – 소스 코드 관리 시스템은 체크인 후 자동으로 검토 자에게 코드를 이메일로 보냅니다. 주석에서 추출 : Tortise에 내장 된 히스토리 / 차이 도구를 사용하여 소스 제어에서 새로운 개정을 풀 때마다 동료 변경 사항을 검토하기 위해 관리자가 모든 종류의 공식 코드 검토에 시간을 할당하도록 설득하지 못했습니다.
• 페어 프로그래밍 – 두 명의 작성자가 동일한 워크 스테이션에서 코드를 함께 개발합니다. 이러한 프로그래밍은 Extreme Programming에서 일반적입니다.
• 도구 지원 코드 검토 – 작성자 및 검토자는 피어 코드 검토 용으로 설계된 특수 도구를 사용합니다.

associated disadvantage공식 코드 검토 에서 검토 이벤트 및 실행 시간 을 준비하는 데 상당한 투자 가 필요한 경우는 하나뿐입니다 .

더 많은 참고 문헌 이 아래에 나열되어 있습니다 (더 깊은 다이빙 측정을 위해)

• MSDN-코드 검토
• 응용 프로그램이 출시되기 전에 취약점 찾기 및 수정
• 위키 링크

그 특정 관행은 비효율적이며 창피 할 것 같습니다. 실수를 원하는 사람은 전체 그룹을 가리 킵니다. 따라서 검토 대상을 선택할 수없고 코드가 아직 제작되지 않은 경우 사람들이 불편해질 수 있습니다.

코드 검토 시점에 따라 코드 검토 주석이 코드를 작성하는지 여부에 큰 차이가 생길 수 있습니다. 개발자가 프로덕션 코드 만 선택하고 선택할 수있는 경우 검토 주석이 구현되지 않을 수 있습니다. 개발자들이 다른 사람들이 관심을 가질만한 멋진 기술을 보여줄 수있는 회의를 갖는 것이 좋지만 코드 검토는 아닙니다. 훈련입니다.

모든 코드를 품질 관리로 옮기기 전에 코드를 검토합니다. 모든 조각. 일반적으로 코드 검토 자와 개발자 만 관련됩니다. 코드 검토자가 공식적으로 통과 할 때까지 품질 관리로 이동하지 않습니다. 따라서 개발자는 변경해야합니다. Google은 품질 관리팀이 찾지 못한 많은 문제를 발견하고 신속하게 해결했습니다 (코드 검토에서도 보이지 않는 사항도 발견). 또한 카우보이 코딩을 줄이고 성능이 좋지 않은 사람들을 신속하게 식별하여 문제를 해결하고 응용 프로그램이 손상되기 전에 교육하거나 제거 할 수 있습니다. 코드 검토 시간은 작업을 계획 할 때 예상 시간의 일부이므로 마감 시간에 전혀 영향을 미치지 않습니다. 실제로 문제를 조기에 발견하면 해결하기가 쉬워 장기적으로 시간을 절약 할 수 있습니다.

나는 개인적으로 경험이 부족한 개발자에게 코드 검토를 통해 더 나은 기술을 많이 가르쳤으며 다른 사람들의 코드와 내 코드에 대한 주석을 검토하여 더 나은 기술을 스스로 배웠습니다. 추가 코드 검토를 통해 다른 사람이 코드를 더 잘 유지 관리 할 수있는 코드를 이해하고 있는지 확인할 수 있습니다. 때로는 코드가 작동하지만 검토 문제로 인해 코드를 이해하기 어렵 기 때문에 인력 문제가있을 수 있습니다. 1 년 후 코드 작성자조차도 머리를 긁고 코드가 왜 그런지 궁금해하는 것보다 1 년이 지난 후에도 리마인드하는 것이 좋습니다.

이 유형의 코드 검토 문제, 2 주마다 한 명의 개발자는 진행 속도가 느려집니다. 모두가 주목을 받기까지 몇 달이 걸릴 수 있습니다.

코드 검토는 좋을 수 있지만, 그 이유와 그 수행 절차 뒤에 이유가 있어야합니다.

몇 가지 문제를 결정해야합니다.

• 개발자를 선택할 사람은 누구이며 얼마나 많은 통지를 받게됩니까? 리뷰는 함정입니다.
• 검토중인 코드 부분을 관리 대상, 프로젝트의 수석 개발자 또는 검토중인 개발자 중 누가 선택합니까?
• 코드가 프로젝터에있는 사람에게 더 나은 방법을 가르치는 목적이거나, 코드가 프로젝터에있는 사람이 방 주위의 모든 사람에게 코드를 개선하는 방법을 가르치는 것입니다.
• 이 방법으로 검토 할 코드의 비율은 QA 프로세스의 일부입니까?

이 계획을 제안한 사람들이 이러한 질문에 대한 답변을 아직 얻지 못한 경우 모든 위대한 회사가 코드 검토를 수행하는 방법에 대한 기사를 읽었을 수 있으므로, 그 뒤에있는 목적을 이해하지 않고 수행해야합니다.

코드 검토는 코드 검토 아이디어가 개발 팀에서 나온 경우에만 우수합니다. 개발자는 서로 코드를 검토하기 위해 프로젝터와 프리젠 테이션이 필요하지 않습니다. 그들이 원한다면-회의에가는 것을 선호 할 것입니다.

코드 검토에 대한 아이디어가 경영진에서 비롯된 경우, 이는 소프트웨어 품질이 낮은 것으로 조사되는 것처럼 들릴 수 있으며 개발 팀을 저하시킬 수 있습니다. 관리 팀이 코드 검토 프로세스에 참여해야한다고 생각하지 않습니다. 관리 팀과 함께 코드 검토-매우 나쁘고 죽이고 파괴적인 연습.

코드 검토는 특히 개발자가 지식을 공유하기 위해 수행하는 경우에 탁월한 방법이며 제안 및 비판이 건설적이며 개별 개발자를 대상 연습에 사용하지 않도록 기본 규칙을 미리 설정합니다.

개발자가 아닌 관리자는 코드 검토를 수행하기로 결정한 경우 개발자가 의심하게됩니다. 대부분의 관리자 유형은 개발자가 코드를 볼 때 본질적으로 얻는 세부 정보를 얻고 싶지 않습니다. 대부분의 관리자는 또한 개발자가 왜 한 접근 방식이 다른 접근 방식을 비판하는지 이해하지 못할 것입니다.

개발자가 관리에 대해 수행 한 훌륭한 작업을 보여주고 싶다면 "코드 검토"는 다른 의미를 지니고 있으며 개발자들 사이에서 코드 품질을 지시 / 개선하기 위해 수행 된 코드 검토만큼 상세해서는 안됩니다. 이러한 종류의 프리젠 테이션은 프리젠 테이션의 레벨이 높고 코드에 덜 의존적 일 수있는 경우 개발자가 무엇을 하는지를 보여줄 때 관리자가 이해하는 것 (가치, ROI 등)에 초점을 맞출 수 있습니다. 관리자는 Joe가 X를 구축함으로써 회사에 상당한 가치를 더했다는 것을 이해할 수 있습니다. X는 Y 시간을 절약하거나 주문 당 Z 달러 등을 절약 할 수 있습니다. 개인의 가치를 보여주는 노력의 가치가 있다고 생각합니다 팀원. 그러나 전문 용어 나 너무 많은 세부 수준으로 청중을 압도하지 않도록주의해야합니다.

코드 검토가 가르치는 데 매우 건설적이라는 데 전적으로 동의하지만, 어쨌든 팀의 디자인 패턴이 올바르게 준수되도록하는 것이 중요합니다.

우리는 작은 프로토 타입 작업을 작성하고 약간의 코드를 리팩터링하고 마지막에 제품에 익숙하다고 느끼는 동안 가독성이 손상되었습니다.

당신이 특정 사고 방식에 갇히게 될 때 나는 독립적 인 눈이 항상 유익합니다. 이것은 모든 경험 수준에 있습니다. 설계 및 코드에 몇 시간을 투자했기 때문에 노력이 중단 될 우려가있는 경우 코드 검토를 다루기가 어렵습니다. 그러나 결국, 당신은 더 깨끗하고, 간결하며, 더 관리하기 쉬운 응용 프로그램으로 끝나고 경험이 당신 안에 뿌리 내리게되기를 바랍니다.

우리 팀에서는 @ElYusubov가 언급 한대로 Code Review-Crucible 전용 도구를 사용합니다. 사람들은 코드를 검토하고 주석을 달고 사인 오프합니다. 매주 우리는 흥미롭고 복잡한 코드를 직접보고 검토합니다.

소프트웨어 엔지니어링 인턴으로서 코드 리뷰가 매우 유용하다는 것을 알았습니다.

우리 팀에서는 커밋마다 코드 검토가 필요합니다 (큰 변경은 공식적인 것이되고 작은 변경은 '빠른 모양'입니다). 나는 내가 '보고있다'는 것을 알고 있기 때문에 터미널보다 화이트 보드를 당길 가능성이 높기 때문에 엔지니어링 / 디자인 절단이 이것에 의해 강화 된 것처럼 느껴진다. :)

실제로, 개발 시간이 약간 느린 유일한 단점이있는 훨씬 더 나은 코드를 생성한다고 생각합니다. 또한 팀에 주니어 / 인턴이 있으면 귀중한 피드백을받을 수있는 기회를 얻게 될 것입니다. 나도 알아!

내 경험상 코드 검토는 잘 수행하면 정말 좋습니다. 전문가 / 성숙한 팀원과 관리자가있는 경우 우리는 프로그래머로서 "솔루션 솔버"입니다. 우리의 임무는 "텍스트"줄을 만드는 것이 아닙니다. 그래서 아이디어, 실수, 문제, 경험을 공유해야합니다. 코드 검토는 실제로 이것을 달성하는 좋은 방법입니다.

불행히도 훌륭하게 들리지만 대부분의 회사에서 구현하기는 정말 어렵습니다. 당신의 팀은 많은 "자율성"을 필요로합니다. 새로운 기능을 만들지 않으면 서 관리자 나 재무 부서에 확신을주는 것은 어려운 일입니다.

우리 회사에서는 코드 검토를 시도하고 있습니다. 그러나 '토끼를 쫓는'(기능 만들기)에 너무 많은 시간이 소요됩니다.

요즘 도구 (FXCop 등)를 사용하여 대부분의 스타일과 기본 구문 유형 검사를 수행합니다.

그러나 코드 검토는 특히 팀의 새 구성원, 복잡하거나 영향력이 큰 물건 (예 : 실패하거나 비즈니스에 영향을 줄 경우 중요한 사람들에게 눈에 띄는 것) 및 특히 단기 계약자를 아웃소싱하거나 사용할 때 특히 좋습니다. 번역 오류 / 언어 문제로 인해 소프트웨어가 모든 테스트를 통과 할 수는 있지만 실제로 의도 한대로 수행 할 수는 없습니다.

다른 팀원 (팀장 등)이 개발자와 목록을 작성하는 코드 검토 회의를 갖는 것이 훨씬 좋습니다. 이것은 더 적은 사람들에게 영향을 미치고 스타일 인수에 많은 시간을 낭비하지 않으며 개발자에게는 덜 창피합니다. 개발자가 실제 문제를 흡수하는 것이 더 건설적이고 쉬우 며 "이 작업을 수행했을 것입니다 ..."라는 말로 눈을 멀게하지 않습니다.

또한 코드를 공유하거나 다른 사람이 점심 시간을 포기하기를 희망하는 이메일로 보내는 것과 같이 강제되지 않은 코드 검토는 시간 낭비라고 생각합니다.

커피 더미에 등재 된 더미, 마커 및 커피 한 잔과 함께 앉아있는 것이 좋습니다.

이런 종류의 그룹 쇼 및 텔은 신기술에 적합하거나 여러 jr을 얻는 것이 좋습니다. 개발 속도는 빨라지지만 새로운 코드를 지속적으로 검토하는 것만 큼 좋지는 않습니다. 일대일로 수행하는 것이 더 효율적입니다.

코드 검토는 "전체"를 보는 데 도움이됩니다. 개별 개발자는 자신의 요구 사항 / 문제 만 보는 경향이 있습니다. CR은 전체 관점에서 아이디어와 솔루션을 발견합니다. CR은 주로 불필요한 작업의 낭비를 없애줍니다. 전체 제품이 저렴하고 품질이 우수합니다.