Pourquoi Laravel ?

Note : cet article est technique.

Après avoir lancé Monica sur Hacker News, j'ai reçu beaucoup de questions sur les raisons qui m'ont poussé à écrire l'outil en PHP, et avec Laravel en particulier. J'ai été surpris d'en recevoir autant sur ce sujet, car je considère qu'un langage n'a pas d'importance : seul compte ce que l'on en fait.

Dans cet article je vais expliquer pourquoi j'ai choisi PHP et Laravel, et quelles difficultés j'ai dû surmonter pour construire la première version du produit. Ce texte n'a pas vocation à déclencher une guerre entre langages.

PHP a une histoire intéressante. Beaucoup d'excellents développeurs web, qui n'utilisent probablement plus PHP aujourd'hui, y ont appris les bases de la programmation. Il était si simple à prendre en main et, même sans être un langage élégant, il a ouvert la voie à des carrières dans le web. Puis, avec le temps, PHP a été de moins en moins aimé, au point qu'il devenait presque honteux de l'utiliser ou même de dire en meetup que son entreprise s'en servait. D'autres langages, sans doute plus élégants, ont gagné en popularité (Python, Ruby) grâce à d'excellents frameworks. En parallèle, de nouveaux frameworks PHP sont apparus. Symfony par exemple. Mais Symfony restait difficile à apprendre et à utiliser. Et puis PHP est mort. Du moins c'est ce que l'on disait, en ignorant apparemment qu'énormément d'entreprises l'utilisaient encore et l'appréciaient. Ensuite PHP 5.5 est arrivé, puis PHP 7, et un nouveau framework au nom étrange est apparu : Laravel. Et les mentalités ont complètement changé. PHP n'est toujours pas aussi élégant que d'autres langages populaires, mais les choses se sont beaucoup améliorées. Il est aussi devenu rapide.

Malgré tout, PHP reste le langage que les gens adorent détester, surtout sur Hacker News. On dit qu'il ne passe pas à l'échelle. C'est probablement pour cela que Facebook et Mailchimp, entre autres grands noms, utilisent PHP aujourd'hui, à très grande échelle.

Avec ce contexte en tête, pourquoi ai-je choisi PHP et Laravel ?

• PHP est simple à apprendre et simple à utiliser.
• Il y a beaucoup de développeurs PHP, et si des gens veulent travailler avec moi sur le projet, le vivier de développeurs PHP est potentiellement plus large, au moins là où je vis, que celui des développeurs Ruby ou Python. Il y a aussi beaucoup de monde sur GitHub qui utilise PHP, et si je voulais que ce projet open source prenne, je devais l'écrire dans un langage où des personnes de niveaux très variés pourraient contribuer facilement.
• La chose la plus importante quand on choisit une pile technique pour un nouveau projet, c'est la facilité à le maintenir sur la durée. PHP est simple. Il est facile à déboguer (même si cela pourrait être mieux) et facile à faire grossir (même si ce n'est pas du tout ma préoccupation aujourd'hui).
• Laravel est de loin le meilleur framework PHP que j'aie utilisé. Il rend les choses complexes très simples. On sent que le framework a été créé pour démarrer de nouvelles applications web très vite, et c'est un vrai plaisir à utiliser. Mais sa fonctionnalité imbattable, c'est la qualité de la documentation, comparée aux autres frameworks PHP et même à beaucoup de frameworks dans d'autres langages. Tout est extrêmement bien documenté. Je ne dirai jamais assez à quel point une bonne documentation compte (ce qui me rappelle que je devrais documenter Monica davantage).
• Il y a une immense communauté autour de PHP et de Laravel en particulier : Laracasts, Forge, Envoyer, une communauté Slack très active, pour ne citer qu'eux. Si vous avez besoin d'aide, beaucoup de monde est prêt à vous en donner.

Quels défis ai-je rencontrés pendant le développement de ce projet ?

Globalement je n'ai pas eu tant de difficultés en développant la version actuelle de Monica. Ce n'est pas une application complexe, et je n'ai pas de problèmes de montée en charge car la base d'utilisateurs reste modeste (environ 7800 utilisateurs au total, 4300 actifs). Mais certains détails d'implémentation sont mauvais, non par mauvaise pratique, mais parce que mes compétences techniques n'étaient pas suffisantes pour résoudre ces problèmes à court terme. J'espère que lister ces erreurs aidera d'autres personnes à ne pas les commettre, ou que des gens bienveillants m'écriront pour me dire comment j'aurais pu les corriger.

• Dans les premières versions, j'utilisais beaucoup d'événements et de listeners. Le concept est formidable, mais j'ai eu énormément de mal à tester unitairement les classes de base à cause d'eux. De plus, plus je les utilisais, plus la magie opérait en coulisses. Je me suis dit que les personnes plongeant dans le code auraient du mal à comprendre pourquoi certaines choses se produisaient à la création d'un objet, par exemple. Dans mon esprit, les événements et les listeners rendaient l'application plus difficile à comprendre, alors j'ai décidé de tous les supprimer (enfin, 99 % d'entre eux, il reste deux listeners dont je dois me débarrasser).
• Au début, la base de données était entièrement chiffrée. Pour des raisons que je n'ai toujours pas comprises, il y avait de temps en temps des bugs dans le déchiffrement, ce qui menait à des données irrécupérables. Comme je ne voulais pas traiter ce problème à ce stade, j'ai décidé de retirer le chiffrement. Par ailleurs, des données chiffrées rendaient impossible tout tri ou toute recherche dans mes requêtes, ce qui aurait posé problème sur la durée. Il existe sûrement des solutions à ces deux problèmes, mais je voulais me concentrer sur de nouvelles fonctionnalités plutôt que sur celui-ci.
• Je n'ai pas écrit de tests unitaires avant de lancer l'application. Cela m'a vraiment coûté cher. Je ne pense pas qu'il faille viser 100 % de couverture, mais il faut au moins des tests pour les fonctionnalités principales de son site. Sinon on se retrouve avec une tonne de bugs auxquels on n'avait pas pensé et, en essayant de les corriger, d'autres parties de l'application sont touchées par le correctif. Cela devient vite un cauchemar. Laravel rend les tests unitaires très faciles : j'aurais dû prendre cela plus au sérieux. À partir de la prochaine version, aucune pull request ne sera fusionnée sans tests unitaires, voire sans tests fonctionnels.

Conclusion

Voilà quelques raisons pour lesquelles j'ai choisi Laravel. Comme je le disais au début, votre projet ne se résume pas au langage. À moins que votre projet ne soit précisément d'apprendre un nouveau langage, vous ne devriez pas passer des semaines à choisir un langage ou un framework. Restez sur ce que vous connaissez et construisez quelque chose. Vos utilisateurs se moquent que votre code soit laid ou que vous ayez choisi Python plutôt que Ruby.