2.1.1. Gestion autonome

Jusqu'à la première déclinaison commerciale (GSalon) de FPmanager en mai 2005, la planification du projet s'est caractérisée par son absence. En effet, la première phase du projet consistait à développer une base de code suffisamment dynamique et simple pour en permettre une extension rapide. L'auto-gestion temporelle a été motivée également par la volonté d'obtenir un produit dont l'entreprise serait elle-même première utilisatrice, donc agréable et adapté. Ceci nous a permis de développer deux modules complets en moins de 2 mois, et sans précipitation. Le premier module, "FPcontact", est le carnet d'adresses; le second, "GTFC", est chargé de gérer les communications. Tous deux ont été intégrés autour d'une base de code commune.

Dans le même temps, nous avons proposé et déployé un site intranet collaboratif, phpwiki, référençant les différentes ressources déployées autour du développement, et contenant toutes les informations utiles par module (tables SQL, types de fichiers définis par exemple). Il a été complété par la mise en place d'une interface de visualisation de l'état du système CVS, cvsweb, et d'une interface de gestion de bugs, flyspray.

La première commande effective a été acceptée avec une contrainte temporelle très importante: développer un système complet de gestion d'événements de type "salon", avec une version livrable en deux semaines. Les différentes tâches ont été définies et effectuées en séquence, sur tableau blanc. Dans ces conditions, leur archivage a été délibérément laissé au système de gestion de développement collaboratif (CVS). Cette période de surcharge a néanmoins accouché d'une mise en production dans les temps.

2.1.2. Gestion prévisionnelle

Forts de cette expérience la seconde commande, un système de vente en ligne, nous a permis d'évaluer dès le départ la charge de travail à venir. Un cahier des charges a été réalisé, et accompagné d'une planification complète répartie sur 2 mois. Malheureusement, elle n'a pas pu être honorée, pour plusieurs raisons. Les plus importantes sont les suivantes:

• factorisation du code à outrance: souhaitant réutiliser autant que code que possible, certaines fonctions (surtout l'affichage) sont devenues trop complexe à maintenir;

• formation d'un stagiaire: M. Hausser nous a rejoint au cours du développement, sa formation au système s'est révélée plus longue que souhaitée;

• communication client disproportionnée: elle s'est révélée insuffisante dans le premier projet majeur, puis trop influente dans le développement du second.

2.2.1. Tests internes

L'apport de la solution de gestion collaborative du développement (CVS) a été accompagné par une méthodologie d'utilisation. Les règles que j'ai proposées de respecter étaient:

• tous les changements doivent être documentés;

• aucune information liée au débogage, et non intégrée au système automatique de débogage en place, ne doit être laissée en place;

• aucun changement n'est appliqué à moins d'être totalement fonctionnel, et de ne pas provoquer de problèmes connus au moment de son application.

Tout au long du développement, des tests de vérification ont été menés manuellement par les développeurs. Cette méthode n'est malheureusement pas exhaustive, et parfois lourde temporellement, mais dans le cas d'un développement web il n'existe pas à ma connaissance de méthode automatisée. Ce manque a été compensé par le découpage et la méthode de développement. La cohérence de la base de données a été assurée par l'utilisation de contraintes d'intégrité. L'affichage optionnel d'informations liées au développement a également facilité cette tâche. En voici un exemple:

Info: module "commerce", action "account"
Info: Array
(
    [user_id] => 2
    [user_name] => ppronchery
    [user_admin] => 1
    [user_export] => 0
    [basket] => Array
        (
        )
)
Info: SELECT fp_commerce_option_value.name,
fp_commerce_product_category.product_category_id AS category_id,
fp_commerce_option_value.option_value_id
FROM fp_commerce_product_category
LEFT JOIN fp_commerce_option_category ON
fp_commerce_product_category.product_category_id
=fp_commerce_option_category.product_category_id
LEFT JOIN fp_commerce_option ON
fp_commerce_option_category.option_id=fp_commerce_option.option_id
LEFT JOIN fp_commerce_option_value ON fp_commerce_option.option_id
=fp_commerce_option_value.option_id WHERE
fp_commerce_product_category.name='accessoire' AND
fp_commerce_option.name='type' ORDER BY name ASC
Info: SQL execution time: 0s and 2.682ms
Info: Page execution time: 0s and 61.718ms
				

2.2.2. Communication client

Toute la communication liée aux projets et sortant du cadre de l'entreprise a été effectuée par M. Perrin, afin d'en assurer la cohésion. Elle a malheureusement soulevé de nombreux problèmes, expliquant partiellement le retard de la solution de vente.

En effet, le développement éclair de la solution de gestion de salons n'a pas immédiatement satisfait le client, ses besoins n'ayant certainement pas été suffisamment définis au moment de la commande. Les ajustements survenus ont pénalisé le projet lui succédant.

Ayant pris en compte ce problème, l'avancée du développement de la solution de vente en ligne a été suivie étroitement avec le client. Ceci a donné lieu à des changements de direction multiples, de nouveaux concepts ayant été pensés au fur et à mesure de la validation. Ils ont pénalisé l'avancée de la tâche de développement.

3.1.1. Décisions techniques

Les choix les plus importants sont le langage de programmation et la plate-forme d'hébergement. Le couple PHP/MySQL a été choisi car il était déjà en place sur de nombreux sites de l'entreprise, et maitrisé par l'équipe en place. L'hébergement sur serveur mutualisé FreeBSD a été choisi pour des raisons de coût et de liberté d'administration. Les ressources processus y étant limitées, il n'était pas envisageable de déployer de service supplémentaire. Cependant, le développement a été pensé afin de ne pas totalement contrarier les possibilités de migration vers un autre système de gestion de base de données: la version initiale de FPcontact fonctionnait indifféremment avec PostgreSQL ou MySQL.

Par ailleurs, le choix des logiciels libres était justifié par des raisons de coût (pas de licenses commerciales), de stabilité, et de clarté d'utilisation en développement. Ils étaient également déjà en place avant mon arrivée dans l'entreprise. Seuls les logiciels liés au graphisme étaient propriétaires, car leurs technologies ont été exigées par certains clients.

3.1.2. Conventions de développement

Ma courte expérience préalable de développement, après discussions avec l'équipe, m'a conduit à imposer certaines règles de développement. L'objectif étant la clarté et la simplicité du code produit, il a été décidé de:

• rédiger intégralement le code en anglais (inclus les journaux CVS et la base de données), afin de garantir une cohérence avec les langages utilisés, et dans le code rédigé;

• formatter le code intégralement avec les mêmes conventions, à savoir "1 ligne est une instruction", les signes délimitant les blocs de code ("{" et "}") sont seuls sur leur ligne, et le placement est celui défini par défaut dans le logiciel "vim";

• écrire le code de sorte à éviter d'avoir recours aux commentaires, en le segmentant en fonctions courtes (25 lignes maximum si possible), et en nommant les variables de façon aussi intelligible que possible.

3.1.3. Structure du code

Dés le départ, le développement a été pensé de sorte à simplifier au maximum le processus de développement, sans en sacrifier ses possibilités. Ceci a d'abord donné lieu à la création d'un moteur minimal de gestion de modules, "engine.php", inclus en Annexe A. Le code redondant sans être indispensable au fonctionnement du moteur a été placé à part, pour intégration au besoin (répertoire "system").

En effet, chaque fonctionnalité majeure a fait l'objet d'une séparation distincte de son code en "modules". Un module est chargé au besoin, par l'utilisateur directement ou par un autre module. Chaque module dispose d'un certain nombre de points d'entrées, ses fonctions nommées "module_action". L'action "default" est celle appelée par défaut. L'action "system" est appelée automatiquement avant toute chose par le moteur, si elle existe et si le module a été appelé directement par l'utilisateur. Elle permet l'altération du comportement par défaut du moteur, pour forcer une redirection, ou effectuer une sortie PDF par exemple.

Ainsi, chaque action logique de la part de l'utilisateur, et chaque présentation de l'information a été réalisée dans une fonction séparée, automatiquement exportée par le système de gestion de modules. Bien sûr, il a été pris soin de ne pas exposer d'autres fonctions par ce système.

Tout le code de rendu HTML a été placé dans des fichiers séparés, nommés avec l'extension ".tpl" pour "templates". Le code PHP présent dans ces fichiers a été limité autant que possible à l'affichage de variables, avec d'éventuelles boucles ou conditions.

Ce choix de fonctionnement m'a semblé évident, d'abord par mon expérience personnelle de développement en PHP (adaptations de PHP-Nuke), par ma culture du développement objet, ainsi que mes notions de développement système (C et interpréteurs). En effet, chaque module ici regroupe un ensemble de méthodes par fonctionnalités, sans s'encombrer des contraintes d'un système purement objet. Ce choix a été accompagné en conséquence de toute la rigueur possible, conscients de l'absence de ce contrôle supplémentaire.

De plus, la fonction PHP "call_user_func_array()", essentielle dans ce type de fonctionnement, nous a semblé suffisamment performante. Elle effectue une recherche dans la liste des fonctions définies par l'utilisateur, et appelle directement la fonction correspondante avec les arguments voulus. Il s'agit d'une facilité analogue à dlopen()/dlsym() en C, permettant la recherche de fonctions à l'intérieur même d'un programme en cours d'exécution.

3.1.4. Portabilité

La flexibilité de l'environnement d'exécution du code a déjà été définie, et délimitée à une solution précise. La portabilité ciblée ici est donc uniquement du côté du client: il faut que le projet soit utilisable quel que soit son environnement. L'interface a donc été testée tout au long du développement sur les trois navigateurs les plus courants: Internet Explorer, Mozilla, et Opera. Le navigateur de référence choisi est Mozilla, pour sa disponibilité sur Debian et FreeBSD, sa documentation et sa fidélité aux standards. Nous n'avions malheureusement pas accès à Safari (Mac OS X), mais des vérifications régulières avec Konqueror (son moteur web étant proche de celui de Safari) nous ont permis de maintenir son utilisation fonctionnelle.

L'utilisation de la norme XHTML 1.1 pour l'interface a facilité le développement du système. En effet, le code généré n'est qu'un formatage organisé des données à afficher. C'est le système de feuilles de styles CSS, accompagnant les pages, qui détermine l'aspect du site. Si son support est optimal dans Mozilla et Opera, il n'en est pas de même pour Internet Explorer. Deux exemples nous ont particulièrement posé problème: un affichage tabulaire composé d'enchainements d'élements "div", ainsi qu'un système de menu horizontal, avec auto-affichage par le passage de la souris.

<form name="explorer_n" class="explorer"> [a]
    <input type="hidden" name="nom" value="valeur"/> [b]
    <div id="explorer_n" class="listing_default"> [c]
        <div class="toolbar">Contenu de la barre
        d'outils</div> [d]
        <div class="header">
            <div class="icon"></div>
            <div class="name">Nom</div>
            <div class="colonne_suivante">En-tête de colonne</div>
        </div>
        <div class="entry">
            <input style="display: none" type="checkbox"
            name="entry_i"/> [e]
            <div class="icon">Image pour l'icône</div>
            <div class="thumbnail">Image pour la vignette</div>
            <div class="name">Nom</div>
            <div class="colonne_suivante">Contenu de la colonne</div>
        </div>
        <div style="clear: left">&nbsp;</div> [f]
    </div>
</form>
					

3.2.1. GTFC

GTFC signifie "Gestion Téléphone Fax Communications". Il s'agit d'un module permettant la gestion quotidienne des appels entrants, et permettant également l'envoi de message entre utilisateurs. Chaque événement donne lieu à l'émission d'un message par courrier électronique, adressé à la personne concernée.

Ce module a constitué la première occasion de tester l'interaction entre modules. Celle-ci a d'abord été considérée comme un succès, l'ajout de peu de code ayant été nécessaire à FPcontact pour l'intégration totale avec le carnet d'adresses. Un premier problème majeur a été soulevé cependant, avec l'emploi d'un groupe de contacts, "GTFC", afin de définir les membres susceptibles d'être concernés par les communications gérées par ce module. En effet ce groupe est retrouvé par son nom, ce qui est peu efficace. Mais surtout, il est modifiable et supprimable par tout utilisateur potentiel de l'interface. Ceci peut en empêcher le bon fonctionnement, sans frein à l'utilisateur. Le compromis de souplesse et d'élégance a été considéré initialement satisfaisant, et maintenu à ce jour.

Par la suite, l'interaction entre modules a mené à des problèmes parfois sévères. Ils sont abordés dans les modules décrits ci-après. D'autre part, le type de solution apporté aux contacts dits "GTFC" a été reproduit, sans souci particulier.

3.2.2. GSalon

GSalon est le module de gestion d'événements de type "salon". Il étend le système de carnet d'adresses en y ajoutant des catégories d'exposants et de visiteurs, qui peuvent être liés à une instance de salon particulière. Leur consultation est facilitée par l'ajout d'un système de filtrage, générant automatiquement les formulaires et requêtes SQL associées. Les critères de filtrage ont une base commune, et sont étendus aux champs d'éventuels questionnaires présentés lors de l'inscription d'un visiteur.

L'inscription des exposants est également gérée, et bénéficie d'une étape de confirmation à l'attention de l'administrateur du salon.

C'est après avoir développé ce module que nous avons rencontré les premiers problèmes liés à la réutilisation de code. En effet, le client a demandé des modifications parfois profondes du système pendant sa maintenance. Celles-ci se sont révélées pénibles à réaliser car le code était devenu tentaculaire lors des opérations d'affichages. Elles ont vu leur liste de paramètres gonfler, afin de gérer différents titres, barres d'outils, et directions de liens entre autres. Après réflexion, il aurait été intéressant de décliner ces opérations dans certains cas, afin de conserver le code général simple.

3.2.3. mon-cafe.com

($count * $month) % 12 < $count ? 1 : 0
					

($count * (12 - (($month + $initial_month) % 12))) % 12 < $count ? 1 : 0