그 연습에서 왔을 때 새로운 장소에서 코드 리뷰를 처리하지 않는 방법은 무엇입니까?

새 회사의 팀에는 코드 검토 프로세스가 없습니다.

필자는 문화를 코드로 검토하는 회사에서 왔으므로 다른 사람이 코드를 검토하지 않고도 코드를 커밋하는 것이 불편하다고 느낍니다.

나는 코드 검토가 품질을 향상시키고 시간을 절약하는 방법이라고 생각합니다.

• 코드 검토가 시간 낭비가 아니라 시간 절약임을 어떻게 알 수 있습니까?
• 단위 테스트가있는 경우 코드 검토를 건너 뛸 수 있습니까?

단위 테스트가있는 경우 코드 검토를 건너 뛸 수 있습니까?

그런데 왜?

동료 검토의 주요 역할은 버그를 파악하지 않는 것입니다.

예, 잠재적 인 버그와 의심스럽고 버그가 발생하기 쉬운 코드를 식별 할 수 있습니다. 이러한 경우가 종종 발생하지만 때때로 실수를 발견한다고해서 동료 검토가 버그의 존재를 배제 하는 신뢰할 수있는 방법은 아닙니다 . 그것과는 거리가 멀다. 구현 의 기능적 정확성 을 검증하는 것은 올바른 도구가 아닙니다 .

코드 검토는 코드 유지 관리 기능을 강화 합니다. 코드를 제작하기 전에 코드가 깨끗하고 이해할 수 있어야합니다 (저자 만이 아니라).

단위 테스트의 존재는 그것과 완전히 직교합니다. 100 % 코드 적용 범위와 모든 테스트를 통해 완전히 이해할 수없는 코드를 전달할 수 있습니다.

코드 검토는 또한 다른 개발자가 자신의 작업에 익숙해 지도록 도와주는 역할을합니다. 휴일에있을 때 버그 보고서를 처리하거나 처리 할 수 ​​있습니다. 직접 수행 한 작업을 알면 도움이 될 수 있습니다. 작업을 잘 수행하십시오-코드베이스를 일관되게 유지하거나 (앱 전체에서 유사한 패턴과 규칙을 따르십시오) 코드 중복을 피하십시오.

더 넓은 사물 체계에서, 다른 사람의 코드를 읽음으로써 개발자로서 배우고 성장합니다.

단위 테스트는 그 어느 것도 대체 할 수 없습니다. 그렇습니다. 글이 잘 작성되면 문서처럼 읽히기 위해 노력해야합니다. 그러나 이것은 다시 피어 검토를 수행하는 것과 상호 배타적이지 않습니다. 상대적으로 피어 검토의 모든 장점은 여전히 ​​유지됩니다. 동료가 볼 수있는 멋진 단위 테스트가 있다는 사실은 검토 프로세스를 쉽고 편리하게 만듭니다. 중복이 아닌.

코드 검토가 시간 낭비가 아니라 시간 절약을 보여주는 연구 및 통계가 있습니까?

나도 몰라 코드 검토를 사용하고 다른 팀은 그렇지 않은 작업 을 수행하기 위해 동일 하고 현실적인 복잡성을 갖는 두 팀이 필요하기 때문에 그러한 연구를 수행하기도 어렵습니다 . 아마도 같은 문제를 해결해야 할 것입니다 . 이는 창 밖으로 많은 돈을 버리는 것을 의미합니다. 그리고 통계적 관련성을 얻기에 충분할 정도로 실험을 자주 반복해야하는데, 이로 인해 돈이 크게 증가 할 것입니다.

그렇지 않은 회사에 대해 코드 검토를 사용하여 회사의 효율성을 측정하는 경우 효율성을 측정하는 방법과 실제 원인이 무엇인지 확실하지 않습니다. 코드 검토는 더 큰 문화의 일부입니다. 실제로 팀의 효율성을 높이는 부분은 말하기 어렵습니다 (그리고 팀이나 프로젝트의 특성에 따라 결정될 수 있음). 또는이 문화의 존재는 단순히 회사가 더 작거나 더 젊다는 것을 의미 할 수 있으며, 각 회사는 많은 영향을 미칩니다. 또는 코드 리뷰에 기꺼이 제출하면 자존심과의 건강한 거리를 배제하거나 장려 할 수 있습니다.)

그러나 잊지 마십시오. 자신 만의 경험이 있습니다. 그들이 당신을 고용 한 이유의 일부입니다. 따라서 실제로 효율성을 높일 수 있다고 생각하면 (그리고 팀에 실제로 부족한 상황이 발생하면) 명확하게 전달하십시오.

단위 테스트가있는 경우 코드 검토를 건너 뛸 수 있습니까?

아니. 테스트의 중요성을 믿는다면 실제로 테스트를 먼저 검토해야합니다. 그들이 말도 안된다면? 또는 보장 범위가 거칠다면? 아니면 행동보다는 구현을 테스트한다면?

내가 찾은 임의의 슬라이드 에서 가져온 것이지만 하드 데이터는 Steve McConnell의 Code Complete 책에서 나옵니다.

코드 리뷰가 유용합니까?

"피어 코드 검토는 코드를 개선하기 위해 할 수있는 가장 큰 일이라고 생각합니다."

http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html 의 코딩 공포의 Jeff Atwood

---

"개별 검사는 일반적으로 결함의 약 60 %를 포착하는데, 이는 프로토 타이핑 및 대량 베타 테스트를 제외한 다른 기술보다 높습니다."

Steve McConnell, 코드 완성 2 판, 485 페이지

60 %의 수치는 Shull et al 2002의 IEEE 결함 논문에서 발췌 한 것입니다.

"피어 리뷰는 결함의 60 %를 포착합니다"

면책 조항 :이 답변은 나의 개인적인 경험입니다 :)

우리가 유지 관리하는 코드의 코드 검토에 대해 매우 나쁜 경험을했습니다. 우리는 보통 라이너가 하나 밖에없고 검토 할 것이 많지 않기 때문입니다.

그러나 실제 프로젝트에서 나는 좋은 경험을했고, 시험 시간에 트레이너가 내 코드를 정기적으로 검토했으며 더 이상하지 않는 실수를 찾는 데 많은 도움이되었습니다.

그래서 나는 그것이 당신이하는 일, 얼마나 많은 사람들 등에 달려 있다고 말할 것입니다.

또한 코드 검토가 전쟁으로 끝나는 위험은 과소 평가되지 않습니다.

코드 검토가 정상적으로 수행되지 않더라도 팀 리더 및 / 또는 동료에게 코드 검토를 요청할 수 있습니다.

검토하기 전에 코드를 잘 작성하고 테스트했는지 확인하십시오.

내가 팀장이었을 때, 나는 새로운 직원들에 대한 코드 검토를하는 데 사용했다. (잠시 후) 나는 코드에서 비판 할 버그 나 다른 것을 찾는 것을 그만 둘 것이며, 그 시점에서 그들과 코드 검토를 중단 할 것이다. 다음과 같은 경우에 발생합니다.

• 그들은 인터페이스하는 시스템을 배웠고 이에 대한 설명이 필요하지 않았습니다.
• 그들은 코드를보기 전에 버그가 없어 질 때까지 코드를 디자인하고 테스트하는 법을 배웠습니다.
• 그들은 코딩 스타일 가이드 라인에 대해 충분히 배웠다.

코드 검토에는 몇 가지 목적이 있습니다.

• 코드에서 결함 찾기
• 팀원 간의 지식 이전

팀이 숙련 된 팀원들 사이에서 코드 검토를 건너 뛰도록 선택하더라도 신입 사원의 코드 검토를 수행하는 것이 좋습니다.

개발 된 모든 소프트웨어에서 코드 검토를 수행 할 수있는 경험은 없습니다. 응용 프로그램의 범위, 클라이언트 크기 및 회사 규모에 따라 다릅니다. 예를 들어 향후에 더 이상 버전이 구현되지 않을 수있는 간단한 애플리케이션이있는 애플리케이션을 빌드하는 경우 유닛 테스트로 충분합니다. 그러나 더 빠른 성능을 위해 더 나은 방법으로 수행 할 수있는 코드가 짧게 떨어지는 코드를 검토해야하는 응용 프로그램의 성능에 대해 이야기 할 때 다시 코드 검토가 이루어집니다.

코드 검토는 일반적으로 2 명 이상의 개발자로 구성된 팀과 기술 책임자가 응용 프로그램의 품질을 보장하고 향후 개선을 위해 응용 프로그램의 규모를 조정하고 다른 응용 프로그램으로 업그레이드하기 위해 코드 표준을 준수하도록하려는 기술 책임자에서 수행됩니다. 다음 버전.

예를 들어, 현재 많은 CMS 오픈 소스 플랫폼을 보유하고 있으며 이러한 플랫폼은 플랫폼 기능을 향상시키기 위해 때때로 업그레이드를 릴리스하고, 이러한 플랫폼 중 하나를 사용하는 개발자를 상상하며 코어 파일의 하드 코딩, 애플리케이션 작성과 같은 코드 표준을 따르지 않았습니다. 템플릿 파일의 코드를 작성하고이 코드가 프로덕션으로 이동 한 후 클라이언트가 플랫폼을 새 버전으로 업그레이드하려는 경우 해당 플랫폼의 코드 표준에 따라 코딩을 다시 수행하지 않으면 업그레이드되지 않습니다. 여기서는 코드 검토를 수행하지 않고 코드를 프로덕션으로 릴리스하는 것이 심각한 문제가됩니다.

따라서 릴리스 전에 코드 검토를 수행하는 것은 모든 전문 소프트웨어 회사의 필수 요소이며 개발자가 노련한 프로그래머이며 경험이 풍부한 개인 / 매우 소규모 응용 프로그램에만 예외가 될 수 있습니다.

코드 검토는 검토 프로세스 자체에서 얻을 수없는 장점이 있습니다. 고품질이지만 짧은 시간 내에 생성 된 코드를 얻는 데는 항상 딜레마가 있습니다. 코드 검토가 없으면 사용자가 직접 수행 할 수 있으므로 짧은 시간 안에 코드를 작성하기위한 품질을 희생 할 수 있습니다. 코드 검토를 통해 코드 품질이 떨어지는 것을 피할 수없는이 검토자가 있습니다. 정확히 원하는 것입니다. 처음에 원하는 품질 코드를 얻는 데 시간을 소비해야합니다. 더 나은 코드를 작성하는 데 소요되는 시간은 디버깅 (또는 그 이상)으로 2 시간이 절약되므로 시간을 절약 할 수 있습니다.

코드 검토가 없으면 자신의 책임이므로 높은 코드 품질을 유지하는 것은 사용자의 몫입니다. 간단한 해결책은 모든 변경 사항을 검토하고 품질 표준에 맞지 않는 사항을 수정하는 것입니다.

이것은 또한 코드 검토가 자아의 충돌로 이어지는 끔찍한 상황을 피합니다. 프로그래머 A는 메소드 X를 사용하고 B는 메소드 Y를 사용합니다 .A가 코드를 작성하면 A는 메소드 X를 사용합니다. 따라서 A는 방법 Y를 사용하여 코드를 다시 작성하지만 B가 코드를 작성하고 A를 검토 한 경우에는 정반대의 상황이 발생했을 것입니다.

코드 검토를 옹호하는 사람이라면 실제로 대체 할 것이 없습니다. 불행하고 틀에 박힌 사건은 (A) 실습에 익숙하지 않거나 (B) 코드 검토를 받기 위해 시간과 노력을 바치고 싶지 않기 때문에 코드 검토를 수행하지 않는 작업장입니다. 그 자리에 시스템.

기본적으로 원하는 것을 얻으려면 직장 문화 변화가 필요합니다. 결코 간단하거나 쉽지 않습니다. 작업장을 100 % 설득하더라도 코드 검토가 우수하고이를 채택하려고한다는 사실을 잊지 마십시오. 실제로 새로운 작업 방식으로 전환하려면 상당한 시간, 에너지 및 생산성 투자가 필요합니다. 이 투자는 그 자체로 상환되어야하지만, 단지 지불을 위해서가 아니라 투자를 위해 매입을해야합니다. Roy Osherove의 비디오 "Unit Testing and TDD-How To Appe Appe "을 참조하십시오 코드 검토 채택의 과제는 단위 테스트 채택의 과제와 매우 유사합니다.

그 동안 가능한 한 많이 할 수있는 일을하십시오.

• 코드 검토의 가치를 보는 다른 개발자가 있다면, 비공식적으로도 서로 검토해보십시오.
• 교육을 담당하는 멘토 또는 개발자가있는 경우 코드 검토에서 볼 수있는 가치를 설명하고 최소한 경우에 따라 코드를 검토 할 의사가 있는지 물어보십시오.
• 관리자에게 다른 사람의 코드를 검토하고 싶다고 말하면 시스템을 더 잘 이해하는 데 도움이됩니다.
• 어느 시점에서 팀장이되면 팀에 대해서만 코드 검토를 로컬로 수행 할 수 있습니다.

이 중 하나의 주요 이점은 시간이 지남에 따라 유지할 수 있다면 주변 개발자가 코드 검토에 주목하기 시작한다는 것입니다. 코드 검토가 기존 문화에 통합 될 수있는 방법을 효과적으로 보여 주므로 문화가 변화하기 시작합니다. 코드 검토가 도움 이되므로 소규모로 증명할 수 있다면 다른 사람과 문화 전체가 모범을 보일 수있는 길이 열릴 것입니다.

걱정하지 마십시오. 새로운 고용주는 코드 검토에 신경 쓰지 않습니다. 다른 사람이 작성한 코드를 확인해도 괜찮다고 말하지 않고 자신의 능력에 대해 자신감을 가지십시오. 곧 다른 사람들의 코드를 검토하는 지루한 과정없이 지내는 법을 배우게 될 것입니다.

다른 사람이 사용하는 스타일 지침 (또는 스타일)을 따르십시오. 경험을 사용하여 주석 달기, 사용할 명명 규칙 등을 결정하십시오.

그런 다음 체크인하기 전에 모든 것을 테스트하십시오. 가장 중요한 것은 올바르게 작동한다는 것입니다.

새로운 고용주가 코드 검토에 대한 아이디어를 좋아하지 않는다면 구식 명령 및 제어 유형 방법론과 부정적인 연관이 있고보다 현대적이고 민첩한 유형의 관행을 목표로하기 때문일 수 있습니다. 이 경우 쌍 프로그래밍이라는 개념에 더 개방적 일 수 있으며, 이는 동일한 이점을 많이 제공하며보다 역동적이고 현대적인 관행으로 널리 알려져 있습니다.