PHP : Environnements, Librairies et Applications, Oh mon …!

Mes premières applications PHP étaient assez simples. Une page PHP qui devait interagir avec une base de données et renvoyer un peu de HTML. En revenant dessus, elles ressemblent toutes à un tas de mikado et de code spaghetti. Bien sûr c'était à la mode des années 1999, donc c'était OK parce qu'après tout, ça faisait son job. À mesure que les projets prenaient de l'ampleur, le désir d'une meilleure organisation grandissait également. Cette nouvelle vague d'applications que j'étais en train d'écrire à l'époque était la première évolution d'applications « Model 1 (MVC) » et elles ont introduit la deuxième librairie que j'ai commencé à utiliser.

Smarty (qui est une part du projet PHP) était une librairie dont je suis venu à dépendre sur tous mes projets. Le seul aspect excellent de Smarty d'un point de vue organisation de code est qu'il sépare les scripts en scripts de « logique métier » et scripts de « présentation ». Si une application était une soupe de code, Smarty était l'outil qui séparait la couche logique de présentation, ou ce que l'on a appelé la « vue » dans le paradigme MVC, du code « métier », ou ce qu'on a appelé le « contrôleur » et le « modèle » dans le paradigme MVC. C'était la première étape vers ce que le monde JSP appelle la programmation selon le « Model 2 (MVC 2) ».

Donc, pourquoi cette histoire débute par une petite expérience personnelle ? Bien, je voudrais dire que le chemin que j'ai suivi est vraiment typique de celui du programmeur qui utilise des langages de script pour bâtir des applications, spécialement les applications Web. Cela dit, comme les technologies que nous utilisons évoluent et grandissent, nous avons tendance à nous diriger vers les solutions qui offrent une once de bonnes pratiques, meilleure organisation du code, et le plus important : qui réduisent le time to market (TTM).

Qu'est-ce que cela a à voir avec vous ? Bien, j'ai vu ma part de projets PHP naître et disparaître. En addition de ces projets, j'ai gardé un œil observateur sur des projets dans d'autres communautés comme Ruby, Perl, Java et .NET. D'eux, nous avons emprunté des concepts, des idées et des outils pour bâtir de meilleures solutions pour la communauté PHP. Ainsi, je vais poursuivre en expliquant plusieurs facettes des plus connues de n'importe quel projet PHP. Si cela paraît simple de prime abord, c'est en réalité une base pour d'autres articles plus détaillés à venir.

En PHP, un environnement est un jeu de ressources, de capacités et de configurations pour un usage immédiat dans la durée de vie de n'importe quel process PHP. Je sais que c'est un constat général, mais explorons cela un petit peu. Sur la plupart des systèmes, vous trouverez un fichier php.ini. Ce fichier ini règle généralement des valeurs pour que le programme PHP les initialise à son démarrage. Certaines peuvent être modifiées par le SAPI (boite de commande, commande apache, etc. .) tandis que d'autres peuvent être modifiées durant l'exécution via set_ini, et d'autres ne peuvent pas être modifiées du tout.

Chaque fois qu'un script est exécuté, il hérite premièrement des valeurs du php.ini. Cela veut dire que, par défaut, si aucune n'a été changée, un script est sujet aux règles du php.ini sur le système. Si ces valeurs (les valeurs du php.ini du système) sont hors de votre contrôle, cela veut dire que le script possède un environnement initial ambigu. Cet environnement a dû être défini par l'administrateur système ou par l'installeur de la distribution PHP que vous utilisez.

Si vous êtes sujet à une configuration d'environnement ambiguë, vous avez de grandes chances pour que votre application plante après le setup ou pendant l'exécution. Au minimum une de ces situations est arrivée à un développeur à un moment ou à un autre :

• display_errors est sur off, causant un moment « WTF » (ndt : What The Fuck) quand une erreur survient ;
• le niveau error_reporting est réglé sur E_STRICT et le script est écrit sans respecter le niveau error_reporting causant des centaines d'erreurs de type « Notice » ;
• open_basedir est activé et votre script n'accède pas à certaines ressources alors qu'il le devrait.

Ce sont seulement les trois exemples les plus populaires provenant de trois différentes clefs qui peuvent être réglées dans le php.ini. Pour vous le montrer à plus grande échelle, il y a des centaines de valeurs comme celles-ci. Le point qui doit être le plus retenu est que pour n'importe quel script ou application PHP, il faudrait vérifier l'environnement au lancement du script, ou au pire fournir tous les prérequis de l'environnement dont le script ou les applications ont besoin. La solution idéale est de proposer un script qui va vérifier l'environnement et remonter au moment de l'installation si les valeurs du fichier ini sont correctes.

Une des variables d'environnement les plus intéressantes en PHP, comme dans d'autres langages ou systèmes, est le chemin commun (common path). En PHP, le chemin commun est appelé l'include_path. L'include_path pourrait bien être la plus importante basée sur le php.ini pour n'importe quel script ou projet. Pendant l'exécution d'un script PHP, le chargement des fichiers et des composants est généralement vérifié via le chemin spécifié dans include_path. Cela veut dire que n'importe quel script ou classe (donc n'importe quel code PHP) peut être localisé et chargé à partir d'un chemin relatif, un chemin qui peut être relatif à n'importe quel autre chemin défini dans l'include_path.

L'include_path est une chose vraiment merveilleuse. Cela rend plus facile de livrer des composants ou des packages dans des « librairies » et de les utiliser dans les projets. Cela aide à faciliter le principe « DRY » en encourageant la réutilisation du code et la conception de librairies robustes. D'un autre côté, si vous ne gérez pas correctement les librairies qui sont dans votre include_path, cela peut vous poser quelques problèmes très importants. Plus d'infos dans le chapitre suivant.

La règle générale de conduite est celle-ci : prenez le contrôle de l'environnement du process PHP autant que possible pour assurer un bon comportement.

Il semblerait que librairie soit un terme trop générique, mais je veux lui ajouter certaines explications spécifiques du moins en termes de PHP. Une définition générale de librairie devrait être effectivement une « collection de codes réutilisables » et cette déclaration est vraie pour toutes les intentions. Pour le but de cet article, j'aimerais aller un peu plus loin.

Une librairie est une collection de composants. Pendant qu'une librairie résout le problème général le moins spécifique, les composants résolvent les problèmes généraux les plus spécifiques. Vous y êtes ?

Dans un but démonstratif : je vais utiliser le Framework Zend, puisque je suis un peu orienté vers celui-ci. Le Framework Zend possède beaucoup de librairies, la principale étant nommée la Librairie Standard. La librairie standard de ZF résout un problème général : « le problème de l'application PHP ». Comme vous pouvez le voir, c'est un problème assez général (relativement parlant) qu'elle essaye de résoudre. Cette librairie est faite pour que plusieurs composants puissent résoudre des problèmes spécifiques dans le problème de l'application PHP. Par exemple, Zend_View et Zend_Controller résolvent le problème « sinlineture d'application web ». Zend_Form résout le problème « formulaires web ». Et bien plus encore. Ce sont des problèmes qui peuvent être résolus par des solutions vraies, testées et éprouvées. Ces solutions peuvent généralement être considérées comme « bonnes pratiques ». Elles sont résolues de manière à ce que vous puissiez vous appuyer dessus pour résoudre des problèmes plus spécifiques, ceux dans « l'application ».

Il est à noter que la définition de librairie est aussi relative à l'audience ciblée. Dans notre exemple précédent, l'audience attendue du Frameworks Zend est tous les développeurs PHP. Votre entreprise, d'un autre côté, à une audience ciblée beaucoup plus petite : ses développeurs internes. Puisque cet auditoire est un groupe plus petit et plus concis, leurs besoins sont plus spécifiques que ceux de la communauté de développeurs mondiale. Ce qui veut dire que la « librairie » d'une entreprise doit résoudre des « problèmes généraux plus spécifiques » à l'échelle d'une entreprise. Par exemple, une entreprise doit avoir dix applications qui utilisent un système de connexion unique, cette solution doit être mieux taillée pour une « librairie » d'entreprise.

En général, les librairies résolvent des problèmes qui sont assez génériques pour l'auditoire complet, et chaque problème est résolu par un composant de la librairie. Tout le reste va dans « l'application ».

Comme écrit ci-dessus, sur la section des librairies, une application aussi est définie par le problème qu'elle doit résoudre. Une application est une collection de codes métier spécifiques qui résolvent un problème métier spécifique. Encore une fois, c'est plutôt générique, mais on peut aller plus loin dans l'explication et la définition.

Un problème métier est le problème le plus spécifique qui peut être résolu via du code : c'est ça une application : une application peut être modulaire. Si une application est modulaire, cela implique que la zone de problèmes de l'application peut être divisée en plusieurs zones spécifiques de code avec des responsabilités spécifiques. Prenons un site communautaire par exemple. Le site doit inclure des forums, management d'utilisateurs, mail, agenda et news. Chacune de ces zones respectives du site doit considérer des modules de l'application ou du module principal. Même si c'est un exemple générique, cela démontre une division logique des responsabilités qui est le point d'introduction des modules dans une application. Chaque projet et métier doit évaluer ses applications et doit décider ouvertement de quelle granularité se compose le problème, et comment le diviser au mieux. Le faire ouvertement va soulager beaucoup de questions qui pourraient surgir plus tard comme la base de code qui commence à grandir.

Derrière la modularité d'une application, plus loin, plus de divisions logiques et d'organisation de code sont généralement appliquées. Tandis qu'il existe plusieurs paradigmes d'organisation d'application, nous allons nous concentrer sur l'architecture MVC (si vous n'êtes pas familiarisé avec l'architecture MVC, ce devrait être bien de lire l'article de Wikipédia avant de continuer). Tant une application modulaire et une application non modulaire peuvent être organisées en Modèles, Vues et Contrôleurs, les constituants principaux du paradigme MVC. Sans arriver à impliquer ce que MVC est, il faudrait savoir que :

• le Modèle représente la base de code pour résoudre le problème métier à portée de main d'un point de vue UI et de diagnostique d'environnement ;
• le Contrôleur représente la base de code responsable de joindre les interactions utilisateur et l'UI au modèle métier, pour configurer une nouvelle UI ;
• la Vue représente la base de code responsable de créer l'UI spécifique de l'environnement.

Le groupement de propositions précédentes est ce qu'on appelle la séparation des couches.

Voici un récapitulatif des termes usités dans cet article.

• Un environnement est une somme de toutes les ressources, possibilités et configurations qui existent dans un process PHP. Cela inclut généralement quelles extensions et valeurs du php.ini sont présentes pour le process PHP.
• Une librairie est une collection de code qui résout le problème le moins spécifique qui est mieux défini par l'audience cible de la librairie et sa zone de problème.
• Un composant est une collection de codes qui résout le problème le plus spécifiquedans une librairie.
• Une application est une collection de code qui résout un problème métier spécifique. Idéalement les applications consomment des librairies et des composants pour faciliter un développement rapide et stable.
• Un module est une collection de code qui résout un problème atomique plus spécifique du plus gros problème métier. La somme de tous les modules dans une application tente de résoudre le plus gros problème métier.
• MVC est une façon de grouper du code dans à la fois un module et une application et aussi dans une base de code qui facilite la séparation des couches.

Vous pouvez aussi aller voir mes autres traductions.