Meus cinco piores erros de desenvolvimento do WordPress

Ou, para todos os servidores que já falhei antes: uma retrospectiva do horror nos cinco piores erros do WordPress que cometi

Como desenvolvedores, cometemos diferentes tipos de erros em diferentes pontos de nossa carreira. No desenvolvimento do WordPress, em particular, cometemos diferentes tipos de erros à medida que nossa familiaridade com a base de código do WordPress cresce.

Alguns anos atrás, ouvi Matt Mullenweg declarar algo no sentido de que a maioria das pessoas repete seus erros, as pessoas mais inteligentes aprendem com seus erros e as pessoas mais inteligentes entre nós aprendem com os erros dos outros. Eu gosto disso e acrescentaria um corolário: todo mundo comete erros, pessoas humildes compartilham esses erros em particular, e os mais ousados ​​entre nós os anotam e os publicam em um blog!

Mas há tempo para meditar mais tarde. Você está lendo este artigo porque quer saber sobre um acidente de trem, e eu sou o engenheiro. Sem mais preâmbulos, junte-se a mim em uma retrospectiva horrorizada dos cinco erros mais embaraçosos que cometi como desenvolvedor WordPress.

A hora em que atualizei uma versão hackeada do WordPress Core

Eu estava apenas me graduando de fazer shows de codificação altamente obscuros no CraigsList, para realmente trabalhar em uma agência ao vivo real. Eu tinha chegado! Eu estava nervosa por estar trabalhando em outro lugar além do meu sofá, em algo diferente do meu pijama. Mas mesmo assim, eu geralmente conhecia o WordPress Right from WordPress Doing It Wrong, e achei agradavelmente auto-engrandecedor me gabar das melhores práticas do WordPress, como nunca “hacking core”.

Minha primeira tarefa de desenvolvimento do WordPress nesta agência foi retomar um projeto parado – bastante complexo para o meu conjunto de habilidades na época. Envolveu muitas personalizações no registro do WordPress e no fluxo de login. O desenvolvedor anterior tinha a fama de ter alcançado um progresso significativo simplesmente editando os principais arquivos wp-login .

Eu sabia que isso era insustentável, então minha primeira tarefa era instalar um plug-in de backup/restauração e substituir o núcleo do WordPress por uma versão recém-baixada. Eu estava confiante de que nada terrivelmente impressionante havia sido realizado até o momento no projeto e que eu seria capaz de imitar o conjunto de recursos existente por meio de filtros.

Qualquer habilidade de codificação que eu pudesse ou não ter naquele momento rapidamente se tornou irrelevante, pois meu novo empregador estava fervendo de raiva. Ela não entendia o significado de “hacking core” e eu não era maduro o suficiente para explicá-lo de uma maneira digerível. A única coisa que esfriou temporariamente sua testa foi quando eu garanti a ela que poderia reverter através do plugin de backup/restauração que instalei.

Você consegue adivinhar onde isso está indo?

Esse plugin, como o destino quis, apenas fez backup da pasta wp-content . Quaisquer que sejam os hacks do WordPress nesses arquivos principais, desapareceram para sempre. Ainda me lembro do meu e-mail de volta para ela (ela havia muito tempo me baniu de volta para o meu escritório em casa a essa altura):

Pessoal, não consigo fazer o backup.

Eu realmente estava preparado para completar o conjunto de recursos desejado por meio de filtros e ações, mas ela não quis ouvir. Ela me demitiu na hora, ameaçou me processar e nunca me pagou por duas semanas de trabalho muito duro. Eu estava tão humilhado.

Há muitas coisas (agora óbvias) que eu poderia ter aprendido com essa experiência. A lição geral, de que um backup não é um backup até que seja ensaiado e confirmado, é boa. Mas o que mais me chamou a atenção é uma lição específica sobre como exatamente fazer backups no WordPress – particularmente com o núcleo do WordPress.

Aprendi a realmente valorizar ambientes gerenciados como o WP-Engine, com um sistema robusto de backup/restauração. Muitos hosts boutique têm várias ferramentas de linha de comando e outros recursos focados no desenvolvedor para realizar backups, mas o WP-Engine é o meu favorito. É bastante rápido, a menos que você tenha uma rede muito grande. A interface do usuário é simples. Tem uma interface do usuário, ponto final: Qualquer pessoa que saiba usar o WordPress pode trabalhar com isso. Ou seja, em contraste com alguma abordagem CLI que provavelmente é muito mais rápida, ou alguma coisa obscura enterrada no Plesk, meus clientes podem usar isso, entendê-lo, monitorá-lo e verificar se estou usando. Eu sou um grande fã.

A vez em que arrastei toda a nossa plataforma para seu diretório de irmãos

Eu ainda era relativamente novo no local de trabalho profissional e sempre fui uma pessoa do Windows. No entanto, meu novo trabalho foi em uma loja de Mac e aprendi a amar tudo sobre isso muito rapidamente. Bem, quase tudo. Eu parecia estar tendo muitos problemas com o “rato mágico”. Eu tinha uma tendência a perder minha conexão Bluetooth, levando a ações de arrastar e soltar acidentais e muitas vezes assustadoras quando ela se reconectava. Mais do que isso, eu era apenas desajeitado com uma nova habilidade motora fina.

Naquela época, nosso fluxo de desenvolvimento do WordPress ainda incluía a implantação para produção via FTP. Não era incomum para mim passar dias inteiros de trabalho escrevendo código, conversando, respondendo e-mails, geralmente girando de um lado para o outro com meu novo mouse mágico, com o Cyberduck aberto para produção na minha área de trabalho. Puxa, isso soa mal! Mas foi assim.

Um dia, toda a nossa plataforma acabou. Nosso administrador de sistema foi rápido em assumir que era algum tipo de DDoS ou algo geralmente no nível dele. Quanto a nós desenvolvedores, confiamos em seus instintos e assumimos que ele descobriria em breve.

As horas se passaram. O dia veio e se foi. Ainda para baixo.

Na manhã seguinte, as coisas foram restauradas, e nossa CTO gentilmente me pediu para me juntar a ela na sala de conferências. Nosso administrador de sistema identificou o problema. Ele puxou os logs de FTP e observou que meu usuário havia movido toda a nossa plataforma para um diretório irmão. Ou seja, wp-content ficou aninhado em wp-includes .

Fiquei desanimado, mas nosso CTO foi ótimo. Ela podia ver que eu era geralmente um funcionário prestativo e responsável, mas ela me desafiou a ir além da mera contrição e encontrar maneiras de evitar que isso acontecesse novamente. Encontrei duas coisas muito úteis.

A primeira foi localizar um comando CLI para impedir que o Cyberduck permitisse movimentos de arquivos remotos a remotos. Essa foi uma boa medida de segurança e a adotamos imediatamente como política da empresa.

A segunda foi que eu tive um grande interesse em implantar via Git. Eventualmente, acabei escrevendo um plugin do WordPress para tecer nosso versionamento do Bitbucket no fluxo normal de atualização do wp-admin . Desde então, não tivemos quase nenhuma razão para ter acesso FTP à produção. Este plugin é uma das minhas conquistas profissionais favoritas. Claro, uma afinidade com o Git é um pré-requisito para os desenvolvedores hoje.

A hora em que removi todo o conteúdo do front-end via add_filter()

Eu realmente pensei que tinha me tornado bastante inteligente com minhas práticas do WordPress a essa altura. A solicitação era para anexar um “crachá” às postagens de uma determinada categoria. Por alguma razão eu tinha em mente que apenas noobs adicionariam mais uma condicional a um arquivo de modelo para algo assim, então com muito orgulho, implementei o seguinte filtro:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Vê algo de errado com isso? Testei-o rapidamente na preparação para confirmar que as postagens necessárias tiveram seus selos aplicados. Então eu o implantei e deixei o trabalho para o dia. Como você pode imaginar, o universo explodiu.

Especificamente, o resultado foi que as postagens sem o emblema estavam renderizando no front-end sem conteúdo algum! Você pode ver por quê? O problema era que, em vez de retornar $content na minha condição de guarda, eu estava retornando false . Mas realmente há muitas camadas de erros aqui.

Por que me contentei em testar apenas se as postagens receberam um selo? Por que eu também não testei se outros posts permaneceram ilesos? Por que eu estava implantando na produção tão tarde? Por que nosso controle de qualidade consistia inteiramente em eu clicar um pouco e atualizar a página?

A resposta a todas essas perguntas pode ser resumida como maturidade . Simplesmente leva um tempo para ficar cansado de cometer esses tipos de erros, antes de investirmos em coisas como testes de regressão visual e testes de unidade. Este erro em particular foi uma gota, entre centenas, que eventualmente quebrou as costas do camelo e me levou a investir muito em phpUnit e xDebug. Por sua vez, essas ferramentas me ensinaram a escrever código testável, o que provavelmente evitou mais bugs do que os próprios testes.

O tempo que dividi por zero dentro de um loop infinito

A solicitação do cliente era reformatar a assinatura do blog do WordPress para que a data fosse “XYZ atrás” em vez de “10 de novembro de 2011”. Eu não sabia exatamente como conseguir isso, mas sabia que era um formato de data que parecia estar crescendo em popularidade e, de fato, o Dr. Google me forneceu um trecho muito rapidamente. Funcionou no meu local! Tinha muita matemática, em particular, muita divisão . Eu não sabia exatamente por que funcionava — havia muitos loops aninhados, restos, arredondamentos e coisas do tipo. Mas estava no Google e parecia funcionar, e fiquei feliz o suficiente para implantá-lo em produção.

Cerca de 30 minutos depois, recebi um Skype hostil do nosso administrador de sistema. A produção caiu. Morto na agua. Ele me perguntou se eu estava dividindo por zero ultimamente e eu não tinha ideia do que ele poderia estar se referindo. Aqui está o que aconteceu.

Acredite ou não, o trecho ilegível “funcionou no meu local” que encontrei, dado um tamanho de amostra grande o suficiente, era capaz de algum comportamento aberrante. Fornecidos com algumas combinações infelizes de dias, horas e minutos, os loops de Rube Goldberg ocasionalmente tentavam dividir um número por zero. Lembre-se da matemática do ensino médio:

Na aritmética ordinária, a expressão não tem significado, pois não há número que, quando multiplicado por 0, dê a (assumindo a ≠ 0), e assim a divisão por zero é indefinida. - Wikipédia

Então, o que isso significa para os computadores? Normalmente, apenas uma mensagem de erro nos logs, mas no meu caso foi pior: o erro matemático estava interferindo na minha lógica de loop, fazendo com que meus loops aninhados fossem executados sem nunca serem concluídos - um loop infinito levando a uma tela branca da morte. E fica pior! Como cada iteração do loop estava escrevendo um erro para dividir por zero, o log de erros cresceu em proporções fantásticas e começou a prejudicar nosso sistema de arquivos. Isso teve o efeito de um ataque DDoS, embora absurdamente auto-infligido.

A coisa ruim sobre esse erro foi que ele derrubou um site de alto tráfego. O bom desse erro é que ele mudou drasticamente minha abordagem de trabalho. Mais do que tudo, eu estava envergonhado pela minha vontade de implementar sem entender. Jurei nunca mais colar um snippet sem fazer todos os esforços possíveis para entender cada linha, mesmo acompanhando o autor do snippet, se necessário.

Mais do que isso, prometi nunca mais enviar código que não fosse altamente legível para desenvolvedores iniciantes. Fiquei obcecado com os padrões de codificação do WordPress, extensões de editor de texto, comentários e docblocks inline, e até tabs versus espaços, aquele rito de passagem clássico! Em suma, decidi me importar mais com a facilidade de ler meu código do que com a facilidade de escrevê -lo. Essa rebelião contra colar sem entender me levou a ter um profundo interesse profissional no gerenciamento de dependências de terceiros, um tópico que alimentou várias oportunidades de escrever e falar para mim na década seguinte.

Ah, e a coisa realmente engraçada sobre esse erro? O núcleo do WordPress tem uma solução de uma linha para ele.

O momento em que deixei um projeto em espiral fora de controle até que todos estivessem cansados ​​disso

Eu tinha conseguido um projeto realmente fascinante. Eu seria o líder técnico e engenheiro de desenvolvimento do WordPress, e teria um desenvolvedor do Amazon AWS Lambda e um profundo especialista em JavaScript se reportando a mim. Esta foi a primeira vez que tive várias pessoas se reportando a mim, e foi de longe o projeto mais complexo em que já trabalhei. Até mesmo se referir a ele como um projeto do WordPress estava subestimando muito o assunto, mas o WordPress era a cola que mantinha tudo junto, então fazia sentido para mim atuar como líder de tecnologia.

Como meu papel principal era ser estritamente técnico, e também porque tenho afinidade com o minimalismo, nunca me ocorreu implementar algo como Jira ou Basecamp ou qualquer plataforma real para gerenciamento de tarefas. As coisas correram muito bem para a primeira iteração do projeto. Conseguimos trabalhar em nossos próprios componentes individuais, nos referir ao documento de especificações do cliente como nosso roteiro de produto e apenas enviar ping uns aos outros via Slack quando precisávamos juntar as coisas.

O problema começou quando começamos a mostrar o progresso ao cliente e implementar seu feedback. O que começou como uma equipe de três pessoas instantaneamente sentiu que havia sido levado a uma nova ordem de magnitude: não estava claro quem era responsável por qual feedback, qual era o status da implementação desse feedback ou mesmo quem estava falando com quem . Excedemos várias vezes o limite de 100 respostas por conversa do Gmail!

As coisas começaram a ficar desconfortáveis. Acho que o cliente sentiu como se tivesse perdido o controle da direção do projeto e, igualmente importante, sentiu como se tivesse perdido a visibilidade do status do projeto. Meu desenvolvedor da Amazon mencionou um dia: “Eu me pergunto se devemos usar o Trello”.

Hum , pensei. Uma equipe de três pessoas precisa de uma plataforma como essa? Novamente, minha tendência usual é preferir menos ferramentas, menos sobrecarga, menos complexidade. Mas o projeto já estava nos arrastando para a sujeira, então qual era o mal em tentar?

Eu vasculhei todos os nossos e-mails, todos os nossos documentos de especificações, todos os nossos tópicos de comentários díspares e mapeei todos eles nos quadros do Trello. Imediatamente, o projeto ressuscitou de sua tumba digital porque pudemos nos comunicar com muito menos sobrecarga mental. Em vez de procurar texto na minha caixa de entrada de e-mail ou um documento de especificação obsoleto, tínhamos quadros, listas e cartões adoráveis. Era fácil ver o status de qualquer recurso, incorporar feedback e distribuir novas tarefas. Parecia que tínhamos ficado cegos gradualmente, tão lentamente que não percebemos, e de repente pudemos ver novamente.

É verdade que o código não se escrevia sozinho, ainda era um projeto muito desafiador e ainda tínhamos que empregar cada grama de nossa habilidade técnica. Mas esse é o ponto: como finalmente tínhamos uma infraestrutura para entender o projeto, agora estávamos livres para aplicar nossa habilidade técnica.

Fico feliz em dizer que esse projeto foi concluído para a plena satisfação do cliente. Hoje em dia, considero o Trello ou o Jira um requisito de fato para equipes de dois ou mais.

Vá em frente e aprenda com os erros dos outros

Aqui está uma das coisas mais inteligentes que ouvi durante meu tempo nas forças armadas: “Tudo bem que os tenentes cometam erros de tenente e tudo bem os capitães cometerem erros de capitão. O que não está certo é que os capitães cometam erros de tenente, ou que os tenentes cometam erros particulares.”

Em outras palavras, não há problema em cometer os erros comuns que são óbvios para o seu atual nível de responsabilidade. O que é mais importante é como você cresce com eles.

Espero que nós, como desenvolvedores, aprendamos a ser compassivos com os outros quando eles cometem erros, como esperamos que outros tenham sido conosco. Espero permanecer curioso e responsável quando cometer erros, para continuar inovando além deles. Espero estar sempre cercado por uma comunidade inspiradora de especialistas em WordPress – pessoas cujos erros eu posso aprender e evitar cometer. E não menos importante, espero que outros possam aprender com minha experiência, como os erros do WordPress que compartilhei aqui.