PHP 마스터 | 코드 검토의 중요성-PHP 튜토리얼-php.cn

PHP Master | The Importance of Code Review

PHP 마스터 | 코드 검토의 중요성 키 테이크 아웃

코드 검토는 컴퓨터 소스 코드를 체계적으로 조사한 것으로, 초기 개발 단계에서 간과 된 실수를 찾고 수정하기위한 전체 소프트웨어 품질과 개발자의 기술을 향상시키기위한 것입니다. 쌍 프로그래밍, 비공식적 인 연습 및 공식 검사와 같은 다양한 형태로 수행 할 수 있습니다.

코드 검토는 코드의 결함 수를 줄일뿐만 아니라 협업을 증가시키고, 팀 구축을 돕고, 개발자 간의 "형제"를 개선하며, 팀이나 부서 전체의 모범 사례와 기술 향상을 전파합니다.

코드 검토를위한 모범 사례에는 일반적인 실수를 알고 적극적으로 싸우는 것이 포함됩니다. 기술이 같은 사람이 코드를 검토하고, 명확한 이정표로 코드를 덜 검토하고, 메트릭을 수집하고, 버그를 찾는 것이 좋은 사회적 측면을 염두에 두어야합니다. , 나쁘지 않습니다. 이 기사는 코드 검토를 부정적인 또는 시간 낭비로 보지 않고 일상적인 워크 플로의 개선으로 보는 것의 중요성을 강조합니다. 오늘날 팀이 사용하지 않는다면 모든 유형의 코드 검토가 없기 때문에 제안합니다.

모든 개발자는 평범한 실수의 고통을 알고 있습니다. 여기에 잘못된 속성, 틀린 속성, 실수로 복제 된 코드 라인이 커피를 마시 며 16 시간의 해커 톤으로 인해 놓친 코드 라인입니다. 지옥의 Java 기반 IDE가 예열하기 전에 타이핑을 시작했기 때문에 실수로 배치 한 PHP 태그 이전의 간단한 $조차도 피곤하고 산만 해지면 커서를 몇 시간 동안 긁을 수 있습니다. . 만약 당신이 한 일을 살펴보기 위해 신선한 눈을 가지고 있다면 - 분명히 이러한 실수를 쉽게 피할 수 있습니까? Wikipedia는 코드 검토를 다음과 같이 정의합니다. 코드 검토는 컴퓨터 소스 코드의 체계적인 시험 (종종 동료 검토라고 함)입니다. 초기 개발 단계에서 간과 된 실수를 찾고 수정하여 소프트웨어의 전반적인 품질과 개발자 기술을 모두 향상시키기위한 것입니다. 리뷰는 쌍 프로그래밍, 비공식 연습 및 공식 검사와 같은 다양한 형태로 수행됩니다. 이 정의는 더 정확한 것만 큼 정확합니다. 더 많은 평신도 용어로 코드 검토는 단순히 다른 사람이 코드를보고 놓친 실수를 찾는 행위입니다.

 코드 검토 유형 
Wikipedia 정의가 암시 된 것처럼 결함에 대한 코드를 검토하는 여러 가지 방법이 있습니다. 다음은 몇 가지 중 빠른 분류입니다.
<blockquote>
<over> OTS (어깨 너머) 검토 - 소규모 팀이 일반적으로 코드 검토를 처리하는 방식입니다. 개발자는 적절한 양의 코드를 작성하고 다른 개발자에게 전화하여이를 살펴볼 것입니다. 다른 개발자는 그곳에 앉아 있고 첫 번째 개발자는 자신이 한 일을 라인별로 설명합니다. 이 이야기를 통해 원래 개발자는 자신의 실수를 발견하고 수정하고 OTS 개발자는 다른 사람들을 알아 차리고 첫 번째를 지적합니다. 또한 검토 프로세스가 완료된 후에 원래 개발자가 때때로 재생하는 특정 문제에 대한 솔루션에 대한 의견을 공유하여 검토를 다시 한 번 요구합니다. 개발자가 원격 인 경우 화면 공유 소프트웨어 및 음성 채팅으로 쉽게 수행 할 수 있습니다. </over>
</blockquote>
<ist> 도구 지원 검토-코드 검토를 지원하기위한 온라인 및 오프라인 모두 다양한 도구가 있습니다. 제공되는 다양한 도구에 대한 자세한 내용은이 기사의 범위를 벗어나지 만 유료 버전 (Atlassian Crucible, Codecollaborator), 무료 버전 (검토 보드) 또는 솔로 개발자 인 경우 솔로 개발자가 있다고 말할 수 있습니다. 커뮤니티 버전 (스택 교환 코드 검토). 사용 된 도구에 관계없이 각각은 거의 동일한 목적을 제공합니다. 소스 코드에 대한 가장 최근의 변경 사항을 검색하고 검토가 필요한 것으로 표시합니다. 동료 - 이는 동일하거나 더 큰 기술을 가진 개발자를 의미합니다. 그런 다음 코드를 검토하고 검토 된대로 표시하거나 찾은 오류를 표시하고 제안을하는 오류를 표시하며 프로세스를 원래 개발자에게 다시 전송하여 프로세스를 마무리하거나 재개합니다. 또한 많은 인기있는 IDE에는 코드 검토 플러그인이 있습니다. <li>
 페어 프로그래밍 - 매우 역동적 인 유형의 코드 검토 인 페어 프로그래밍은 한 개발자 코드와 다른 개발자가 옆에 앉아 그의 진전을 따르는 두 개발자를위한 핫 사이트 "게임"입니다. 수백 줄의 코드 후 또는 미리 정해진 이정표에 도달 한 후 짧은 휴식을 취하고 장소를 전환합니다. 코딩중인 사람은 현재 관찰 한 반면, 이전에 관찰 한 사람은 이제 코드를 코딩합니다. 이는 버그를 피하고 전반적인 코드 품질을 향상시키는 데 매우 효과적이지만 인력의 두 배가 비용이 듭니다. 많은 회사들이 그러한 위험에 대한 준비가되어 있지 않으며 불행히도“두 기계의 두 사람이 한 기계에서 두 사람보다 더 많은 일을합니다”라고 생각할 수 없습니다. 최상의 결과를 얻는 것은 이러한 유형의 검토입니다. 버그가 평평 해지는 것뿐만 아니라 두 개발자는 직접 협업하고 진행되는 문제에 대한 솔루션에 대한 아이디어를 공유합니다. 이 유형의 검토는 익숙하지 않은 팀에서 구현하기가 매우 어렵다는 것도 가치가 없습니다. 주로 젊은 팀에서 작동합니다. </li>.
제쳐두고, 1970 년대 Michael Fagan이 처음 소개하고 연구 한 공식적인 유형의 검토도 있습니다 (이 방법은 Fagan 검사라고도 함). 공식 검사는 소규모 팀에서는 거의 사용되지 않으며 대부분 정신적으로 강렬하고 비싸기 때문에 수백만 달러 제품과 관련이 있습니다. 여기에는 프로젝터와 함께 앉아 코드를 함께 검토하는 여러 사람 (최대 6 명)이 포함됩니다. 각 참가자는 역할 (독자, 중재자 또는 검토 자 등)이 할당되며 팀이 모든 종류의 버그 또는 결함을 알아 차면 모든 것이 심각도, 실제 코드 라인, 원인 및 원인 및 원인 및 효과,이 버그의 예상 비용조차도 고객에게 도달합니다. 이것은 가장 전문적인 유형의 코드 검토이지만 개발자에게 가장 낙담하며 널리 채택되지 않았습니다. 연구에 따르면 많은 사람들이 오랫동안 오랫동안 묶을 필요없이 다른 코드 검토 방법이 적절하게 사용되는 경우에도 효과적인 것으로 나타났습니다.
<for> 코드 검토를위한 모범 사례 

코드 검토를 구현하기로 결정한 후에는 극복해야 할 장애물이있을 것입니다. 경영진은 추가 시간 검토 테이크에 대한 정당성을 보지 못하거나 일부 프로그래머는 검토가 그들이 만들기 위해 열심히 일한 코드에 대한 개인적인 공격이라고 생각할 수 있습니다. 코드 검토가 구현 될 때 명심해야 할 몇 가지 팁이 있습니다.

<h2>
<mist> 당신의 일반적인 실수를 알고 적극적으로 싸우십시오. 일할 때, 모든 개발자는 자신이 "영역에서"아무리 깊어 지더라도 일반적으로 오류가 발생합니다. 우리 각자는 바보 같은이 작은 결함을 가지고 있으며 다른 사람들은 완전히 눈에 띄는 것입니다. 이 미끄러짐을 기록하십시오. 입력을 필터하는 것을 잊어 버렸습니다… 다시? 메소드에 댓글을 달는 것을 잊어 버렸습니다… 다시? 그런 목록을 사용하면 개발자가 리뷰를 요청하기 전에 실수를 적극적으로 사냥 할 수 있습니다. 이것은 자아 효과로 알려져 있습니다 - 당신은 당신의 코드를 검토하려고한다는 것을 알고 있으며, 당신은 검토자가“아, 당신은 다시 입력을 필터링하는 것을 잊었다”고 말하는 것을 듣고 싶지 않습니다. 당신은 록 스타, 닌자, 다른 사람들이“와우, 그것은 실제로 훌륭한 해결책입니다”라고 말하는 사람이되기를 원합니다. 자아 효과는 다른 사람들이 그것을 살펴볼 기회를 갖기 전에 코드를 개선하게하는 것입니다.

  피어 코드 검토는 기술이 같은 사람이 검토하는 것을 의미합니다. 상식이 되려면 주니어가 시니어 코드를 검토 할 때 코드 검토는 작동 할 수 없습니다. 주니어는 일반적인 불일치, 표준 위반, 오타 또는 입력 필터링과 같은 오류를 발견 할 수 있지만 일반적으로 더 큰 문제를 식별 할 수 없습니다. 이것은 종종 팀이 아직 존재하지 않으면 팀의 기술에 의한 계층 구조의 정의가 필요합니다. </mist>
</h2>.명확한 이정표가있는 코드가 적다는 것은 더 나은 리뷰를 의미합니다. 코드는 개인 이정표에 도달 한 후에 만 검토해야하며, 이러한 이정표는 작아야하며 자주 발생해야합니다. 객체 지향 프로그래밍에서 이것은 특히 중요하지만 특히 가능합니다. 이미 검토 된 어댑터에 연결되는 인터페이스를 확장하는 새로운 구성 요소를 완료 했습니까? 마지막으로 부서를 일주일 동안 버그로 만들고있는 특정 방법에 문제가 해결 되었습니까? 엄청난! 구성 요소 별 구성 요소 및 한 번에 최대 700-800 줄의 코드를 유지하는 것이 가장 효율적인 검토 프로세스를 생성하는 것입니다. 검토해야 할 코드를 짧고 간결하며 독립적으로 유지하고 아이디어가 여전히 신선한 상태에서 마무리 한 후 가능한 빨리 검토를 수행하십시오. 기억하십시오 - 시간이 비싸므로 너무 많이 가져 가지 마십시오! 이 "섹션 검토"를 수행하기에 한 시간이 충분해야합니다. <li>
<ics> 메트릭을 수집하십시오. 도구 보조 또는 공식과 같은보다 체계적인 유형의 코드 검토를 사용하는 경우 더 쉽지만 OTS에서도 수행 할 수 있습니다. 주어진 수의 코드 라인과 시간 단위를 통해 찾은 버그 및 슬립 업의 수와 유형에 유의하십시오. 개발자 간에이 데이터를 집계하고 누가 가장 많은 도움이 필요한지, 누가 가장 많은 표준을 위반하는지, 코드 검토를 통해 실제로 회사를 절약 한 돈을 쉽게 알 수 있습니다. 곧 코드 검토의 유용성을 실제로 정량화 할 수 있으며 회사의 모든 사람이 적극적으로 흥미를 느끼게됩니다. 수동 통계에 대한 인내심을 가진 개발자는 거의 없기 때문에 이는 일반적으로 구현하기에 가장 어려운 부분입니다. 그러나 채택하면 유리할 수 있습니다. </ics>
</li>.
<of> 사회적 측면을 염두에 두십시오 - 버그를 찾는 것은 좋지 않습니다! 버그를 찾는 것이 좋지 않고 좋지 않다는 것을 기억하는 것이 필수적입니다. 실수를 저지른 개발자를 낙인하거나 독창적으로하지 마십시오. 사람들이 코드 검토에 적응하도록하십시오 - 동료들이 그것을 두려워하지 말고 동료를 받아들이도록 도와줍니다. 코드 검토는 유용 할뿐만 아니라 재미있을 수 있습니다. 더 많은 시간과 더 어려운 작업은 더 많은 버그와 같습니다. 버그 수는 개발자의 기술을 나타내지 않습니다! 관리자 또는 팀 리더 인 경우 코드 검토를 부정적인 또는 시간 낭비로 보지 않도록하십시오. 회사가 시행 한 규칙으로 보지 않고 일상적인 워크 플로우를 개선하여 회사에 관계없이 유지해야합니다. 가능할 때마다 개인 코드 검토의 개인적인 접근 방식을 위해 노력하십시오. 도구를 사용하는 경우 도구를 사용하십시오. 문제에 대한 잠재적 솔루션에 대한 상호 브레인 스토밍 및 비공식적 토론에 대한 개인적인 접근은 친구로서 코드 검토를 수락하는 과정에서 매우 중요합니다.
 결론에서 <h2>
코드 검토는 특히 익숙하지 않은 옛 타이머 팀에서 구현하기가 매우 어려울 수 있습니다. 그러나 일단 완료되면 코드의 결함 수를 줄일뿐만 아니라 협업을 증가시키고 팀 구축을 돕고 개발자 간의 "형제"를 개선하며 전체 팀 또는 부서 전체에서 모범 사례를 전파하고 기술을 향상시킬 것입니다. 모든 유형의 코드 검토는 없을 때보다 낫습니다. 오늘 팀을 사용하지 않는 경우 제안하십시오. 도움이 될 수 있습니다. 솔로 개발자라면, 온라인으로 가고, 사교하고, 개발 서를 확장하고, 팀을 이루어 코드를 검토 할 친절한 정신을 찾으십시오. 다른 개발자를 경쟁으로보고 코드 검토에서 적으로서의 코드 검토를 보지 말고, 최전선에서 무기로 코드 검토를 통해 팔에있는 형제와 같은 다른 사람들을 완벽하게보십시오.


Fotolia를 통한 이미지 <ot>



<questions> 코드 검토에 대한 자주 묻는 질문 </questions></ot>
</h2>



<importance> 소프트웨어 개발에서 코드 검토의 중요성은 무엇입니까? <small> </small> 코드 검토는 소프트웨어 개발에 중요한 프로세스입니다.이 프로세스는 소프트웨어 개발에 실수, 버그 또는 잠재적 인 개선에 대한 동료 개발자의 코드를 확인하는 데 중요한 프로세스입니다. 높은 수준의 코드 품질을 유지하고 코드를 다른 사람들이 읽을 수 있고 이해할 수 있도록하며 팀 간의 지식 공유를 촉진합니다. 코드 검토는 또한 개발 프로세스 초기에 버그를 포착하고 수정하여 후반 단계에서 버그 수정 비용과 시간을 줄이는 데 도움이됩니다. <h2> </h2> 코드 검토를 수행하기위한 모범 사례는 무엇입니까? <h3> </h3> 코드 검토를 수행하기위한 몇 가지 모범 사례에는 코드의 컨텍스트 이해, 코딩 스타일이 아닌 코드의 논리 및 구조에 중점을두고 건설적인 피드백을 제공하며 검토 프로세스를 서두르지 않는 것이 포함됩니다. 또한 검토 과정에 올바른 사람들을 참여시키는 것이 중요합니다. 일반적으로 코드베이스에 익숙한 사람들과 검토중인 특정 기능을 검토하는 것이 중요합니다. <p> </p> 내 코드 검토를보다 효과적으로 만들 수 있습니까? <h3>  코드 검토를보다 효과적으로 만들려면 코드가 자명하고 문서화되어 있으며 팀의 코딩 표준을 따라야합니다. 또한 검토하기 쉬운 작고 관리 가능한 덩어리로 변경 사항을 분류해야합니다. 또한 코드 검토 도구를 사용하면 검토 프로세스를 간소화하고보다 효율적으로 만드는 데 도움이 될 수 있습니다.  </h3> 코드 검토에서 피해야 할 일반적인 실수는 무엇입니까?  </importance></of></for></ist>

코드 검토에서 피해야하는 일반적인 실수는 몇 가지 일반적인 실수입니다. 코드를 철저히 검토하지 말고 코드의 논리와 구조보다는 코딩 스타일에 너무 집중하고 건설적인 피드백을 제공하지 않고 검토 프로세스를 돌진하는 것을 포함합니다. 리뷰 과정에서 올바른 사람들을 참여시키지 않는 것은 실수입니다.