Il y a pas mal d’applications qui ont été écrites en C++ natif, avec les MFC. Ou bien avec ATL.

La bonne nouvelle c’est que Visual Studio 2010 nous donne les moyens de moderniser ce genre d’application, et de les remettre au goût du jour.

Avant Visual Studio 2010 on se disait :

“ Bon, on a cette application C++/MFC dont l’écriture a commencé il y a 6 ou 10 ans. Maintenant la tendance et les derniers gadgets à la mode sont dans .NET : Winforms ou WPF. Alors on va migrer l’application vers .NET. “

Et commençait un long périple qui avait plusieurs issues possibles, selon les cas. Les exemples cités ici sont de vrais cas, seuls les noms ont été changés ;-) :

1ère solution : les devs prennent la décision de tout réécrire from scratch en WPF (ou en Winform) et arrivent à convaincre leur hiérarchie. Effet tunnel, ça prend deux ans. Il faut payer l’équipe de développement pendant ce temps parce que rien ne sort. Et à la fin, si ça aboutit (des fois ça n’aboutit pas), on a les mêmes fonctionnalités qu’avant. Avec un look and feel plus sympa et moderne quand même. Le marketing râle après le développement : “Quoi ?! Il vous a fallu deux ans pour faire ça ? Et on a quoi de neuf nous à vendre aux clients ? On avait déjà toutes ces fonctionnalités avant”. Les développeurs ont passé leurs nuits pour tout refaire en C#. Au moins le code est en .NET, et il est propre. Mais ça a coûté très cher. Entrer dans ce genre d’aventure et s’en sortir n’est possible qu’avec de bons développeurs et un excellent encadrement technique.

2eme solution : Le chef déclare qu’il faut faire une migration vers .NET petit à petit, écran par écran. Pour éviter l’effet tunnel. Alors commence une longue souffrance pour l’équipe de développement. Les écrans vont être réécrits en .NET un par un, et intégrés dans le projet C++ natif avec de l’interop. Au bout de quelques semaines, le chef voit qu’il a des boîtes de dialogue en .NET (Winform par exemple) dans son application. Il a l’air content. Mais il ne voit pas l’usine à gaz en dessous. Si certains développeurs comprennent ce qu’ils font et le font proprement, il peut arriver que d’autres ne comprennent pas bien. Réaliser ce genre d’intégration avec de l’interop n’est pas si simple qu’il n’y paraît. J’ai vu du code C++ natif appeler du code C#, qui rappelait du code natif, qui à son tour appelait du code C#. Je n’ai pas vu de projet conséquent de ce genre arriver à terme. Ca a fini dans un mélange infâme de code natif et managé. Mais des fonctionnalités on pu être ajoutées au projet pendant que des écrans étaient réécrits en C#, et le marketing est content.

Heureusement Visual Studio 2010 propose une autre approche avec de nouvelles fonctionnalités pour les projets C++. Une troisième solution devient possible pour mettre à jour une vieille application C++ ! La mettre au goût du jour avec les nouvelles fonctionnalités proposées dans Visual Studio 2010 !

3eme solution : Quelques programmeurs C++ vont pouvoir changer l’interface utilisateur, connecter l’application au Web, ajouter quelques gadgets sexy, gérer le parallélisme pour profiter des processeurs modernes, etc. Et tout ça en quelques semaines seulement.

La conférence sur Visual C++ 2010 que j’ai citée dans le billet précédent sur la conférence PDC résume comment faire. 

Et puis, j’effectue moi-même en ce moment la migration d’un projet C++/MFC commencé il y a… 16 ans ! Il fonctionne toujours, est très rapide, et consomme très peu de mémoire.

Voici une capture d’écran d’un logiciel écrit proprement en C++ depuis 16 ans, toujours en cours de développement avec VS 2010, et qui ne fait pas son âge.

Oui, on ne dirait pas une application dont l’essentiel du code date de plus de 15 ans…

Je détaillerai très bientôt les étapes à effectuer pour une migration de ce genre dans des billets à venir.