Avez-vous déjà fait une réécriture totale d'une grande application C ++ en C #?

Question

Je sais Joel dit de ne jamais le faire, et je suis d'accord avec ce dans la plupart des cas. Je pense qu'il y a des cas où c'est justifié.

Nous avons une grande application C++ (autour de 250 000 total de lignes de code) qui utilise un MFC front-end et un service Windows en tant que composants principaux. Nous sommes en réflexion sur le déplacement du projet en C#.

Les raisons que nous pensons à propos de la réécriture sont:

1. Accélération du développement
2. L'utilisation de WCF et d'autres .NET fonctionnalités intégrées
3. Plus un fonctionnement cohérent sur les différents les systèmes de
4. Plus facile de support 64 bits
5. De nombreuses et belles .NET les bibliothèques et les les composants de là

Quelqu'un a fait une réécriture de ce genre? Était-ce un succès?

---

EDIT:

Le projet est de presque 10 ans maintenant, et nous sommes arriver au point que l'ajout de nouvelles fonctionnalités que nous voulons être écrit importante que la fonctionnalité .NET a déjà intégré.

Answer 1

Avez-vous pensé à la place de la ré écrit à partir de zéro, vous devriez commencer à séparer l'interface graphique et l'extrémité arrière de la couche si ce n'est déjà fait, alors vous pouvez commencer à écrire des pièces de en C#.

les 250 000 lignes ne sont pas écrites en une nuit ils contient des centaines de milliers d'années d'efforts, afin que personne sain d'esprit assez suggère de réécrire tout à partir de zéro tout à la fois.

La meilleure approche si vous avez l'intention de le faire morceau par morceau. sinon, demandez plusieurs années de travail de développement de votre gestion alors que pas de nouvelles fonctionnalités sont mises en œuvre dans votre produit existant (en gros, en stagnation, en face de la concurrence)

Answer 2

Mon entreprise a fait. Nous avons eu un code C++ de base d'à peu près de cette taille, et tout le monde (programmeurs, de la gestion, clients), plus ou moins convenu qu'il n'était pas le meilleur morceau de logiciel. Nous voulions certaines fonctionnalités qui aurait été extrêmement difficile à mettre en œuvre dans l'ancien code de base, nous avons donc décidé (après beaucoup de discussions et de projets de test) pour le réécrire en .NET. Nous avons réutilisé le code qui a été assez modulaire à l'aide de C++/CLI (environ 20% de l' - la plupart du temps la performance est critique arithmétique des trucs qui devraient avoir été écrit en C++), mais le reste a été ré-écrit à partir de zéro. Il a fallu environ 2 ans / homme, mais ce nombre dépend vraiment de beaucoup de choses sur le type d'application, de la taille de votre équipe et de vos programmeurs, bien sûr. Je considère l'ensemble un succès: Nous avons été en mesure de réorganiser l'ensemble du système pour activer de nouvelles fonctionnalités, qui aurait été quasi-impossible avec l'ancien code de base. Nous avons pu également éviter les problèmes nous avons souvent eu dans l'ancien logiciel en réorganisant autour d'eux. Aussi, le nouveau système est beaucoup plus souple et modulaire dans les lieux où nous avons appris que la flexibilité était nécessaire. (En fait, je suis parfois surpris de voir à combien il est facile de nouvelles fonctionnalités peuvent être intégrées dans le nouveau système, même si nous n'avons jamais mais quand nous l'avons conçu.)

Donc, en résumé: Pour un projet de moyenne envergure (100k-500kloc) une réécriture est une option, mais vous devez certainement être au courant des prix et de risque. Je tiens seulement à faire si l'ancien code est vraiment de faible qualité et résiste à la refactorisation.

Aussi, il y a deux erreurs que vous ne devriez pas le faire:

1. Embaucher un nouveau .NET programmeur et lui faire de la réécriture - quelqu'un de nouveau peut aider, mais la plupart du travail, et en particulier de la conception doit être fait par les développeurs, qui ont suffisamment d'expérience avec l'ancien code, de sorte qu'ils ont une solide compréhension des exigences. Sinon, il vous suffit de répéter vos erreurs de vieux (plus quelques nouveaux) dans une autre langue.
2. Laisser un programmeur C++ ne le réécrire comme leur premier projet C#. C'est une recette pour un désastre, pour des raisons évidentes. Lorsque vous attaquer à un projet de cette taille, vous devez avoir une solide compréhension du framework que vous utilisez.

(Je pense que ces deux erreurs pourraient raisons pour lesquelles tant d'réécrit l'échec.)

Answer 3

Cela a déjà été essayé, non seulement C ++ => C #, mais VB6 => VB.NET, C ++ => Java et tout autre ancien => nouveau auquel vous pouvez penser. ça n'a jamais vraiment marché. Je pense que parce que ppl ne considère pas cette transformation pour ce qu'elle est vraiment (une réécriture totale), ils ont tendance à la prendre à la légère.

L'histoire de la migration à partir de C ++ => .NET doit se faire via CLI, en décidant soigneusement ce qui est géré et ce qui reste non géré et en "réparant" petit à petit.

Answer 4

Expression Blend a été à l'origine d'une MFC application. La version actuelle utilise WPF pour l'INTERFACE utilisateur, mais le moteur est encore à tous les parents. J'ai vu un grand discours par le directeur de l'architecte Henry Sowizral il y a une année où il décrit le processus de la migration. Faire le moteur de l'INTERFACE utilisateur agnostique et vous serez en mesure de soutenir quelle que soit la toute dernière technologie d'INTERFACE utilisateur est. L'Expression de l'équipe à un point avait ce qu'il a appelé l'hydra-version à tête. Deux avant la fin de l'Isu en cours d'exécution simultanément avec un moteur sous-jacent de manière à ce qu'ils pouvaient voir où le comportement a involontairement dévié de la version précédente. Depuis l'INTERFACE utilisateur souscrit à des événements et des notifications, les modifications effectuées dans un WPF toolwindow ont été reflétées dans le vieux MFC toolwindow.

EDIT: il Semble bien que certaines présentations powerpoint sont disponibles ici ou html ici.

Answer 5

J'ai été par le biais d'un projet qui fait exactement ce que vous décrivez avec environ la même taille de la base de code. D'abord, j'ai été complètement embarquée avec la réécriture. Il a fini par prendre+ de 3 ans et presque transformé en une marche de la mort". En général, je suis maintenant d'accord beaucoup plus avec le incrementalists.

Basé sur notre expérience, cependant, je dirai que cette réécriture (surtout si vous êtes en mesure de réutiliser une partie du C++ code de la logique métier dans .NET), n'est pas techniquement dangereux que cela puisse paraître. Cependant, il peut être très socialement dangereux!

Tout d'abord, vous devez vous assurer que tout le monde comprenne bien que ce que vous êtes entreprise est d'abord une "réécriture" (ou "remake") pas une mise à niveau ou de "la réinvention de l'." L'1998 Psycho a été un coup-pour-coup remake des années 1960 d'origine. L'2003 Battlestar Galactica est une réinvention de l'1978 original. Vous voyez la différence?

Dans notre cas, le plan initial était de recréer le produit existant dans la .NET. Qui n'aurait pas été techniquement ardue, car nous avons compris le puits d'origine. Cependant, dans la pratique, l'envie d'ajouter et de corriger et d'améliorer quelques choses s'est avéré irrésistible, et, finalement, a ajouté 2 à 3 ans pour le scénario.

Deuxièmement, vous devez vous assurer que tout le monde à partir de la execs pour le personnel de vente à l'utilisateur final est ok avec votre produit actuel reste inchangé au cours du développement du remake. Si votre marché est en mouvement de telle façon que vous ne serez pas en mesure de soutenir votre entreprise au cours de cette période, alors ne le faites pas.

Ainsi, les principaux obstacles pour nous s'est avéré être social, plutôt que de la technique. Les utilisateurs et les intérêts de l'entreprise est devenu très frustré par le manque de progrès visibles. Tout le monde s'est senti obligé de pousser pour leur propre animal de compagnie améliorations et fonctionnalités, trop, de sorte que notre produit final n'ont qu'une ressemblance superficielle avec l'original. C'était certainement une ré-imagination plutôt qu'un remake.

En fin de compte, il semble avoir tourné ok pour nous, mais c'était un vrai grind, et pas quelque chose que nous aimerions choisir de le faire à nouveau. Nous avons brûlé par le biais de beaucoup de bonne volonté et de la patience (internes et externes), ce qui pourrait avoir été en grande partie évités par une approche progressive.