답변:
다음은 타사 모듈 평가에 대한 몇 가지 생각입니다.
기초:
현재 마 젠토 버전 지원-최신 마 젠토 버전 (현재 개발중인 Magento 포함)을 지원합니까?
모듈이 Magento의 최신 릴리스를 지원하지 않으면 귀중한 개발 시간을 소비하지 않으면 작동하기가 어려울 것입니다.
지원-모듈을 만든 개발자가 제품을 지원합니까?
정상적인 모듈의 징후 중 하나는 개발자가 적극적으로 지원한다는 것입니다. 그들이 지원하지 않으면 그것은 붉은 깃발입니다, 왜 그들이 좋은 제품을 지원하지 않습니까?
또한 모듈이 지원되면 간단한 전자 메일로 개발자로부터 중요한 정보를 얻을 수 있습니다 (예 :이 모듈은 jQuery 또는 프로토 타입을 사용합니다).
리뷰-다른 사용자들의 의견은? 그들의 경험은 어땠습니까?
리뷰를 읽으면 큰 그림을 더 잘 이해할 수 있습니다. 설치 문제가 있습니까? 개발자가 적시에 도움이되는 방식으로 응답합니까? 광고 된대로 작동합니까?
환불-의도 한대로 작동하지 않으면 돈을 돌려 주나요?
여러 번 우리는 모듈이 작동하고 사양을 충족하면 테스트 할 수 있도록 모듈을 시험 해보고 싶습니다! 그러나 그렇지 않은 경우 반품 및 환불 옵션을 원합니다.
중급 :
클래스 재정의-모듈이 핵심 클래스를 재정의합니까?
일반적으로 좋은 모듈은 핵심 클래스를 재정의해서는 안되며 관찰자를 사용해야합니다.
그 이유 중 하나는 Magento 업그레이드가 어려울 수 있기 때문입니다. 또한 다른 모듈은 주어진 기능의 출력 하나에 의존 할 수 있으며이 모듈은 다른 기능을 제공합니다.
때때로 이것이 불가능한 일인데,이 경우에 핵심 클래스를 재정의하는 데에는 매우 좋은 이유가 있어야합니다.
레이아웃 업데이트-모듈이 일부 레이아웃 설정을 변경합니까?
일부 모듈은 레이아웃 설정을 사이트 (예 : 제품 페이지)로 변경하고 현재 레이아웃을 손상시키지 않는지 확인하고 필요한 경우 (읽기 : 시간이 얼마나 걸리는지) 수정합니다. .
템플릿 변경-모듈에 현재 디자인을 변경하는 템플릿이 포함되어 있습니까?
이 모듈은 새로운 템플릿을 소개합니까? 그렇다면 디자인이 손상됩니까? 디자인을 원하는 방식으로 만드는 데 시간이 얼마나 걸립니까?
종속성-모듈이 다른 모듈에 종속됩니까?
모듈이 다른 모듈에 의존하는 경우 모듈이 설치되어 있는지 확인해야합니다. 또한 우리는 스스로에게 물어볼 필요가 있습니다. 미래에 의존하는 모듈을 끄고 싶습니까?
많은, 진보 한, 많이 경과 한:
SQL 업그레이드 스크립트-모듈이 DB를 어떤 방식으로 업데이트합니까?
모듈이 데이터베이스를 업데이트하면 몇 가지 사항을 확인해야합니다.
코어 테이블을 업데이트합니까? 그렇다면, 데이터베이스가 깨끗하지 않고 업그레이드 준비가 된 것을 좋아합니다.
합리적인 방식으로 정보를 저장합니까? 데이터베이스에서 직접 데이터를 가져 오려면 이해할 수 있습니까?
이벤트-모듈이 이벤트를 관찰하거나 전달합니까?
모듈이 이벤트를 전달하거나 관찰하면 다음을 알고 싶습니다.
어떤 이벤트를 관찰 / 파견합니까? 이것은 시스템에서 작동하는 다른 모듈에 영향을 미칩니 까? 예를 들어, 모듈 중 하나가로드시 제품 이름을 대문자로 변경하고이 모듈이로드시 제품 이름에 'free'라는 단어를 추가하면 어떻게 작동합니까? '무료'라는 단어가 대문자로 나옵니까?
코드 검토-모듈이 허용 가능한 코딩 기술을 사용합니까?
이것은 Magento보다 PHP 코딩 기술과 더 관련이 있습니다.
코드는 Try / Catch 블록을 사용합니까?
코드가 사용자 입력을 이스케이프합니까?
이것의 세부 사항은 실제로 우리의 기술 수준 / 요구 사항에 달려 있습니다.
잠재적 문제-이 모듈을 설치하면 어떤 잠재적 문제가 발생할 수 있습니까?
이 모듈을 설치하면 발생할 수있는 상위 5 가지 문제를 상상해보십시오. 놀랍게도 실제로 전체 프로젝트에 대한 통찰력을 제공합니다.
결론 :
이 모든 것들이 이상적인 세상에 있으면 좋으며, 실제 시나리오에서는 '타협'이라는이 일을해야합니다. :)
또한이 가이드 라인은 하나의 모듈 만 설치하고 소셜 공유 모듈을 말하면 간단한 사이트 설정이 필요한 클라이언트를위한 결과로서 우리를 방해하는 것이 아니라 우리를 돕기위한 것입니다. 많은 연구를하는 것은 말이되지 않습니다.
다시 말해,이 지침 (항목의 항목)을 사용하면 장기간 사용하지 않고 시간을 절약하고 건강을 해치지 않으면 시간을 절약 할 수 있습니다.
일부 마 젠토 고유의 "나쁜 연습"적신호는 다음과 같습니다.
app/code/local/Mageapp/design핵심에 이미 존재하는 파일 )catalog/product. 일반적으로 모든 재 작성을주의 깊게 검토하여 피할 수 있는지 확인합니다.Mage::getModel거의 규칙 : 템플릿 디렉토리에서 발생하는 것은 일반적으로 잘못된 신호입니다)일부 PHP 관련 적신호 (이것은 매우 선택적이고 불완전한 목록입니다) :
E_STRICT)@운영자의 사용법성능 관련 레드 플래그 :
또한 일반적인 Code Smells 를 찾아보십시오. 이것은 필요한 적신호 가 아니지만 전반적인 품질을 평가하는 데 도움이됩니다.
1 단계 — 개발자가 AWOL을 사용하는 경우 고객이이 확장을 지원할 여유가 있습니까?
그렇지 않으면 확장명을 사용할 수 없습니다.
그렇다면 확장 평가를 진행하십시오.
Inchoo의 훌륭한 사람들은 타사 모듈 코드 분석에 대한 기사 를 가지고 있습니다. 이 기사에서는 클래스 재 작성, 크론 작업, 레이아웃 업데이트 및 이벤트 관찰자를 언급합니다.
최고의 성능을 발휘할 수있는 이벤트 옵저버 코드를 찾았습니다. 자주 전달되는 이벤트에 대해 실행되는 리소스 집약적 인 타사 코드를 찾으십시오. controller_action_predispatch 또는 컬렉션로드와 같은 이벤트
Prattski 의이 유틸리티 모듈 을 사용 하여 재 작성 및 관찰자에 대한 훌륭한 개요를 얻습니다.
*_after이벤트 대신 이벤트 를 사용하는 것이 선호되어야한다는 것 *_before입니다. 성능 측면에서 관찰자에 대한 언급은 전혀 없습니다.
controller_action_predispatch요청 당 한 번 발송되므로 가장 좋은 예는 아닙니다. 그러나 성능 문제에 대한 높은 잠재력 만 언급하고 요청 당 여러 번 전달되는 이벤트가 있지만 관찰자는 다른 코드보다 성능 문제가 발생하기 쉽지 않습니다. 모든 제품로드와 같이 성능에 실제로 영향을 미치는 작업을 수행하는 경우 발생하는 위치에 관계없이 자체적으로 문제입니다.
기본 / 기본 대신 기본 / 기본 (또는 프로 또는 엔터프라이즈)에 템플릿 및 스킨 자산이있는 것은 상당히 성가신 일입니다.
난독 화 된 코드는주의해야 할 사항입니다. eval (), base64_decode () 등에 대한 호출 검색. 이것은 종종 라이센스 유효성 검사에 사용되지만 악의적이거나 무서울 수 있습니다. RSS 피드에서 임의 코드를 평가하는 구성 요소가 하나 이상 있습니다.
dl () 호출을 찾으십시오-내가 본 적어도 하나의 지불 게이트웨이 구성 요소는 연결을 수행하기 위해 PHP 확장을 설치해야합니다!
네 말이 맞아
불행히도 마술은 없습니다 : 당신은 그것을 테스트하고, 코드가 제대로 개발되었는지 확인하고, 포럼이나 질문에 신속하게 답변하여 상용 모듈을 잘 지원해야합니다 ...
Magento Connect에 대한 몇 가지 리뷰가 있으며 확장의 인기는 그것이 가치가 있는지 아닌지를 아는 데 도움이 될 수 있지만 솔직히 많은 버그가있는 매우 인기있는 모듈을 찾을 수 있습니다. 지난 주 MailChimp 모듈을 사용하여 좋은 예를 보냈지 만 주로 버그를 수정하고 개발자에게 제공해야했습니다. 항상 위험이 있으므로 테스트해야합니다.
WebShopApp은이 방향으로 나아가 겠다는 아이디어를 가지고있었습니다. 저는 모듈에 대한 좋은 정보를 얻을 수있는 플랫폼을 가져 왔습니다. 아이디어는이 방향으로 Magento를 밀어 넣는 것이 었습니다. 따라서 모듈 품질은 실제 질문입니다.
내가 취할 수있는 # 1 테스트는 코드에서 제로 데이 익스플로잇을 발견하는 것입니다 (보통 Magento 확장으로는 그다지 어렵지 않습니다). 모의 익스플로잇으로 인한 피해 만 보안 팀에보고합니다 코드의 일부는 취약합니다.), 스톱워치를 시작하십시오. 이는 사이트가 해킹 당했을 때 일어날 일이기 때문입니다. 지원 담당자가 전역 FTP 및 mysql 액세스를 요청하면 PCI-DSS를 위반한다고 명시 적으로 거부하고 소스 코드 저장소에 대한 읽기 전용 액세스 권한을 부여합니다.
내가 수행하는 # 2 테스트는 공급 업체를 불러서 경비원을 잡아내는 것입니다. 어떤 종류의 행동 / 단위 테스트, 그들이 사용하는 소스 제어 시스템, 테스트하는 PHP 버전, 테스트되는 마 젠토 버전, 테스트중인 웹 서버, 브라우저 사용 여부 등을 물어보십시오. 프론트 엔드 구성 요소 등을 테스트하기위한 스택-공급 업체가 당신이 말하는 것을 알지 못하거나 침묵하거나 "전문가에게 이메일을 보내도록"하려는 경우 번호가 가장 많이 사용되기 때문에 지옥처럼 실행됩니다. "버전 제어"용 zip 파일을보고 고객이보고 한 후 3 개월 후에 만 버그를 수정합니다.
PCI-DSS에 관해 말하면, 모든 시스템 수정에는 복귀 전략이 필요합니다. Null을 허용하지 않는 열을 코어 테이블에 추가하는 모듈을 사용하면 감사를 통과하는 복귀 전략을 유지하면서 거의 불가능합니다. 비활성화되면 문제 (읽기 : SQL 오류)를 유발하는 모든 모듈에서 지옥처럼 실행하십시오.
PCI-DSS v3
6.4.5.4 철회 절차.
샘플링 된 각 변경에 대해 취소 절차가 준비되어 있는지 확인하십시오.
각 변경에 대해 변경이 실패하거나 응용 프로그램이나 시스템의 보안에 악영향을 미쳐 시스템을 이전 상태로 다시 복원 할 수 있도록 문서화 된 철회 절차가 있어야합니다.
이것은 다른 답변과 함께. IMO이 플랫폼에서 생성 된 일부 위험한 쓰레기에 대한 수치심의 벽이 있어야합니다.