Retour à la liste

Le manifeste « micro PHP »

Créé : 16.04.2016, 14:40:04  -  Modifié : 11.10.2018, 19:16:55

Le manifeste

Plutôt que de faire un copier-coller bête et méchant de la version originale, voici une traduction approximative :

Je suis un développeur PHP
Je ne suis pas un développeur Zend Framework ou Symfony ou CakePHP.
Je pense que PHP est déjà suffisamment compliqué.

J’aime créer des choses simples
J’aime créer des choses simples avec des objectifs simples.
J’aime créer des choses qui résolvent des problèmes.
J’aime créer des choses simples qui, mises ensemble, résolvent des problèmes complexes.

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.
Chaque morceau de code que j’ajoute à un projet doit être justifié.

J’aime le code simple et lisible
Je veux écrire du code qui se comprend facilement.
Je veux du code qui se teste facilement.

Le détail

Le créateur de ce manifeste explique sa pensée plus en détail sur son blog. Dans un premier post, il donne sa vision d’ensemble. Mettons de côté sa comparaison musicale (il compare l’installation de deux batteurs, pour dire qu’il se voit comme un codeur punk, et non pas comme un codeur rock-progressif… mais on s’en fout un peu).

Ce qui est intéressant, c’est lorsqu’il donne un exemple de code, censé être typique des applications Zend Framework :

 

<?php
chdir(dirname(__DIR__));
require_once (getenv('ZF2_PATH') ?: 'vendor/ZendFramework/library') . '/Zend/Loader/AutoloaderFactory.php';
Zend\Loader\AutoloaderFactory::factory(array('Zend\Loader\StandardAutoloader' => array()));

$appConfig = include 'config/application.config.php';

$listenerOptions = new Zend\Module\Listener\ListenerOptions($appConfig['module_listener_options']);
$defaultListeners = new Zend\Module\Listener\DefaultListenerAggregate($listenerOptions);
$defaultListeners->getConfigListener()->addConfigGlobPath('config/autoload/*.config.php');

$moduleManager = new Zend\Module\Manager($appConfig['modules']);
$moduleManager->events()->attachAggregate($defaultListeners);
$moduleManager->loadModules();

// Create application, bootstrap, and run
$bootstrap = new Zend\Mvc\Bootstrap($defaultListeners->getConfigListener()->getMergedConfig());
$application = new Zend\Mvc\Application;
$bootstrap->bootstrap($application);
$application->run()->send();

Et là, je le rejoins complètement. C’est une chose que j’ai déjà rabâchée à plusieurs reprises. À mon sens, un framework doit simplifier le développement, le rendre plus rapide et plus lisible. C’est une évidence pour tout le monde, mais le moyen d’y arriver ne semble pas être commun à tous.

À mes yeux, le code d’une application doit être limpide. Évidemment, on s’attend à avoir un « socle de base », un « moteur » sous-jacent qui est là pour simplifier les choses. L’exemple de code ci-dessus est sans appel. Moi non plus, je ne veux pas avoir à coder des trucs comme ça.

Je peux comprendre qu’il puisse y avoir à choisir entre complexité du code d’un côté, et complexité de la configuration de l’autre. Si un framework rend le code simple, mais au prix d’une configuration plus complexe, cela peut s’expliquer. Ensuite, tout dépend de là où on souhaite mettre le curseur. Une configuration plus simple aura sûrement pour effet de complexifier le code.
Le problème, c’est qu’on se retrouve parfois à avoir du code complexe ET des fichiers de configuration illisibles.

Les micro-frameworks et les micro-bibliothèques

L’auteur du manifeste prend ensuite le parti de dire qu’il existe des micro-frameworks qui font très bien le boulot. Prenant l’exemple de SlimEpiphanyBreeze et Limonade, il part du principe qu’il sont largement suffisant pour la plupart des besoins, et que son approche est de les enrichir grâce à des bibliothèques de fonctions, plutôt que de vouloir utiliser un framework « full-stack ».

Pour rappel, les micro-frameworks fonctionnent quasiment tous sur le même modèle. Pour illustrer la chose, voici l’exemple de code fourni par Slim :

<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();
?>

Pour finir, l’auteur du manifeste tient à jour une liste de projets, qui sont tous censés être simples à utiliser, qui remplissent une seule fonctionnalité (ou un groupe de fonctionnalités connexes). L’idée est sympa, même si le nombre de projets similaires réduit son utilité.

Mon avis

Je suis complètement d’accord avec ce manifeste. Le code doit être simple ; rapide à écrire, facile à lire, facile à modifier. Je pense que personne ne dira le contraire.

Le seul point sur lequel je suis un peu plus circonspect, c’est en ce qui concerne les micro-frameworks. Je m’y suis intéressé un peu à une époque, et j’ai joué avec Silex, notamment. Et je n’ai pas trouvé que cette approche simplifiait réellement l’écriture de vrais sites.

Je suis peut-être trop formaté par l’approche à laquelle je suis habitué, mais je ne pense pas que la manière dont le routage est imbriqué dans le code soit l’idéal pour avoir du code simple à lire et à maintenir. Et plus le site sera important, plus ce sera vrai.

Cela m’amène à parler un peu du framework Temma.
Comme présenté sur le site du projet, l’idée générale est très simple :

  • Pour une URL du type /article/show/123/title
  • le framework exécute ArticleController::execShow(123, ‘title’);
  • et transmet les données au template article/show.tpl

Et, à part une configuration très succincte (paramétrage de l’accès à la base de données), tout ce qu’on se retrouve à écrire comme code, ce sont simplement des objets dont les méthodes vont répondre aux URL. Nous sommes d’accord qu’il n’y a rien de fondamentalement novateur là-dedans, cette approche est partagée par de nombreux frameworks. Mais le code applicatif n’est pas pollué par le framework.

L’idée générale de Temma est de proposer quelques fonctionnalités de base (il y a quand même un embryon de routage, une gestion des sessions et du cache, de la base de données, …), qui sont extensibles à l’aide de plugins. On en parlait récemment sur le forum de discussion qui lui est consacré. Si vous avez besoin d’un routage élaboré, il suffit d’ajouter un plugin ; si vous voulez gérer un site multilingue, encore un plugin ; et ainsi de suite.
Ça permet de garder un cœur simple à comprendre et à assimiler, tout en gardant la souplesse d’en faire ce qu’on veut en fonction de nos besoins.

Pour en revenir au manifeste micro PHP, je pense qu’il s’agit surtout d’un rappel d’un principe fondamental du développement. Quand on développe, on sépare le code en entités séparées les unes des autres. La programmation orientée objet facilite cette approche en fournissant la brique de base de ce concept ; mais au-dessus de l’objet, il y a les bibliothèques qui regroupent plusieurs objets.

Ces différentes entités s’appellent entre elles pour profiter des fonctionnalités qu’elles offrent. Ce qui fait la différence entre un bonne bibliothèque et une mauvaise, c’est entre autre à quel point elle encapsule sa complexité et réussit à présenter une interface simple et facile à utiliser. Si une bibliothèque impose d’écrire des dizaines de lignes de code pour simplement y faire appel, ou si son API est tellement obscure qu’il faut faire plusieurs appels pour réaliser la moindre action simple, c’est qu’il y a un soucis.


Rendu :0.1186 | Mémoire :2.92MB

Accueil | Informations | Top