Le manifeste du développeur Liferay

Ou comment m’est venue l’idée de rédiger sous forme d’un manifeste des principes d’utilisation d’un portail Liferay dans un contexte de génération de site Web International.

Pourquoi rédiger un manifeste du développeur Liferay ?

Lors d’une de mes récentes mission j’ai été amené à définir des règles afin d‘industrialiser de bout en bout la mise en œuvre d’un portail Liferay dans un contexte de génération de site Web international.

La problématique fonctionnelle de la génération de site est par expérience une problématique complexe à gérer et surtout à expliquer. En effet pour que l’entreprise soit un succès il est primordial de définir un cadre d’implémentation technique certes stricte mais également pour le client d’adopter la bonne organisation projet.

Les principales problématiques liées à ce domaine que l’on peut citer sont :

  • Comment livrer une application sur un environnement mutualisé en limitant les impacts sur les sites déjà en production ?
  • Comment encadrer les développements pour garantir un niveau de performances acceptable pour tous ?
  • Comment assurer que les développements puissent être migrés ?
  • Comment expliquer cette nécessité à des décideurs sans entrer dans la complexité technique ?
  • Comment contenir le volume des écrits afin de limiter le coût tout maximisant la valeur des documents ?
  • Etc …

A mon sens pour augmenter la valeur utile d’un document il est nécessaire d’arriver à concentrer sur peu de volume un maximum d’informations. La méthodologie Agile à répondu à ce problème en définissant des principes regroupés au sein d’un manifeste.

Ce document est bien entendu une ébauche dont je vous propose le détail ci-après

Les principes du manifeste

I. ISOLATION : « Développement plutôt que modification du produit »

Même si Liferay est un outil prévu pour être adapté, nous privilégierons toujours le recours au développements spécifiques réutilisables plutôt que la modification du noyau du produit.
Dans cet esprit le recours aux plugins de type hook et ext sera minimisé.

 

II. STANDARDISATION : « Réutiliser pour maximiser l’efficacité »

Chaque applicatif devra être en mesure de suivre le plus simplement possible les évolutions du produit (montées de version). Dans cette optique la réutilisation de l’existant sera toujours privilégiée par rapport à la réalisation de développements spécifiques.

 

III. SÉCURITÉ: « Implémenter les bonnes pratiques de sécurité dès le départ »

Chaque application garantira elle-même la sécurité d’accès à ses données par le déploiement des outils standards proposés par le produit (Resource Bundle, Permission, Rôles).

Les droits d’accès seront contrôlés systématiquement au niveau des couches hautes (vue) ET basses (service remote) cela même si le service n’est pas utilisé de manière distante.

 

III. AUTOMATISATION : « Automatiser pour garantir la qualité »

Chacun contribuera au développement et à la maintenance d’outils communs de déploiement.

Chacun s’attachera à identifier au plus tôt les tâches pouvant être automatisées au niveau du socle et à commander à l’avance des évolutions des outils concernés plutôt que le développement de mécanismes spécifiques.

 

V. INTERNATIONALISATION : « Déployer les outils de gestion multilingue dès le départ »

Appliquez vous dès le départ à fournir des applications gérant plusieurs langues. L’anglais sera utilisé comme langue par défaut.
La réalisation de cet objectif s’appuiera sur les mécanismes standards fournis par l’outil et sur les règles de développement associées (traduction des libellés et des contenus notamment).

 

VI. DOCUMENTATION : « Tout le code est auto-documenté »

L’utilisation des commentaires et de la Javadoc sont privilégiés comme pratiques en matière de documentation technique des API. La mise à jour de la documentation fait partie intégrante de la tâche de développement.

Les commentaires positionnés dans l’implémentation elle-même sont à destination des développeurs. L’utilisation de variables, méthodes et de classes avec des noms clairs couplés à l’utilisation des commentaires garantissent la réalisation de cet objectif.

La Javadoc est à destination des utilisateurs de l’API. Pour eux les détails de l’implémentation ne sont pas visibles. Ces commentaires sont utilisés pour décrire les règles d’utilisation de l’API  (résultat attendu, exceptions levées, signification des paramètres d’entré etc …).

Consultant JAVA / JEE

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !