Boas práticas de desenvolvimento PHP

Quando estamos desenvolvendo nosso código PHP, ninguém nos define regras de como desenvolver. Podemos fazer como quisermos e é bom que a gente tenha essa liberdade.

Mas, na medida que nosso sistema cresce e começamos a implementá-lo em varios lugares, surge, inevitavelmente, a necessidade de seguir algum padrão para que quem vá implementar ou dar manutenção consiga entender o que está acontecendo.

Ao desenvolver um método para validar os dados de um usuário, nada nos impede de escrever algo como:

class Validator{
    public function validaUSUARIO($usuario){
        if($nomeValido == FALSE && $emailValido == FALSE && self::validaNome( $usuario->getNome()) && self::validaEmail($usuario->getEmail())
    && self::validaSenha ($usuario->getSenha())){
    return true;}
        else{
            return false;}}}

Perfeito, nosso método funciona. Mas, como funciona esse método? Quais validações ele faz? Onde começa o if e onde termina? Se alguém fosse, futuramente, dar manutenção nesse método, seria extremamente difícil!

É por isso que surgiram as PSRs (PHP Standard Recommendations). Para que haja maior interoperabilidade entre os desenvolvedores e projetos.

Uma das PSRs é a PSR 2, ou Guia de estilo de codificação (Coding Style Guide), que aborda como deve ser feita a formatação do nosso código para facilitar a leitura por outros desenvolvedores. Algumas das indicações desse guia são:

• Devemos usar 4 espaços para identação, não tabs.
• Não devemos fixar um numero de caracteres por linha, mas é bom que uma linha tenha menos de 80 caracteres.
• A abertura de colchetes de classes e métodos devem vir na proxima linha.
• A abertura de colchetes de estruturas de controle devem vir na mesma linha com um espaço em branco.

Se seguirmos a PSR 2 com nosso método, teriamos:

class Validator
{
    public function validaUsuario($usuario)
    {
        if (self::validaNome($usuario->getNome())
            && self::validaEmail($usuario->getEmail())
            && self::validaSenha($usuario->getSenha())) {
                return true;
        } else {
            return false;
        }
    }
}

Nosso código está muito mais legível! Conseguimos entender perfeitamente que a validação do usuario depende de 3 outros métodos validaNome, validaEmail e validaSenha e retorna um boolean. Ou seja, com PSRs conseguimos nos comunicar de forma transparente como desenvolvedores.

Mas, PSRs não servem apenas para identação de código. Quando trabalhamos com frameworks MVC é muito comum precisarmos importar arquivos. Algo como:

include_once "arquivo.php";

Porém conforme o sistema cresce, precisamos importar mais arquivos:

include_once "Namespace/SubNamespace/arquivo.php"; 
include_once "Namespace/SubNamespace/arquivo2.php"; 
include_once "Namespace/SubNamespace/arquivo3.php"; 
include_once "Namespace/SubNamespace/arquivo4.php";

E a quantidade de includes tende a crescer. Esse é um dos motivos pelo qual utilizamos a funcionalidade de autoload! Existem diversas formas de se realizar autoload em php, uma delas é a PSR-4 que define uma forma padronizada de escrever nossos namespace para que possamos importar nossos arquivos da mesma forma em nossos sistemas, aumentando, também, a interoperabilidade entre projetos! Para isso, declaramos nossos namepsace com a estrutura:

namespace Namespace SubNamespace;

Agora para importar nossos arquivos, a partir da versão 7 do PHP, basta utilizarmos o agrupamento do use:

use Namespace SubNamespace {
    arquivo1,arquivo2,arquivo3,arquivo4
};

Alguns frameworks MVC estão implementando este padrão para realizar o autoload. Um exemplo é o Laravel, a partir da versão 5.

Atualmente existem 14 PSRs criadas pela PHP-FIG (Framework Interoperability Group) sendo que sete estão em desenvolvimento e cinco já foram aceitas. As PSRs aceitas, além da Coding Style Guide, são:

• Basic Coding Standard (Padrão de código básico) – Aborda o que devemos considerar para garantir um código de alta interoperabilidade técnica com PHP.
• Logger Interface (Interface de Logger) – Descreve uma interface comum para bibliotecas de Log.
• Autoloading Standard (Padrão de auto-carregamento) – Descreve uma especificação para auto-carregamento de classes pelo diretório do arquivo. Também diz onde colocar arquivos que serão auto-carregados de acordo com a especificação.
• Caching Interface (Interface de Cache) – Descreve uma interace padrão para desenvolver sistemas de Cache.
• HTTP Message Interface (Interface de Mensagem HTTP) – Descreve uma interface padrão para desenvolvimento de mensagens HTTP .

Uma definição mais aprofundada de cada PSR, além das PSRs em desenvolvimento, está disponível no site da php-fig

Com PSRs evitamos a necessidade de nos preocupar com certas peculiaridades de cada sistema! Se um sistema segue uma PSR, ou todas, já saberemos como manipulá-lo da forma correta.

E a mesma coisa serve para os sistemas que nós desenvolvemos. Se seguirmos as PSRs, quem for implementar saberá exatamente como fazê-lo da forma correta, reservando a documentação para coisas mais específicas do sistema.

Claro que ninguém é obrigado a seguir as PSRs, ou qualquer outra especificação, ao desenvolver em PHP. É uma escolha livre do desenvolvedor, mas é necessário que, pelo menos, conheçamos bem. Afinal, a tendência é que cada vez mais projetos/frameworks sigam e, por consequência, o mercado também.

Aqui na Alura temos uma formação PHP onde vemos boas práticas, além de conhecer os frameworks mais utilizados no mercado.