검토 할 코드를 어떻게 선택합니까?

소규모 소프트웨어 회사에서 7 명의 개발자로 구성된 팀의 일원이며 정기적 인 그룹 코드 및 디자인 검토를 소개하려고합니다. 우리는 과거에 일부 검토를 수행했지만 산발적이었습니다. 좀 더 규칙적으로 만들고 싶습니다.

Code Complete 및 기타 유사한 리소스를 읽었 으며 코드 검토를 수행 하는 방법 에 대해 이야기 하지만 검토 대상 을 선택 하는 방법에 대한 모범 사례를 찾지 못했습니다 . 우리는 8 년이 넘고 다양한 언어를 다루는 코드 기반을 가지고 있으므로 살펴볼 수있는 것이 많이 있습니다.

선택에 영향을 줄 수있는 몇 가지 요소는 다음과 같습니다.

• 언어 : C, 자바, SQL, PL / SQL
• 코드 에이지 : 새 코드와 이전 코드
• 코드 사용 : 자주 사용되는 코드 대 (효과적으로) 죽은 / 거의 사용 된 코드
• 코드 중요도 : 중요 코드와 중요하지 않은 코드
• 개발자 : 주니어 개발자 코드와 수석 개발자 코드

나는 이것이 절대적인 결정적인 질문이 아니라는 것을 이해하지만 모든 지침이 유용 할 것입니다.

주변기기 관련 질문 :

• 코드 검토 방식 (중요한 섹션 및 새로운 개발자 코드 검토)
• 모든 코드를 검토해야합니까?

일반적으로 모든 것을 검토해야합니다 . 새로운 응용 프로그램에 2 000 LOC가있는 경우 2 000 LOC를 모두 검토해야합니다.

따라서 검토 대상 을 선택 하는 방법에 대한 모범 사례가없는 이유 입니다.

존재하는 큰 코드베이스에 접근하고 이전에 검토하지 않은 경우 존재하는 큰 코드베이스를 다시 작성하고 시작 위치를 선택 해야하는 경우와 동일합니다 . 그것은 크게 의존합니다 :

• 코드베이스에서 (단일 모 놀리 식 코드는 별도의 구성 요소 등보다 재 작성 / 검토하기가 더 어려울 것입니다),

• 당신의 맥락 (작업을 중단하고 3 개월 (3 년?)을 재 작성 / 검토만으로 일할 수 있습니까, 아니면 자유 시간이있을 때만 조금씩해야합니다)?

• 검토 유형 (검토 대상 점검 목록이 있습니까? 점검 목록 항목에 따라 일부 부품을 먼저 검토 할 수 있습니다).

내가 만약 너라면 나는:

• 연결 한 두 번째 질문의 첫 번째 의견에서 언급 한 80 % -20 % 원칙을 따르십시오.

• 이상적인 100 %는 그만한 가치가 없다는 점을 고려하십시오. 단위 테스트의 코드 범위는 100 %와 비슷하지만 코드 범위가 대부분 불가능하거나 매우 비싸다는 점만 다릅니다.

• 가장 많이 사용하고 가장 중요한 코드 부분부터 시작하십시오. 코드베이스에 회사 웹 사이트에서 새 사용자를 인증하고 등록하는 라이브러리가있는 경우 해커보다 먼저 보안 허점을 찾아야하므로 먼저 검토하십시오.

• 기존 측정 항목을 사용하여 검토해야 할 사항을 결정합니다. 코드베이스의 한 부분에 단위 테스트가 전혀없는 반면 다른 중요한 부분에도 85 %의 코드 적용 범위가있는 경우 첫 번째 부분을 검토하여 시작하십시오. 경험이없는 것으로 알려진 개발자가 코드베이스의 일부를 작성하고 동료보다 더 많은 버그를 도입 한 경우 먼저 코드를 검토하십시오.

코드의 모든 변경 사항을 검토하여 시작하십시오. 문제가 악화되는 것을 막을 수 있습니다. 그런 다음 변경 빈도에 따라 코드 검토를 시작하십시오. 이것들은 '문제'영역이 될 것입니다.

코드 섹션을 검토했음을 추적 할 수있는 방법을 찾아서 다른 문제와 비교하여 코드의 검토 범위를 분석 할 수 있습니다.

테스트에서 다루지 않은 코드를 확인할 수 있으면 검토 우선 순위가 높아집니다.

프로덕션 환경에서 변경하기 전에 새로 변경된 모든 사항을 검토하십시오. 설치 스크립트, 소스 코드, 데이터베이스 변경, 모든 것! 코드 검토의 요점은 불량 코드가 프로덕션에 들어 가지 못하게하는 것입니다. 조직 구성이 좋지 않거나 무언가를 놓 쳤기 때문에 단순히 도입 된 버그 일 수 있습니다.

작업중인 현재 코드를 리팩터링하면 코드 검토와 함께 진행됩니다. 예를 들어, 코드를 검토 할 때 버그 수정이 포함 된 클래스에 코드가 중복 된 경우 개발자가 수정에서 해당 코드를 변경하지 않은 경우에도 전달하지 않습니다. 다시 돌아가서 중복 코드를 제거하도록하십시오.

끊임없이 리팩토링하면 코드 검토가 유용 해집니다. 그렇지 않으면 시간 낭비입니다.

코드 검토 프로세스를 개발 프로세스의 단계로 통합하면 시간이 지남에 따라 코드 기반이 향상됩니다. 더 나은 방법은 개발자가 코드 검토 백 로그가 비워 질 때까지 새로운 기능 작업이나 버그 수정을 수행하지 못하게하는 것입니다. 이를 통해 코드 검토가 완료됩니다.

리팩토링해야하는 알려진 영역이 있지만이를 수행하는 데 시간이 오래 걸립니다 (예 : 1 주일 이상). 그런 다음 리팩토링 자체에 대한 작업 항목을 작성하고 작업 할 항목으로 추가하십시오.

모든 새 코드를 검토하고 기존 코드를 수정하십시오.

기존 코드의 수정 사항을 검토 할 때 개발자는 boyscout 규칙을 따라야합니다. 코드를 찾은 것보다 더 나은 상태로 두십시오.

그렇다고해서 전체 파일을 완벽하게 수정해야한다는 의미는 아닙니다. 그러나 그것은 혼란에 더해져서는 안되며 조금 나아질 것입니다. 아마도 수정 사항을 올바르게 구조화 된 새 클래스로 옮기고 나머지 원본 코드 파일을 그대로 유지하십시오.

개발자로서 모든 새로운 코드와 수정 사항을 검토하여 코드를 개선하기 시작하면 가장 변화가 필요한 애플리케이션 영역을 알아야합니다. 그런 다음 그것들을 검토하고 조금씩 개선 될 수있는 방법에 대해 토론하십시오.

10 년 전에 작성된 코드를 검토하기 위해 코드를 검토하는 것은 의미가 없습니다. 개발자는 10 년 동안 개선해야합니다. 따라서 여러분이 아는 것을 배우기 위해 그것을 검토 할 필요는 없습니다.

코드 검토의 목적은 현재 수행중인 실수를 개선 및 수정하고 해당 지식을 팀간에 공유하는 것입니다.

내 프로젝트에서는 대부분의 경우 개발중인 모든 할당 / 사용자 스토리 / 버그에 대한 코드 검토를 필수 사항으로 포함시킵니다. 스크럼 / 애자일 프로세스를 사용하고 있으며 단위 테스트가 작성되고 코드 검토가 완료 될 때까지 티켓 / 스토리가 빌드 (QA에 대한 백 로그)로 이동되지 않습니다.

이러한 목적으로 JIRA + SVN과 통합 된 Crucible 코드 검토와 함께 Atlassian FishEye 분석을 사용 합니다.

개발자가 특정 스토리에 대한 코드를 체크인하면 FishEye에서 새 코드 검토를 작성하고 검토를 위해 팀의 다른 구성원을 선택합니다.

코드 검토가 완료되면 (도구가 제출 된 변경 사항을 강조 표시하고 특정 코드 줄에 대한 주석을 남길 수 있음) 개발자는 언급 된 문제를 수정하고 제안 된 개선 사항을 구현하고 티켓을 JIRA의 Built 열로 옮깁니다. 테스트 준비가 완료되었으며이 특정 작업 항목에 대해 더 이상 코드 변경이 예상되지 않습니다.

또한 코드 검토 후 코드를 리팩토링하는 동안 QA가 변경되어 손상 될 수있는 것은 테스트하지 않습니다 .

요약하면 모든 코드를 검토해야합니다. 이는 고품질 코드를 지원하므로 일반적으로 코드의 디자인, 가독성, 유지 관리 및 테스트 성이 향상되고 장기적으로 개발 성능이 향상됩니다.