Cours de PHP 5

Je vais vous proposer une méthode pour développer des applications de manière à la fois flexible et qualitative.

Nous allons utiliser trois serveurs par projet :

1. Développement ;
2. Staging / Test ;
3. Production / Live.

Le premier niveau est le serveur de Développement. Il est destiné aux développeurs, eux seuls y ont donc accès.

Une technique flexible pour le développement en équipe, consiste à utiliser un seul serveur pour le développement des applications. Si le développeur est seul dans son équipe, il peut utiliser sa propre machine ; dans le cas contraire, il est préférable d’utiliser une seule machine commune à tous les développeurs. Le serveur Web Apache permet de configurer des hôtes virtuels (VirtualHost) dans son fichier de configuration httpd.conf : c’est une manière idéale d’attribuer un serveur Web complet à chaque développeur.

Un module très utile pour configurer simplement Apache dans un tel cas de figure est mod_macro, qui permet de définir une macro (un « gabarit ») puis de la réutiliser pour chaque développeur. Si vous avez un serveur de noms (DNS) sur votre réseau, vous pouvez l’utiliser pour lier chaque VirtualHost à un développeur.

Côté PHP, vous aurez besoin de toutes les extensions du serveur de Production ainsi que d’extensions spécifiques au développement, par exemple Xdebug (cf. le débogage ci-après).

C’est le serveur Staging qui contient le dépôt (repository) de votre outil SCM (par exemple CVS ou Subversion). Vous pouvez utiliser un utilitaire de « postcommit » pour que le code envoyé par les développeurs soit déployé automatiquement sur le serveur Web de l’environnement Staging.

La configuration de ce serveur Web est strictement identique à celle du serveur de Production : cela permet de s’assurer que la transition Staging/Prod se fera sans problème. L’idée est de faire valider par l’équipe, puis par le client, l’intégralité de l’application avant de la déployer (mise en Production).

Le serveur de Production est la dernière phase. L’application doit avoir été validée par l’équipe puis par le client avant d’être envoyée en Production.

Souvenez-vous de ne jamais rien modifier directement en Production : développez un patch en Dev, faites un commit dans le SCM en Test puis utilisez le serveur Web de Test pour faire valider le patch. Une fois que vous avez la certitude que le code déposé dans votre outil SCM fonctionne, déployez-le en Production.

Les tests sont une étape fondamentale de la démarche qualité. Ils permettent de valider le fonctionnement de l’application avant de la soumettre au client.

Les tests unitaires sont les tests les plus élémentaires. Il s’agit de vérifier qu’une fonctionnalité réagit bien comme on s’y attend.

Les tests ne sont pas utiles s’ils ne sont pas automatisés, c’est pourquoi on parle se « suites de tests ».

Il existe plusieurs outils PHP pour écrire les tests de vos applications : PHPUnit, SimpleTest, phpt…

N’oubliez pas de rédiger un test à chaque rapport de bug : cela permet de valider à la fois l’existence du bug et sa résolution effective. Intégrer ces tests de bugs à vos suites de tests permet d’éviter les régressions (réapparition d’anciens bugs) lors de la vie d’une application. Un test peut permettre de valider soit qu’une partie de l’application fonctionne correctement, soit qu’un bug n’est pas réintroduit.

Site de PHPUnit : http://www.phpunit.de/
Site de SimpleTest : http://simpletest.sourceforge.net/
Site de phpt : http://qa.php.net/write-test.php

Le développement orienté par les tests consiste à écrire les tests avant d’écrire le code qui répond à la fonctionnalité testée. C’est le test qui décrit le besoin fonctionnel. Cela permet d’une part de ne pas oublier de tests et, d’autre part, de s’assurer que la fonctionnalité a bien été codée en conformité avec le besoin.

Les tests sont une étape fondamentale de la vie d’une application. Toutefois, c’est à vous de choisir votre stratégie.

La complexité des applications développées aujourd’hui ne permet plus de déboguer un site avec des armées d’echo ou die(). Ces techniques fonctionnent bien pour de petites applications, mais, dès que l’application gagne en complexité et en taille, ajouter des instructions echo augmente le risque d’apparition de nouveaux bugs.

Par conséquent, il est primordial de mettre en place une solution permettant de déboguer les scripts à la manière d’un compilateur C++ : avec des points d’arrêt, des états instantanés sur les variables, une exécution pas à pas, etc.

C’est possible en installant une extension PHP. Historiquement, la première extension à permettre ce type de débogage est DBG. Bien que son protocole de communication soit encore utilisé, elle est aujourd’hui remplacée par sa concurrente Xdebug, bien plus performante et mise à jour plus fréquemment.

Installer une telle extension permet non seulement de déboguer l’application pas à pas, mais aussi d’en établir un profil afin de déterminer quels scripts consomment le plus de mémoire ou de temps CPU. Le débogage est donc non seulement un outil de développement, mais aussi d’optimisation.

• APD (Advanced PHP Debugger - extension PECL dont le développement semble arrêté depuis 2004) ;
• DBGDBG (extension incompatible avec PHP 5.3 et 6) ;
• XdebugXdebug (extension PECL) ;
• Zend StudioZend Studio (application commerciale).

Site : http://xdebug.org/Xdebug pour PHP

Xdebug est l’extension de débogage PHP la plus efficace en ce moment. Elle est développée par Derick Rethans, elle est disponible pour toutes les versions de PHP, elle est gratuite (licence compatible PHP) et elle s’interface avec n’importe quel EDI capable de débogage avec le protocole DBGp.

zend_extension_ts = "full/path/to/php_xdebug.ext"
xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.extended_info = On
xdebug.remote_mode = req; "req" ou "jit"
xdebug.profiler_enable = On
xdebug.profiler_enable_trigger = On
xdebug.profiler_output_dir = "path/to/profiling"
xdebug.profiler_output_name = "cachegrind.out.%t"
xdebug.trace_output_dir = "path/to/temp"
xdebug.trace_output_name = "trace.%c"

Un motif de conception (design pattern) est une technique permettant de résoudre un problème standard. Plutôt que d’avoir recours à votre propre solution à un problème, il est préférable de réutiliser un motif déjà identifié et résolu par d’excellents concepteurs de logiciels.

Un exemple simple concerne les variables globales. Tous les enseignements sont formels (avec raison) : il faut éviter les variables globales. Pourtant, il arrive fréquemment d’avoir besoin d’une variable dans plusieurs contextes à la fois, et les problèmes de portée (scope) nous mettent des bâtons dans les roues. La solution à ce problème est le pattern Registry. Il s’agit d’une classe qui regroupe toutes les variables qui pourraient être globales et qui nous les donne au besoin. Ce pattern repose sur le pattern Singleton, qui nous assure d’avoir une seule instance du registre dans tout notre code.

Les motifs de conception reposent très largement sur la POO, il est donc fortement recommandé d’être à l’aise dans ce domaine.

Voici l’un des plus connus des motifs de conception pour sites Web.

Le principe est d’avoir un unique point d’entrée au site Web : le front controller. Cela permet de placer la presque totalité de vos scripts en dehors de la racine du serveur Web, et ainsi de protéger votre application. De plus, cela vous incite à utiliser une technique de réécriture d’URL (URL rewriting), ce qui a de nombreux avantages. Nous avons déjà débattu de tout cela dans ce tutoriel, je ne vais donc pas y revenir.

Le pattern MVC oblige le développeur à séparer la structure de son application en trois types de composants :

• M pour « modèles » : Ce sont les classes donnant accès aux données ;
• V pour « vues » : C’est la partie de l’application qui se charge de l’affichage des données ;
• C pour « contrôleurs » : Ces classes s’occupent de charger les modèles adéquats, d’appliquer les traitements nécessaires et d’envoyer aux vues les données demandées.

Le pattern Singleton permet de s’assurer qu’il n’existe qu’une seule instance de la classe. C’est utile dans certaines situations précises, par exemple certains composants d’architecture MVC ou un pattern Registry.

L’idée du Singleton est de rendre le constructeur protected afin d’empêcher l’instanciation de la classe, et d’utiliser une méthode statique pour construire une instance unique. Par convention, cette méthode s’appelle getInstance().

<?php
class MyClass
{
    protected $instance;

    protected function __construct(){}

    public static function getInstance()
    {
        if(empty(self::$instance))
        {
            self::$instance = new self();
        }

        return self::$instance;
    }
}

Au lieu d’instancier cette classe (opérateur « new »), le programmeur appelle la méthode getInstance().

<?php
$objet = new MyClass(); //utilisation standard, ne peut pas fonctionner ici

<?php
$objet = MyClass::getInstance(); //pattern Singleton

Si vous êtes certain de n’avoir toujours besoin que d’une seule connexion à la base de données dans vos scripts, vous pouvez par exemple utiliser ce pattern pour implémenter votre classe de connexion. Un autre exemple peut être votre classe de configuration.

Ne sur estimez jamais votre capacité à résoudre seul les problèmes auxquels vous faites face. D’autres développeurs y ont été confrontés avant vous et ils ont eu tout le temps de parvenir à des solutions à la fois élégantes, simples et robustes. Ayez l’humilité d’utiliser leurs solutions plutôt que d’essayer d’y parvenir vous-même, car, ayant moins d’expérience, vos solutions ne seront probablement pas aussi efficaces. Vous aurez tout le temps de révolutionner le monde du développement logiciel lorsque vous aurez suffisamment de recul pour pouvoir vous permettre de critiquer l’existant.

De nombreux autres motifs sont disponibles. Nous ne pouvons pas tous les expliquer ici, car c’est l’objectif d’ouvrages bien plus complets.

Lorsque vous commencez à développer, il est préférable de simplement apprendre à utiliser le langage. Cependant, avec le temps, vous vous rendez compte que vous résolvez sans arrêt les mêmes problèmes et que vous réutilisez (recopiez) des composants d’une application à l’autre. Cela signifie que vous avez développé une sorte de framework utilisé par 0% des autres développeurs.

De plus, se plonger dans le code écrit (sans framework) par un autre développeur est souvent un cauchemard parce qu’il n’utilise pas les mêmes conventions que vous. Maintenir les applications des autres développeurs est donc problématique à cause de la courbe d’apprentissage du framework spécifique à chaque application (également utilisé par environ 0% des développeurs).

Une solution à tous ces problèmes est d’adopter des composants standards, écrits et utilisés par une communauté de développeurs. Cela ne vous immunise pas totalement dans le cas où vous devez maintenir du code développé avec un autre framework, mais les probabilités de rencontrer un framework inconnu passent de 100% à un nombre bien plus raisonnable. Un framework regroupe des composants standards, choisis spécialement et adaptés pour fonctionner parfaitement ensemble, et propose des conventions de codage afin de réduire au maximum les différences dans les styles de programmation des développeurs de la communauté.

Utiliser un framework ne produira pas un site Web en deux clics (ce n’est pas un CMS). En revanche, il vous permettra de produire des sites uniques tout en simplifiant les problématiques standards.

Les frameworks sont généralement classés comme « glue » ou bien « full-stack ». Les premiers sont simplement des ensembles flexibles de composants, tandis que les autres obligent le développeur à suivre une ligne de conduite bien précise. Les deux catégories ont leurs avantages, et le choix d’un framework par rapport à un autre dépend du cahier des charges de chaque projet.

Site : http://cakephp.org/

Tutoriel rapide : http://manual.cakephp.org/appendix/blog_tutorialThe Cake Blog Tutorial

CakePHP est un framework de type « full-stack ».

Il adhère au principe « convention over configuration » qui prône les conventions de codage plutôt que la configuration. Cela permet de réduire les temps de développement, mais enlève au développeur une marge de liberté sur la structure de sa BDD ou de son code, voire dans certains cas sur l’aspect de son site.

La documentation de CakePHP suit de bons principes et le champ sémantique homogène (cookies, bakery…) dénote une bonne ambiance au sein de la communauté.

Liste des conventions de CakePHP : http://manual.cakephp.org/appendix/conventions

Site : http://ezcomponents.org/

Vue d’ensemble : http://ezcomponents.org/overview

eZ Components est la bibliothèque développée par eZ Systems et utilisée dans eZ Publish. Ce n’est pas un framework à proprement parler puisqu’il ne se présente pas en tant que tel, mais on peut probablement en parler comme d’un framework de type « glue ». eZ Components a le soutien de Derick Rethans, l’un des participants majeurs à PHP (internals, xdebug…).

Tutoriels eZ Publish : https://php.developpez.com/cours/?page=scripts#ezp

Site : http://pear.php.net/

PEAR est l’un des plus anciens frameworks « glue » pour PHP. Ils proposent des conventions de codage depuis de nombreuses années, et certaines ont été reprises par d’autres projets depuis lors. C’est aujourd’hui une bibliothèque de composants parfois rendus obsolètes par les frameworks concurrents.

Le groupe PEAR a su standardiser la diffusion d’extensions et de composants, ainsi que distribuer un outil qui n’est pas sans rappeler apt-get (Debian GNU/Linux).

PEAR est aujourd’hui connu principalement pour sa démarche qualité et pour ses outils de distribution (go-pear, etc.).

Site : http://www.symfony-project.org/

Framework de type « full-stack ».

Le projet symfony, d’origine française, s’appuie sur l’expérience de ses développeurs en matière de développement de sites Internet. Toutes les problématiques rencontrées de manière récurrente par les développeurs du framework ou par ses utilisateurs sont répertoriées, mises en facteur et éventuellement incluses dans une version ultérieure.

L’un des gros points forts de symfony est sa documentation : il existe un livre, disponible à la vente ou bien en téléchargement gratuit, également consultable en ligne et traduit en français.

Le projet symfony a le soutien de l’entreprise française SensioLabs.

Tutoriels symfony : https://php.developpez.com/cours/?page=frameworks#symfony

Site : http://framework.zend.com/

Framework de type « glue » à tendances « full-stack ».

Zend, qui fournit notamment le Zend Engine depuis de nombreuses versions de PHP, a commencé en 2007 à diffuser son propre framework. L’idée est de diffuser un framework de très haute qualité en matière de développement de sites Web : best practices, design patterns, OOP, sécurité…

Le framework suit un processus communautaire de développement, chaque proposition est étudiée avec soin puis soumise à validation par l’ensemble de la communauté, la documentation (traduite dans de nombreuses langues) est révisée fréquemment, des tests unitaires sont systématiquement exigés, etc.

Le projet Zend Framework est soutenu par Zend Technologies.

Tutoriels Zend Framework : https://zend-framework.developpez.com/cours/

Au risque de me répéter…

Ne sur estimez jamais votre capacité à résoudre seul les problèmes auxquels vous faites face. D’autres développeurs y ont été confrontés avant vous et ils ont eu tout le temps de parvenir à des solutions élégantes. Ayez l’humilité d’utiliser leurs solutions plutôt que d’essayer d’y parvenir vous-même, car, ayant moins d’expérience, vos solutions ne seront probablement pas aussi efficaces. Vous aurez tout le temps de révolutionner le monde du développement logiciel lorsque vous aurez suffisamment de recul pour pouvoir vous permettre de critiquer l’existant.