Artigos de Tecnologia e Negócios

Boas práticas de desenvolvimento PHP

andre.chaves
andre.chaves

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:

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 "Namepsace/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:

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.

Artigos de Tecnologia e Negócios