--- comments_url: https://com.richard-dern.fr/post/540 date: '2015-01-15 02:43:38' links: - lang: fr name: Page d'origine sur LinuxFr url: https://linuxfr.org/users/richarddern/journaux/je-n-aime-pas-le-code-moderne tags: - PHP - Composer - Fancy - Bibliothèque - PSR - PEAR title: Je n'aime pas le code moderne weather: humidity: 83 illuminance: 0.0 precipitations: false pressure: 1012.0 source: - open-meteo temperature: 4.6 wind_direction: 205 wind_speed: 19.0 --- Cher journal, ## Avant propos # Développeur PHP depuis près de dix ans, internaute depuis quinze et geek depuis vingt-cinq, comme tout bon geek, je fais de la veille. Je m'intéresse aux nouveautés, j'étudie scrupuleusement les spécifications des langages que j'utilise (soit PHP, Javascript, CSS et HTML), en bref, je me tiens au courant et j'applique les recommandations les plus récentes. ### C'était mieux avant ## J'adorais Internet. Je l'aime toujours, mais moins qu'avant. "Avant" ? Avant l'avènement des réseaux sociaux. Similairement, bien que j'aime toujours coder, j'aime le code moins qu'avant. "Avant" ? Avant l'avènement des frameworks usines-à-gaz qui ne respectent même pas les principes élémentaires de codage ou du modèle [MVC](https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur) (du code logique dans des commentaires ? du code brut dans les templates ?). ### Mon framework à moi ! ## Je travaille depuis quelques temps sur un framework maison, composé d'un loader du même genre que celui de [CakePHP](http://cakephp.org/) mais en plus lisible (```CoreLoader::load_vendor('phpmailer')``` ou ```CoreLoader::load_controller('home')``` par exemple), d'un routeur particulièrement complet (prenant en charge des routes automatiques, les droits des utilisateurs en fonction de la route demandée, etc.), de templates, etc. Bien que j'ai codé moi-même le gros du framework, l'idée reste qu'il s'agisse d'une agrégation des meilleures librairies dans leur domaine respectif: - [PHPMailer](https://github.com/PHPMailer/PHPMailer) - [Redbean](http://www.redbeanphp.com/welcome) - [Smarty](http://www.smarty.net) - etc. ## Changement de cap # ### La philosophie du Libre ## Hier, j'ai eu une épiphanie: > "Hey, coder toi-même ce qui existe déjà ? > Pas trop la philosophie du Libre !" Ok. Ça implique - apparemment - d'utiliser des trucs ~~tout moches~~ modernes du genre [composer](https://getcomposer.org/). Bon, allez, je m'y colle. Je cherche un peu une librairie pour remplacer mon routeur, et je tombe sur un certain nombre d'entre elles: - [klein](https://github.com/chriso/klein.php) - [Toro](https://github.com/anandkunal/ToroPHP) - [Aura](https://github.com/auraphp/Aura.Router) Et puis tiens, [PHP-Error](https://github.com/JosephLenton/PHP-Error) pourrait être pas mal. ### La déconvenue ## > Oh ! > Il y a un éditeur intégré pour modifier le code en direct quand une erreur se présente ! > Cool ! > Oh, ça m'enregistre un fichier presque vide quand il y a un antislash dans un namespace ! > Bon, ben encore une application moderne qui mise sur l'apparence et qui en fait est tout bugguée... Mon application de test n'est pas à la racine. Aucun problème pour mon routeur, mais _klein_ ne fonctionne pas sans _.htaccess_ pour le rewrite, _Aura_ est beaucoup trop gros et aucun des trois ne matche mes routes sur la variable _PATH_INFO_ mais sur le chemin relatif depuis _DOCUMENT_ROOT_. Bizarre... ### Cause et effet ## De façon assez étrange, ni _Smarty_, ni _Redbean_ ne mentionnent _composer_ dans leur documentation, et _PHPMailer_ s'en passe parfaitement. D'ailleurs, j'aime beaucoup [la raison avouée pour laquelle l'auteur de _Redbean_ ne propose pas de package _composer_](http://www.redbeanphp.com/download). Certe, les trois peuvent s'installer via le gestionnaire de dépendances, mais de manière plus ou moins officieuse. Personnellement, j'ai bien envie de tomber dans la facilité et voir un lien entre la qualité des librairies, le fait que _composer_ soit obligatoire ou non pour les installer, et la vétusté/simplicité de leur site Internet. J'ai testé pas mal d'autres librairies encore et je constate une chose: une grosse partie a une page web créée avec [Bootstrap](http://getbootstrap.com/). Encore des clones de _bootstrap_... Certains mieux réalisés que d'autres toutefois, mais on sent toujours cette patte _bootstrap_, c'en est désespérant. Ni _Redbean_, ni _Smarty_ n'utilisent _bootstrap_ sur leur site. Là encore, j'ai envie de tomber dans la facilité: comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de _bootstrap_, ou du moins, faire en sorte que ça ne se voit pas ? Du coup, je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité. ### Le mal-aimé ## En parlant de popularité, autre exemple: [PEAR](http://pear.php.net/). _PEAR_ existait avant _composer_. Avoir sa librairie disponible sur _PEAR_ était, à une époque, la quintessence, l'aboutissement, une reconnaissance extrême. Bien sûr, _PEAR_ est un framework alors que _composer_ est un gestionnaire de dépendances, mais tout de même. Aujourd'hui, tout le monde boude _PEAR_, à part [Horde](http://www.horde.org/) et quelques irréductible de ce que j'appelle l'artisanat du web, vestige d'une époque où le code devait être bien écrit, quasiment exempt de bugs, et fonctionner partout sans la moindre nécessité d'adaptation. Il semblerait qu'on ait perdu cette versatilité au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les [namespaces](http://php.net/manual/en/language.namespaces.php), les [traits](http://php.net/manual/en/language.oop5.traits.php), etc.). ### Interopérable ? ## Le pire, c'est que toutes ces libs modernes suivent les recommandations [PSR](https://github.com/php-fig/fig-standards), donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées. D'ailleurs, je crois que les "standards" recommandés par le PHP-FIG ne servent qu'à _composer_. Il y a évidemment quelques bonnes idées dedans (UTF-8 sans BOM, _LoggerInterface_, etc.) qui contribuent effectivement et efficacement à l'interopérabilité des librairies PHP, mais désormais, je fuirai les librairies arborant fièrement avoir suivi ces recommandations parce que cela signifie qu'il va être pratiquement impossible de les utiliser sans _composer_ (qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives). ### On n'est jamais mieux servis que par soi-même ## Au final, je vais faire ce que j'ai toujours fais: continuer de tester des librairies, et intégrer à mon framework les meilleures d'entre elles, les plus simples à installer et utiliser, même si elles devaient être quelque peu obsolètes ([simplepie](http://simplepie.org/) par exemple). Pour ceux que ça intéresse, voici les différentes librairies que j'utilise, outre _Redbean_, _PHPMailer_ et _Smarty_ (sans _composer_ et sans les avoir modifier de quelque manière que ce soit): - [Munee](http://mun.ee/) - concaténation et minification à la volée de CSS et JS avec support de less, scss, coffescript, etc. - [Parsedown](https://github.com/erusev/parsedown) - parser [markdown](http://daringfireball.net/projects/markdown/syntax) - [phpass](http://sunnyis.me/blog/secure-passwords/) - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish ### Happy end, quand même ## Je note tout de même que cette expérience m'a tout de même apporté de bonnes surprises, comme [monolog](https://github.com/Seldaek/monolog), [sentry](https://github.com/cartalyst/sentry) ou [climate](https://github.com/thephpleague/climate) que j'intégrerai peut être à mon framework, malgré l'utilisation "nécessaire" de _composer_ et leur usage abusif des namespaces... Ou bien je coderai mes propres libs, les distribuerai sous licence Libre, hors _composer_, en mentionnant que j'ai une approche plus conservatrice du dév...