Le choix des outils

Les meilleurs outils sont ceux que l'on maîtrise !

À moins qu'on ne vous les impose, vous aurez à choisir les outils les plus adaptés à votre travail.

Deux types d'outils sont nécessaires :

• d'une part, les éditeurs, qui vont vous permettre de réaliser vos schémas UML, de dessiner (puis de générer) votre base de données, de créer votre code, voire de gérer les versions ou la documentation ;
• d'autre part, les briques logicielles que vous allez utiliser pour éviter de tout avoir à réinventer.

Les éditeurs

Personnellement, je préfère utiliser les produits OpenSource. Ils ont toutefois parfois quelques inconvénients :

• leur richesse fonctionnelle n'est pas assurée : par exemple, ArgoUML a mis des années avant d'être capable de générer des diagrammes de séquence ;
• ils peuvent être instables, et ne pas supporter la montée en charge (là encore, j'ai eu pas mal de déboires avec les éditeurs UML) ;
• ils peuvent volontairement être limités : les sociétés qui les éditent sortent une version OpenSource limitée, à charge pour vous d'acheter les versions « professionnelles » si vous voulez plus de fonctionnalités ;
• ils peuvent disparaître, ou le développement peut s'arrêter, ou changer de licence en cours de route... Jusqu'à récemment, j'utilisais un éditeur UML dont la licence a changé pour les dernières versions livrées (abandon de l'OpenSource pour basculer en licence commerciale). J'ai donc abandonné l'outil pour un autre.

Néanmoins, certains sont des « best sellers » (si l'on peut dire!) dans leur domaine, comme Eclipse, qui a fini par devenir LA référence des éditeurs de code.

Voici les outils que j'utilise actuellement :

• pour les diagrammes UML : ARGOUML (http://argouml.tigris.org/) ;
• pour la conception des bases de données : SQL Power Architect (http://www.sqlpower.ca/page/architect), pas forcément très simple d'emploi, mais qui couvre l'essentiel des besoins ;
• pour le codage : ECLIPSE-PHP (http://projects.eclipse.org/projects/tools.pdt), avec les extensions DOXYGEN (http://www.stack.nl/~dimitri/doxygen/) si vous souhaitez générer la documentation, SMARTYPDT ( http://code.google.com/p/smartypdt/) pour colorier les syntaxes SMARTY dans les templates HTML, et bien sûr configuré pour intégrer le débogueur PHP inclus.

Il me manque un outil de gestion de version (je n'ai jamais pris le temps d'en chercher un sérieusement, mais c'est un tort).

Et bien sûr, LibreOffice pour tout ce qui est « rédactionnel » ou schémas variés (hors UML).

Les frameworks

Les frameworks, ou squelettes d'applications, évitent d'avoir tout à refaire à chaque application. Il en existe des dizaines ou centaines... Pour les choisir, attention aux effets de mode, ne vous attachez pas trop aux commentaires dithyrambiques, aux « panacées universelles » !

Voici quelques critères qui vous aideront à choisir :

• privilégiez les frameworks bâtis sur le modèle MVC (Modèle – vue – contrôleur). En gros, ça signifie que vous avez un point d'entrée unique dans votre application (une page « contrôleur »). Ce contrôleur va vous permettre d'appeler les différents modules, de gérer les droits d'accès, etc. L'affichage des pages HTML est en grande partie automatisé, vous ne devriez pas avoir besoin d'insérer des commandes « echo » dans votre code ;
• il existe en gros deux types de frameworks : ceux purement objets, qui copient le mécanisme de Java, et ceux qui autorisent des scripts procéduraux couplés avec des classes. Les premiers sont souvent plus formels et plus complexes à comprendre, les seconds plus aisés à manipuler. Là encore, il n'y a pas d'avantage majeur des uns ou des autres, c'est vraiment l'approche personnelle qui fait la différence ;
• vérifiez la manière dont la sécurité est gérée (c'est un des points principaux), et notamment :
  • comment s'identifient les personnes dans l'application ? Peut-on intégrer une identification basée sur un annuaire LDAP ? Peut-on utiliser un serveur CAS (Common Access Service) ?
  • Comment sont gérés les droits d'accès ? Peuvent-ils être stockés dans un conteneur externe (base de données des droits, annuaire ldap, etc.) ? La gestion des droits est-elle suffisamment riche par rapport à vos besoins ?
  • Quels sont les mécanismes de sécurité qui ont été implémentés :
    • pour protéger les personnes qui travaillent avec l'application (Cross-site scripting) ;
    • pour éviter l'injection de code SQL ;
    • pour éviter les requêtes transmises hors contexte (cross-site request forgery) ;
    • pour empêcher le détournement de session ;
    • etc.
• intéressez-vous également aux modes d'accès aux bases de données qui sont disponibles : PDO ne supporte pas toutes les bases de données, contrairement à AdoDB. De même, vous devez disposer d'un outil vous permettant de générer automatiquement les requêtes de lecture/écriture/suppression (également appelé pompeusement couplage relationnel-objet, ou ORM en anglais – Object Relational Mapping). Vérifiez qu'il correspond bien à ce que vous voulez faire ;
• le framework doit disposer d'un module permettant de générer le code HTML de façon simple, sans que vous ayez besoin d'insérer du code PHP au milieu de balises HTML (ou inversement). Il doit également vous proposer un mécanisme pour générer vos menus : vérifiez son fonctionnement et sa configuration ;
• il est judicieux que les modules que vous allez écrire puissent être déclarés à un endroit unique : ce sera bien plus simple à maintenir ;
• et puis, posez-vous des questions générales :
  • supporte-t-il les requêtes AJAX (c'est un mode où il faut inhiber l'affichage « classique » pour pouvoir renvoyer au navigateur uniquement les données demandées) ?
  • Est-il régulièrement mis à jour ? Existe-t-il une communauté active, et son évolution semble-t-elle cohérente ?
  • Est-il facile de prise en main ? Est-il performant (charger toutes les classes à chaque appel de page n'est pas forcément un signe d'optimisation) ?
• Etc.

Vous pourriez avoir la tentation de créer votre propre framework. Même si c'est ce que j'ai fait il y a quelques années (les frameworks étaient moins courants, et les fonctionnalités ne correspondaient pas alors à mes besoins), je vous le déconseille aujourd'hui. Au besoin, s'il manque une fonctionnalité dont vous auriez besoin, voyez si vous pouvez l'intégrer dans le framework vers lequel va votre préférence.

Les outils complémentaires

On en a vu quelques uns au travers des recommandations sur les frameworks. Ces outils vont vous permettre de gagner du temps dans le développement, pour éviter de réécrire ce qui a été fait par d'autres. Voici ceux que j'utilise actuellement :

• pour l'accès aux bases de données : ADODB (http://adodb.sourceforge.net/), qui encapsule la connexion et l'exécution des requêtes. Il supporte quasiment toutes les bases de données existantes, contrairement à PDO, qui ne gère que les bases de données les plus courantes ;
• pour l'encapsulation des requêtes vers les tables : OBJETBDD (http://objetbdd.sourceforge.net/). C'est une classe que j'ai créée il y a quelques années, alors que je ne trouvais rien qui corresponde à mes besoins. Cette classe s'appuie sur AdoDB ;
• pour l'affichage des pages HTML, SMARTY (http://www.smarty.net/), le moteur de templates le plus connu ;
• pour la génération de documents PDF : TCPDF (http://www.tcpdf.org/) ou, pour des cas simples, FPDF (http://www.fpdf.org/);
• pour générer des documents LibreOffice : ODTPHP (http://sourceforge.net/projects/odtphp/) pour créer des fichiers ODT à partir d'un modèle, et OpenOffice_Generation (http://membres.multimania.fr/tafelmak/index.html) pour créer des feuilles de calcul ;
• pour générer des diagrammes : PCHART (http://www.pchart.net/) ;
• pour la gestion des droits : PHPGACL (http://phpgacl.sourceforge.net/).

Vérifiez les licences d'utilisation. Lorsque je cherchais une classe pour générer des graphiques, la plupart de celles que j'avais trouvé avaient une licence qui ne me permettait pas de les utiliser en milieu professionnel sans verser une redevance.