I. Introduction

I-A. Remerciements

Je remercie toute l'équipe de Developpez ainsi que celle de Zend France, pour leur soutien et pour m'avoir donné l'occasion d'essayer ce logiciel.

I-B. Installation

L'installation se passe sans histoires. Zend Studio est développé en Java, ce qui le rend disponible pour tous les systèmes d'exploitation ayant une machine virtuelle Java.

Image non disponible
Installation de Zend Studio

Il est préférable d'installer la Zend Platform avec Zend Studio, si vous souhaitez profiter de ses capacités avancées de débogage. Pour pouvoir profiter de la Zend Platform en version 3, il faut avoir Zend Core 2... Pour ma part, j'ai utilisé les versions 2.0.3 de Core et 3.0.3 de Platform.

Image non disponible
Écran de connexion à Zend Core : tout fonctionne
Image non disponible
Écran de connexion à Zend Platform : tout fonctionne

Cependant, Zend Studio est fourni avec sa propre version de PHP, qui ne correspond peut-être pas à la version de votre machine de développement, en particulier le php.ini et les extensions disponibles... Il est donc nécessaire de modifier la configuration de Zend Studio afin qu'il utilise vos extensions habituelles. Pensez à activer les mêmes extensions que dans votre php.ini :

C:\Program Files\Zend\ZendStudio-5.5.0\bin\php5\php.ini
Sélectionnez
extension_dir=C:\PHP5\ext

Zend Core ne fournit pas les DLL pour toutes les extensions dont vous pourriez avoir besoin, car php.exe est parfois compilé pour inclure directement les extensions. Il vous faut donc avoir une distribution de PHP à part.

Il reste une petite chose à régler avant de commencer. Dans certaines versions, Zend Studio configure mal le plugin du navigateur Web. Dans mon cas par exemple, le chemin d'accès à Zend Studio était défini pour une version incorrecte de Studio, ce qui m'empêchait de lancer Studio depuis le bouton ajouté au navigateur par le plugin. Pour y remédier, il suffit d'aller dans Extra Stuff / Settings et de sélectionner le chemin adéquat :

Image non disponible
Modifier 'Zend Studio Path'

II. Gestion d'un projet

II-A. Création

Je vais prendre pour exemple le tutoriel de Rob AllenDébuter avec le ZF et l'utiliser comme un projet.

Voici les étapes de création d'un projet sous Zend Studio :
  1. Choisir le nom ;
  2. Sélectionner les répertoires à inclure ;
  3. Configurer le débogueur ;
  4. Configurer Java Bridge.
Image non disponible
Le nom du projet
Image non disponible
Les répertoires à inclure
Image non disponible
Le débogueur
Image non disponible
Java Bridge

Et voilà, votre projet est prêt ! Zend Studio va immédiatement parcourir votre code pour lire tous les scripts, afin de compléter sa base de données interne de variables, constantes, classes et prototypes de fonctions (vous pouvez demander à Zend Studio de rafraîchir ces informations en allant dans Tools / Rebuild Inspection Data). Il se peut que votre projet fonctionne mais que Zend Studio ne parvienne pas à trouver tous les scripts, auquel cas vous obtenez la boîte de dialogue suivante (que vous pouvez demander vous-même en allant dans Project / Check Included Files...) :

Image non disponible
Fichiers manquants

Cela n'empêche pas votre application de fonctionner, mais cela empêche peut-être Zend Studio de proposer une autocomplétion de votre code. Dans mon cas il n'en a rien été, car Studio connaît le Framework :

Image non disponible
Autocomplétion de code

II-B. Déploiement (FTP)

Une étape importante de tout projet est le déploiement en production, une fois tous les tests réussis.

Zend Studio peut se connecter à un serveur FTP en mode normal, en SFTP ou en FTP par SSH, ce qui permet au développeur de transférer ses scripts en toute confiance. De plus, le protocole FTP est intégré au gestionnaire de fichiers de Studio à tel point qu'il est possible de glisser-déposer des fichiers depuis un serveur FTP vers le système local de fichiers (et vice versa) ; il est également possible d'éditer direcement les fichiers en ligne, comme s'ils étaient en local.

Pour utiliser un serveur FTP, il suffit d'aller dans le menu File / Add FTP Server et de remplir les champs habituels (nom, adresse, utilisateur et mot de passe). Il apparaît alors dans le Gestionnaire de fichiers.

Image non disponible
Ajout d'un serveur FTP

Le déploiement de l'application consiste alors simplement à glisser/déposer le répertoie du projet (système local) vers le serveur FTP en utilisant le gestionnaire de fichiers interne à Zend Studio.

III. Outils de code

III-A. Débogage d'un script

III-A-1. Depuis Zend Studio (touche F5)

Afin de résoudre facilement les erreurs, et surtout afin de ne pas risquer de créer des ereurs en résolvant des problèmes, il est préférable de ne pas modifier le code du projet avant de savoir ce qu'il se passe. Utiliser print, echo, die et exit est une bonne solution pour un projet composé de quelques scripts, mais pour un projet de plusieurs dizaines de scripts cela devient impossible à gérer : on risque d'oublier du code destiné au débogage dans un script, d'oublier que l'on a mis certaines portions de code en commentaires, etc.

Le débogage est la solution à tous ces problèmes.

Avec le débogage, vous pouvez mettre des "points d'arrêt" dans votre code et ainsi exécuter les scripts petit à petit, en faisant des pauses que vous contrôlez, et tout cela sans modifier votre code un seul instant. Vous pouvez donc étudier le comportement de vos scripts sans en modifier le contenu et sans risquer d'oublier de rétablir le code qui fonctionne.

Zend Studio propose deux manières de déboguer le code : en interne ou avec un serveur distant. Nous allons utiliser la méthode la plus simple : en local.

Plaçons des points d'arrêt avant et après la première affectation des variables $config et $registry afin de voir comment fonctionne le débogage. Placer un point d'arrêt se fait simplement en cliquant dans la marge, sur le numéro de ligne. Zend Studio colore en rouge les lignes avec point d'arrêt :

Image non disponible
Les points d'arrêt dans le code
Image non disponible
Les points d'arrêt apparaissent dans la Debug Window

Le menu Debug / Go nous permet maintenant de voir ce qu'il se passe. Il est préférable d'afficher la Debug Window avant de commencer (image ci-dessus). Zend Studio commence le débogage et met en pause l'exécution du script à l'endroit du premier point d'arrêt. Dans la Debug Window, l'onglet Variables est maintenant rempli avec toutes les variables qui ont été affectées jusqu'ici : pour le moment, seules les variables automatiques de PHP sont présentes. Nous pouvons en examiner le contenu, ce qui est équivalent à utiliser var_dump au même endroit dans le code.

Continuons le débogage avec Debug / Go : Zend Studio fait une autre pause sur le second point d'arrêt. Une nouvelle variable est maintenant apparue dans l'onglet Variables de la Debug Window :

Image non disponible
Inspection de variable

L'intérêt du débogage par rapport à echo/var_dump est maintenant clair : cela facilite la lecture des données tout en épargnant le code de tout type de modification inutile. Mais ce n'est pas tout, car il est également possible de modifier une valeur depuis Zend Studio, pendant la session de débogage.

Image non disponible
Modification de valeur

Continuer le débogage nous montre que la variable $registry apparaît également dans la liste. Il est possible d'ajouter d'autres points d'arrêt avant de continuer, sans quoi la session de débogage s'arrêtera là. Positionnons le curseur de la souris après la dernière ligne de code du script :

 
Sélectionnez
$frontController->dispatch();

Le menu Debug / Go To Cursor permet d'avancer l'exécution du script jusqu'au curseur, ce qui est un bon moyen de palier le problème des points d'arrêt (efficaces uniquement sur les lignes de code).

Nous pouvons maintenant inspecter l'ensemble des variables du script avant que le front controller lance l'exécution du reste du script. Nous pouvons notamment voir quelle action, quel module et quel contrôleur sont déterminés dans $frontController->_request, ce qui permet par exemple de diagnostiquer les problèmes de réécriture d'URL, ou bien le corps de la réponse dans $frontController->_response->_body->default, ou encore les entêtes HTTP dans $frontController->_response->_headers par exemple. Tout ceci est spécifique au Zend Framework mais vous saisissez l'idée.

Le problème de ce type de débogage est qu'il ne prend pas en compte les paramètres que l'on peut vouloir envoyer à l'application... C'est l'environnement de Zend Studio avec son php.ini, sa configuration pour Apache, etc. C'est pour cette raison que Zend Studio propose un autre moyen de déclencher le débogage : depuis le navigateur Web.

III-A-2. Depuis le navigateur Web (plugin)

Zend Studio vous a proposé d'installer un plugin pour certains navigateurs Web, en particulier Internet Explorer et Firefox ont chacun le sien. Ce plugin vous permet d'initier une session de débogage depuis votre navigateur, ce qui vous permet d'analyser le comportement de vos scripts en situation réelle.

Conservons par exemple le curseur de la souris après la dernière ligne de code du script zf-tutorial/index.php et chargeons l'accueil du projet dans le navigateur. Rien ne se passe dans Zend Studio puisque nous n'avons rien demandé au plugin. Voici ce que propose le plugin de Firefox :

Image non disponible
On peut déboguer la page courante, la page suivante ou d'autres options

Si l'on demande de déboguer la page suivante, puis que l'on utilise l'un des liens de la page affichée dans le navigateur, alors Zend Studio lance une session de débogage et nous pouvons inspecter le code de la même manière que précédemment.

Image non disponible
Les paramètres de la requête du navigateur ont changé

III-B. Profiler un script

Profiler un script revient à étudier le temps d'exécution de chacun des appels de fonction dans chacun des scripts au cours de l'exécution globale. Le procesus se lance à partir du plugin dans le navigateur.

Le profiler donne les informations sous trois formes :
  • Diagramme du temps d'exécution des scripts impliqués ;
  • Diagramme des temps d'exécution des appels de méthodes ;
  • Arbre hiérarchique des appels de méthodes.
Image non disponible
Diagramme du temps d'exécution des scripts impliqués
Image non disponible
Diagramme des temps d'exécution des appels de méthodes
Image non disponible
Arbre hiérarchique des appels de méthodes

Bien entendu, le temps d'exécution dépend de trop nombreux paramètres pour être une information utile. Ici par exemple, 4 secondes est un temps bien trop long pour un script aussi simple : mon ordinateur est largement fautif et il ne faut pas tenir compte de cette information. En revanche, les pourcentages ne devraient pas trop varier entre deux exécutions du script.

Le profiler est un outil fondamental pour savoir où sont les goulots d'étranglement, au long de l'exécution d'un script. Il est primordial d'apprendre à se servir d'un profiler afin d'être en mesure d'optimiser ses scripts, surtout dans le cadre d'un gros projet.

III-C. Analyser le code du projet

Zend Studio dispose d'un analyseur de code source. C'est un autre moyen de traquer les problèmes éventuels. C'est une fois que les scripts fonctionnent que l'analyseur entre en jeu : il permet de déceler le code inutile, par exemple suite à un changement dans une portion de code il est possible d'oublier de supprimer une autre portion de code ou une variable devenue inutile. L'analyse est là pour cela.

Dans le tutoriel de Rob Allen, il semble par exemple que la variable $rows_affected appartienne à cette catégorie de variables obsolètes (et peut donc être supprimée) :

Image non disponible
Description des bugs

III-D. Documentation automatique

Documenter un projet est une tâche essentielle pour permettre aux autres développeurs d'utiliser le projet ou de le reprendre. Un projet non documenté a peu de chances d'être utilisé et moins encore d'être maintenu.

Zend Studio utilise phpDocumentor pour générer une documentation automatique à partir de commentaires situés dans le code source.

Image non disponible
Une nouvelle configuration pour ce projet
Image non disponible
Ajouter les fichiers et les répertoires hors de la racine du projet
Image non disponible
Choix du gabarit pour la documentation finale

phpDocumentor ne reconnaît pas pleinement la syntaxe PHP5, ce qui vous conduira sans doute à des erreurs lors de la génération de la documentation de vos projets récents. Zend Studio n'y peut malheureusement rien, mais si c'est un trop gand handicap pour vous je suis sûr que vous pouvez contribuer au projet phpDocumentor.

III-E. Gestion des versions (CVS, SVN)

Au cours du développement d'un projet, il est fréquent de modifier le code après avoir testé avec succès une fonctionnalité. Cela peut se faire au moyen de copies des dossiers, mais cette technique rend extrêmement difficile le suivi du code qui fontionne et impossible le suivi dès lors que plusieurs développeurs participent au projet.

La meilleure solution à ce problème est un gestionnaire de versions pour code source. Les outils les plus connus à ce sujet sont CVS (le plus ancien) et SVN (plus récent et plus mature). Des solutions propriétaires ont également vu le jour, par exemple MS Visual SourceSafe.

Il faut donc disposer d'un tel gestionnaire et configurer Zend Studio pour l'utiliser avec notre projet. Voici comment se passe la configuration d'un compte SVN :

Commençons par faire un checkout, ce qui prépare le répertoire sur le disque local :

Image non disponible
Connexion au serveur
Image non disponible
Checkout d'un répertoire depuis SVN

Si le checkout a fonctionné, le répertoire est préparé pour SVN. Sous Windows, il ressemble maintenant à ceci dans l'explorateur :

Image non disponible

Nous pouvons désormais utiliser Zend Studio pour mettre le repository à jour. Il faut d'abord ajouter (add) un à un les répertoires pour lesquels nous voulons contrôler les versions. Dans notre cas, nous allons tout contrôler excepté le Framework (sous le dossier "library").

Image non disponible
Les commandes sont maintenant accessibles

Ajouter les fichiers et dossiers permet à SVN de savoir ce qu'il doit contrôler. Il ne reste plus qu'à effectuer un commit pour envoyer tous les fichiers contrôlés vers le serveur SVN :

Image non disponible
Résultat du commit
Image non disponible
Tous les fichiers sont sur le serveur (visualisation avec Tortoise SVN)

IV. Outils de projet

IV-A. SQL

Zend Studio vous permet d'explorer vos bases de données et d'exécuter des requêtes depuis l'EDI. Cela vous épargne de devoir installer un outil externe si vous souhaitez effectuer des requêtes directement sur votre base de données, ce qui peut être utile pour le débogage.

Image non disponible
Navigateur de bases de données
Image non disponible
Exécution d'une requête

IV-B. Services Web

Zend Studio peut générer pour vous les fichiers WSDL de vos services Web.

V. Conclusion

Épilogue

Zend Studio est un excellent environnement de développement intégré. Il est très robuste, de très nombreux outils permettent de faciliter la navigation dans le code source, la prévention et la résolution des problèmes.

S'il faut lui trouver un défaut, ce sera probablement l'impossibilité de drag-and-drop de scripts depuis le système d'exploitation vers l'EDI, ou bien le peu d'informations fournies lors du déploiement de l'application (pas de barre de progression).

Liens