Observação: este é um post técnico.
Depois de lançar o Monica no Hacker News, recebi muitas perguntas sobre por que
escolhi escrever a ferramenta em PHP e, em particular, com Laravel. Fiquei
surpreso com tantas perguntas sobre o assunto, porque considero que a linguagem
não importa: só conta o que você faz com ela.
Neste post vou contar por que escolhi PHP e Laravel e quais dificuldades precisei
superar para construir a primeira versão do produto. O texto não pretende começar
uma guerra entre linguagens.
O PHP tem uma história interessante. Muitos ótimos desenvolvedores web, que
provavelmente não usam mais PHP, aprenderam com ele as bases da programação. Era
simples de usar e de começar e, embora não fosse uma linguagem elegante, abriu
caminho para carreiras no desenvolvimento web. Com o tempo, o PHP passou a ser
menos amado, a ponto de ser quase vergonhoso usá-lo ou até dizer em um meetup
que sua empresa o utilizava. Outras linguagens, sem dúvida mais elegantes,
ganharam muita popularidade (Python, Ruby) graças a frameworks maravilhosos
construídos sobre elas. Ao mesmo tempo, surgiram novos frameworks PHP. O Symfony,
por exemplo. Mas o Symfony ainda era difícil de aprender e de usar. E então o PHP
morreu. Ou pelo menos era o que diziam, ignorando aparentemente que muita
gente do mundo dos negócios continuava usando e gostando dele. Depois veio o PHP
5.5, seguido do PHP 7, e apareceu um framework com um nome estranho: Laravel. E a
mentalidade das pessoas mudou completamente. O PHP ainda não é tão elegante
quanto outras linguagens populares, mas as coisas melhoraram muito. E ele também
ficou rápido.
Mesmo assim, o PHP continua sendo a linguagem que as pessoas adoram odiar,
especialmente no Hacker News. Dizem que o PHP não escala. Provavelmente é por
isso que o Facebook e o Mailchimp, entre outros grandes nomes, usam PHP hoje, em
grande escala.
Com esse contexto em mente, por que escolhi PHP e Laravel?
- O PHP é simples de aprender e simples de usar.
- Existem muitos desenvolvedores PHP e, se as pessoas quiserem trabalhar comigo
no projeto, o grupo potencial de desenvolvedores PHP é maior, pelo menos onde eu
moro, do que o de Ruby ou Python. Além disso, há muita gente no GitHub usando
PHP e, se eu quisesse que este projeto de código aberto ganhasse tração, tinha
que escrevê-lo em uma linguagem em que pessoas de diferentes níveis pudessem
contribuir com facilidade.
- O mais importante ao escolher uma pilha tecnológica para um projeto novo é o
quanto será fácil mantê-lo no longo prazo. O PHP é simples. É fácil de depurar
(embora pudesse ser melhor) e fácil de escalar (embora isso não seja de forma
alguma minha preocupação agora).
- O Laravel é de longe o melhor framework PHP que já usei. Ele torna simples
fazer coisas complexas. Fica claro que o framework foi criado para iniciar novas
aplicações web bem rápido, e é um verdadeiro prazer usá-lo. Mas o grande
diferencial do Laravel é a qualidade da documentação, comparada à de outros
frameworks PHP e até de muitos frameworks em outras linguagens. Tudo é
extremamente bem documentado. Não consigo enfatizar o suficiente como uma boa
documentação é importante (o que me lembra que eu deveria documentar ainda mais
o Monica).
- Há uma enorme comunidade em torno do PHP e do Laravel em particular:
Laracasts, Forge, Envoyer e uma comunidade forte no Slack, para citar algumas. Se
você precisar de ajuda, há muita gente pronta para dar uma mão.
Quais desafios enfrentei durante o desenvolvimento deste projeto?
No geral não tive tantos desafios ao desenvolver a versão atual do Monica. Não é
uma aplicação complexa e não tenho problemas de escala, já que a base de usuários
ainda é pequena (cerca de 7800 usuários no total e 4300 ativos). Mas há detalhes
de implementação que fiz errado, não por má prática, mas porque minhas
habilidades técnicas não eram suficientes para resolver esses problemas no curto
prazo. Espero que listar esses erros ajude outras pessoas a não cometê-los, ou
que gente gentil me escreva contando como eu poderia tê-los corrigido.
- Em versões anteriores, eu usava muitos eventos e listeners. O conceito é
ótimo, mas tive muitos problemas para testar unitariamente as classes base por
causa deles. Além disso, quanto mais os usava, mais mágica acontecia nos
bastidores. Achei que quem entrasse no código teria dificuldade para entender
por que certas coisas aconteciam quando um objeto era criado, por exemplo. Na
minha cabeça, eventos e listeners tornavam a aplicação mais difícil de entender,
então decidi remover todos (bem, 99% deles, ainda há dois listeners dos quais
preciso me livrar).
- No começo, o banco de dados era inteiramente criptografado. Por razões que
ainda não entendi, de vez em quando havia bugs no processo de descriptografia,
resultando em dados que eu não conseguia recuperar. Como não queria lidar com
esse problema naquele momento, decidi remover a criptografia. Além disso, dados
criptografados tornavam impossível qualquer ordenação ou busca nas consultas, o
que teria sido problemático no longo prazo. Tenho certeza de que há soluções para
esses dois problemas, mas eu queria focar em criar novas funcionalidades em vez
de resolver esse único ponto.
- Não escrevi testes unitários antes de lançar a aplicação. Isso me custou caro.
Não acho que devamos buscar 100% de cobertura, mas ao menos ter algum tipo de
teste para as funcionalidades principais do site. Caso contrário, você acaba com
uma tonelada de bugs em que não havia pensado e, enquanto tenta corrigi-los,
outras partes da aplicação são afetadas pela correção. Isso vira um pesadelo
rapidinho. O Laravel torna os testes unitários muito fáceis: eu deveria ter
levado isso mais a sério. A partir da próxima versão, nenhum pull request será
integrado sem testes unitários e talvez até testes funcionais.
Conclusão
Estas são algumas razões pelas quais escolhi o Laravel. Como disse no começo do
post, seu projeto não é sobre a linguagem. A menos que o objetivo do projeto seja
aprender uma linguagem nova, você não deveria passar semanas escolhendo
linguagem ou framework. Fique com o que você conhece e faça alguma coisa. Seus
usuários não vão se importar se o código é feio ou se você escolheu Python em vez
de Ruby.
