Not Just another technical weblog…

Un développeur a trouvé utile de décrire dans un article une liste de toutes les mauvaises pratique de développement qu’il connait…

Son article est assez complet et les présentes de façon humoristique. Il est toujours utile de se replonger a l’intérieur car même si certaines sont de pures abérations d’autres nous rappellent à l’ordre sur nos façon de faire habituelles. Une bonne remise en question pour progresser, à lire absolument!

Vous trouverez toutes ces informations ici: http://www.thc.org/root/phun/unmaintain.html

J’ai récemment trouvé deux articles en épurant mes différents abonnements RSS de cette fin d’année qui présentent l’utilisation de PHPUnit.

Cet outil permet de mettre en place des tests unitaires pour PHP de la même façon que JUnit pour Java. Ces tests, une fois développés permettent de garantir le fonctionnement de tout le code après chaque modification. En effet, ils sont écrits suite aux spécifications fonctionnelles et technique du produit et décrivent précisément tous les comportements attendus des objets PHP. Ils sont ensuite exécutés à chaque commit sur le système de versioning ou part un système d’intégration continu (Cruise Control, Trac Bitten, Hudson, …)

Ce genre de technique ne peut être mis en place que lorsque le développement est réalisé dans un cadre strict de génie logiciel (Design Patterns, Single Responsability, Interface Segregation, …). Julien Pauli, contributeur sur le site Développez.com a récemment écrit deux articles sur le sujet.

Le premier présente le concept de tests unitaires et son implémentation à travers PHPUnit, il est disponible à l’adresse http://julien-pauli.developpez.com/tutoriels/php/phpunit-tdd/. Il est très complet et m’a permis de bien appréhender l’utilité de ces tests pour la fiabilisation des applications web.

Le second est séparé en deux parties. Une introduction bien détaillée, expliquant les principes élémentaires du développement objet et du principe SOLID (ca ne fait jamais de mal de se refaire une petite lecture dessus). La deuxième partie est un exemple concret de mise en place de scripts de tests PHPUnit sur la fonctionnalité panier d’un site marchand. Cet article est disponible à l’adresse : http://julien-pauli.developpez.com/tutoriels/php/phpunit-avance/

Si comme moi vous êtes en quête d’amélioration de vos développements (utilisation du debugger xdebug, mise en place de tests unitaires, …), je vous conseille vivement la lecture de ces deux articles!

Pour répondre à cette question, je vais m’appuyer sur un article publié par Fabien Potencier sur le sujet: Templating Engines in PHP. Fabien Potencier est un membre très actif de la communauté symfony, il est aussi le PDG de la société Sensio à l’origine du projet.

Il décrit dans cette article les différentes raisons qui l’ont fait changer d’avis sur les templates PHP. En effet, aujourd’hui, j’utilise souvent PHP pour construire mon HTML rapidement sous la forme de templates simpliste (passage de variable par fonction extract puis utilisation dans un fichier HTML template).

Pour un développeur cette méthode fonctionne à merveille mais n’est pas très souple. Dès que l’on doit rajouter une nouvelle information, il faut repasser dans le HTML, le PHP, parfois le JavaScript pour réorganiser le tout… Rapide me direz-vous? Pas si on remet le template à sa place.

En effet le Template sert normalement à gérer l’affichage des données. En modèle MVC, il est utilisé dans les vues pour mettre en forme les données transmises par le contrôleur. Pour cette raison, un Web Designer peut conscient des technologies PHP doit pouvoir s’approprier facilement les Templates pour les modifier. Il ne devrait pas se soucier des données, de la forme, l’encodage, le découpage, la cesure et tout ce qui s’en suit…

Par rapport à se constat, PHP n’est pas un moteur de Template adapté pour être utilisé dans une équipe de création structurée et multi-compétences. Pour cela des moteurs de Template simples (attention à utiliser pas à réaliser) comme celui utilisé dans le FrameWork Django. Il en éxiste d’autres mais je trouve celui-ci vraiment souple et puissant par rapport à d’autres.

Il utilise une syntaxe et un interpréteur développer spécifiquement pour répondre à la besoin de la création de Templates. Il est possible d’utiliser des variables, de faire des boucles, des conditions booléennes de l’inclusion de fichier, des filtres sur les données (couper quand trop long, mise en minuscules/majscules…). La syntaxe très simple peut être utilisée par n’importe quel public technique non développeur (Monteur, Web Designer, …).

Un éventail des possibilités de ce moteur de template se trouve sur le site: http://www.biologeek.com/django,traduction,web-frameworks/le-langage-de-template-django-pour-les-auteurs-de-templates/

La documentation est accessible directement sur le site du projet Django: http://docs.djangoproject.com/en/dev/ref/templates/builtins/