Discussion :

[alf_idsoft]

Bonjour

Je suis développeur Delphi et C#, et avec mon équipe, on maintient des applications Delphi et développons de nouvelles en C#, le tout sous Oracle à grand renforts de procédures stockées.

Nos applications Delphi sont disons... âgées et comme pour beaucoup, il y a eu la frayeur du BDE en système 64 bits. Ca fonctionne toujours
Mais jusqu'à quand ?

- Ré-écrire nos applications en se passant du BDE ? C'est bourré de TTable et de TQuery, cela me semble un long travail, sur un vieux Delphi 7.
- Ré-écrire avec le dernier Delphi ? Encore + de boulot sur une technologie qui ne nous inspire plus, et pourtant j'ai énormément apprécié de bosser en Delphi. Nous avons déjà commencer à développer en C#...
- Ré-écrire tout en C# ? Va falloir un jour, mais cela ne presse pas : allez expliquer aux utilisateurs (et pire encore aux chefs) que vous allez bosser pendant 2-3 ans pour qu'ils aient la même application !

Il semble que tout nos outils passent windows server 2012 et windows 8, mais à votre avis, quand faudra-t-il sonner le signal d'alarme ?

[Paul TOTH]

tout dépend du produit, si le code Delphi 7 a un intérêt et qu'il serait laborieux de le porter en C# autant se débarrasser du BDE...quitte à remplacer les composants TTable etc... par des versions équivalentes mais sans BDE...

j'ose espérer que même avec le BDE la base derrière n'est pas Paradox ^^

[ShaiLeTroll]

- Ré-écrire tout en C# ? Va falloir un jour, mais cela ne presse pas : allez expliquer aux utilisateurs (et pire encore aux chefs) que vous allez bosser pendant 2-3 ans pour qu'ils aient la même application !

C'est comme cela que l'on fini par jamais le faire !

Il faut migrer module par module, à un moment, un "chef" a bien validé le changement de logiciel de développement, un "chef" intelligent aurait du dès le début, côter le cout de migration en jour/homme, les délais nécessaires pour assumer à la fois la TMA Delphi, la migration puis TMA C# tout en continuant la maintenance Delphi

On appel cela une Roadmap, procrastiner parce que l'on hésite à le passer le cap est un grand classique mais c'est effectivement risquer l'infarctus surtout que le BDE est déclaré obselète depuis 10 ans par Borlacogecadero

- Ré-écrire avec le dernier Delphi ? Encore + de boulot sur une technologie qui ne nous inspire plus, et pourtant j'ai énormément apprécié de bosser en Delphi. Nous avons déjà commencer à développer en C#...

Avec une totale objectivité de gentil troll évidemment
Ré-écrire avec le dernier Delphi : C'est la meilleure solution !
Il est évident qu'il faut utilisé un Framework vraiment multi-platforme comme FMX et non .NET multi-windows mais pas multi-plateforme

[Lung]

Nos applications Delphi sont disons... âgées et comme pour beaucoup, il y a eu la frayeur du BDE en système 64 bits. Ca fonctionne toujours

Fonctionner est un bien grand mot.
De ce que j'en ai vu, ça marchouille. Des fois, ça plante, sans qu'on sache pourquoi. Il est plus que temps de migrer.
Nous, pour attaquer Oracle (depuis Delphi), on est passé à ODAC (c'est payant, mais beaucoup plus puissant que le BDE).

[SergioMaster]

- Ré-écrire nos applications en se passant du BDE ? C'est bourré de TTable et de TQuery, cela me semble un long travail, sur un vieux Delphi 7.

j'ai fait faire un passage de BDE à un BDE like (ZEOSDBO) d'une application 'moyenne' (une quinzaine de modules), cela n'a pris que 3 semaines mais ceci parce que chaque fois qu'il était possible de se passer des TTable j'ai demandé que cela soit en TQuery
Bien sur ce ne sera toujours qu'un pis aller si vous avez décidé de passer en C# automatiquement les compétences Delphi vont 'disparaitre'
je plussoierai donc volontiers le Troll de service

[Paul TOTH]

Bien sur ce ne sera toujours qu'un pis aller si vous avez décidé de passer en C# automatiquement les compétences Delphi vont 'disparaitre'

c'est pour cela qu'il y a des sous-traitants et même des expert Delphi

J'assure actuellement la maintenance d'une application dont j'ai fait la migration de Turbo Pascal pour Windows vers Delphi

la réécriture de l'accès BDD d'une appli Delphi 7 c'est de la rigolade à côté

[alf_idsoft]

Merci pour vos avis

Les applications sont nées à la fin du siècle dernier, les développeurs se sont succédé et si je ne suis pas toujours d'accord avec la façon dont cela a été codé... faut assurer malgré tout les demandes des utilisateurs donc on n'a jamais vraiment évoqué une migration, c'est plutôt "ça a fonctionné, ça continuera" sans s'attarder sur ce point de détail.

Il a été question de migrer en C#, plan abandonné pour un tas de raisons.
Je vais schématiser une "bonne raison" :
- Monsieur le directeur, nous voudrions ré-écrire en partie les applications car elles risquent de ne plus fonctionner avec l'évolution des systèmes
- Oui, combien de temps et qu'est-ce que cela va apporter tous les jours aux utilisateurs vos nouvelles applications ?
- 2 ans, et ils continueront à travailler comme ils le font actuellement
- Je vais payer 2 ans une équipe informatique pour avoir la même chose que maintenant ?

J'ai vu paradox..... oui, y a du paradox malheureusement, un peu partout pour les tables temporaires

C'est me débarrasser du BDE que je verrai le plus pratique, oui, car ce sont des années de programmation avec des tonnes de subtilités pas forcément très documentées que l'on pourrait conserver.

Admettons, on se débarrasse du BDE. En 2020, Delphi 7 avec un BDE-like, ça marchera comment ? Personnellement, je n'en ai aucune idée...

[Paul TOTH]

Admettons, on se débarrasse du BDE. En 2020, Delphi 7 avec un BDE-like, ça marchera comment ? Personnellement, je n'en ai aucune idée...

tu veux une solution sur 10 ans ? ça me parait audacieux quand on voit comment les choses bougent Même .Net n'est pas à l'abri

manifestement cette application entre dans la catégorie des applis dont plus personne ne maîtrise les subtilités et dont les concepteurs ont depuis longtemps quitté la boîte

c'est la pire des situations - mais loin d'être rare - où l'investissement nécessaire à la mise au propre est rarement accepté.

si vous avez une équipe de testeurs (car je doute que l'appli possède des tests unitaires) il est envisageable de faire des modifications en profondeur, virer le BDE, entamer la migration Unicode (pour le jour où ce passage sera obligatoire) tout en restant sur Delphi 7 qui permet de développer encore pour quelques années.

Ma dernière expérience en la matière a été assez drôle, un développeur fraîchement recruté s'est retrouvé seul à migrer une appli Delphi 5 (langage qu'il ne connaissait pas) vers C#... il a fallut en fait que tous les développeurs Delphi quittent la boîte pour que la direction décide de supprimer Delphi...alors que jusque là, la politique était de ne pas touche à l'existant dont on savait juste qu'il fonctionnait

Si vous ne voulez pas en arriver à cet extrême il faudra investir un minimum dans Delphi pour s'assurer de la pérennité de l'application, ou entamer le processus de conversion vers C# que tu estimes à 2 ans.

[SergioMaster]

En 2020, Delphi 7 avec un BDE-like, ça marchera comment ? Personnellement, je n'en ai aucune idée...

je n'ai pas de boule de cristal
mais je retourne la question un programme en C# avec .. peu importe , ça fonctionnera comment ?


Le BDE , on est prévenu depuis 10 ans

Le BDELike que j'indiquais c'est une manière 'douce' de passer des compétences DELPHI+BDE a Delphi+ZEOSDBO dans ce cas , sans casser tout (un pis aller mais de cout moindre) .

[alf_idsoft]

Très intéressant

C#, c'est sur que Microsoft nous a habitué à des technologies super méga bien... dont la durée de vie n'a pas toujours atteint 10 ans

Mais en tout cas, c'est bien le cas de programmes conçus par des développeurs partis depuis longtemps. Il y a eu plusieurs transferts de compétences mais on perd forcément des informations au passage.

Ah non, ce sont les utilisateurs qui testent directement
On a des dizaines de modules, l'évolution peut tout à fait se faire en douceur.
Cerise sur le gateau : y a très peu de datamodules, tout est dispersé dans les Forms


On va regarder de + prêt ZEOSBDO et ODAC

[Paul TOTH]

Très intéressant

C#, c'est sur que Microsoft nous a habitué à des technologies super méga bien... dont la durée de vie n'a pas toujours atteint 10 ans

Mais en tout cas, c'est bien le cas de programmes conçus par des développeurs partis depuis longtemps. Il y a eu plusieurs transferts de compétences mais on perd forcément des informations au passage.

Ah non, ce sont les utilisateurs qui testent directement
On a des dizaines de modules, l'évolution peut tout à fait se faire en douceur.
Cerise sur le gateau : y a très peu de datamodules, tout est dispersé dans les Forms


On va regarder de + prêt ZEOSBDO et ODAC

les modules sont sous forme de DLL ? si elle utilisent des types portables (PChar, ...) ils peuvent être migrés sous XE2 progressivement en effet (PAnsiChar).

et l'avantage des modules...c'est qu'il est plus facile de sous-traiter ^^

[chaplin]

Il a été question de migrer en C#, plan abandonné pour un tas de raisons.
Je vais schématiser une "bonne raison" :
- Monsieur le directeur, nous voudrions ré-écrire en partie les applications car elles risquent de ne plus fonctionner avec l'évolution des systèmes
- Oui, combien de temps et qu'est-ce que cela va apporter tous les jours aux utilisateurs vos nouvelles applications ?
- 2 ans, et ils continueront à travailler comme ils le font actuellement
- Je vais payer 2 ans une équipe informatique pour avoir la même chose que maintenant ?

Heureusement qu'il n'a pas de centrale nucléaire à gérer, parce qu'il y aurait partout des Tchernobyl en puissance. J'oubliais, le chef à toujours raison et si on se plante, c'est que le chef avait raison de ... se planter.

EDIT: Je parle d'expérience, et aujourd'hui ça me fait doucement rigoler.

[SergioMaster]

On va regarder de + prêt ZEOSBDO et ODAC

Nota.Bene , pour les tables 'temporaires' paradox , il y a la solution des memory tables (KBmemTable ou autres)

[alf_idsoft]

Il y a un bon paquet de modules sous forme de DLL (une partie importante avec des reportbuilder ) et quelques grosses applications contenant des dizaines de forms.
On peut planifier et étaler les modifications par DLL et par forms.

Je ne connais pas les memory tables, je suis adepte des tclientdataset avec tout chargé en mémoire, ça conviendrait surement partout. C'est sur que le Paradox, ça laisse une trace sur le disque et en cas de plantage, on peut récupérer les infos... à part ça, je ne vois que des inconvénients

C'est quand même pas Tchernobyl : la boite ne va pas migrer tous les serveurs sur un système incompatible avec nos programmes sans réfléchir. Dans le pire des cas, on aura un sursis avec un ancien système, ça nous laissera le temps de re-coder. Pis on va tuer personne

Sous-traiter..... pas trop la politique, on considère que le temps de formation est trop important, personne ne va ré-écrire du code le 1er mois

[chaplin]

C'est quand même pas Tchernobyl : la boite ne va pas migrer tous les serveurs sur un système incompatible avec nos programmes sans réfléchir. Dans le pire des cas, on aura un sursis avec un ancien système, ça nous laissera le temps de re-coder. Pis on va tuer personne

Sous-traiter..... pas trop la politique, on considère que le temps de formation est trop important, personne ne va ré-écrire du code le 1er mois

Alors qui décide ? Le directeur, les développeurs ou les deux dans un consensus mutuel?

[Graffito]

Ré-écrire tout en C# ? Va falloir un jour, mais cela ne presse pas : allez expliquer aux utilisateurs (et pire encore aux chefs) que vous allez bosser pendant 2-3 ans pour qu'ils aient la même application !

On a fait cette même migration il y a 4 ans sans trop de douleur.

Les modules faisant appel au BDE ont été entierement refondus.

Les classes de calcul ont été juste été migrées avec une conversion manuelle, mais juste en changeant la syntaxe pour l'adapter à C#. Dans la grande majorité des cas, les fonctions traduites marchent du premier coup sans bug.

[alf_idsoft]

Alors qui décide ? Le directeur, les développeurs ou les deux dans un consensus mutuel?

Mon chef ainsi que le directeur de dev + un autre responsable, le dsi doit surement aussi dire son mot, et pourquoi pas le directeur
En tout cas, je peux jouer les conseillers dans cette histoire

C'est encourageant de voir que la migration peut très bien se passer
Je vais pousser pour qu'on mette ça dans les tuyaux, à petits feux (assez pour être efficace, pas trop pour éviter que les utilisateurs se sentent abandonnés)

[alf_idsoft]

Déterrage
Prêt de 3 ans ont passé, notre LIMS est toujours du delphi 7 + BDE, mais cela sent le roussi, puisqu'on commence à regarder pour acheter un LIMS clé en mains, et donc éradiquer Delphi de l'entreprise.

A aucun moment nous avons eu l'occasion de bosser sur une migration.
L'équipe devrait bientôt être composée de (attendez je compte) 2 personnes (+ le directeur qui ne développe pas), réparties entre le dépannage, les nouveaux projets à concevoir, développer, tester, exploiter.
Je regarde ce gros programme Delphi sur lequel j'ai passé tant de temps et dont chaque évolution demande un temps trop important.
Sans compter que j'ai changé de PC et qu'une journée n'a pas réussi à réinstaller correctement delphi, car il y a un monstrueux attirail d'extensions à installer.

Soit on achète un lims, on met des mois à le personnaliser et on jette Delphi
Soit on fait survivre notre programme delphi le temps de le redévelopper en .net, module par module, mais y en a pour des années à 2 personnes ne pouvant y consacrer que très peu de temps.
Et j'ai tellement l'impression d'avoir à remonter boulon par boulon un paquebot que les personnes qui n'ont pas eu trop de difficultés à migrer leur appli, ça me semble du rêve pour moi.
Impossible de vous représenter la taille de ce projet. On serait 4 dans l'équipe que je trouverai ça encore trop peu, mais on est 2 est ça changera pas avant un moment.

Pourquoi ce message ? des fois que quelqu'un soit confronté à un problème similaire et qu'il ait trouvé une solution que je n'ai pas envisagée.

Bon week-end

[SergioMaster]

Bonjour,

sans conviction aucune mais à voir

un lien trouvé via Linkedin
comme il faut être affilié je propose la vidéo
https://youtu.be/vONjPMEnJmY

[alf_idsoft]

Merci pour le lien

Le site delphi parser est vide, y a juste écrit "coming soon". Et malgré ce qu'ils disent, ça fait vraiment tour de magie.
Sur un petit programme, je veux bien, je peux même tester. Mais sur notre gros programme plein de règles de de gestion, malgré des milliers de lignes déplacées en oracle, les tests à effectuer peuvent donner le tournis.

Je pense qu'on va essayer de diversifier les solutions : Utiliser un lims du commerce, redéveloppez une partie de notre outil sur mesure en c# et continuer à faire vivre notre lims Delphi le temps qu'il reste des fonctions utilisés. En gros, diminuer régulièrement le nombre d'utilisateurs, métier par métier.

Je n'ai jamais aimé la gestion des datasets sous visual studio, je suis habitué au Delphi, mais en +, je trouve ça plus logique.