Au-delà  de RPG III

/>
Deuxièmement, ILE RPG a intégré un support d’API modulaire. Troisièmement, le personnel actuel connaît RPG. Quatrièmement, il existe une abondance de logiciels applicatifs RPG tiers et maison. Cinquièmement, l’ancien code fonctionne parfaitement dans les nouvelles releases d’OS sans recompilation. Et, sixièmement, comme Scott Klement nous le dit dans « RPG Rules » (www.itpro.fr Club Abonnés), il est parfaitement intégré à la base de données et au système d’exploitation, et il possède la meilleure journalisation de jobs de l’industrie.
Mais RPG est le Frégoli des langages de programmation, avec au moins quatre personnalités : RPG II, RPG III, RPG IV, RPG/400 et ILE RPG. Et j’ai souvent constaté la présence de plusieurs d’entre-elles, sur le même site, voire dans le même programme.

Une telle multiplicité est la conséquence logique d’un demi-siècle d’existence. En effet, les vieux langages s’adaptent au-delà de leur but originel, par une sorte de morphing. Résultat : RPG est plus complexe que des langages plus récents. Le problème se pose alors de savoir ce qu’il ne faut pas utiliser. Il est trop facile de propager à l’envie une syntaxe démodée: sous-routines, listes de paramètres d’entrée, indicateurs non nommés et variables globales.

Croyez-en mon expérience, même de vieux programmeurs RPG chevronnés et compétents n’utilisent pas bien le langage. Je me souviens d’un consultant huppé (quant aux honoraires) me déclarant « Il n’existe pas de fichiers de type PC (ASCII) sur le 400 ». Une autre fois, alors que je participais au comité de standards RPG d’une importante société d’électronique grand public, l’un des experts déclara « Je ne vois pas d’avantage à ILE, donc créons des standards pour RPG IV seulement ». Un autre obstacle au dépassement de RPG III, est que les fournisseurs tiers ne sont pas capables ou désireux de moderniser leurs bases de code.

L’une des raisons pour lesquelles le code RPG III n’a pas été modernisé est que RPG est difficile ou impossible à refactoriser. Il n’existe pas de moyens courants pour formaliser la refactorisation. La refactorisation est un processus d’ingénierie logicielle bien accepté. Il inclut une combinaison de processus de contrôles de source, tests d’unités, tests d’intégration, tests système et construction. Le manque de moyens de refactorisation a conduit à une inflation de code en double. De plus, le code compilé ne correspond pas toujours au code source. RPG II et III ont en commun un bogue de taille : la collision des noms de champs de fichiers (où RPG utilise le même emplacement mémoire pour des champs définis en externe dans deux fichiers ou plus portant le même nom).

Ce bogue a poussé certains sites à transgresser les conventions de nommage de base de données relationnelles au profit d’un préfixe unique pour tous les noms de champs. Quand les débutants sur System i voient des noms de champs de quatre caractères, ils jugent sévèrement notre base de données. Dur dur pour le système à qui l’on doit la première base de données relationnelle et qui, à ce jour, possède la meilleure base de données relationnelle au monde. ILE RPG a une solution simple au problème de collision des noms de champs de fichiers (c’est-à-dire des qualificateurs), mais elle est rarement utilisée et les sites ne prendront pas le temps de donner des noms significatifs à leurs colonnes de tables de base de données.

C’est vrai, RPG vient de loin. Mais combien de développeurs RPG ont vraiment changé leur mode de programmation ? Il est temps de dépasser RPG III. Adoptez ILE RPG et les pratiques de conception à base de composantes modernes. Et envisagez d’autres langages.