Como avaliar extensões de terceiros?

Embora o Magento faça muitas coisas prontas, descobrimos que existem inevitavelmente recursos e instalações necessários para lojas de clientes que exigem uma extensão de terceiros.

No entanto, dada a natureza do meio, pode ser uma proposição arriscada introduzir código 'estrangeiro' em um sistema tão complexo que lida com transações comerciais.

O que você procura ao avaliar extensões Magento? Quais são as 'bandeiras vermelhas' que você encontrou (porcos de desempenho, riscos de segurança, práticas inadequadas de arquitetura)?

Aqui estão algumas reflexões sobre a avaliação de módulos de terceiros:

Noções básicas:

• Suporte à versão atual do Magento - Ele suporta a versão mais recente do Magento (incluindo a atual para a qual estamos desenvolvendo)?

  Se um módulo não suportar a versão mais recente do Magento, provavelmente será difícil fazê-lo funcionar sem gastar um tempo precioso de desenvolvimento nele.

• Suporte - Os desenvolvedores que criaram o módulo suportam o produto?

  Um dos sinais de um módulo íntegro é que os desenvolvedores o apoiam ativamente. Se eles não suportam, é uma bandeira vermelha, por que eles não suportam o produto, se é bom?

  Além disso, quando um módulo é suportado, geralmente podemos obter informações importantes dos desenvolvedores com um simples email (por exemplo, este módulo usa jQuery ou Prototype).

• Comentários - O que os outros usuários estão dizendo? Como foi a experiência deles?

  Ao ler os comentários, podemos ter uma idéia melhor do cenário geral, há um problema de instalação? Os desenvolvedores respondem de maneira oportuna e útil? Isso funciona como anunciado?

• Reembolso - Eles devolvem seu dinheiro se não funcionar como pretendido?

  Muitas vezes queremos experimentar o módulo para que possamos testá-lo, se ele funcionar e atender às nossas especificações, ótimo! Mas, se não, queremos a opção de devolvê-lo e obter um reembolso por ele.

Intermediário:

• Substituições de Classe - O módulo substitui alguma classe principal?

  De um modo geral, um bom módulo não deve substituir nenhuma classe principal, mas deve usar Observadores.

  Uma razão para isso é que isso pode dificultar a atualização do Magento. Além disso, outros módulos podem depender de uma saída de uma determinada função, e este módulo está fornecendo uma diferente.

  Às vezes, isso não é possível, se for o caso, deve haver uma boa razão para substituir uma classe principal.

• Atualizações de layout - O módulo altera algumas das minhas configurações de layout?

  Alguns módulos alteram as configurações de layout para o seu site (por exemplo: página do produto), verifique se ele não quebra o layout atual e se faz o que seria necessário (leia-se: quanto tempo nos levará) para corrigi-lo .

• Alterações de modelo - O módulo inclui modelos que alteram meu design atual?

  Este módulo apresentará novos modelos? Se sim, eles vão quebrar o meu design? Quanto tempo leva para ter o design da maneira que queremos?

• Dependências - O módulo depende de outro módulo?

  Se o módulo depender de outros, precisamos garantir que eles estejam lá e instalados. Além disso, precisamos nos perguntar: queremos desligar o módulo em que ele depende no futuro?

Avançado:

• Scripts de atualização do SQL - O módulo atualiza o banco de dados de alguma forma?

  Depois que um módulo atualiza o banco de dados, precisamos garantir algumas coisas.

  Atualiza uma tabela principal? Se sim, isso não é bom, gostamos de nossos bancos de dados limpos e prontos para atualização.

  Ele armazena as informações de maneira sensata? Se quisermos obter os dados brutos do banco de dados, poderíamos entender isso?

• Eventos - O módulo observa ou despacha algum evento?

  Se um módulo despacha ou observa eventos, queremos saber:

  Quais eventos são observados / despachados? Isso afetará outro módulo que trabalha no sistema. Por exemplo, se um de nossos módulos altera o nome de nossos produtos em carga para maiúsculas, e este módulo adiciona a palavra 'grátis' ao nome do produto em carga, como funcionará? A palavra 'grátis' também sairá em maiúsculas?

• Revisão de código - O módulo usa técnicas de codificação aceitáveis?

  Isso tem mais a ver com técnicas de codificação PHP do que o Magento.

  O código usa blocos Try / Catch?

  O código escapa à entrada do usuário?

  As especificidades disso realmente dependem do nosso nível de habilidade / requisitos.

• Problemas potenciais - Quais problemas potenciais podem surgir como resultado da instalação deste módulo?

  Tente imaginar os cinco principais problemas que podem surgir se instalarmos este módulo, por mais surpreendente que seja, ele realmente fornece informações sobre o projeto como um todo.

Bottom Line:

Todas essas coisas são boas de se ter em um mundo ideal; em cenários do mundo real, precisamos fazer isso chamado 'compromisso' :)

Além disso, essas diretrizes devem ser uma ajuda para nós, não para nos impedir, como resultado, se estamos instalando apenas um módulo, digamos um módulo de compartilhamento social, e é para um cliente que precisa de uma configuração simples do site, não faz sentido fazer uma tonelada de pesquisa.

Em outras palavras: trata-se de ser eficiente com o nosso tempo, se o uso desta (item na diretriz) me ajudar a economizar tempo a longo prazo, usá-lo, se não o abandonar e salvar sua sanidade.

Algumas bandeiras vermelhas específicas da "má prática" do Magento são:

• qualquer código em app/code/local/Mage
• modelos substituídos (arquivos app/designque já existem no núcleo)
• reescreve de classes essenciais como catalog/product. Em geral, olho cuidadosamente todas as reescritas, para ver se elas poderiam ter sido evitadas.
• violações graves dos padrões de codificação Zend / Magento. Embora isso seja apenas sobre formatação de código, concluo que os desenvolvedores que não se importam com os padrões provavelmente também se importam com outras coisas mais importantes.
• mudanças nas tabelas principais do banco de dados
• texto codificado em modelos (não usando o mecanismo de tradução) e em outros lugares
• lógica de negócios em modelos (regra geral: qualquer ocorrência Mage::getModelno diretório de modelos geralmente é um mau sinal)

Alguns sinalizadores relacionados ao PHP (esta é uma lista muito seletiva e incompleta):

• quaisquer avisos e avisos com relatório de erros ativado ( E_STRICT)
• uso do @operador
• não higienizando os dados do usuário antes da saída

Algumas bandeiras vermelhas relacionadas ao desempenho:

• consultas de banco de dados dentro de loops
• carregando uma coleção inteira apenas para usar uma parte dela

Observe também os odores gerais do código , esses não são sinais de alerta necessários, mas ajudam a estimar a qualidade geral.

Etapa 1 - Seu cliente pode se dar ao luxo de oferecer suporte a essa extensão se o desenvolvedor for AWOL?

Se não, você não pode usar a extensão.

Se sim, continue com a avaliação da extensão.

O pessoal do Inchoo tem um artigo sobre a análise do código do módulo de terceiros. O artigo menciona reescritas de classe, tarefas cron, atualizações de layout e observadores de eventos.

Eu descobri que o código do observador de eventos tem o potencial de obter o maior desempenho possível. Procure código de terceiros com uso intensivo de recursos, que é executado para eventos frequentemente enviados. Eventos como controller_action_predispatch ou carregamentos de coleção.

Eu uso este módulo utilitário da Prattski para obter uma boa visão geral de reescritas e observadores.

Ter modelos e ativos de capa localizados em padrão / padrão (ou profissional ou corporativo) em vez de base / padrão é bastante irritante.

Código ofuscado é algo a ser observado - procure por chamadas para eval (), base64_decode () e similares. Isso geralmente é usado para validação de licença, mas pode ser malicioso ou assustador - vi pelo menos um componente que avaliava o código arbitrário de um feed RSS.

Procure por chamadas dl () - pelo menos um componente de gateway de pagamento que vi requer a instalação de uma extensão PHP para fazer suas conexões!

Você está certo.

Infelizmente, não há mágica: você precisa testá-los, verificar o código para ver se está bem desenvolvido, ter um bom suporte para módulos comerciais, graças ao fórum ou rapidez para responder às suas perguntas ...

Existem algumas análises sobre o Magento Connect e a popularidade de uma extensão pode ajudar a saber se é valiosa ou não, mas honestamente, você pode encontrar módulos muito populares com muitos erros. Tive um bom exemplo na semana passada com um módulo MailChimp, principalmente bem feito, mas tive que corrigir alguns bugs e fornecê-los ao desenvolvedor. Sempre há riscos, você precisa testar.

O WebShopApp teve a ideia de avançar nessa direção, ou seja, trazer uma plataforma para obter boas informações sobre os módulos. A idéia era empurrar o Magento nessa direção. Portanto, a qualidade do módulo é uma questão real.

Meu conselho: preste muita atenção aos módulos que possuem scripts de instalação / atualização que alteram valores nas tabelas principais, porque nem sempre é fácil reverter esse tipo de alteração.

O teste número 1 que posso encontrar é encontrar uma exploração de dia zero em seu código (geralmente não muito difícil com as extensões Magento), relatar apenas o dano resultante de uma exploração simulada à sua equipe de segurança (não dando indicação de qual parte do código é vulnerável) e inicie o cronômetro - porque é exatamente isso que acontecerá quando o site for invadido. Quando a equipe de suporte solicitar acesso global ao FTP e ao mysql, recuse educadamente que esteja violando o PCI-DSS e ofereça para que eles tenham acesso somente leitura ao seu repositório de código-fonte.

O teste nº 2 que realizo é chamar o fornecedor e pegá-lo desprevenido. Pergunte a eles que tipo de teste comportamental / unitário eles fazem, em qual sistema de controle de origem eles usam, em quais versões do PHP eles testam, em quais versões do Magento são testadas, em quais servidores da Web são testados, se usam ou não o navegador. - pilha para testar componentes front-end, etc ... Se o fornecedor não souber do que você está falando, ficar em silêncio ou quiser "obter um especialista para lhe enviar um e-mail de volta", corra como o inferno, porque provavelmente usa números arquivos zip para "controle de versão" e apenas corrija bugs 3 meses depois que os clientes os reportarem.

Falando no PCI-DSS, todas as modificações do sistema também são necessárias para ter uma estratégia de reversão. Com os módulos que adicionam colunas não anuláveis ​​às tabelas principais, isso se torna quase impossível, mantendo uma estratégia de reversão que passaria na auditoria. Execute como qualquer outro módulo que causará problemas (leia-se: Erros SQL) quando desativado.

PCI-DSS v3

6.4.5.4 Procedimentos de retirada.

Verifique se os procedimentos de retirada estão preparados para cada alteração amostrada.

Para cada alteração, deve haver procedimentos de retirada documentados, caso a alteração falhe ou afete adversamente a segurança de um aplicativo ou sistema, para permitir que o sistema seja restaurado de volta ao estado anterior.

Isso, além das outras respostas. Na IMO, deve haver um muro de vergonha para algumas das porcarias perigosas que foram geradas nesta plataforma.