Codificando padronizadamente em PHP com PSR

Padronização PHP com PSR

Com esta postagem estou iniciando uma série de explanações sobre como codificar seguindo os padrões de codificação em PHP. Sim, isto existe! Quando aprendemos a programar, geralmente não nos preocupamos com questões como esta. Tendemos a pensar que o simples fato do código rodar já é suficiente. Mas pense que uma vez o sistema rodando não quer dizer que você e somente você dará suporte no sistema. É comum sair de empresa ou por algum motivo não poder mais dar suporte para seu cliente, e neste contexto o próximo programador olha para seu sistema lindo que você demorou meses para fazer, usou os melhores algoritmos possíveis e passou dias em claro e diz a inevitável frase “prefiro fazer do zero”.

Motivos para fazer tudo do zero

Se o sistema está todo ali e funcionando perfeitamente, por que decidimos perder todo o know-how ali construído para reiniciar todo um processo doloroso que é fazer um sistema? Por que não aproveitar o que já foi criado e apenas adaptar às necessidades que forem surgindo? Geralmente estas perguntas levam às mesmas respostas: (1) o novo programador não conhece a linguagem do sistema; se o programador conhece a linguagem então (2) o novo programador não programa na mesma framework em que o sistema se encontra; e se tanto a linguagem quanto a framework são conhecidas, então (3) o novo programador não está contente ou não compreende com precisão a codificação.

Desconhecimento da Linguagem

No cenário em que o programador não conhece a linguagem do sistema é compreensível querer refazer tudo, mas não justificável. Em grandes sistemas pode não ser viável trocar toda a gama de tecnologias utilizadas só porque o novo programador (ou equipe de desenvolvimento) não lida com aquelas já existes. Então este é um ponto crítico a se considerar.

Diversidade de Frameworks

Além do mais, a quantidade (absurda) de frameworks no mercado, e muitas delas para o mesmo propósito, possuem seus próprios jeito de se “fazer acontecer”. São formas variadas de configuração e codificação, preparação de classes. O leque de possibilidades dentro de uma única framework é tão grande que se especializar e conhecer suas nuances pode levar anos, tal como acontece com Zend e Symphony. Para termos uma ideia do problema, foquemos no mapeamento objeto-relacional.  Algumas frameworks não possuem o recurso, mas as que possuem devem ser configuradas para tal fim. Isto pode acontecer em arquivos de texto separados, xml, json ou php. A geração do código pode acontecer através de linha de comando ou automaticamente ao utilizar a classe. Os comandos variam de uma framework para outra, assim como os recursos internos como validação e relacionamento com outras classes. Falar sobre diferenças entre ORM de diferentes frameworks renderia um outro ótimo artigo. Qualquer framework demanda tempo para ser compreendida e cliente algum aguarda esse tempo, por isso o comportamento mais óbvio nesses casos é querer recomeçar.

Exclusividade cognitiva

Programar é uma arte e há multiformes meios de se programar devido a originalidade e criatividade inerente a cada ser lógico. Para se executar um mesmo procedimento as pessoas tomam rumos diferentes, pelos quais acreditam veemente seres os melhores possíveis para se atingir o objetivo pretendido. Na informática isto acontece naturalmente, pois cada um tem seu jeito de codificar, e isto é nato e inalienável, tal como um artista cria um quadro, música ou romance. Portanto é óbvio que ao se deparar com classes feitas por outras pessoas você diga que daquela outra forma seria melhor de resolver o problema. E pode até ser mesmo, mas aquela foi a forma encontrada por outro indivíduo para resolver o mesmo problema. Rejeitar a manifestação da expressão lógica de um colega programador são como dois artista que pintam o mesmo objeto, um sobre o olhar impressionista e o outro abstrato, e depois ficam a digladiar para ver quem é o melhor; e neste caso não há, pois, apesar de observarem o mesmo objeto, cada um se manifestou segundo sua própria crença e experiências. O programar não é diferente. Mesmo seguindo padrões estabelecidos, codificar ainda é uma arte, por isso a expressão individual do ser que mostra as características individuais do programador. Quem sabe um dia alguém se aprofunde mais sobre isto e consiga montar um perfil psicológico de programadores só de observar seu código (fica a dica para os pesquisadores).

Como continuar projetos de sistema de onde pararam

Muitas pessoas tendem a não seguir padrões. São padronizados demais. Geralmente os programadores tendem a criar seus próprios jeitos de programar (como o Naruto tem seu próprio jeito ninja) a fim de tornar os códigos mais originais e orientados à sua forma de pensar. Isso é bom até certo ponto. Já participei de diversos projetos de desenvolvimento de sistema e convivi com programadores que também defendem a padronização. Se existe um problema em seguir o próprio nariz é manter sempre o mesmo rumo: em um projeto forma-se o padrão e o segue, mas no próximo altera uma coisa ou outra, e no próximo mais uma e por aí vai. Isso acontece porque mudamos continuamente e as tendências adquiridas entre um sistema e outro acabam ficando impressos no código.

É por isso que, para se evitar a perda de um sistema por troca ou adição de framework e as diferenças na lógica empregada por diferentes programadores sobre o projeto, existem os padrões de codificação. Seguir padrões não significa que o programador vai deixar de imprimir sua marca, mas vai garantir que no futuro qualquer uma possa ser capaz de somar com os esforços realizados, ou seja, novas necessidades poderão ser sanadas num sistema que já está funcionando. É como um idioma, o qual define alfabeto e regras sobre como utilizar este alfabeto, entretanto a ideia expressa com o idioma continua sendo único, porém utilizando um padrão comum a todos. Olhando por este prisma, participar de comunidades ficará mais fácil com todos falando a mesma língua e promover a reutilização de código pregada pela Orientação a Objetos que não vimos se concretizar até agora (por falta de padronização), a capacidade de integração entre sistemas diferentes e melhor manutenibilidade de código.

Padronização PSR

A codificação padronizada em PHP advém do Framework Interoperability Group, um consórcio que reúne as principais frameworks PHP do mercado onde são discutidas questões pertinentes. As diretrizes formuladas pelo grupo são apresentadas na forma de PSR, PHP Standards Recommendation, que são mais recomendações do que regras. Ali estão descritas convenções de nomenclatura de classes e namespaces, estilo de código-fonte (como espaços na indentação e mesmo a quantidade máxima de caracteres por linha), forma de criar log do sistema e como carregar os arquivos fonte. A elaboração dessas regras não são feitas de qualquer jeito, todas estão de acordo com as normas estabelecidas por RFC (2119) pra você sentir que o negócio é sério!

Proposta da série #trueprogrammerPHP

O objetivo aqui é estudar a fundo cada uma das recomendações PSR na prática. Ao todo são quatro grupos de recomendações que serão abordados detalhadamente:

  • PSR-0 – Autoloader (obsoleto, substituído pela PSR-4, portanto não será abordado)
  • PSR-1 – Basic Coding Standard: indica qual deve ser a codificação dos arquivos, organização lógica dos arquivos e convenção de nomes para namespaces, classes, constantes, propriedades e métodos
  • PSR-2 – Coding Style Guide: espaçamento em algumas palavras reservadas, tamanho e tipo dos espaçamentos em indentações, quantidade máxima de caracteres por linha, apresentação de variáveis, propriedades e métodos e das estruturas de seleção, controle e iteração
  • PSR-3 – Logger Interface: mostra a implementação e utilização de classes interface padronizadas para fins de log do sistema nos oito níveis descritos no RFC 5424
  • PSR-4 – Autoloader: descreve uma especificação para carregar automaticamente arquivos classes dentro da pasta do projeto (sem a necessidade de require ou include) ao nomear corretamente o namespace do arquivo e colocar em local apropriado em disco

Considerações finais

Acompanhem o blog para atualizações sobre este projeto. Se você gostou curta, e se você tem amigos que também são programadores, compartilhe nas redes sociais! Qualquer dúvida, entre em contato ou comente aí logo abaixo. Ficarei honrado em responder sua pergunta!

Deixe seu comentário