Livre blanc - Industrialisation de PHP

A un moment de la vie d'un projet, on a besoin d'un diagnostic et donc, d'un expert. Le projet présente des symptômes naissants de gangrène (sécurité, performance, maîtrise du code, sentiment de maîtrise, etc.). Les audits sont particulièrement intéressants lors de la reprise d'une activité, ou en cas de disparition complète de l'équipe de développement : reprendre en main un existant se fait bien après une évaluation externe ou interne et il est souvent plus efficace de passer par un service externe.

Pour cela, il faut faire appel à un expert : ce dernier vient réaliser un état des lieux de l'application et de son organisation. Les missions portent souvent le nom d'un des symptôme principaux :

• Audit de sécurité
• Audit de performances
• Audit de qualité logicielle
• Audit de l'application

Cette dernière dénomination est générale. Dans la pratique, elle recouvre les trois problèmes précédents et signale des problèmes graves. C'est un manque de confiance dans l'application et un manque de direction dans son développement.

Les sociétés de services capables de mener un audit PHP sont actuellement peu nombreuses. Elles doivent disposer d'experts, de préférence reconnus par la communauté et d'une vaste expérience de développement et de menée de projets. De bonnes références sont aussi un atout. La pratique des audits en général, même si elle n'est pas appliquée à PHP, est alors un atout : savoir présenter un rapport est un métier en soi.

Un audit d'une plate-forme Web prend généralement entre une et trois semaines, et impose une mise à disposition d'informations assez importantes. Le code source, les configurations serveurs, l'architecture de la plate-forme, les acteurs du projets, la base de données et sa volumétrie. Dans tous les cas, il faut exiger un engagement à confidentialité de la part des experts.

Les audits doivent toujours intégrer l'utilisation des outils automatiques. Ces outils sont faciles à utiliser, et couvrent beaucoup de surface. Ils sont limités dans la profondeur de leur attaque, mais permettent d'identifier immédiatement des problèmes simples et spectaculaires ou de mettre en avant des problèmes potentiels qui seront analysés par un expert. Ils permettent aussi de vérifier les vulnérabilités qui ont été publiées : ce sont les problèmes les plus fréquents.

Il existe plusieurs outils d'audit de code PHP.

Les outils automatiques d'analyse de code sont immatures : ils apportent des retours superficiels, quoique souvent spectaculaires. Ils gagneront à être utilisés dans le cadre de la maîtrise du code tout au long du développement.

Les audits d'applications PHP sont aujourd'hui peu sollicités. La taille des projets permet souvent d'abandonner la base de code en cours et de reprendre à partir de zéro. C'est une règle bien connue des équipes de développement, qui choisissent souvent ce type de solution. Entre l'audit et la réécriture totale, il faut continuer la promotion des bonnes pratiques et de leur application.

Enfin, le recours à un audit PHP doit toujours être considéré comme un dernier recours : c'est une étape qui va coûter très cher. Des méthodes existent pour prendre en compte les problèmes de qualité de code et de sécurité plus en amont, durant le développement ou bien dès la conception et l'architecture.

PHP est reconnu pour sa simplicité d'utilisation et de prise en main. Nombreux sont les autodidactes qui décident de faire leurs premiers pas sur le Web avec PHP et évoluent vers de nouvelles responsabilités. Cette approche tire partie de l'expérience acquise sur le terrain et fournit des résultats rapides et tangibles.

Les équipes de développement sont fréquemment organisées autour d'un gourou : souvent en interne, parfois en externe, le gourou a pour vocation de guider les développeurs en devenir entre les fonctionnalités et les méthodes que propose PHP pour résoudre les problèmes. Un gourou est précieux, mais il est difficile d'en avoir un de disponible et ils sont rares. Au final, la formation est la meilleure solution pour élever le niveau de jeu de son équipe.

Pour maintenir un bon niveau de compétences techniques et méthodologiques dans une équipe, la formation régulière est un atout indispensable. Selon le temps disponible et le budget alloué à la formation, plusieurs options se présentent.

Accessible à tout un chacun, une veille technologique régulière est essentielle. Grâce aux techniques de syndication (RSS, Atom, etc.) et aux agrégateurs, ces outils qui centralisent l'accès aux flux d'information, mettre en place une veille PHP est relativement simple. En fait, obtenir une masse d'information sur l'actualité PHP et connexe est aisée, mais le ratio signal/bruit risque d'être faible.

Les outils automatiques d'analyse de code sont immatures : ils apportent des retours superficiels, quoique souvent spectaculaires. Ils gagneront à être utilisés dans le cadre de la maîtrise du code tout au long du développement.

Il y a plusieurs possibilités pour diminuer la part du bruit dans une veille :

• Utiliser les filtres des agrégateurs afin de n'extraire que les articles intéressants de flux de syndication trop généralistes ;
• S'abonner à des sites qui effectuent une sélection des articles les plus pertinents dans un domaine ;
• Identifier des personnes ayant les mêmes centres d'intérêt et partageant le fruit de leur veille sur des services de bookmarks sociaux (Delicious, Diigo, etc.).

Une activité sérieuse de veille est nécessaire dans une équipe importante : il est intéressant d'attribuer ce rôle à une personne curieuse, qui sera chargée de partager le fruit de sa veille avec le reste de l'équipe. Cette approche est formatrice. Elle permet aussi de dégager des intérêts techniques ou des discussions sur l'actualité PHP et des technologies, dont les développeurs sont friands.

Pour avoir plus de recul sur les évolutions de fond de PHP, la formation professionnelle reste le meilleur outil.

Les organismes de formation proposent des sessions concentrées en moins d'une semaine. Le formateur est spécialement entraîné pour faire la synthèse des évolutions de fond de PHP, et les faire comprendre correctement aux stagiaires. La formation comporte généralement deux phases qui alternent :

• Des présentations magistrales détaillant les aspects théoriques des technologies;
• Des travaux pratiques où l'on applique les notions précédentes à des cas concrets.

Les formations peuvent être dispensées au sein d'une entreprise uniquement pour le personnel de celle-ci, on parle alors de formation intra-entreprise, ou bien dans un organisme de formation pour des personnes venant de sociétés différentes, il s'agit dans ce cas de formation inter-entreprises.

Les formations sont un pied à l'étrier pour aborder une nouvelle technologie ou un nouvel outil. Il ne faut pas penser que des développeurs partant de zéro seront parfaitement opérationnels dès la fin de la formation. En revanche, les quelques jours qu'ils y auront consacrés doivent être vus comme un investissement pour éviter une auto-formation nécessairement plus longue et comportant le risque de faire l'impasse sur certains éléments importants ou de partir sur de mauvais usages.

Parmi les très nombreux sources d'informations disponibles, voici les plus notables :

La formation des équipes se concentre sur PHP et sa technique. Les notions présentées y sont principalement techniques et s'attachent à garder le développeur au top niveau de ce que la plate-forme lui propose. Il est indispensable de garder ses équipes à l'heure concernant les problématiques PHP, ou encore sur des aspects critiques comme les performances, la sécurité ou les outils d'industrialisation.

De la même manière que chacun d'entre nous a une écriture qui lui est propre, chaque développeur a ses habitudes de travail. Le formatage du code et le nommage des éléments varient beaucoup d'un développeur à un autre. Pourtant, le commun des mortels utilise une langue écrite, le français dans ce texte, qui comporte des règles et des conventions. Le respect de ces règles tend à supporter le message que veut faire passer l'auteur et permet souvent d'en vérifier le contenu. Les conventions de code jouent le même rôle vis-à-vis des applications.

C'est d'autant plus important que les équipes de développement ont tendance à croître en taille. Entrer dans le code d'un programmeur qui utilise d'autres conventions que les notres, ce qui est souvent le cas, est une barrière à la compréhension. D'ailleurs, une grosse partie du temps est passée à reformater ce code, simplement pour le mettre dans un format lisible et agréable. Au lieu de laisser libre cours à des conventions parfois contradictoires, il est recommandé d'en choisir une seule, commune à toute l'équipe.

Code mal écrit :

<?php
function fibonacci($n)       {
$i = $a = $b = 0;
while($i < 0)           {$c = $a + $b; $a = $b; $b = $c; $i++}
return $b;
}
?>

Code aux conventions :

<?php
function fibonacci($n) {
$i = 0;
$a = 0;
$b = 0;
while($i < 0) {
$c = $a + $b;
$a = $b;
$b = $c;
$i++
}
return $b;
}
?>

Certains langages imposent des conventions de programmation, comme Python. Ce n'est pas le cas de PHP. Il n'y a pas, à ce jour, de convention officielle.

Il existe toutefois plusieurs conventions de programmation découlant souvent des communautés ou de certains projets d'envergure. Celles-ci expliquent plus ou moins en détails comment le code source doit être formaté (indentation, encodage, placement des signes, etc.) et comment les éléments qui le constituent doivent être nommés (fichiers, classes, méthodes, variables, etc.). Chacun est donc libre d'utiliser celle qu'il souhaite. Il existe trois stratégies pour choisir une convention de programmation :

• Adopter une convention existante ;
• Adapter une convention existante ;
• Créer sa convention.

Créer sa propre convention est souvent le choix qui paraît le plus naturel. On est ainsi sûr d'avoir une convention qui réponde parfaitement à ses besoins et représente le plus petit effort d'adaptation de la part de l'équipe en place. Par contre, cet effort de standardisation fait partie du contrat social de la convention : l'important est de sensibiliser les développeurs au fait qu'un autre développeur puisse se sentir aussi à l'aise dans son code.

Il est alors naturel de partir d'une convention existante et de la modifier ou de la compléter selon ses besoins spécifiques. Cela demande un travail réduit mais là encore l'écart avec une convention standard devra être intégré par les nouveaux arrivants ou les prestataires travaillant pour la société.

La solution la plus courante est d'adopter une convention existante et de s'y tenir. D'ailleurs, les frameworks proposent toujours une convention de programmation, qu'il est pratique d'adopter.

Le choix d'une convention est généralement moins important que la discipline qui l'accompagne. Comme souvent, cela tourne aux querelles de clocher et il est difficile de mettre tout le monde d'accord. Une fois un choix adopté, il est primordial de respecter la convention de manière systématique, sous peine de perdre progressivement la maîtrise de la présentation. D'ailleurs, les points d'un logiciel où le nombre de violations de convention de code est le plus grand représente toujours une raison pour un audit.

Il existe plusieurs conventions de programmation dans le monde PHP. Trois d'entre elles sont le plus souvent citées :

• PEAR : La célèbre bibliothèque de composants PHP utilise une convention bien conçue et documentée qui a été reprise par de nombreux projets Open Source ;
• Zend Framework : Pour son framework, la société Zend s'est basée sur la convention de PEAR et l'a complétée ;
• PHP Coding Standard: Cette convention est maintenant ancienne mais elle est bien conçue.

Le choix final d'une convention est souvent une question d'habitudes et de goûts personnels cependant le choix peut être induit par l'usage d'un outil comme un framework ou un CMS. Ceux-ci ont généralement une convention de codage qu'il est judicieux d'utiliser afin de s'assurer de l'homogénéité de l'application développée.

Vérifier l'application d'une convention de programmation peut rapidement devenir une tâche titanesque. Heureusement, des outils ont été créés afin de simplifier l'essentiel voire la totalité des vérifications :

• PHP_CodeSniffer : Ce paquet PEAR est l'outil de référence pour vérifier l'application d'une convention de programmation. Il propose de valider plusieurs des conventions les plus connues dont celles de PEAR et de Zend Framework mais également de créer des vérifications supplémentaires. Par ailleurs, il permet également de vérifier le code Javascript et CSS ;
• PHPCheckStyle : Bien que moins connu et plus limité que PHP_CodeSniffer, cet outil peut rendre des services ;
• PHPCodeBeautifier : Il se charge de mettre votre code à votre convention, sur Windows.

Choisir une convention de programmation n'est pas un acte anodin car le code source d'une application sera manipulé tout au long de sa vie. Il est recommandé de le choisir avec l'équipe, pour une meilleure adoption, et pour identifier les conflits que cela peut engendrer.

Le plus important reste de la respecter : des outils automatiques d'analyse permettent de tester régulièrement le code et de produire des indicateurs sur la discipline. Tout comme la sécurité, cela se travaille au quotidien.

Le développement d'une application est rarement aussi linéaire que les planifications de projets le laissent entendre. Il y a des essais, des erreurs, des tâtonnements. Quand on travaille à plusieurs, il est encore plus compliqué de s'organiser pour publier un code propre sans se marcher sur les pieds : le premier symptôme du besoin d'un dépôt de code survient lorsque deux développeurs travaillent sur le même fichier et que le dernier écrase le code correctif du premier.

Les petites équipes choisissent souvent de centraliser leur code à l'aide d'un partage réseau sauvegardé régulièrement dans des archives. Cette solution est simple à mettre en place, mais la pratique montre vite ses limites :

• Il n'y a pas de gestion de conflits, chacun peut écraser le travail de ses collègues par mégarde ;
• Il est impossible d'avoir un historique des modifications apportées au code ;
• Il est très difficile de gérer des expérimentations.

Il est alors temps de passer à un dépôt de code, qui sait gérer les versions et les conflits.

Les dépôts de code ont été créés spécialement pour régler ces problèmes, qui sont communs à toutes les technologies qui gèrent des codes sources. Ces logiciels stockent un historique de chacune des modifications apportées : on appelle ces modifications des révisions. Grâce à cet historique, il devient possible de :

• Savoir qui a écrit, quel code et quand ;
• Visualiser les modifications apportées entre deux révisions ;
• Revenir à une version précédente du code si nécessaire.

Les versions sont entretenues sur un serveur appelé un dépôt. Un dépôt est un système client-serveur. Le serveur stocke l'ensemble du code source. Il est chargé de conserver l'historique des modifications, de veiller au respect des droits d'accès, d'incrémenter les numéros de versions, de gérer les tags de versions, de signaler les conflits, etc.

Les logiciels clients se connectent au serveur afin de récupérer le code source sur lequel travailler. Une fois ce travail effectué, les modifications apportées à ce code source sont renvoyées sur le serveur. Les autres clients peuvent ultérieurement récupérer ce code source mis à jour et continuer leur travail sur leurs postes respectifs.

La terminologie appliquée aux versions est empruntée aux arbres. Ainsi, on parle de tronc pour désigner l'endroit où est stocké le code principal et de branches pour les variations du tronc. Il existe plusieurs stratégies pour gérer ces branches (branches expérimentales, branches de maintenance, branches par développeur ou par équipe, etc.)

En complément du tronc et des branches, il existe des tags qui sont des «photos» du code à un instant donné. C'est à l'aide de tags que l'on gère les versions des applications, sans empêcher son développement.

Il existe de nombreux outils tant Open Source que propriétaires pour implémenter un dépôts de code.

Dans ce domaine, le serveur Open Source CVS a longtemps été l'outil le plus populaire. Il est aujourd'hui remplacé par un nouveau serveur appelé Subversion, souvent abrévié SVN, qui reprend les mêmes bases que CVS, et corrige nombre de limitations que la pratique a mis à jour. Subversion est actuellement le dépôt de code centralisé de référence. Puissant et fiable, il est utilisé par de très nombreuses sociétés et projets Open Source partout dans le monde : PHP lui-même a fait la migration de CVS vers SVN.

Actuellement, les gestionnaires de dépôts dits « décentralisés », par opposition aux gestionnaires traditionnels qui sont dits « centralisés », ont le vent en poupe. Leur fonctionnement local est le même, à la différence majeure qu'il n'y a pas de serveur central. Chaque client est également serveur et à ce titre s'organise avec les autres clients pour entretenir un code source unifié. La souplesse ainsi gagnée se fait au prix d'une plus grande intervention humaine dans le processus. Git est probablement l'outil le plus emblématique de ces gestionnaires. Il a été créé par Linus Torvalds, également créateur de Linux, et est utilisé pour gérer le code du noyau de ce dernier.

Mettre en place un dépôt de code est une étape cruciale dans un processus d'industrialisation de ses développements. On y vient pour des raisons de gestion quotidienne du code source, mais le VCS (Version Control System) va vite devenir la clé de voute de l'industrialisation : le code de l'entreprise est le code qui est dans le dépôt et nombre d'outils secondaires viennent y prendre le code : l'usine de code, les outils de tests, les administrateurs qui déploient le code.

PHP présente une richesse fonctionnelle incroyable : plus de 7000 fonctions documentées, des centaines d'extensions. Il s'adapte facilement aux diverses problématiques qu'on rencontre lors du développement d'applications Web. Il propose souvent plusieurs solutions pour le même problème. Et cette richesse a cependant un revers : elle peut rapidement se transformer en chaos si l'on n'y prête pas attention.

Initialement, PHP a été créé pour pouvoir mélanger au sein d'un même script du code de traitement, l'accès aux données et l'affichage HTML. Le code était confus, la structure peu claire et la maintenance compliquée. Aujourd'hui, la séparation du contrôleur, du template (ou gabarit) et du modèle, est une bonne pratique courante.

Et pour aller plus loin dans la structuration du code, les frameworks sont alors un passage obligé. Ils sont d'ailleurs nombreux et très dynamiques.

Les frameworks ont évolué pour répondre à différentes problématiques. Un framework fournit un ensemble de composants, d'outils et de conventions permettant le développement d'applications.

• Les composants sont livrés sous forme de bibliothèques et font gagner du temps en évitant de réinventer la roue. Les frameworks sont d'ailleurs généralement capables d'adopter des composants issus d'autres frameworks ;
• Les outils permettent de gagner du temps de mise en place, en créant rapidement des squelettes à compléter, ou en assurant la
• création directe de tests unitaires ;
• Les méthodes sont un ensemble de convention et d'organisations qui permettent d'assurer un bon niveau de sécurité et de maintenance, ainsi que l'homogénéité du code.

Les frameworks utilisent généralement la Programmation Orientée Objet de manière intensive, car ils exploitent les capacités de généricité et de réutilisabilité du modèle objet. Ce n'est toutefois pas une obligation.

PHP compte de très nombreux frameworks : plus de 400 à ce jour. Ils adoptent des philosophies différentes, parfois contradictoires, et parfois astucieusement réconciliées : MVC, strut, événementiel, Full stack, faible couplage, etc. Seule une poignée d'entre eux est en mesure de répondre aux besoins des entreprises pour développer des applications importantes.

Parmi eux, les deux plus connus sont Symfony et Zend Framework. Leurs modes de développement sont similaires. Ces deux frameworks sont développés et supportés par une société, respectivement Sensio Labs et Zend Technologies. Les deux frameworks bénéficient d'une communauté importante de développeurs bénévoles et professionnels.

Au niveau conceptuel, Symfony et Zend Framework sont basés sur le motif de conception MVC : Modèle-Vue-Contrôleur. Il s'agit d'un concept d'architecture logicielle qui prône la séparation stricte entre l'accès aux données, leur traitement et leur affichage. Au niveau technique en revanche les approches divergent. Symfony se positionne comme un framework intégré, qui encadre fortement le développement afin de permettre un développement rapide d'applications. Le Zend Framework se présente plus comme une bibliothèque de composants fortement découplés dans laquelle le développeur va pouvoir piocher.

Il faut noter que le développement de chacun de ces frameworks va dans le sens d'une rencontre entre les deux approches. Ainsi, Symfony découple de plus en plus ses composants tandis que Zend Framework propose de plus en plus de composants et d'outils de haut niveau.

Les frameworks aident véritablement les équipes de développement à structurer les projets. C'est particulièrement important pour les projets d'envergure. Le choix du framework est important, car il a des impacts forts sur l'organisation de l'équipe de développement, ou son acceptation.

Le choix du framework prend en compte différents aspects : sa maturité, la taille de sa communauté, l'offre de services autour du framework. Cet univers est très concurrentiel, car le web est en innovation permanente. Les codes vieillissent vite et s'encombrent parfois trop vite de fonctionnalités qui sont abandonnées.

Leur ouverture permet aussi d'envisager une utilisation des frameworks avant-gardiste : contribuer à un framework permet de mieux le comprendre et de l'intéresser à des sujets qu'il n'a pas toujours envisagé de traiter. Avec, à la clé, une diffusion très importante dans toute la communauté.

Les scripts PHP sont de simples fichiers de texte. Pour les créer un éditeur de base comme le BlocNotes de Windows suffit. Certains s'en contentent d'ailleurs, ou bien utilisent des outils légèrement plus avancés, comme Notepad++, qui apporte les premières fonctionnalités adaptées. On parle alors d'éditeurs de texte.

Mais pour être efficace, il faut bien plus que les fonctionnalités de base proposées par ces outils. Si un pilote de ligne peut manoeuvrer un avion en commandes manuelles, la tâche lui sera grandement facilitée par l'usage des systèmes modernes d'assistance. Il en va de même pour l'édition de PHP.

L'aide à la saisie, par exemple, permet de détecter des erreurs de syntaxe ou des coquilles dans les noms de variables très tôt et évite de passer par un processus d'erreur / débogage pour les corriger : autant de temps de gagné.

Pour répondre à des besoins de plus en plus avancés, les éditeurs de texte ont fait place à des IDE (Integrated Development Environment). Un IDE est un programme qui regroupe un ensemble d'outils pour le développement d'applications, avec, au minimum, un éditeur de texte et un débogueur.

Les IDE PHP proposent généralement les fonctionnalités suivantes :

• Colorisation syntaxique ;
• Autocomplétion ;
• Intégration aux dépôts de code ;
• Intégration avec un ou plusieurs frameworks ;
• Débogueur ;
• Profileur ;
• Intégration d'outils externes (Tests unitaires, déploiement, gestion de base de données, éditeur UML, etc.).

Dans le monde PHP, le débogage d'une application reste trop souvent artisanal. Les valeurs des variables sont affichées avec des fonctions placées judicieusement dans le code et une méthode dichotomique. Cette technique est fastidieuse et souvent peu efficace. Elle est largement réduite par l'utilisation de débogueurs. Ces derniers sont couramment utilisés dans d'autres langages comme Java ou C++, où la phase de compilation empêche la modification du code à des fins de tests. La pression pour l'utilisation de ces outils est donc beaucoup plus forte que dans le monde PHP.

Le débogueur permet d'exécuter pas à pas une application afin de s'assurer que le cheminement à travers le code est bien celui attendu. On peut à tout moment consulter le contenu de chaque variable. Il est possible de définir des points d'arrêt. Ce sont des endroits dans le code où le débogueur stoppera momentanément l'exécution de l'application afin de ne pas avoir à parcourir pas à pas l'ensemble du déroulement de l'application à partir de ce point, ou consulter le contenu des variables.

Parallèlement au déboguage dont la vocation est d'aider à diagnostiquer les bogues, il existe le profilage dont le but est de déterminer les endroits qui ralentissent l'exécution de l'application. Un profileur s'interface avec le coeur de PHP afin de recueillir des informations sur le comportement de chacun des éléments du code au cours de l'exécution.

Ainsi, on peut visualiser, généralement sous forme d'arbre, les éléments qui interviennent lors de l'exécution de l'application. Pour chacun, il est possible de savoir combien de fois il a été appelé, combien de temps il a fallu pour qu'il fasse son travail et éventuellement combien de mémoire il a utilisé. C'est extrêmement utile car l'expérience montre que les goulets d'étranglement ne sont pas toujours là où l'on pense.

Au delà des outils fournis en standard, les IDE sont souvent modulaires. Il est donc aisé d'en étendre les fonctionnalités à l'aide d'extensions libres ou commerciales.

Il est recommandé de définir un IDE de référence qui doit être utilisé pour tous les développements au sein de la société. Cela permet de standardiser les postes, de s'assurer que chacun peut travailler efficacement avec des outils conformes aux besoins et aux contraintes.

L'offre d'IDE PHP est très vaste et variée tant du côté des outils libres que commerciaux.

Au delà de ses fonctionnalités propres, un IDE est conçu pour s'intégrer au sein d'une usine de développement. Certains éditeurs comme Zend Technologies proposent des produits dont Zend Server et Zend Plateform qui s'interfacent avec Zend Studio et permettent d'optimiser des serveurs de production, de déboguer à distance et même de rejouer des incidents a posteriori.