Tendo trabalhado por mais de 10 anos como desenvolvedor web e muitos desses anos especificamente com o WordPress, eu vi (e escrevi) um código terrível … e acumulou uma série de peeves de estimação ao longo do caminho.
Então, hoje, eu pensei que seria interessante compartilhar e talvez uma discussão acontecesse sobre as coisas que, como comunidade de WordPress, não gostamos.
Então vamos contar as 13 coisas que mais me irritam, sem nenhuma ordem específica …
1. Inconsistência
Eu menti, há uma ordem particular, tipo de. Estou começando com o que mais me irrita, o resto realmente está em ordem aleatória, honesto!
A inconsistência é o pior inimigo que você pode ter como programador, quando você trabalha com sistemas e estruturas de dados.
Você perdeu todos os prefixos de sua função? Você salvou um meta valor 1000 vezes com uma chave incorreta? Absolutamente nenhum problema, basta pesquisar e substituir. Você às vezes confuso o prefixo, mas às vezes se lembra da correta? Você pode precisar passar por todo o código, linha a linha.
Algo feito de forma incorreta, mas consistentemente incorretamente, é muitomelhor do que algo feito na maioria das vezes.
Não se esqueça de aplicar esta regra quando você está estendendo o trabalho de outra pessoa. Se eles usaram o caso de camelo – o que você odeia – pode valer a pena sugá-lo e se conformar, porque isso é o que outros desenvolvedores esperam.
2. Produtos inchados
Eu realmente não gosto do fato de que alguns temas “multiusos” vêm como um download de 100MB +, mesmo que os arquivos reais que executem o tema estão em alguns megabytes. Não há como um tema de Jack of All Trading seja melhor do que um tema de nicho bem feito.
Eu entendo que a força motriz por trás disso é a demanda, e é por isso que é tão difícil mudar as coisas. Está tudo bem e bom para suportar temas inchados, mas eles têm um potencial de ganhos muito maior, então, naturalmente, os negócios os farão.
Estou esperando que, assim como o tema Pickle de Jason Schuller, muitos autores irão acompanhar temas focados que adicionem mais a um site do que apenas uma barragem de doces para o olho que acaba por ser inútil quando você olha as estatísticas.
3. Hordas de arquivos CSS e JavaScript
Este é um dos meus maiores peeves para animais de estimação, especialmente se você é um criador de tema, e ainda mais, se você fizer temas premium com controles deslizantes e todos os outros lixo que parece ser a norma agora. Você simplesmente não pode permitir que 45 arquivos JavaScript e 18 CSS sejam carregados para cada solicitação, é simplesmente errado!
O contra-argumento geralmente é que isso torna mais fácil para os desenvolvedores fazer alterações. Existe, é claro, uma solução para tudo: use Sass / Less e crie ferramentas como o Gulp. Crie um diretório de desenvolvedor que contenha todos os arquivos Sass e JS crus e use um Gulp ou Grunt para colocar tudo em um conjunto de arquivos. Como as informações sobre o processo de compilação estão contidas no projeto, qualquer pessoa pode assumir o controle a qualquer momento.
4. Pais para pais não preparados
Se você está lançando seu tema para o mundo, é provável que alguém em algum lugar queira modificar seu trabalho. Sempre que isso acontece, nós gritamos um assassinato sangrento se um tema infantil não é usado, então devemos fazer algum esforço para apoiá-los em nosso trabalho, especialmente no arquivo functions.php.
Se você estiver criando uma função que atue como uma etiqueta de modelo, envie uma function_exists()chamada para garantir que os temas filho possam substituí-la adequadamente. As funções do tema infantil são carregadas primeiro, então, se eles tentam redefinir o nosso trabalho, o PHP cuspirá um erro “não pode definir uma função duas vezes”.
5. Documentação incompleta
Para ser honesto, estou mais marcado quando leio documentação incompleta do que estou quando falta completamente. Quero dizer, por que 80% do trabalho e não ultrapassar os 20% restantes?
Se você decidir compartilhar seu projeto com outros, faça o documento! Especialmente se é um código que deve ser reutilizado, substituído ou modificado de outra forma – isso acontece o tempo todo com temas e plugins.
Se você quiser seguir o caminho, eu recomendo a documentação separada para desenvolvedores e usuários finais. Os usuários finais só precisam trabalhar com a UI, enquanto os desenvolvedores precisam encontrar coisas no código, conhecer versões de vários componentes e todo tipo de outras informações.
6. Vai ao ar com prefixo
Eu sei que você tem que prefixar suas funções, mas não use 23duasn123uehd_como prefixo. Eu entendo que isso tem 0 chances de colidir, mas, certamente, se você estiver desenvolvendo um plugin de lista de endereços, você poderia prefixar suas funções awesome_mailing_.
Se você realmente deseja separar suas funções, esqueça o prefixo completamente e use classes e objetos para encapsulá-los – problema resolvido.
7. Não encaixando adequadamente
Deve ser um dado que, se você precisar de algum CSS ou JavaScript, você enfim, então eu nem vou falar sobre isso. Além disso, tome cuidado para enqueuar ativos somente quando eles são necessários. Você realmente precisa carregar os estilos e scripts para controles deslizantes em todas aspáginas? Claro que não, apenas carregá-los quando um controle deslizante é realmente exibido.
Além disso, tente usar HTTPS sempre que possível, ou melhor ainda, use //sourceoffile.com/file.js. Apenas deixe o protocolo e seu navegador descobrirá por você. Impressionante!
8. Desenvolvimento Web errôneo
Isso pode aparecer como um pouco crasso, mas se você comprar um tema, ajustar e ajustar as configurações, ensinar um cliente a como usá-lo e encerrar um projeto, não se chame de desenvolvedor web.
Antes de começar a lançar pedras para mim, não há absolutamente nada de errado ao fazer isso para os clientes, é a quantidade de desenvolvedores, eu incluído, que começaram. No entanto, chamá-lo de desenvolvimento web está esticando um pouco longe.
9. Cotações difíceis que não devem ser codificadas
Muitas coisas se enquadram nesta categoria. Um exemplo proeminente é o uso do wp_prefixo do banco de dados em consultas . O prefixo do banco de dados pode ser alterado em uma instalação, então você deve usar a propriedade $wpdb->tablenameem vez disso.
Você nunca deve fazer o plugin de código rígido e locais de temas, pois estes também podem ser alterados. Sempre que quiser codificar um caminho, procure apenas o “caminho do WordPress X” e substitua o X pelo caminho que você procura. Se a localização for variável, você encontrará uma função para chegar a ela sem hardcoding.
10. Temas prontos para não-tradução
Eu tive a sorte de crescer com o inglês desde que eu tinha dois anos de idade, então, em grande parte do mundo, eu sou compreendido facilmente, e o software está escrito em uma linguagem que eu entendo muito bem.
Você já viajou para o exterior e desejou que você pudesse ler alguma coisa? Imagine esse sentimento o tempo todo na web, o lugar onde você busca informações e sente confusão e incerteza.
As traduções estão se tornando uma grande parte da comunidade do WordPress e, uma vez que não faz quase nenhum esforço para que isso aconteça em seus produtos, você realmente não tem uma desculpa para não implementá-lo. Você estará usando todas as duas funções e o papel __()e _e()o texto não são tão difíceis. Mesmo.
11. Narrow Mindedness
Este é realmente o meu maior aborrecimento de todos em geral, não apenas no mundo do desenvolvimento. Com os desenvolvedores, você vê isso muitas vezes quando fala sobre Joomla / Drupal / WordPress, ou mesmo mais, se você conversar com desenvolvedores Java sobre o WordPress.
Muitos deles desprezam os desenvolvedores do WordPress, uma vez que o WordPress não é um sistema perfeito; Não é o epítome do código moderno, com certeza. Esses desenvolvedores estão simplesmente perdendo o ponto. WordPress é uma ferramenta que se encaixa muito bem em uma determinada tarefa. Não cabe todas as tarefas, nem se destina.
Muitas vezes, as pessoas não conseguem levar em consideração que existem outras considerações do que seu próprio ponto de vista e podem haver mais importantes nisso. Um bom exemplo é o desenvolvedor que deseja reescrever o WordPress para torná-lo todo agradável e orientado a objetos. Claro, como desenvolvedor, ficaria extremamente feliz com isso, mas estaríamos quebrando a compatibilidade com versões anteriores. Nós causariamos problemas para literalmente milhões de pessoas em benefício de um par de mil desenvolvedores teimosos.
Como regra geral, se alguém tiver opiniões extremamente fortes e agressivas sobre alguma coisa, eu as descarto imediatamente porque não posso ver todos os pontos de vista. Há, claro, exceções, mas foi um bom indicador para mim.
12. #wpdrama
Mesmo? Não temos coisas melhores a fazer? Para ser sincero, nunca li mais do que dois comentários em qualquer situação de #wpdrama, porque simplesmente não me importo. Obviamente, eu me importo com o problema por trás do drama, mas, no número três do comentário, é um livre para todos que não é realmente sobre o problema em questão, mas sobre quem é prejudicado, quem não é, quem tem mais experiência, quem É um desenvolvedor mais profissional … blah, blah, blah. Bocejão, tenho coisas melhores a fazer.
Dito isto, adoro debates intensos. As diferentes opiniões são saudáveis e oferecem diferentes pontos de vista, especialmente porque isso muitas vezes gera muitos recursos excelentes do WordPress. Drama, por outro lado, diminui a produtividade em todo o quadro. Bruto.
Bônus: E-mails grosseiros / estranhos
Isso não está relacionado ao desenvolvimento, mas eu tenho três tipos específicos de e-mails que eu realmente não gosto ou, pelo menos, acho engraçado. Caminho no topo da lista é o tipo de pessoa que leu que mencionar o nome de alguém em uma conversa várias vezes mostra interesse, maior conexão e simpatia. Não, isso torna tudo super-estranho.
Esse mesmo tipo de pessoa geralmente também me chama de “Dan”. Além dessa frase, agora eu nunca escrevi meu nome assim. Se você ver o nome de alguém em um site, use seu nome completo; Se eles tendem a usar uma versão mais curta eu aposto que eles assinarão sua resposta inicial com ele. Além disso, basta usar um nome uma vez, talvez duas vezes, caso contrário, é assustador. Ou é só isso eu?
O tipo número dois é o e-mail super curto que literalmente vai: “Quero aprender o WordPress e precisar da sua ajuda nesse sentido. Agradecendo … “(esse foi um e-mail real que recebi).
Há também o número três, a variante super-longa de pedir ajuda, que na verdade não tem uma pergunta no final. O remetente continua sobre o que ele está fazendo e quais os problemas que ele está tendo e depois apenas assina seu nome.
Então, o que é o seu animal de estimação Peeve?
Algum de meus aborrecimentos atingiu um nervo com você? Certamente você tem um (ou alguns) de seus próprios peeves para animais de estimação.
Deixe-nos saber sobre as coisas que mais o aborrecem sobre trabalhar como desenvolvedor do WordPress e, se você já recebeu algum e-mail grosseiro / estranho, compartilhe esses também!
