Nota: este es un artículo técnico.
Después de presentar Monica en Hacker News, recibí muchas preguntas sobre por
qué había escrito la herramienta con PHP y con Laravel en particular. Me
sorprendió recibir tantas preguntas sobre el tema, porque considero que el
lenguaje no importa: solo cuenta lo que haces con él.
En este artículo explicaré por qué elegí PHP y Laravel y qué dificultades tuve
que superar para construir la primera versión del producto. Este texto no
pretende iniciar una guerra entre lenguajes.
PHP tiene una historia interesante. Muchos grandes desarrolladores web, que
probablemente ya no usan PHP, aprendieron con él las bases de la programación.
Era sencillísimo de usar y de empezar y, aunque no era un lenguaje elegante,
abrió el camino a muchas carreras en desarrollo web. Con el tiempo PHP fue
perdiendo cariño, hasta el punto de que casi daba vergüenza usarlo o incluso
decir en un meetup que tu empresa lo utilizaba. Otros lenguajes, sin duda más
elegantes, ganaron mucha popularidad (Python, Ruby) gracias a frameworks
estupendos construidos sobre ellos. Al mismo tiempo aparecieron nuevos
frameworks PHP. Symfony, por ejemplo. Pero Symfony seguía siendo difícil de
aprender y de usar. Y entonces PHP murió. O eso decía la gente, ignorando al
parecer que muchísimas empresas seguían usándolo y disfrutándolo. Después
llegó PHP 5.5, seguido de PHP 7, y apareció un framework con un nombre raro:
Laravel. Y la mentalidad cambió por completo. PHP sigue sin ser tan elegante
como otros lenguajes populares, pero las cosas mejoraron mucho. Además se volvió
rápido.
Aun así, PHP sigue siendo el lenguaje que la gente adora odiar, sobre todo en
Hacker News. Dicen que PHP no escala. Probablemente por eso Facebook y Mailchimp,
entre otros grandes nombres, usan PHP hoy, y a gran escala.
Con ese contexto en mente, ¿por qué elegí PHP y Laravel?
- PHP es sencillo de aprender y sencillo de usar.
- Hay muchísimos desarrolladores de PHP y, si alguien quiere trabajar conmigo en
el proyecto, el grupo potencial de desarrolladores de PHP es mayor, al menos
donde yo vivo, que el de desarrolladores de Ruby o Python. Además, hay mucha
gente en GitHub que usa PHP y, si quería que este proyecto de código abierto
tuviera recorrido, tenía que escribirlo en un lenguaje en el que personas con
niveles muy distintos pudieran contribuir con facilidad.
- Lo más importante al elegir una pila tecnológica para un proyecto nuevo es lo
fácil que será mantenerlo a largo plazo. PHP es simple. Es fácil de depurar
(aunque podría serlo más) y fácil de escalar (aunque ahora mismo no es mi
preocupación en absoluto).
- Laravel es con diferencia el mejor framework PHP que he usado. Hace que las
cosas complejas resulten muy sencillas. Se nota que se creó para arrancar
aplicaciones web muy rápido y es un verdadero placer usarlo. Pero su gran
diferencia es la calidad de la documentación, comparada con otros frameworks PHP
e incluso con muchos frameworks de otros lenguajes. Todo está documentado de
forma excelente. No puedo insistir lo suficiente en lo importante que es una
buena documentación (lo que me recuerda que debería documentar Monica todavía
más).
- Hay una enorme comunidad alrededor de PHP y de Laravel en particular:
Laracasts, Forge, Envoyer y una comunidad de Slack muy activa, por citar solo
algunos. Si necesitas ayuda, hay mucha gente dispuesta a echarte una mano.
¿Qué retos me encontré durante el desarrollo del proyecto?
En general no tuve demasiados retos al desarrollar la versión actual de Monica.
No es una aplicación compleja y no tengo problemas de escalado, ya que la base de
usuarios sigue siendo pequeña (unos 7800 usuarios en total y 4300 activos). Pero
hay detalles de implementación que hice mal, no por mala práctica, sino porque
mis conocimientos técnicos no daban para resolver esos problemas a corto plazo.
Espero que enumerar esos errores ayude a otros a no cometerlos, o que gente
amable me escriba para contarme cómo podría haberlos arreglado.
- En versiones anteriores usaba muchos eventos y listeners. El concepto es
estupendo, pero por su culpa tuve muchos problemas para hacer pruebas unitarias
de las clases base. Además, cuanto más los usaba, más magia ocurría entre
bastidores. Pensé que quien entrara en el código tendría dificultades para
entender por qué pasaban ciertas cosas al crear un objeto, por ejemplo. En mi
cabeza, los eventos y los listeners hacían la aplicación más difícil de
entender, así que decidí quitarlos todos (bueno, el 99 %, todavía quedan dos
listeners de los que tengo que deshacerme).
- Al principio la base de datos estaba cifrada por completo. Por razones que
todavía no entiendo, de vez en cuando había errores en el descifrado que dejaban
datos que no podía recuperar. Como no quería lidiar con ese problema en esa
etapa, decidí quitar el cifrado. Además, tener los datos cifrados hacía imposible
cualquier ordenación o búsqueda en mis consultas, lo que habría sido problemático
a la larga. Seguro que hay soluciones para ambos problemas, pero quería
centrarme en crear funcionalidades nuevas en lugar de arreglar ese único asunto.
- No escribí pruebas unitarias antes de lanzar la aplicación. Eso me dolió de
verdad. No creo que haya que aspirar al 100 % de cobertura, pero al menos hay que
tener alguna prueba de las funcionalidades principales de tu sitio. Si no,
acabas con un montón de errores en los que no habías pensado y, mientras
intentas arreglarlos, tu solución afecta a otras partes de la aplicación. Eso se
convierte rápidamente en una pesadilla. Laravel hace que las pruebas unitarias
sean muy fáciles: debería habérmelo tomado más en serio. A partir de la próxima
versión, no se fusionará ninguna pull request si no trae pruebas unitarias y
quizá incluso funcionales.
Conclusión
Estas son algunas razones por las que elegí Laravel. Como decía al principio, tu
proyecto no va del lenguaje. A menos que tu proyecto consista precisamente en
aprender un lenguaje nuevo, no deberías pasar semanas eligiendo lenguaje o
framework. Quédate con lo que conoces y construye algo. A tus usuarios no les
importa que tu código sea feo o que hayas elegido Python en lugar de Ruby.
