Les fondations d’un projet Talend : principes, lignes directrices et conventions

« Quelle est la meilleure façon d’écrire ce job ? » Tous les développeurs Talend se posent la question, du débutant au plus expérimenté. Studio laisse une grande liberté : le canevas accepte n’importe quelle disposition, chaque composant a des dizaines d’options, et deux développeurs résolvent rarement le même problème de la même façon. Sur un projet d’équipe, cette liberté devient vite un coût. Les jobs ne se ressemblent pas, la relecture est lente et chaque reprise oblige à redécouvrir les choix de l’auteur.

Avant de parler de composants, il faut donc s’entendre sur des règles communes. C’est le point de départ de la série de Dale Anderson.

Cet article synthétise et adapte à Talend Studio 8 les parties 1 et 2 de « Talend Job Design Patterns and Best Practices » de Dale Anderson (Talend, 2015-2016). Ses conseils restent des références : nous les relisons avec les outils d’aujourd’hui.

Des principes à arbitrer

Dale Anderson part de treize principes qu’un bon job devrait respecter : lisibilité, rapidité d’écriture, maintenabilité, fonctionnalité, réutilisabilité, conformité, souplesse, évolutivité, cohérence, efficacité, cloisonnement, économie de code et performance. Aucun n’est nouveau. Leur intérêt est de rappeler qu’ils se contredisent.

Un triangle relie trois principes : lisibilité en haut, rapidité d’écriture en bas à gauche, maintenabilité en bas à droite ; au centre, le mot arbitrer. À droite, une carte liste les dix autres principes : fonctionnalité, réutilisabilité, conformité, souplesse, évolutivité, cohérence, efficacité, cloisonnement, économie de code et performance.

Les trois premiers principes se disputent : en tenir deux est facile, le troisième demande un choix.

Les trois premiers en sont l’exemple le plus net. Un job écrit vite est rarement le plus lisible ; un job très découpé, donc facile à maintenir, demande plus de temps à écrire. On en obtient facilement deux, le troisième se négocie. L’exercice que propose l’auteur est utile en équipe : classer ces principes par ordre d’importance pour votre projet. Le classement d’un flux temps réel ne sera pas celui d’un chargement nocturne d’entrepôt, et c’est précisément ce qu’il faut expliciter.

Des lignes directrices, pas des normes

Deux écueils guettent une équipe. Le premier est la norme rigide, qui ne prévoit pas les cas particuliers et finit contournée. Le second est l’absence de règles, où chaque développeur fait à sa manière. Dale Anderson défend une voie médiane : un document de lignes directrices de développement, adopté par toute l’équipe, qui fixe des repères sans tout figer.

Il en propose un plan en trois volets :

les méthodes, c’est-à-dire comment construire : modélisation des données, cycle de développement (cycle en V ou agile), gestion des exigences, traitement des erreurs et audit, gouvernance des données ;
les technologies, c’est-à-dire avec quels outils : infrastructure, bases de données, chiffrement, services web, systèmes externes ;
les bonnes pratiques, c’est-à-dire quoi faire et quand : environnements, conventions de nommage, journalisation, codes retour, contextes, mise en page des jobs, parallélisme, gestion des versions, tests, déploiement, sécurité et planification.

Trois documents complètent utilement ce guide : un catalogue des modules réutilisables (joblets, routines, groupes de contextes), un dictionnaire des données et une description de la couche d’accès aux données. Le tout doit rester court et à jour : un guide de dix pages que tout le monde lit vaut mieux qu’un manifeste que personne n’ouvre.

De bonnes habitudes, une à la fois

Plutôt que d’imposer toutes les règles d’un coup, l’auteur recommande d’installer les habitudes une par une. On commence par la plus simple : donner un libellé à chaque composant. Un tMap_3 ne dit rien ; « Calculer la remise » dit tout. Une fois ce réflexe acquis, on passe au rangement des jobs dans des dossiers parlants, puis à un format de message de log commun, et ainsi de suite.

Un raccourci utile aujourd’hui : la documentation de Qlik Talend publie un guide de conventions de nommage (Object Naming Conventions) et un guide de bonnes pratiques du cycle de développement. Ils fournissent une base à adapter plutôt qu’à réinventer.

Ranger le référentiel

Le panneau Référentiel de Studio (Repository) contient tous les objets du projet. Il mérite le même soin que le code. Dale Anderson insiste sur trois rubriques qu’on néglige trop souvent :

les groupes de contextes, à créer dans le référentiel plutôt que dans chaque job, pour les réutiliser partout. Nous y revenons dans l’article sur les contextes ;
les métadonnées : connexions aux bases, structures de fichiers et schémas génériques, à définir une fois et à réutiliser ;
la documentation : Studio génère une documentation HTML du projet en quelques minutes. Publiez-la à l’équipe une fois le travail terminé.

Le préfixe dit ce qu’est l’objet ; le dossier numéroté dit où il se place dans le traitement.

Pour les noms, la règle d’or est la constance. Notre exemple reprend les préfixes que suggère le guide de cycle de développement de Qlik Talend (job_, test_, task_) et les complète pour les joblets, contextes, métadonnées et routines. Dale Anderson propose par exemple md_ pour les métadonnées : par défaut, Studio les nomme toutes « metadata », ce qui rend le code illisible. Numéroter les dossiers (00_, 10_, 20_) les classe dans l’ordre du traitement plutôt que dans l’ordre alphabétique.

Un détail compte plus qu’il n’y paraît : le nom d’un job devient le nom d’une classe Java dans le code généré. Évitez espaces et caractères accentués, et restez court.

Ce qui a changé depuis 2016

Talend Open Studio n’est plus distribué depuis 2024 : la série s’adresse aujourd’hui aux utilisateurs de Talend Studio 8, avec Qlik Talend Cloud ou Talend Administration Center.
Le guide de cycle de développement de Qlik Talend fixe désormais un repère chiffré : éviter plus de vingt composants par job, et confier l’orchestration à un job parent. C’est l’objet de l’article suivant.
Les versions internes d’un job (numéros majeur et mineur) ne remplacent pas Git. Nous en parlons dans l’article sur l’industrialisation.

À retenir

Arbitrer, pas maximiser. Lisibilité, rapidité d’écriture et maintenabilité se contredisent : décidez en équipe ce qui prime.
Des lignes directrices, pas des normes. Un guide court, adopté par tous, qui laisse de la place aux cas particuliers.
Une habitude à la fois. Commencez par un libellé sur chaque composant.
Un préfixe par type d’objet. job_, jl_, ctx_, md_, rt_ : le nom dit ce qu’est l’objet.
Un référentiel rangé. Dossiers numérotés, contextes et métadonnées partagés, documentation publiée.
La constance d’abord. Une convention imparfaite suivie par tous vaut mieux qu’une convention parfaite ignorée.

Essayer dans Talend Studio

Un exercice de dix minutes, dans un projet de test :

Dans le référentiel, sous Job Designs, créez les dossiers 00_orchestration, 10_extraction et 20_chargement.
Dans 10_extraction, créez un job job_extr_demo : un tRowGenerator qui produit dix lignes, relié à un tLogRow.
Donnez un libellé à chaque composant : sélectionnez-le, onglet Vue (View), champ Format du libellé (Label format). Par exemple « Générer 10 clients » et « Afficher ».
Exécutez le job, puis ouvrez l’onglet Code : le nom du job est devenu une classe Java.
Faites un clic droit sur le job et choisissez Generate Doc As HTML : la documentation produite reprend vos libellés.

Sources

Dale Anderson, Talend Job Design Patterns and Best Practices, partie 1 et partie 2, Talend (version archivée).
Aide Qlik Talend : Object Naming Conventions et Software Development Lifecycle Best Practices Guide.

Tout le mérite du contenu original revient à Dale Anderson ; l’adaptation à Talend Studio 8 et ses éventuelles erreurs sont de HeyData. Cet article fait partie de notre série sur les bonnes pratiques de conception de jobs Talend : découvrir la série.