Mudar um botão na página inicial recebe uma estimativa de duas semanas. A atualização dos plugins fica para segunda-feira, porque à sexta ninguém quer arriscar. Ao fim de uma semana, o programador novo ainda não tem uma cópia do site a funcionar no seu computador. O dono da empresa vê as faturas a crescer e tira a conclusão mais fácil: as pessoas trabalham devagar.
Ally Piechowski, que audita equipas de programação, descreveu no artigo Why Your Engineering Team Is Slow (It’s the Codebase, Not the People) cinco sinais de que é o código, e não a equipa, que trava o ritmo. Escreveu sobre aplicações, mas cada um destes sinais tem equivalente num site WordPress e numa loja WooCommerce. A seguir encontra cada um deles, com uma forma de o medir na sua própria instalação.
Porque é que a estimativa para uma alteração simples no WordPress é tão alta
A autora chama ao primeiro sinal a estimativa com pedido de desculpas. Para uma funcionalidade que devia levar três dias, o programador diz: “Conhecendo este código, deve levar umas duas semanas” (Ally Piechowski, tradução própria). Sabe que uma alteração num sítio estraga algo noutros três. Para a autora, estimativas que saem sistematicamente 2-3 vezes superiores ao que deviam não são um problema de estimativa. A equipa sabe quanto custa este código, apenas deixou de o explicar.
No WordPress, estas ligações ocultas têm origens típicas: um tema que gera parte do conteúdo por conta própria em vez de usar blocos, modelos do WooCommerce substituídos e copiados há várias versões, vários plugins a fazer a mesma coisa e código próprio ligado aos mesmos hooks.
Como medir: pegue nas últimas dez alterações do histórico de tickets e compare a estimativa com o tempo real. Se o desvio for constante e sempre no mesmo sentido, a estimativa diz a verdade sobre o código.
Porque é que ninguém quer atualizar o site à sexta-feira
O segundo sinal é o medo de publicar. O artigo dá o exemplo de uma equipa com a regra não escrita “nada de publicações depois de quarta-feira”. Surgiu depois de três publicações seguidas à quinta-feira terem acabado em avarias ao fim de semana, sem plano para voltar atrás, com testes em que ninguém confiava e um processo de publicação de 45 minutos.
Num site WordPress, este medo tem este aspeto: atualizações de plugins feitas diretamente em produção, nenhum ambiente de testes ou um com a base de dados de há seis meses, uma cópia de segurança que ninguém alguma vez restaurou. O resultado é o mesmo do artigo: as alterações acumulam-se em pacotes, e cada pacote é maior e mais arriscado do que o anterior.
Como medir: responda a três perguntas. Existe um ambiente de testes com a base de dados atual? Alguém restaurou uma cópia de segurança no último trimestre? Há dias em que a equipa não publica? Cada “não” nas duas primeiras e um “sim” na terceira aumentam a pontuação.
Que ficheiro do tema WordPress é a zona proibida
O terceiro sinal é o ficheiro em que ninguém mexe. A autora procura-o no histórico do repositório: um ficheiro que aparece constantemente no git log, mas cuja estrutura ninguém altera há anos. À volta dele, a equipa constrói desvios, e o código cresce em torno de uma zona que todos evitam.
No WordPress, é quase sempre o functions.php do tema, que ao longo dos anos chegou a vários milhares de linhas, ou o plugin próprio da empresa, ao qual cada um acrescentou “só mais uma função”.
Como medir: no repositório do tema ou do plugin próprio, execute
git log --since="1 year ago" --format= --name-only | sort | uniq -c | sort -rn | head -10A lista mostra os ficheiros alterados com mais frequência. O ficheiro no topo cujas alterações são apenas acrescentos no fim é candidato a zona proibida. Se o tema não tem repositório, a pontuação deste sinal é alta de qualquer forma: não há como saber quem alterou o código, nem porquê.
Aproveite para contar os plugins ativos:
wp plugin list --status=active --format=countO número por si só não decide nada, mas vários plugins de formulários, cache ou SEO em simultâneo são uma fonte frequente de conflitos que tornam cada alteração mais demorada.
Uma cobertura de testes elevada protege o checkout do WooCommerce
A autora chama ao quarto sinal a mentira da cobertura. O painel mostra uma percentagem de cobertura saudável, enquanto três modelos que lidam com dinheiro não têm um único teste. Além disso, os testes no servidor de CI levavam 40 minutos, por isso os programadores deixaram de os correr localmente. O teste dela é simples: quando foi a última vez que um teste apanhou um erro antes de chegar à produção?
Uma loja WooCommerce sem qualquer teste tem o mesmo problema de forma mais aguda. O percurso do dinheiro é o carrinho, o checkout, o gateway de pagamento e o e-mail de confirmação da encomenda. Se após cada atualização alguém faz uma encomenda de teste à mão, a loja tem um teste, só que manual e dependente da memória de uma única pessoa.
Como medir: verifique se existe algum teste automático que faça uma encomenda e pergunte quando foi a última vez que apanhou alguma coisa.
Quanto tempo leva a pôr um programador novo a trabalhar num site WordPress
O quinto sinal é o tempo até à primeira alteração: quanto tempo passa até uma pessoa nova publicar uma correção real. Segundo a autora, num projeto saudável é um dia ou dois, enquanto em projetos doentes viu duas semanas ou mais. A causa é muitas vezes uma configuração degradada: scripts de instalação desatualizados, dados iniciais estragados, variáveis de ambiente por documentar.
No WordPress, a lista é parecida: nenhum repositório, uma cópia da base de dados que é preciso pedir ao alojamento, chaves de API guardadas só em produção, plugins premium sem licença de desenvolvimento.
Como medir: monte do zero uma cópia local funcional, por exemplo com o wp-env, e anote o tempo e cada coisa que teve de pedir a alguém.
Como se calcula a pontuação dos cinco sinais
A autora avalia cada sinal numa escala de 0 a 2. Um total de 4 ou mais significa que o código precisa de investimento direto antes de outras medidas ajudarem. A partir de 7 pontos, segundo escreve, começa a maioria dos seus trabalhos.
| Sinal | 0 pontos | 2 pontos |
|---|---|---|
| Estimativa com pedido de desculpas | as estimativas batem certo com o tempo real | desvio constante para cima |
| Medo de publicar | ambiente de testes, plano para voltar atrás, publicação em qualquer dia | alterações em produção, nenhuma cópia verificada |
| Ficheiro em que ninguém mexe | nenhum ficheiro domina o histórico | um ficheiro vai acumulando acrescentos |
| Cobertura de testes | um teste apanhou recentemente um erro antes da produção | checkout sem qualquer teste |
| Tempo até à primeira alteração | cópia local numa hora | vários dias e pedidos de acesso |
Os pontos em si são convencionais, o que conta é a ordem dos sinais. A autora aconselha a começar pelo sinal com a pontuação mais alta, dedicar-lhe duas semanas de trabalho concentrado e medir algo concreto, como a frequência das publicações ou o acerto das estimativas.
Porque é que o melhor programador do site é o mais lento
A autora aponta um paradoxo: com um código assim, quem mais abranda são os melhores. Veem o risco, sabem que uma alteração neste ficheiro pode estragar aquele processo, por isso trabalham com cautela, escrevem código defensivo e inflacionam as estimativas. Uma pessoa menos experiente às vezes é mais rápida porque não vê o perigo, e depois causa uma avaria a seguir à qual todos ficam ainda mais cautelosos.
Um exemplo do artigo: dois programadores passaram uma semana a acrescentar uma exportação em CSV ao painel de administração, quando o trabalho em si era talvez de um dia. O resto do tempo foi gasto a compreender o código existente o suficiente para o alterar em segurança. Esta sobrecarga não aparece em nenhum relatório, e a direção só vê pessoas lentas.
Reconstruir o site do zero resolve a lentidão das alterações
Nem sempre. A autora descreve um cliente pelo qual passaram seis equipas de programação em dez anos. O padrão repetiu-se sempre: pressão por novas funcionalidades, limpezas adiadas, até o código parecer impossível de salvar. Então alguém propunha reescrever tudo ou separar microsserviços, o que piorava a situação, porque em vez de um sistema passava a haver dois, e o antigo continuava a funcionar.
No WordPress, este cenário é familiar: um tema novo montado ao lado do antigo, um frontend headless que assume parte das páginas enquanto o resto continua a passar pelo modelo antigo, ou uma loja nova para a qual metade das integrações nunca chega a ser migrada. Uma reconstrução faz sentido quando se sabe que sinal está a travar e se a nova arquitetura o elimina. Sem isso, os obstáculos antigos mudam-se para o código novo.
O que corrigir primeiro em cada sinal
A autora indica um primeiro passo diferente para cada sinal. Seguem-se as recomendações dela e o equivalente num site WordPress.
- Estimativa com pedido de desculpas: separar os módulos cujas alterações têm maior alcance. No WordPress, isto costuma significar dividir o
functions.phpem ficheiros separados ou num plugin com funções de nomes claros, e retirar os modelos do WooCommerce substituídos que ninguém atualizou. - Medo de publicar: um processo de publicação mais rápido, regresso automático à versão anterior e pacotes de alterações mais pequenos. No WordPress: um ambiente de testes com a base de dados atual, publicação do código a partir do repositório em vez de FTP e uma restauração de cópia de segurança testada.
- Ficheiro em que ninguém mexe: primeiro testes à volta dele, depois alterações de estrutura. Para um tema, bastam para começar alguns testes que verifiquem se as páginas principais são apresentadas.
- Cobertura de testes: um teste do percurso do dinheiro. No WooCommerce, é um teste automático que faz uma encomenda no ambiente de testes e verifica se chegou o e-mail de confirmação.
- Tempo até à primeira alteração: segundo a autora, um único dia dedicado a corrigir a configuração paga-se a si próprio. No WordPress: um ficheiro de configuração do wp-env no repositório, um script que descarrega uma cópia anonimizada da base de dados e uma lista das variáveis de ambiente.
Quando falar disto com a administração ou com um cliente, o concreto funciona melhor do que o genérico. A autora contrapõe duas frases: “cada funcionalidade demora aproximadamente o dobro do tempo por causa das ligações entre estes três módulos” é uma conversa completamente diferente de uma queixa sobre dívida técnica (Ally Piechowski, tradução própria).
A IA vai acelerar as alterações num site WordPress antigo
É tentador supor que um agente de IA vai reescrever o problema. A autora cita um estudo da METR de 2025: 16 programadores experientes de código aberto trabalharam 19% mais devagar com ferramentas de IA em repositórios que conheciam bem. Acrescenta que escrever código nunca foi o ponto de estrangulamento.
O agente esbarra nas mesmas dependências ocultas que uma pessoa, só gera mais depressa o próximo desvio à volta do ficheiro em que ninguém mexe. Vale a pena, por isso, baixar os cinco sinais antes de deixar a IA entrar no repositório.
Por onde começar a corrigir um site WordPress lento
Com quatro pontos ou mais, comece por remover o obstáculo com a pontuação mais alta. Um programador novo ou um tema novo vão encontrar os mesmos obstáculos. Normalmente são um ambiente de testes com a base de dados atual e um repositório para o tema, porque sem eles não é possível mexer em segurança em nenhum outro sinal.
É assim que funciona o nosso sprint de recuperação WooCommerce: um diagnóstico pago, correções por ordem de prioridade, publicação primeiro no ambiente de testes e um relatório escrito com o que foi alterado e porquê. Se está a pensar se ainda compensa reparar o site, comece pela auditoria de prontidão para redesign ou pelo guia sobre quando reconstruir um website.
