Est-il difficile de migrer un projet de Delphi 7 vers Delphi XE?
Notre société possède un logiciel en développement depuis plus de 10 ans. Il contient donc des éléments vraiment obsolètes. Cela reste tout à fait fonctionnel et tout, mais je vois les nouvelles fonctionnalités de Delphi XE et cela me donne envie de basculer. Le problème est que le code source lui-même contient plus de 300 Mo de fichiers .pas (1 Go au total avec les composants, etc.).
Nous utilisons des composants personnalisés, des vieux fichiers jvcl et le dernier devexpress.
À quel point puis-je espérer que les choses se passent si je décide de migrer de Delphi 7 vers Delphi XE?
Je vous remercie.
Le seul problème réel est la conversion en Unicode. Vous devriez apprendre comment le support Unicode est implémenté dans Delphi - à partir de Marco Cantu Livre Blanc: Delphi et Unicode
Il est impossible d'estimer la quantité de travail nécessaire pour mettre à niveau d'anciennes applications vers Unicode sans connaître le code réel. Si vous utilisiez des types de chaîne de manière standard, la conversion serait facile. Toutes les astuces de bas niveau avec des types de chaîne (comme stocker des données binaires dans des chaînes) sont maintenant obsolètes et le code correspondant doit être réécrit.
Certains petits outils migrent sans qu'il soit nécessaire de faire des modifications, ou juste quelques correctifs unicode pour le faire fonctionner.
Toutefois, si votre base de code est aussi volumineuse que vous l'expliquez, vous ne devriez pas vous fier entièrement à ce que quelqu'un ici va vous dire. Obtenez juste une copie de XE et chargez le code. Voyez quels problèmes vous rencontrez pour avoir une idée de la quantité d'effort que cela va demander.
A ce moment, j'ai porté tout mon code sur XE (même les vieux projets). Je réutilise autant que possible les mêmes bibliothèques. Ainsi, une fois que j'ai converti la plupart de celles-ci, le "portage" d'applications de Delphi 7 vers Unicode était généralement une tâche répétitive consistant à traiter les interfaces mises à jour dans les bibliothèques ou à corrige les erreurs et les avertissements du compilateur.
Les erreurs les plus courantes que j'ai rencontrées:
Trucs Unicode. Cela prendra 90% du temps. C'est agaçant si le code gère beaucoup de chaînes de bas niveau, mais la plupart des problèmes peuvent être facilement résolus en ajoutant des dactylographes.
le compilateur bitches quand vous utilisez
c in ['a'..'z']. Vous êtes censé utiliserCharInSet()pour les chaînes unicode.Si vous définissez ShortDateFormat, vous recevrez un avertissement du compilateur indiquant que vous devez utiliser FormatSettings.ShortDateFormat à la place. Dans le nouveau code, c'est une bonne idée. Si vous effectuez un portage, ignorez-le au départ si vous souhaitez simplement y aller.
En outre, vous devrez probablement mettre à niveau vos bibliothèques tierces vers des versions plus récentes, de sorte que vous n'ayez pas à les porter vous-même. Il n'est pas rare que ceux-ci aient changé d'interface ou de fonctionnement. Je téléchargerais donc quelques versions d'essai de celles-ci pour voir ce qui a été changé.
J'ai fait pas mal de ces conversions.
Vous devez vous préparer en rendant votre base de code actuelle testable. Utilisez de préférence des tests unitaires automatisés, mais prévoyez au moins un bon plan de tests pour les utilisateurs finaux.
Ensuite, vous devez planifier la plus grande partie: la conversion Unicode pour votre application et votre base de données.
Enfin, il y a des aspects moins importants, mais potentiellement très fastidieux:
- si vous utilisez le BDE, c'est le moment de vous en débarrasser
- delphi XE est plus strict que Delphi 7
- Des versions de bibliothèques tierces qui en ont installé pas mal et sont généralement beaucoup moins compatibles en amont que la VCL
Lorsque vous l'avez porté, il est temps de changer les choses: puisque vous avez vu la base de code dans son intégralité, vous savez maintenant où se trouvent vos points faibles. Vous pouvez donc les refactoriser et obtenir une meilleure application qu'auparavant.
Vous avez mentionné SQL dans l'un de vos commentaires de réponse ... Votre base de données prend-elle en charge le format Unicode? Sinon, vous pourriez avoir beaucoup de travail. Vous devrez peut-être convertir des bases de données à la volée ou créer un outil de conversion pour vos utilisateurs. Vous devrez peut-être mettre à niveau la base de données ou même passer à autre chose. Par exemple, DBISAM n'est pas compatible Unicode, mais le fournisseur fabrique ElevateDB, qui est. La transition n'est pas anodine. Et certaines autres bibliothèques comme Hyperstring, écrite principalement en assembleur, constituent un autre point sensible.
Mon projet concerne environ un million de lignes de code et j'ai récemment porté de CB9 à XE. Pour réduire la quantité de travail, j’ai tout d’abord réécrit beaucoup pour ne plus dépendre des packs de composants tiers, puis j’ai soigneusement passé en revue tout ce qui concerne la chaîne (unicode) et ce n’est que par la suite que je suis passé à XE. La préparation demandait beaucoup de travail, le port actuel était relativement facile.
C'est certainement un défi pour cette MIGRATION d'être exécutée. Mais besoin d'une bonne planification!
Nous devons d’abord trouver tous les composants possibles qui doivent également être migrés avec le Code. S'il existe des composants tiers utilisés dans le projet Delphi7 qui ne sont pas disponibles, il est assez compliqué d'aller plus loin. Deuxièmement, l'autre conversion de type concerne Unicode, ce qui est assez simple. Et enfin Bien sûr, nous devons mettre en place d’autres bibliothèques de support, BDE et Database Adapaters.
Pour l'interface utilisateur riche, Delphi FireMonkey peut être utilisé.
Delphi va de mieux en mieux, car il prend désormais en charge le développement d’applications de bureau à Web et de mobiles.