Premier projet Web, ça marche !

Nous sortons de quelques semaines intenses où nous avons accompagnés un nouveau client, un éditeur de logiciel  qui souhaite développer un nouveau produit avec notre technologie.

L'équipe de développement est composé de 3 personnes experts sur leur domaine métier ; ils n'ont pas d'expériences dans les technologies Microsoft, ils ont précédemment travaillé avec un AGL propriétaire et en PHP/ Flash pour quelques projets. C'est donc, en partant de zéro sur l'univers Microsoft que nous avons accompagné l'équipe dans le développement de son application avec notre approche et nos outils.

Nous avons dispensé 8 jours de formation: 5 jours sur la plate-forme .Net, et 3 jours sur Aspectize. Avec le recul, sans doute 1 ou 2 jours supplémentaires n'auraient pas été inutiles sur la plate-forme Aspectize. Notre solution est suffisamment riche en fonctionnalités et son originalité méritent bien un cursus de 5 jours. Certains concepts méritent d'être répétés, et détaillés sur des exemples simples pour bien les utiliser dans le projet.

Deux exemples en particulier:

• La logique des échanges entre client et server est totalement nouvelle, et n'a pas d'équivalent dans une architecture web classique. L'état, matérialisé par les données, est maintenu côté client dans le navigateur, et seules les données sont échangées entre client et serveur. Cette logique a un impact sur le fonctionnement de l'application, et permet d'obtenir un comportement et une fluidité qu'il était très difficile, voire impossible, d'obtenir auparavant. Elle ouvre de nouvelles perspectives applicatives, et évitent certains écueils classiques (comme la perte des données d'un formulaire en cours de saisie par exemple). Néanmoins, il est important de bien comprendre cette logique pour en tirer partie, et éviter des allers & retours inutiles et couteux entre le client et le serveur.
• La logique déclarative du binding relationnel, a un pouvoir expressif très puissant pour décrire le fonctionnement de l'IHM. Le "DataName" associé à des contrôles est simple à définir (1 clic de souris suffit), et permet d'afficher les données filtrées et synchronisées entre plusieurs formulaires. Comme tout ce qui est nouveau, ce n'est pas toujours immédiat et il y a quelques bonnes pratiques à mettre en œuvre pour configurer correctement.

Evidemment, ce projet est aussi pour nous, une mise à l'eau de notre produit, dans un environnement autre que le notre. Cela permet évidemment de déceler et corriger certains dysfonctionnements (l'intégration avec le contrôleur de source ou certains bugs de notre moteur javascript), et en même temps d'intégrer des bonnes idées de fonctionnalités pour  augmenter le confort du développeur. Nous avons pu ainsi apporter des nouveautés comme une meilleure gestion du Layout, pour obtenir un rendu plus rapidement, et des nouveaux contrôles bindable (DateTimePicker, CheckBoxList).

Alors, qu'est ce que nous pouvons tirer comme conclusion de cette première expérience d'un projet Web ?

Comme cette appréciation pourrait être sujette à interprétation subjective, nous avons mesuré quelques critères significatifs.

La charge de travail est de 70 jours répartis entre les 3 développeurs.

Le Schéma est constitué de 47 entités (38 Entités et 9 Enum) et 86 relations ! Cela peut sembler étrange, mais l'importance des relations est fondamentale dans la logique fonctionnelle de l'application. C'est dans la définition même de ces relations que sont définies une grande partie des règles de gestion de l'Application. Là où un code fastidieux aurait été nécessaire, le schéma permet de modéliser l'essentiel, de façon déclarative et graphique. Au niveau physique, la base SQL Server contient 53 tables (ce qui donne une idée de l'importance du projet).

L'interface utilisateur comprends 225 vues configurées. Chaque vue configurée est un UserControl, qui constitue un morceau de page Web, qui sont imbriquées les unes dans les autres. Au sein de ces UserControl, il y a 629 Contrôles configurés (TextBox, CheckBox, Button, Grille, Arbre ...) ce qui correspond à 862 DataBinding (pour l'affichage/édition de données), et 578 CommandBinding (pour l'appel d'un Service). Il faut bien comprendre qu'un Binding se fait en quelques secondes (2 ou 3 clics de souris, aucune saisie d'information clavier), là où l'équivalent en code classique nécessiterait des heures de développement et de tests.

Et justement, le code écrit - car il y en a - que représente t il ?

• 1 240 lignes de C#
• 735 lignes de JavaScript
• 1 294 lignes de CSS (les développeurs maitrisent le CSS, et ont fait un travail très soigné sur le design de l'application)

Ce volume de code est extrêmement faible compte tenu de la richesse et de la complexité de l'application (c'est le nombre de lignes tel qu'il apparait dans l'IDE Visual Studio, c'est à dire qu'il inclut les lignes blanches, les { }, les using et autres verbosité du code, et donc que le nombre de ligne réellement utile qui a nécessité des neurones de développeur est évidemment beaucoup moins). Et bien sur, 0 lignes de SQL, 0 lignes de code technique, pas de manipulation de contrôles, pas d'abonnement, pas de code de gestion d'erreurs, pas de code de gestion de la sécurité, pas de manipulation de DOM ou autre considération technique ! L'ensemble du code est essentiellement le chargement des données, et quelques règles métiers (transformations de données, validation); c'est un code simple, lisible, qui manipule les données du Schéma, a très peu d'imbrications, et est directement lié avec le fonctionnel de l'application.

Juste pour voir, s'il y a un développement .Net d'un projet comparable pas loin de vous, combien y a-t-il de lignes de code ? vous serez surpris de l'étendu du score, et vous comprendrez mieux pourquoi cela prend autant de temps et pourquoi il y a autant de problèmes.

Et il s'agit d'un progiciel, d'une application métier, sécurisée, multilingue, full-ajax, destinée à être utilisée chez des Grands Comptes, avec toutes les contraintes d'un Système d'Informations d'entreprise ! Evidemment, tout n'est pas fini à l'heure actuelle, mais l'application fonctionne en permanence, et les nouveaux Use Case sont implémentés tous les jours.

Enfin, au delà du volume de code, il y a notre appréciation personnelle, qui n'est pas mesurable, mais qui a réellement fonctionné, à savoir l'agilité colossale du projet. On modélise, on configure, on constate, on ajuste; le cycle de développement d'une heure est une réalité. Cela permet une agilité étonnante, sans doute jamais atteinte dans un développement spécifique. A plusieurs reprises, des changements de modèles ont eu lieu; s'ils sont structurants sur le plan fonctionnel, ils ne le sont pas au niveau de développement. Là où des modifications auraient eu un coût important, voir prohibitif sur le projet, tous les changements sont permis. L'IHM et la navigation entre les différentes pages a été plusieurs fois revues, sans aucune difficultés.

Le développement est complètement linéaire. Il n'y a aucun poids de l'existant sur les développements des nouvelles fonctionnalités.

Le développeur est beaucoup plus proche du fonctionnel; le schéma graphique permet de structurer le modèle de l'application, et de mieux partager la logique applicative. Les niveaux de discussions sont essentiellement fonctionnels, il n'y pas de débat technique car toute la tuyauterie technique est issue du produit. Enfin, il n'y a aucun bug technique dans l'implémentation du projet. La qualité du développement est là, constante sur l'ensemble de l'application.

En conclusion, c'est un progrès considérable de développer et concevoir une application complexe, en si peu de temps, et avec si peu de code (là où nous envisagions de diviser le volume de code par 10, nous allons plutôt considérer un facteur 50 !) ; et comme nous le faisions remarquer en cours de projet, s'il est arrivé parfois que la voiture tombe en panne, pour cause de quelques bugs techniques, et que nous devions la pousser sur quelques mètres, nous sommes arrivés à bon port, et c'est beaucoup plus rapide, plus confortable et nettement moins fatiguant que la charrette !