Comment continuez-vous à développer de grands systèmes logiciels (à long terme) avec du code existant et nouveau?

Question

Je travaille sur une grande base de code avec une grande base d'utilisateurs. Le code a été écrit à l'origine en vb6 avec quelques modules COM C++ pour le travail de bas niveau.

Il est complètement impossible de réécrire tout le code qui est déjà écrit en vb6 et qui est utilisé par nos clients tous les jours, mais nous continuons également à apporter des améliorations et des personnalisations au logiciel (grand et petit).

Ma solution jusqu'à présent est d'écrire la plupart du nouveau code dans C# (winforms et même wpf maintenant), puis utiliser COM interop pour appeler les modules de vb6. Est-ce que n'importe qui a de l'expérience avec des suites logicielles à long terme comme celles-ci (10+ ans) qui ne peuvent pas être arrêtées pour une réécriture complète, mais ont besoin d'un nouveau développement continu en même temps. De même, dans les systèmes mixtes comme celui-ci, quelle est la meilleure façon d'interfacer les modules? J'utilise COM en ce moment, mais j'ai également considéré l'IPC avec des processus séparés.

Answer 1

Il est difficile de donner une réponse globale mais l'approche de haut niveau est claire. Au moins, c'est l'approche que j'ai utilisée. Priorisez vos objectifs et essayez d'identifier les coûts pour atteindre ces objectifs. Vos coûts se résumeront essentiellement à «temps de développement».

Tout d'abord, vous voulez tout fonctionne de continuer à travailler. Si vous avez quelque chose qui fonctionne, et qu'il n'y a pas de bonne raison de le réécrire, gardez-le.

Si une partie de votre code existant a besoin d'être mise à jour pour faire son travail, alors vous regardez les coûts de maintenance. À ce stade, vous devez déterminer si une réécriture améliorera suffisamment les coûts de maintenance pour en valoir la peine. N'oubliez pas de soustraire les tests et le débogage de nouveaux bogues car il y aura de nouveaux bogues. Ne pas rejeter le code de travail juste parce qu'il est vieux.

Si votre code existant est suffisamment modulaire, vous pouvez généralement l'éliminer morceau par morceau. Réécrivez les composants à haute maintenance en premier.

Si vous allez faire un nouveau développement en C#, alors vous devriez travailler avec les composants COM jusqu'à ce que vous ayez suffisamment de justification pour les remplacer.

Answer 2

Je pense que vous devez regarder vos chemins de mise à niveau pour vos clients. Le fait est qu'à un certain moment, quand ils auront 16 processeurs principaux, vous aurez besoin de la concurrence pour accélérer les choses. Donc, vous avez une analyse de rentabilisation pour quitter le formulaire VB6 et vers WCF. WCF a intégré la prise en charge de la simultanéité et de la synchronisation. Il peut être utilisé pour la communication locale en cours, ainsi que pour la communication entre processus et entre machines. Il a également l'avantage de vous permettre de faire plus de programmation de style AOP.

Answer 3

Je pense que vous avez un bon plan. Cela finira par déplacer la majeure partie du code en C#, en tirant parti du meilleur ensemble d'outils.

Est-ce que le code VB6 comprennent des objets COM?

Vous avez mentionné que le code "ne peut pas être arrêté pour une réécriture complète". Mais tu n'as pas à t'arrêter. Un par un, vous pouvez remplacer chaque élément de la fonctionnalité VB6 par le code C# équivalent. Cela vous permettrait de faire un changement à la fois (de préférence avec des tests automatisés pour prouver que vous n'avez rien cassé).

Answer 4

Réécrire sur une base de besoins quand il y a un facteur de motivation.

Un ancien projet Windows sur lequel je travaillais avait un moteur de règles écrit en C qui fonctionnait donc nous l'avons simplement laissé en tant que DLL de boîte noire.

Nous avons construit une nouvelle face avant et la base d'utilisateurs a été impressionnée par le nouveau look moderne et facile à utiliser de l'application. Rien dans les internals n'avait vraiment changé.

La couche d'accès à la base de données utilisait SQL Server DBLIB et n'a pas été ré-écrite jusqu'à la mise à niveau de SQL Server.

Answer 5

Je suis actuellement l'un de plusieurs développeurs travaillant sur un système hérité important qui a débuté comme une combinaison de C et C++ avec Win32 et, plus tard, MFC avec une poignée d'assemblage parmi le code C back end. Nous avons récemment passé de VC++ 6 à Visual Studio 2005 (et nous l'avons depuis mis à jour en 2008) pour la dernière version du projet sur lequel nous travaillons. Depuis la mise à jour de l'IDE/compilateur, nous avons nettoyé certains aspects de l'aspect et de la convivialité et ajouté C++ géré avec WinForms et maintenant C# avec WCF. Alors que les fondements de notre système, y compris le backend, resteront presque définitivement en C (au moins dans un avenir prévisible), tout ce qui est nouveau dans la partie frontale sera probablement fait en C#/WCF. Lorsque nous avons le temps et/ou le besoin, nous avons l'intention de commencer à remplacer les parties antérieures de l'extrémité avant par un code C#/WCF équivalent.

Answer 6

Nous avons plusieurs systèmes de ce type. La partie dérangeante de tout cela est le lifecycle support status of VB6. Il y a un risque (même minime) que vous ne puissiez pas obtenir de l'aide de Microsoft avec un problème de showstopper avec par exemple. une future mise à niveau du serveur, et n'aura pas la capacité de le réparer vous-même (par exemple, en raison d'incompatibilités entre les DLL VB6 et le serveur patché O/S). C'est un risque qui pourrait intéresser votre direction - mais si vous n'avez pas d'entente de soutien maintenant, peut-être sont-ils à l'aise avec cela?

Nous cherchons en fait à réécrire et à redessiner certains des plus critiques. Nous avons essayé l'évolution progressive, et cela peut fonctionner, mais cela rend (disons) une situation intéressante en matière d'opérations et de maintenance. Je recommande fortement d'instrumentation tout (ancien et nouveau code) avec beaucoup de consignation configurable, si vous n'êtes pas déjà, pour aider à l'isolation des fautes. COM ressemble à une interface raisonnable entre l'héritage et le nouveau. À moins d'avoir des interactions très simples entre les composants, je ne vois pas vraiment pourquoi vous voudriez revenir à un mécanisme IPC plus basique. COM a ses complexités, mais il fournit également beaucoup d'abstractions utiles pour, par exemple, le typage de données et le versioning que vous auriez à réinventer et à maintenir ...