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)?
performance
extensions
Junap
fonte
fonte
Respostas:
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.
fonte
Algumas bandeiras vermelhas específicas da "má prática" do Magento são:
app/code/local/Mageapp/designque já existem no núcleo)catalog/product. Em geral, olho cuidadosamente todas as reescritas, para ver se elas poderiam ter sido evitadas.Mage::getModelno diretório de modelos geralmente é um mau sinal)Alguns sinalizadores relacionados ao PHP (esta é uma lista muito seletiva e incompleta):
E_STRICT)@operadorAlgumas bandeiras vermelhas relacionadas ao desempenho:
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.
fonte
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.
fonte
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.
fonte
*_aftereventos em vez de*_beforeeventos, se possível. Em termos de desempenho, não há nenhuma declaração sobre os observadores.controller_action_predispatché enviado uma vez por solicitação, então esse talvez não seja o melhor exemplo. Porém, embora você mencione apenas um alto potencial para problemas de desempenho e haja eventos despachados muitas vezes mais por solicitação, discordo: os observadores não são mais ou menos propensos a problemas de desempenho do que qualquer outro código. Se você faz coisas que realmente afetam o desempenho, como carregar todos os produtos, isso é um problema por si só, independentemente de onde isso acontece.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!
fonte
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.
fonte
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.
fonte
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.
Isso, além das outras respostas. Na IMO, deve haver um muro de vergonha para algumas das porcarias perigosas que foram geradas nesta plataforma.
fonte