Si j'ai bien compris, le code Java est écrit par un "traducteur" Cobol vers Java. Le code généré est-il facilement maintenable ? La qualité de l'outil de traduction doit être fondamentale dans un projet comme celui-ci ; personnellement je pense que c'est un gros risque à prendre... Et puis, le Java et le COBOL sont assez différents pour qu'un bon algorithme COBOL soit parfois un mauvais algorithme Java. Le travail de refactoring doit être colossal.
Je travaille aussi sur un projet de migration mainframe -> Linux + Java/JEE (en tant que simple programmeur), mais l'approche est différente (et le nombre de lignes beaucoup plus réduit).
Nous avons profité de la nécessité de faire évoluer l'application pour effectuer le changement de plate forme. Le projet a démarré il y a trois ans, et l'échéance prévue est 2010. L'application originale était découpée en modules (très) indépendants (je vous passe les détails pénibles sur la reprise de données...). Ces modules sont réécrits un par un, et on implémente des moyens de communication entre les deux mondes.
Naturellement, c'est sur ces points de communications que les grincements des rouages se font entendre... Mais ce problème existe aussi dans la migration "automatique" décrite dans l'article.
L'avantage, c'est que nous avons une application développée dès le début pour l'architecture J2EE. En portant les fonctions un pour un de COBOL vers Java, le risque est gros de porter aussi du code servant à contourner un problème technique dans l'architecture d'origine (je ne sais pas si je me fais bien comprendre là :-)
Bref, je trouve cet article très intéressant car il parle d'un problème important mais rarement abordé dans la "communauté open-source". L'accent mis sur l'importance du "facteur humain" est très bien vu (je peux le confirmer au quotidien).
# Maintenance du code Java ?
Posté par doupatex . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 5.
Je travaille aussi sur un projet de migration mainframe -> Linux + Java/JEE (en tant que simple programmeur), mais l'approche est différente (et le nombre de lignes beaucoup plus réduit).
Nous avons profité de la nécessité de faire évoluer l'application pour effectuer le changement de plate forme. Le projet a démarré il y a trois ans, et l'échéance prévue est 2010. L'application originale était découpée en modules (très) indépendants (je vous passe les détails pénibles sur la reprise de données...). Ces modules sont réécrits un par un, et on implémente des moyens de communication entre les deux mondes.
Naturellement, c'est sur ces points de communications que les grincements des rouages se font entendre... Mais ce problème existe aussi dans la migration "automatique" décrite dans l'article.
L'avantage, c'est que nous avons une application développée dès le début pour l'architecture J2EE. En portant les fonctions un pour un de COBOL vers Java, le risque est gros de porter aussi du code servant à contourner un problème technique dans l'architecture d'origine (je ne sais pas si je me fais bien comprendre là :-)
Bref, je trouve cet article très intéressant car il parle d'un problème important mais rarement abordé dans la "communauté open-source". L'accent mis sur l'importance du "facteur humain" est très bien vu (je peux le confirmer au quotidien).
J'attends la suite avec impatience :-)