O que faz um programador Magento: os quatro perfis e qual deles a sua loja precisa

Programador Magento e desenvolvedor Magento são a mesma coisa?

São. Os dois nomes descrevem o mesmo trabalho, e eu uso os dois sem distinção. A diferença que importa para quem contrata está na camada da loja em que a pessoa trabalha, e não no nome do cargo.

A própria Adobe separa as coisas: nas certificações de Adobe Commerce, Developer e Front-end Developer são trilhas diferentes (as certificações terão artigo próprio aqui).

O que todo perfil tem em comum é uma regra da plataforma: ninguém edita o código do Magento que fica em vendor/magento, porque o Composer sobrescreve essa pasta na próxima atualização. Toda mudança entra por módulo, tema ou configuração.

Os quatro perfis do ecossistema Magento

A última coluna é a mais útil para quem contrata: é onde o trabalho de cada perfil fica visível e pode ser conferido.

As versões suportadas de cada serviço mudam com a versão do Magento e estão na página oficial de requisitos de sistema da Adobe.

Desenvolvedor backend Magento: módulos, integrações e DI

É quem cria e mantém módulos: um campo novo no cadastro do cliente, uma regra de frete que o painel não oferece, a integração que manda o pedido para o ERP.

O que diferencia um backend Magento de um bom programador PHP de outra plataforma é a injeção de dependência (DI). No Magento as classes pedem o que precisam no construtor, e o arquivo di.xml decide o que entregar. É por esse mecanismo que o dev altera o core sem editar o core, com plugin, observer ou preference. A documentação da Adobe diz que uma classe não deve depender do ObjectManager diretamente, salvo fábricas com lógica complexa e testes de integração.

Três sinais mostram cedo quem ainda não domina essa camada: consulta SQL escrita direto no meio do código, ObjectManager::getInstance() espalhado pelas classes e qualquer alteração dentro de vendor/.

Desenvolvedor frontend Magento: Luma ou Hyvä

O frontend do Magento tem duas bases técnicas bem diferentes, e um profissional excelente em uma pode ser iniciante na outra.

• Luma (e o Blank, os temas que acompanham o Magento): estilos em LESS, JavaScript carregado pelo RequireJS, jQuery e componentes de interface com bindings de Knockout.js.
• Hyvä: tema de outra empresa, construído com Tailwind CSS e Alpine.js. A documentação do Hyvä avisa que módulos feitos para Luma ou Blank precisam de um módulo de compatibilidade para funcionar nele.

Numa loja Hyvä, cada extensão que altera a vitrine pode exigir essa compatibilidade, e o dev precisa conferir isso antes de orçar. Para saber qual tema a sua loja usa, entre em Content > Design > Configuration, edite a store view e veja o campo Applied Theme.

DevOps para Magento: servidor, cache, busca e deploy

Magento em produção depende de vários serviços juntos: PHP-FPM, Varnish guardando páginas prontas, OpenSearch na busca do catálogo, Valkey ou Redis para cache e sessão, RabbitMQ para as filas e o cron disparando a indexação agendada. Quando um deles cai ou fica lento, quem investiga é o perfil de DevOps.

O deploy também é dele. Com a loja em modo production, a documentação da Adobe diz que os arquivos estáticos são servidos só a partir do cache, então o deploy precisa gerá-los com setup:static-content:deploy, na ordem certa junto com setup:upgrade e setup:di:compile. O app/etc/env.php, com a conexão do banco, o cache e a chave de criptografia, também é território dele.

Em hospedagem gerenciada, parte desse trabalho pode estar incluída no plano. Pergunte qual parte, por escrito.

Adobe Commerce Cloud pede outro profissional?

Depende de qual Cloud, porque a Adobe tem dois produtos com nome parecido:

• Adobe Commerce on cloud infrastructure: a mesma aplicação que roda em servidor próprio, hospedada pela Adobe em regiões da AWS ou da Azure. O código dos módulos e do tema é igual; muda a operação. Build e deploy acontecem a cada push no Git, configurados em .magento.app.yaml e .magento.env.yaml com o pacote ece-tools, e a Adobe pede Fastly em staging e produção para manter a conformidade PCI. Quem faz o papel de DevOps precisa conhecer esse fluxo.
• Adobe Commerce as a Cloud Service: o modelo SaaS, com atualização automática. O guia de migração da Adobe diz que o modelo de módulos, plugins e observers em PHP rodando dentro da aplicação não vale para ele: a customização vira aplicação do App Builder, fora da aplicação, ligada ao Commerce por eventos e APIs, com ferramentas como API Mesh e webhooks. Aqui o perfil muda de verdade.

Se a sua loja é Magento Open Source ou Adobe Commerce em servidor próprio, nenhum dos dois casos se aplica.

Qual perfil a demanda da sua loja precisa

Muita demanda cruza perfis, e é aí que a contratação escorrega. Dois exemplos:

• Campo novo no checkout: o backend salva o dado no carrinho e no pedido e mostra no admin; o frontend exibe e valida na tela. Contratar só um dos dois deixa metade pronta.
• Loja lenta: a causa pode ser um módulo que desliga o cache da página (backend) ou um Varnish mal configurado (DevOps). Quem investiga precisa enxergar as duas camadas, ou você paga duas investigações.

Um profissional só dá conta quando a hospedagem cuida da infraestrutura e as demandas são pontuais. Eu separaria os perfis quando aparecem juntas integração com ERP e mudança de tema, ou quando desempenho é problema recorrente. Na dúvida, pergunte ao candidato qual foi o último deploy que ele fez sozinho e quais comandos rodou: a resposta mostra em qual camada ele vive. Se quiser ajuda para enquadrar a sua demanda, fale comigo.