PHPzeiro? Adote um Framework! :)

É notável a quantidade de aplicações em PHP que ainda utilizam nosso velho e conhecido modo Macarrônico de programar: dezenas de snippets e blocos de código que trabalham com regras de negócio, apresentação e tudo mais espalhados por N lugares na aplicação.

O PHP Macarrônico é assim

O PHP Macarrônico é assim

Esse método é justificável dentro da PHP até certo ponto: a própria linguagem tem por princípio a simplicidade e velocidade na codificação e resolução de problemas. O próprio Rasmus Lerdorf, criador do PHP, já se mostrou bem contrário aos frameworks atuais pois eles são lentos e não escaláveis, culpa do feeling de  “faz-tudo” que a maioria delas leva no sentido de continuar ostentando a bandeira de “desenvolvimento rápido” da PHP, que muita gente confunde com gambiarras e que transformou a PHP em sinônimo de POG (Programação Orientada à Gambiarras).

Por muito tempo eu, como muitos desenvolvedores/empresas que conheço e já conversei, pensava assim:

Porque vou abandonar toda aquela minha infra-estrutura pronta de gerenciamento de conteúdo e minhas bibliotecas caseiras que funcionam muito bem para adotar uma framework MVC e perder $$tempo$$ precioso ou impactar no $$prazo$$ que dei para o meu cliente. Não tem porque eu correr esse ri$co“.

Existem duas situações muito especiais que consigo identificar na hora de desenvolver uma aplicação e que impactam de forma crítica na decisão correta da arquitetura a ser seguida: necessidade de escalar a aplicação e potencial expansão de funcionalidades durante e depois do projeto.

Quantas aplicações de alta consumo de banda você já desenvolveu em sua empresa com PHP ? E dessas, quantas você realmente tem que dar uma atenção e implementação contínua de funcionalidades novas ? Se você não contou nenhuma, o seu caso é bem comparável ao de muitos desenvolvedores PHP por aí. Se você contou alguma e não teve dores de cabeça com a manutenção ou testes em sua aplicação, você é um cara de sorte.

O feijão com arroz do desenvolvimento PHP no Brasil é muito atrelado à gerenciadores de conteúdo, front-end de websites e muitos projetos que geralmente são desenvolvidos por times por vezes multi-disciplinares. Um ecossistema comum são agências digitais, bureau de mídias digitais e várias outras que precisam desenvolver da forma mais simples e eficaz possível, muitas vezes devido até ao orçamento apertado e a menor margem de chance de que as coisas deêm errado para não ferrar um cronograma geralmente apertado e sem vez para os mais lentos. Juntamos isso à realidade dessas empresas que nem sempre tem um desenvolvedor com uma boa experiência, sem background de programação ou “migrados” de outras áreas e a lenha está feita.

Mesmo em ambientes mais profissionais, ainda existem aqueles que ainda resistem à idéia e são os “super-homens” que desenvolvem coisas que só eles conhecem e são difíceis de disseminar conhecimento válido na equipe.

Dentro desse contexto, algumas situações abaixo concerteza já rolaram com você ou na empresa em que você trabalha:

  • Designers sobrescrevendo páginas com lógica de negócio embutida
  • Programadores detonando CSS dos outros
  • Classes das regras de negócio sendo alteradas a torto e direito ferrando algo que ja estava funcionando
  • Métodos espalhados pela aplicação com nomes bizarros e/ou funcionalidades redundantes ou no mínimo estranhas
  • Lógica de negócio repetidas, implementadas de formas diferentes e sem um lugar comum
  • Registros no banco de dados com dados incompletos e inconsistentes
  • Formulários que não validam tudo o que deveriam validar e que deixam cadastrar assim mesmo
  • e por ai vai …. :P

Puxadin ali, patchzin aqui e geralmente temos monstros burocráticos ou incontroláveis que temos que lidar com o passar do tempo: fruto de uma arquitetura por vezes equivocada mas que por N motivos não pode ser substituída. E aí José ?

Adote um framework!

A solução mais sustentável para esse tipo de situação seja provavelmente a adoção de um framework, mas existe uma resistência muito grande que é completamente justificável: voltamos àquelas perguntas relativas à “para que mexer num time que está ganhando?“.

A resposta é:  “Você pode ganhar muito mais a curto prazo e com mais qualidade de vida”.

Algumas perguntas e afirmações que já ouvi (e eu mesmo me fiz) antes de tudo:

  • Meus programadores (ou eu) tem nível técnico para trabalhar com isso?
  • E tudo o que eu tenho? O que eu faço que isso ?
  • Isso vai atrasar o projeto cara!
  • MVC ? ORM? Que p*rra é essa ?
  • As funções dos meus includes já fazem tudo isso e muito melhor!
  • Bah! Já temos nosso ADM pronto: é só copiar, colar e alterar os campos. ;)
  • O cliente disse que quer apenas produtos e não vai precisar de nada mais.

Todo esse tipo de pensamento/sentimento as vezes não vem de comodismo ou preguiça, mas da falta de conhecimento ou estudo de como uma framework pode ajudar no trabalho, até onde ela pode ir e principalmente em equipe multi-disciplinares com prazos ultra-curtos.

Então, vão algumas observações/pontos de vista em relação às principais frameworks PHP do mercado que podem resumir de certa forma alguns pontos positivos e relevantes para a adoção de uma framework:

  • Elas já estão bem difundidas, com boa documentação e geralmente tem uma curva de aprendizado mínima: com um mês um programador iniciante estará fazendo cadastros simples e bacanas;
  • Por serem frameworks de conhecimento público, a disseminação do conhecimento e uso é muito maior e não fica atrelado à uma ou duas pessoas;
  • Você não tem apenas uma ou duas pessoas pra fazer “aquela melhoria no envio de e-mail”: você terá uma comunidade para te ajudar com isso;
  • Se o “dono da framework” morrer, você não perder todo o investimento na ferramenta porque não existe “dono”. Acaba aquela falácia do “super-homem” ou do “cara que fez a framework e só ele sabe mexer nisso”.
  • Estatisticamente comprovado, desenvolver e manter uma framework caseira é muito mais custoso que usar e customizar uma framework já extensamente utilizada no mercado, tanto à nivel de suporte quanto à melhoria da ferramenta e correção de bugs;
  • O que traz diferencial para o negócio de seu cliente (e o seu) é o conhecimento de negócio: a ferramenta será apenas um meio e é mais que bacana que ela esteja pronta e você se preocupe apenas com o negócio e não como “fazer aquele usuário logar e se manter autenticado em página X e Y”.
  • Frameworks trabalham com padrões de design testados e refatorados continuamente por pessoas com anos de experiência em software: é jogar dinheiro no lixo tentar re-inventar a roda ou re-implementar tudo se não for completamente necessário.
  • Programadores experientes terão uma ferramenta amplamente testada e na maioria das vezes bem flexíveis quando precisar adaptar “aquela regra de negócio extraterrestre do cliente XPTO“;
  • Frameworks tem um conjunto grande de plugins/componentes que cobre a maior parte das tarefas comuns como controle de sessão/cookies, envio de e-mails, upload de imagens, internacionalização, autenticação e por ai vai. Se não existir, geralmente é fácil (e muito didático) desenvolver algo novo e que a comunidade vai concerteza agradecer;
  • A parte de visualização dos dados (view) fica separada do controle das ações possíveis no sistema (controller), que por sua vez tem que respeitar as regras de negócio implementadas no acesso ao banco (model) que ficam centralizadas num lugar apenas: ou seja, o MVC (Model-View-Controller) vai diminuir bastante o quebra pau entre designers e programadores e evitar bastante re-trabalho. No caso de sistemas, vai melhorar e muito a manutenção deste;
  • O trabalho com testes é praticamente embutido nessas frameworks e é uma forma ótima para iniciar os trabalhos com TDD nos projetos. Testes não são moda e sim uma tendência natural do mercado onde as aplicações precisam ser cada vez mais confiáveis para não trazer prejuízo para seu cliente;

Boa parte das dúvidas que geralmente se tem recaem principalmente na preocupação de comprometer um projeto com questões técnicas e impedimentos ou na parte do aprendizado em si da ferramenta. Felizmente, com o tempo se percebe que com empenho em cerca de um ou dois meses uma boa framework é absorvida naturalmente.

De certa forma, ela até mesmo promove uma auto-reciclagem de todos os profissionais pois começam a envolver questões como padrões de projeto, orientação à objetos, testes, controles de versão e tudo o que há mais de novo no mundo de desenvolvimento e que volta e meia não chega ao mundo das agências ou software houses mais caseiras.

Em resumo

A adoção de uma framework MVC não é um bixo de 15 cabeças cuspindo fogo e destruindo, mas assim como qualquer novidade apresenta riscos e custo, que CONCERTEZA são altamente recompensadores mesmo que no final ela não seja aproveitada: idéias são concebidas e o nível de conhecimento pós-experimentação é notadamente maior.

Para quem quiser tentar, algumas dicas podem ajudar (ao menos me ajudaram):

  • Inicie com projetos pequenos ou internos para sentir como a framework funciona e até mesmo descobrir características a favor ou contra sua adoção na empresa. Após conhecer pontos fortes e fracos, decida se ela é realmente viável em seu projeto;
  • Se você tem um time, escolha uma pessoa para estudar a ferramenta escolhida e depois faça um hands-on com a equipe pois assim as dúvidas/conclusões fluem de uma maneira surpreendente;
  • Procure conhecer sobre OO (Orientação à Objetos), ORM (Object-Relational Mapping), MVC (paradigma Model-View-Controller), TDD (uso bastante o SimpleTest), controle de versão (estamos usando bastante o GIT) e metodologias ágeis (uso bastante o Scrum): essas coisas “puxam” junto um monte de outras coisas que vão fazer o aproveitamento de qualquer framework MUITO maior;
  • Participe ativamente de listas para tirar dúvidas suas e dos outros: em pouco tempo se tornar um commiter em um projeto pode ser uma experiência e tanto de aprendizado;
  • Mantenha-se antenado nas novidades da framework: a maioria delas tem atualizações constantes e as vezes até chave para alguma coisas que sua empresa pretende fazer;

Existem, claro, frameworks com diferentes abordagens e  vantagens. Então, para tentar encurtar o caminho mas sem traçar um comparativo muito técnico, vão algumas bacanas para se começar:

  • CakePHP, hoje uma das frameworks mais conhecidas e utilizadas no PHP, é uma ferramenta bem influenciada pelo Ruby On Rails, com documentação bacana e uma comunidade grande pacas. Sua curva de aprendizado é bem fácil e os resultados saem bem rápido também, devido ao enorme número de coisas prontas para serem utilizadas. Um ponto fraco é sua performance que não é tão rapida quanto às concorrentes;
  • CodeIgniter, é uma framework que vai no caminho contrário da CakePHP: ela é mais enxuta e sem muitos componentes para rodar bem rápido. Sua curva é tranquila e a documentação bem bacana. Um ponto fraco é a ausência nativa de ORM para mapeamento do banco de dados.

Existem várias frameworks, com vários “sabores” a serem degustados: é ver, testar e ver qual mais agrada e ser feliz!

Simbora.

  • Pingback: jeffersongirao

  • Pingback: Francisco Souza

  • Pingback: Léo Hackin

  • Pingback: Arian Maykon

  • Pingback: topsy_top20k

  • Pingback: Loiane Groner

  • Pingback: Mayck Xavier

  • http://www.lucascoradini.com Coradini

    É?

  • http://twitter.com/lcquadros Leo Cabral

    Tenho que concordar contigo, mestre.

    A adoção de um framework é necessária pelos argumentos citados. O que se vê hoje é algo do tipo “hm… aprendi MVC, farei um framework” e em muitos casos os frameworks caseiros, corporativos (LOL) ou mesmo de comunidades já sólidas estão longe da visão fundamental do MVC e de outros design patterns que basicamente traduzem-se numa frase bacana: “se precisar dar manutenção ou ampliar a aplicação, não tem problema”. Isso se dá ao fato dos frameworks serem feitos por programadores para programadores e não para analistas, programadores, designers e demais membros do projeto; dessa forma, o que parece tão óbvio e certo de fato é obscuro e contraproducente para os demais, satisfazendo uma pequena parte e ignorando toda a cadeia de produção e as futuras manutenções e ampliações.

    Espero que esse texto encabeçe uma lista de dicas imprescindíveis logo.

    Abraço.

  • http://www.franciscosouza.net Francisco Souza

    Salve Hackin! :)

    Eu nunca fui muito chegado em PHP, justamente por essa fama, mas caí numa empresa pra trabalhar com PHP. Lá ainda é tudo meio macarronada, ou pelo menos era, estou começando a “injetar” o CodeIgniter lá. E está sendo bem satisfatório =)

    Parabéns pelo post, super recomendado o/

    Abraços ;)

  • Pingback: Fabiano Sobreira

  • http://blog.sobreira.eti.br Fabiano Sobreira

    Tenho acompanhado os últimos posts do blog e quero parabenizá-lo pela abordagem profissional dos artigos sobre o php. Que venham os próximos!

  • http://www.leohackin.com.br Léo Hackin

    Valew pessoal pelas palavras. :)

  • http://fernandomantoan.com Fernando

    É, eu sei como frameworks caseiros podem se tornar monstros. Ainda existe o fato dos “chefes” acharem que a adoção de um framework vai prejudicar os projetos… WTF? Se prejudicasse não existiriam tantos desenvolvedores que adotam os frameworks… Existem pessoas que mesmo ouvindo 1 milhão de argumentos não abrem a cabeça… Fazer o que? :)

  • Diogo

    E a questao do desempenho é uma pedra muito grande no caminho. Muitas vezes somente a aplicaçao de um framework em um sistema ja existente reflete numa perda de desempenho grande por conta do citado no texto: mania de canivete suiço.

    Pra mim o framework deveria ser muito mais uma base para organizaçao no modo de programar do que muitos por aí que vem cheio de coisas que nao vou usar. Acho que o CodeIgniter é assim, estou certo ? Mesmo a falta de um ORM nele nao é problema, ja que este tb costuma prejudicar bastante o desempenho com consultas nao otimizadas.

    Aqui mesmo na empresa cogitei e recomendei implantar um framework, mas a parte do “estimativa de impacto no desempenho : 50~60%” (Zend Framework) foi decisiva.
    Num sistema com 15 mil clientes nao há como adivinhar os problemas gerados por isso (entre inumeras outras coisas).

    A vantagem futura nao tem limites, concordo. Mas nem sempre é aplicável. Entao continuamos com nosso framework próprio.

  • Pingback: Marco Aurélio

  • http://www.leohackin.com.br Léo Hackin

    Concordo contigo Diogo: bem pontuado, uma framework tem que ser usada quando não pesa na descisão critica para o desenvolvimento de um sistema. As frameworks (TODAS) tem suas aplicações e GAPs e existem peculiaridades em alguns sistemas que esbarram exatamente nessas falhas e não otimizações. ;)

  • Pingback: André Gomes

  • Pingback: Almir Mendes

  • Pingback: Wellington Rocha

  • http://www.teaserpropaganda.com Andre

    Muito bom o post,
    Estava em uma empresa que trabalha no sistema macarronada , mas agora estou em uma que utiliza ZendFramework + Smarty e realmente é excelente trabalhar com um Framework, tudo fica organizado e mais facil de se trabalhar.

  • Pingback: Luis Milanese

  • http://www.cesarscur.com Cesar Scur

    @Diogo: Tenho que discordar totalmente de ti. Uma serie de fatores fazem com que a qualidade do código seja prioritária sobre a performance.
    O custo de desenvolvimento tende a aumentar durante os ciclos de desenvolvimento e continuar aumentando mesmo após a implantação. Enquanto o custo de hardware tende a diminuir com o tempo.
    Além do mais, código mau escrito tende as ser lento. Programadores experientes escrevem códigos elegantes e otimizados por natureza.
    Case: Facebook não seria escrito em php, e sim em java ou C++ se a preocupação principal fosse performance (de fato ele tem extensões em C para php por motivo de performance).
    Em sistemas de alta disponibilidade depender apenas da performance do FW é complicado. Existem diversas técnicas que mitigam essas questões, como o cache.
    Além de que performance em sistemas de alta disponibilidade deve ser medido em TPS. Frameworks como o Zend Framework apesar de reduzir a performance de execução de uma requisição, tem um impacto muito reduzido no volume de TPS.
    Então projetar um sistema sem levar em conta performance é errado. Mas priorizar performance sobre a qualidade do código sem saber de onde estarão so gargalos do seu sistema é muito ruim.