MicroPHP

samedi 02 juin 2012 à 02:31

Désolé pour ces derniers jours plutôt silencieux, mais Decard Cain m'a appelé d'urgence pour remettre un peu d'ordre à Tristram. Mais maintenant que Diablo est à nouveau mort, je peux m'occuper de la doc de mon framework et vous parler de quelque chose que j'ai vu il y a quelque temps déjà : le manifeste MicroPHP ou comment remettre les choses en ordre dans la logique de PHP qui, selon moi, est mise à mal depuis quelque temps avec des solutions de plus en plus lourdes pour des projets qui ne le méritent pas.

Mais tout d'abord, le manifeste :

The MicroPHP Manifesto


I am a PHP developer

  • I am not a Zend Framework or Symfony or CakePHP developer
  • I think PHP is complicated enough


I like building small things

  • I like building small things with simple purposes
  • I like to make things that solve problems
  • I like building small things that work together to solve larger problems


I want less code, not more

  • I want to write less code, not more
  • I want to manage less code, not more
  • I want to support less code, not more
  • I need to justify every piece of code I add to a project


I like simple, readable code

  • I want to write code that is easily understood
  • I want code that is easily verifiable

Et sa traduction :

Le manifest MicroPHP

Je suis un développeur PHP

  • Je ne suis pas développeur pour Zend Framework ou Symfony ou CakePHP
  • Je pense que PHP est suffisament compliqué


J'aime créer des petites choses

  • J'aime créer des petites choses a des fins simples
  • J'aime faire des choses qui résolvent des problèmes
  • J'aime créer des petites choses qui travaillent ensemble pour résoudre des problèmes compliqués


Je veux moins de code, pas plus

  • Je veux écrire moins de code, pas plus
  • Je veux gérer moins de code, pas plus
  • Je veux maintenir moins de code, pas plus
  • Je dois justifier chaque partie de code de mes projets


J'aime le code simple et lisible

  • Je veux écrire du code facile à comprendre
  • Je veux du code facile à vérifier

Innutile de dire que je suis d'accord avec ces principes et que, j'espère, I-Radian suis ces idées. Mais tous les projets ne sont pas compatibles avec cette façon de faire. Les gros projets imposent de partir d'une base solide et permettant de le faire évoluer rapidement. Et c'est ainsi qu'on se retrouve avec du Symfony pour un site vitrine de 8 pages, du EzPublish pour un blog perso et du ZendFramework pour un site évennementiel…

Alors d'ou viens ce problème de surdimentionnement exessif des projets ? Selon moi, ce problème vient entre autre des web agency qui recrutent des développeur ZF ou Cake ou Symfony avant même de recruter des développeurs compétant, qui font confiances à quelques chefs de projets qui partent du principe que leurs projets seront développé avec tel framework sans passer par la case «est-ce le bon outil ?» et à des commerciaux qui sur-vendent la maintenabilité et la souplesse de ces solutions. Alors certe, le manque de temps joue un rôle crucial.

Entre apprendre un nouvel outil à chaque projet ou lire et comprendre un cahier des charges, un développeur n'a pas le choix et ne peux pas le justifier devant ses supérieurs… Entre passer 2 jours à tester les outils qui pourraient convenir à une problématique donnée ou passer ce temps à commencer le projet, le CP n'a pas à hésiter… Entre passer cinq jours à préparer une vrai présentation d'un projet «homemade» difficile à vendre car plus dur à maintenir par une autre équipe ou montrer un Power Point tout fait mais se mettre dans les bonnes grâces du client en lui payant une bonne bouffe, le commercial n'hésite pas…

Et voila, tout le monde est heureux de fournir un site à un photographe codé en Symfony (je dis bien «en» et pas «avec» car Symfony est souvent utilisé comme une solution toute faite et non comme un outil) pour un poids de 2,9 Mo compressé codé réalisé en téléchargeant 2 extensions et en suivant un tuto, en 5 jours, facturé 15, pour 12 000 euros. Et le client là dedans, il est content, sûr d'investir pour l'avenir et d'avoir un site facile à maintenir. Jusque là, tout va bien, et lorsque 3 ans plus tard le client revient pour faire une petite mise à jour technologique de son site, on lui dis qu'il est totalement dépassé techniquement et qu'il faut tout refaire, que maintenant, tout le monde est sur Symfony 2 avec de l'ajax partout et le commercial qui commence à avoir l'habitude, lui vend ça facilement.

Alors, si tout le monde est heureux, où est le mal ? Le commercial se fait une bouffe au frais de sa boite, le client a un site et reviendra certainement auprès de cette société si compétente, le chef de projet à assureé auprès de ses supérieurs et le dèv a fait économiser 10 jours de son temps à sa boite. Il y en a deux : tout d'abord, personne ne fait son boulot; ensuite, le prix. Non, un site internet ne coute pas 10 000 euros.

Je sais qu'en disant ça, beaucoup vont me prendre pour un fou. Pourtant, le calcul est simple : 3 semaines de dèv, 4 jours de conception et 4 jours de commercial… Un dèv moyen est payé 30 à 35K€ en voyant large, donc disons 3500€ pour 3 semaines (charges comprises), le CP et le commercial couteront grossomodo 1000 à 1500€ chacuns et les 3500€ qui restent, partent dans la poche de la société. En fait, cet argent est destiné à la gestion des clients chiants qui reviennent sur ce qu'ils veulent tous les quatres matins et qui menacent de ne pas payer et d'aller voir ailleur.

Quel dèv de web agency n'a pas ris en voyant le commercial revenir d'un repas en annoncant qu'il avait réussis à faire cracher 5000€ un dèv de 2 jours pour ajouter une fonctionnalité bidon à un projet ? Alors toutes les web agency ne sont pas comme ça, mais ayant bossé pour une petite et une grosse, c'est ce que j'ai vu… Le pire, je pense que c'est dans la grosse boite… Cette société, que vous connaissez sans doute, gère un framework français très réputé (oui, c'est eux). J'ai eu la chance de rester très peu de temps dans cette boite qui m'a pris en période d'essai sans vraiment tester mes compétences sur leur outil… Cette grosse web agency avait donc trop de boulot comparé à sa main d'œuvre et le moindre projet était facturé 40K. Ils avaient certe des compétences que toutes les autres boites n'ont pas forcément, mais soyons réaliste, ce qu'on paye en allant chez eux, c'est uniquement le prestige…

Le rapport entre le manifeste microPHP, les micro framework et ce que je viens de dire, n'est pas direct, mais il est bien là. Il est aussi important pour un codeur de faire de la veille techno et de découvrir de nouveaux outils que de pisser du code. La grande majorité des projets ne vaut pas la peine de peser 3Mo avec des tartines de code qui ne servent à rien. J'en suis même arrivé à me demander si un site vitrine valait la peine d'utiliser une base de données ou s'il ne valait pas mieux prendre tinyMCE, d'enregistrer le résultat dans un bon vieux fichier en include sur le front. Et certains de mes amis ont eu la même idée que moi et l'ont fait… La sécurité n'est pas compromise puisque le mot de passe est en dur directement en MD5 ou SHA1 dans un fichier et finalement, c'est tout aussi sécurisé que d'avoir les accès à la DB dans un fichier de conf.

Le problème, c'est qu'un micro framework, c'est pas vendeur. Soyons clair : il est impossible d'innover sur 50Ko de code. Niveau maintenabilité, on n'a pas la même communauté derrière 50Ko que derrière 50Mo. On n'offre pas la même chose (au pire une interface pour la DB et un peu de gestion de formulaire). Bref, le principal problème de microPHP, c'est que ce n'est pas aussi sexy qu'une solution fini.

Pourtant, avoir un socle de 50Ko a ses avantages : puisque j'aime me contredire, c'est plus facile a maintenir. Sauf si on n'est pas à jour techniquement, on ne passe pas 1h à trouver la ligne qui beuge dans 10 fichiers alors que dans 1000, on ne cherche pas : on demande sur un forum. On a moins peur des effets de bord lorsqu'on modifie le core du framework. On a réellement la main sur tout. Le gestionnaire de formulaire vous agace ? Changez-le, c'est pas compliqué. Finalement, gérer 50Ko, c'est bien plus simple que de laisser la main à d'autre comme Zend ou Symfony, même si techniquement ils sont super au point; la question n'est pas la compétence technique externe, mais l'interne.

Pour finir, je vais vous donner ma façon personnelle pour noter un framework : si l'installation passe par des lignes de commandes imbitables et me génère 500 fichiers alors qu'un dézipage et un fichier de conf suffisent pour obtenir une install potable sur 95% des autres, c'est mal parti. Si les tâches simples de la création d'un projet sont plus dur avec le framework que sans, c'est mort. Par exemple, générer un formulaire, c'est bien, mais laisser la main sur le rendu, c'est mieux. Et donc je regarde Google : «probleme zend framework form», «probleme installation symfony», etc.

Petite note quand même : je ne pouvais pas ne pas saluer l'initiative de Sensio (qui gère Symfony) qui a sorti dernièrement Silex. Je ne l'ai pas encore tester et j'ai peur de retomber sur du Symfony à la mode slim fast mais avec des modules pré-installé inutiles. Mais au moins, ils semblent avoir compris que Symfony était souvent utilisé à tort sur des petits projets. Malheureusement, je viens de voir : le zip c'est 500Ko… je vais le tester, mais j'ai peur.

Laissez un commentaire

captcha

En bref...

Dernier article

La dictature sur facebook

Cette semaine, l'actu, c'est Facebook qui trébuche. Le réseau social vient en effet de supprimer le droit de vote de ses membres. On a aussi GoogleNow sur Chrome, des nouvelles pas très réjouissantes de l'UIT, du piratage, l'étoile de la mort de Star Wars et une évasion échoué.

Ressources externes