Eu já compartilhei algumas das próximas funcionalidades do PHP 7, neste artigo eu pensei em dar uma olhada em alguns dos padrões ruins que devemos parar de usar quando mudarmos para o rápido e relâmpago PHP 7. E não se esqueça de conferir nosso novo mega-benchmark da versão final do PHP 7.2.
Melhores práticas do PHP 7 AKA O que não se deve fazer no PHP 7
- Não usar mysql_ Functions
- Não Escrever Código Desperdiçador
- Não Usar PHP Fechar Tags
- Não Passar por Referência se Não For Necessário
- Não Realizar Consultas em Circuito
- Não Usar * em Consultas SQL
- Não Confie na Entrada do Usuário
- Não tente ser esperto
- Não Reinvente a Roda
- Não negligencie outros idiomas
1. Não usar mysql_ Functions
Finalmente chegou o momento em que você não será apenas aconselhado a parar de usar as funções mysql_. O PHP 7 irá removê-los completamente do núcleo, o que significa que você precisará mudar para as funções muito melhores do mysqli_, ou para a implementação ainda mais flexível da DOP.
2. Não Escrever Código Desperdiçador
Este pode não ser um bom treino, mas vai tornar-se cada vez mais importante porque a velocidade aumenta no PHP 7 pode esconder alguns dos seus problemas. Não fique satisfeito com a velocidade do seu site simplesmente porque a mudança para o PHP 7 tornou-o mais rápido.
Para entender como a velocidade é importante e o que você pode fazer para melhorar as coisas, dê uma olhada no nosso guia para iniciantes no artigo sobre otimização de velocidade.
Como desenvolvedores você deve sempre se certificar de carregar os scripts apenas quando eles são necessários, concatená-los quando possível, escrever consultas eficientes de banco de dados, usar cache quando possível e assim por diante.
Para um impulso rápido e fácil para sua otimização geral, considere também a possibilidade de extrair seu código. Kinsta construiu um recurso de minificação de código diretamente no painel do MyKinsta, permitindo aos clientes ativar a minificação automática de CSS e JavaScript com um simples clique.
3. Não Use Etiquetas de Fecho PHP no Final de um Arquivo
Se você der uma olhada, a maioria dos arquivos principais do WordPress omite a tag PHP final quando um arquivo termina com um código PHP. Na verdade, o Zend Framework proíbe-o especificamente. Não é exigido pelo PHP e ao omiti-lo no final de um arquivo você está se certificando de que nenhum espaço em branco pode ser adicionado.
4. Não Passar por Referência se Não For Necessário
Eu pessoalmente não gosto de passar por referência. Eu entendo que em alguns casos é útil, mas em muitos outros torna o código mais difícil de entender e seguir e especialmente difícil de prever o resultado.
Aparentemente, as pessoas pensam que isso torna o seu código mais rápido, embora, de acordo com programadores respeitáveis de PHP, não seja verdade.
Um exemplo de porque as referências são ruins é o PHP construído em shuffle() ou sort(). Em vez de devolver uma matriz embaralhada ou ordenada, eles modificam o original, o que é completamente ilógico para a minha mente.
5. Não Realizar Consultas em Ciclo
Realizar consultas a bases de dados em loop é um desperdício. Isto coloca uma tensão desnecessária nos seus sistemas e é provável que consiga obter o mesmo resultado mais rapidamente fora do laço. Quando me deparo com uma situação em que isso seria necessário, normalmente posso resolver o problema com duas consultas separadas que utilizo para construir uma matriz de dados. Depois passo por cima da matriz, sem necessidade de realizar consultas no processo.
Devido à forma como o WordPress funciona, pode haver algumas exceções a isso. Enquanto get_post_meta() irá pegar um meta valor do banco de dados, você pode usá-lo em um loop se você estiver fazendo loop através de um metadados específico de um post. Isto porque quando você o usa pela primeira vez, o WordPress realmente recupera todos os metadados e os armazena em cache. As chamadas subsequentes utilizam os dados em cache, não as chamadas à base de dados.
A melhor maneira de resolver essas coisas é ler a documentação da função e usar algo como o Query Monitor.
6. Não Usar * em Consultas SQL
Tudo bem, este é mais um problema do MySQL, mas nós tendemos a escrever o nosso código SQL em PHP, então eu digo que é um jogo justo. Em qualquer caso, não utilize wildcards nas consultas SQL se puder evitá-los, especialmente se tiver uma base de dados com muitas colunas.
Especifique as colunas exatas que você precisa e só as recupere. Isto ajuda a minimizar a utilização dos seus recursos, proteger os seus dados e tornar as coisas o mais claras possível.
Enquanto estiver a falar de SQL, conheça as suas funções disponíveis e teste a velocidade o mais possível. Ao calcular médias, somas ou números semelhantes, utilize funções SQL em vez de funções PHP. Se você não tem certeza da velocidade de uma consulta teste-a e tente algumas outras variações – use a melhor delas.
7. Não Confie na Entrada do Usuário
Não é prudente confiar no input do utilizador. Filtrar sempre, higienizar, escapar, verificar e usar fallbacks. Há três problemas com os dados dos usuários: nós, desenvolvedores, não levamos em conta todas as possibilidades, é freqüentemente incorreto e pode ser intencionalmente malicioso.
Um sistema bem pensado pode proteger contra tudo isto. Certifique-se de usar funções embutidas como filter_var() para verificar os valores apropriados e escapar e outras funções quando trabalhar com bancos de dados.
O WordPress tem um monte de funções para ajudar você. Dê uma olhada no artigo Validação, fuga e sanitização de dados do usuário para obter mais informações.
8. Não Tente ser Esperto
Seu objetivo deve ser escrever um código elegante que expresse suas intenções da forma mais clara possível. Você pode ser capaz de raspar mais 0,01 segundo em cada carregamento de página, encurtando tudo para variáveis de uma letra, usando lógica ternária de vários níveis e outras espertezas, mas isso realmente não é nada comparado com as dores de cabeça que você estará causando a si mesmo e a todos os outros ao seu redor.
Nomeie suas variáveis apropriadamente, documente seu código, escolha clareza em vez de brevidade. Melhor ainda, use código padronizado orientado a objetos que mais ou menos documente a si mesmo sem a necessidade de muitos comentários em linha.
9. Não Reinvente a Roda
O PHP já existe há muito tempo, os sites foram feitos há ainda mais tempo. As chances são que o que quer que você precise fazer, alguém já fez antes. Não tenha medo de se apoiar nos outros, Github é seu amigo, Composer é seu amigo, Packagist é seu amigo.
De loggers a ferramentas de manipulação de cores, de profilers a frameworks de teste de unidades, de APIs Mailchimp a Bootstrap do Twitter, tudo está disponível com o apertar de um botão (ou digitação de um comando), use-os!
10. Não negligencie outros idiomas
Se você é uma pessoa com PHP, agora é prática padrão saber pelo menos HTML, CSS, Javascript e MySQL. Quando você tiver um bom domínio destas línguas, é hora de aprender Javascript novamente. Javascript não é jQuery. Você deve aprender Javascript corretamente para ser capaz de utilizá-lo eficientemente.
Eu também recomendaria aprender tudo sobre PHP orientado a objetos, ele é um salva-vidas e tornará seu código melhor por ordens de magnitude. Também abrirá portas para linguagens como C# e Java, elas serão muito mais fáceis de entender com o OOP sob o seu cinto.
Amplie seus conhecimentos aprendendo sobre gerentes de pacotes, scripts de construção, Coffeescript, LESS, SASS, YAML, motores de templates e outras ferramentas incríveis. Eu recomendaria vivamente que olhássemos para outras PHP estruturas, Laravel em particular.
Quando você está se saindo muito bem com isso, que tal Ruby, Ruby on Rails, desenvolvimento de aplicativos para Android, iPhone, Windows Phone? Você pensaria que não vale a pena porque estes caem fora da sua zona de conforto e necessidades de trabalho, mas essa é apenas a questão. Cada língua tem algo útil para ensinar e um pouco de conhecimento extra nunca dói. Não é por acaso que todos os principais desenvolvedores de PHP sabem muito sobre outras linguagens de programação!
Hi, my name is Daniel, I'm the CTO here at Kinsta. You may know me from Smashing Magazine, WPMU Dev, Tuts+ and other WordPress/Development magazines. Aside from WordPress and PHP I spend most of my time around Node, React, GraphQL and other technologies in the Javascript space.
When not working on making the best hosting solution in the Universe I collect board games, play table football in the office, travel or play guitar and sing in a pretty bad band.
Deixe um comentário