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

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

또한 코드 검토는 코드가 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 쿼리를 찾을 수 있습니까?
  • 새로운 유형의 데이터가 모든 유형의 사용자, 관리자 또는 프론트엔드에 노출됩니까? 그것이 보안상의 위험입니까?
  • 사용자 생성 데이터의 유효성을 검사했습니까? 쿠키 값 및 서버 헤더를 포함하여 브라우저에서 오는 모든 것은 사용자 생성 된 것으로 간주됩니다.

개인 정보 및 GDPR

개인 정보 및 GDPR에 대한 검토는 수동으로 수행됩니다.

  • 이 코드는 고객 데이터 또는 이메일을 처리합니까? 각별히 주의하세요.
  • 이 코드가 루프에서 실행될 수 있으면 한 루프 주기에서 다른 루프 주기로 고객 데이터를 유출할 수 있습니까?
  • 위험 지표는 가져오기, cron 작업, 트랜잭션 이메일 및 일괄 처리 큐 핸들러입니다.
  • 루프에서 사용자 데이터가 격리되는지 확인합니다. Adobe은 루프 주기 내에서 루프 외부에서 액세스할 수 없는 모델을 생성하기 위해 공장 또는 저장소를 사용하는 것을 권장합니다.

멘토링

멘토링에 대한 리뷰는 수동으로 수행됩니다.

  • 팀을 교육하는 것을 목표로 지식을 공유할 수 있는 장소를 찾아본다.
  • 귀하의 의견이 순전히 교육적이지만 기준을 충족하는 데 중요하지 않은 경우 작성자가 이를 해결하는 것이 필수가 아님을 나타냅니다.
  • 좋은 것을 발견하면 개발자에게 알리십시오. 특히 개발자가 귀하의 의견 중 하나를 훌륭하게 처리했을 때 그러합니다. 코드 검토는 종종 실수에 중점을 두지만, 좋은 사례에 대한 격려와 감사를 제공해야 합니다. 때로는 멘토링 측면에서, 그들이 무엇을 잘못했는지 말하는 것보다 그들이 무엇을 올바르게 했는지 개발자에게 말하는 것이 훨씬 더 가치 있습니다.

자동화

개발자는 자동화를 사용하여 DI 컴파일, 데이터베이스 스키마, 작성기 유효성 검사 및 코딩 표준 준수를 검토할 수 있습니다.

  • DI compilation - 다음 CLI 명령을 실행하여 아무런 문제 없이 코드를 컴파일할 수 있는지 확인합니다.

    code language-bash
    bin/magento module:disable -n -q --all || exit;
    bin/magento module:enable -n -q --all || exit;
    bin/magento cache:enable -n -q || exit;
    bin/magento cache:flush -n -q || exit;
    rm -rf generated/*
    rm -rf var/view_preprocessed/*
    rm -rf pub/static/*
    rm -rf var/cache/*
    bin/magento deploy:mode:set --skip-compilation production || exit;
    bin/magento setup:di:compile -vv || exit;
    bin/magento setup:static-content:deploy en_US || exit;
    bin/magento deploy:mode:set developer || exit;
    
  • 데이터베이스 스키마 whitelist.json - 다음 CLI 명령을 실행하고 db_schema_whitelist.json 파일이 추가되거나 변경되지 않았는지 확인합니다.

    code language-bash
    bin/magento setup:db-declaration:generate-whitelist --module-name[=MODULE-NAME]
    
  • 작성기 유효성 검사 - composer.json 파일이 포함된 디렉터리에서 다음 CLI 명령을 실행하여 composer.json 파일의 유효성을 검사합니다.

    code language-bash
    composer validate
    
  • 코딩 표준(Coding Standard) - 코딩 표준 도구를 설치 및 실행하고 모듈에 대해 실행합니다. 다음 파일은 mcs ./app/code/Vendor/Module/을(를) 입력하여 어디에서나 실행할 수 있도록 하는 방법을 보여 줍니다.

    code language-bash
    #!/usr/bin/env bash
    $HOME/web/magento/magento-coding-standard/vendor/bin/phpcs --standard=Magento2 "$@"
    
  • 프스탄

    code language-bash
    ./vendor/bin/phpstan analyze app/code/Vendor/Module
    
  • PhpStorm 검사

  • PhpStorm PHP 복사/붙여넣기 탐지기

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60