PaaS만

Adobe Commerce에 대한 코드 검토 모범 사례

마지막 업데이트: 2025년 8월 15일

작성 대상:

  • 경험
  • 개발자

코드 검토의 주요 목표는 구현된 기능이 성능, 아키텍처 및 보안 관점에서 최적의 방식으로 요구 사항을 충족하는지 확인하는 것입니다.

또한 코드 검토는 코드가 Adobe Commerce 개발 모범 사례를 충족하고, 쉽게 이해하고 유지할 수 있으며, 코딩 표준을 따르도록 하기 위한 것입니다. 대부분의 코딩 표준은 적절한 도구에 의해 자동으로 확인되어야 한다.

권장 코드 검토 프로세스

높은 수준에서 코드 검토 프로세스는 다음 단계로 구성되어야 합니다.

  1. 로컬 개발 환경의 체크아웃 기능 분기.
  2. 검토를 위해 코드가 제출된 지 오래되면 대상 분기(일반적으로 QA 분기)의 최신 변경 내용을 병합하고 원격 기능 분기(있는 경우)에 업데이트를 푸시합니다.
  3. 높은 수준의 검토를 수행하여 코드가 모든 요구 사항을 구현하는지 확인합니다. 중요한 불일치가 있는 경우 개발자에게 자세한 내용을 문의하십시오.
  4. 코드 실행은 선택 사항이지만 코드가 예상대로 작동하는지 또는 프로세스의 효율성을 용이하게 하는지 확실하지 않은 경우 구현된 기능이 기본 사용 시나리오에 예상대로 작동하는지 테스트합니다. 중요한 문제가 있는 경우 검토 프로세스를 중지하고 적절한 의견을 제시하여 티켓을 다시 엽니다.
  5. 철저하게 검토하여 코드가 모든 요구 사항을 구현하는지 확인합니다. 문제가 있는 경우 풀 요청에 적절한 주석을 추가하고 티켓을 다시 엽니다.
  6. 모든 것이 정상적으로 보이는 경우 가져오기 요청을 병합하거나 요청이 이미 설정된 경우 다음 코드 검토 수준으로 전달합니다.

또한 코드 검토 프로세스를 구현할 때 다음 사항을 고려하십시오.

  • 코드 검토는 팀 내의 의사 소통 및 지식 전달을 위한 기본 도구입니다. 가져오기 요청에 주요 문제가 포함되어 있지 않고 필요한 비즈니스 논리를 구현하는 경우에도 병합 후 더 많은 개선 사항을 제안하는 기회로 사용할 수 있습니다.

  • 코드 검토는 평균적으로 개발 노력의 10%~20% 이상을 차지해서는 안 됩니다. 개발팀이 함께 잘 일하는 선임 엔지니어들로 구성되어 있다고 가정하는 것이다. 코드 검토가 오래 걸리면 프로젝트 예산 및 타임라인에 영향을 줄 수 있습니다.

  • 근본 원인을 식별하여 코드 검토에 과도한 노력이 필요한 문제를 해결하십시오. 일반적으로, 요구 사항이 개발 티켓으로 잘못 번역되었거나(통신 문제, 사용자 스토리 부족) 또는 코칭 문제이기 때문입니다. 첫 번째 경우 권장되는 완화 방법은 팀 구성원이 요구 사항을 효율적으로 전달할 수 있는 충분한 정보를 티켓에 있는지 확인하는 것입니다. 두 번째 경우에는 선임 엔지니어를 더 포함하도록 팀 구조를 조정하거나 멘토링과 코칭 이외의 승인을 받아야 할 수도 있다.

영향을 받는 제품 및 버전

지원되는 모든 버전:

  • 클라우드 인프라의 Adobe Commerce
  • Adobe Commerce 온-프레미스

코드 검토에서 찾을 내용

스타일

PhpStorm 검사를 실행하여 스타일을 자동으로 테스트할 수 있습니다(아래 참조).

PHPMD 및 PHPCS을(를) 구성하고 CLI에서 코딩 표준 도구를 실행하십시오(아래). 겹치는 부분이 있지만 두 가지 모두 독특한 검사도 있다.

규칙 및 구조

규칙 및 구조에 대한 검토는 수동으로 수행됩니다.

  • 클래스 기능은 단일 권한으로 제한됩니까?
  • 디렉터리 구조가 적절합니까?
  • 는 적절한 수준(서버, 클라이언트, CSS, JS, 데이터베이스, 프레임워크, 인프라)에서 수행되는 기능입니다.
  • 버전 관리가 올바릅니까?
  • 코드가 틀리게 보이거나 문제를 잘못된 방법으로 해결하려는 것처럼 보이나요?
  • 모듈 이름, 패키지 이름 및 저장소 이름에 대한 이름 지정 규칙이 올바르게 적용됩니까?
  • 전역 CSS 스타일이 신중하게 적용되는지 그리고 과도하게 사용되지 않는지 확인하십시오.

완성도

완성도에 대한 검토는 수동으로 수행됩니다.

  • 구성에 따라 코드를 활성화하거나 비활성화할 수 있으며 필요한 모든 코드가 예상대로 작동합니까?
  • 티켓에 언급된 모든 구성이 있습니까? 범위, 데이터 유형, 유효성 검사, 번역 및 기본값을 확인합니다.
  • 구성은 항상 가능한 가장 낮은 수준(스토어 보기 수준, 웹 사이트 수준 또는 글로벌 수준)에서 검색됩니까? 구성 검색은 system.xml 파일의 범위 정의와 일치해야 합니다.
  • 기술 사양의 순서도에 있는 모든 경로가 적용됩니까? 다른 기술 사양은 모두 다룹니까?
  • 새 기능에 대해 ACL이 정의됩니까?
  • PhpDocs가 명확합니까? 커밋 메시지가 명확합니까?
  • 코드가 주석 처리되어 있습니까, 아니면 디버그 코드가 표시됩니까?

성능

성능에 대한 검토는 수동으로 수행되며, 이는 확실하지 않은 경우 코드 실행에 의해 도움이 될 수 있습니다.

  • 쿼리가 루프로 실행됩니까? 이 루프는 편집된 파일 외부에 있을 수 있습니다.
  • cachable="false" 특성을 찾을 수 있습니까? 제대로 붙어있나요?

보안

보안을 위한 검토는 수동으로 수행되며, 텍스트 검색으로 도움을 받을 수 있습니다. 보안 검사의 일부는 자동화된 테스트를 통해 처리됩니다.

  • 필요한 경우 예외가 기록됩니까? 올바른 유형의 예외가 사용됩니까?
  • around개의 플러그인을 사용하지 않을 수 있습니까?
  • 플러그인이 올바른 유형의 데이터를 반환합니까?
  • 데이터베이스 추상화 계층을 사용하여 빌드해야 하는 원시 SQL 쿼리를 찾을 수 있습니까?
  • 새로운 유형의 데이터가 모든 유형의 사용자, 관리자 또는 프론트엔드에 노출됩니까? 그것이 보안상의 위험입니까?
  • 사용자 생성 데이터의 유효성을 검사했습니까? 쿠키 값 및 서버 헤더를 포함하여 브라우저에서 오는 모든 것은 사용자 생성 된 것으로 간주됩니다.