Comment pouvez-vous continuer à développer des systèmes logiciels de grande taille (à long terme) avec l'héritage et le nouveau code? [fermé]

Question

Je travaille sur une grande base de code avec une grande base installée d'utilisateurs. Le code a été écrit en VB6 avec quelques c ++ modules COM pour le travail de bas niveau.

Il est tout à fait impossible de réécrire tout le code qui est déjà écrit en VB6 et est utilisé par nos clients tous les jours, mais nous continuons aussi d'apporter des améliorations et personnalisations du logiciel (grandes et petites).

Ma solution à ce jour est d'écrire la plupart du nouveau code en c # (WinForms et même maintenant WPF), puis utiliser COM Interop pour appeler les modules de VB6.

Quelqu'un là-bas ont de l'expérience avec des suites logicielles à long terme comme ceci (10 ans) qui ne peut pas être arrêté pour une réécriture complète, mais ont besoin de nouveaux développement continu en même temps. En outre, 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 ont considéré IPC avec des processus distincts ainsi.

Answer 1

Il est difficile de donner une seule réponse globale mais toute l'approche de haut niveau est clair. Au moins, cela est l'approche que je l'ai utilisé. Prioriser vos objectifs et ensuite essayer d'identifier les coûts d'atteindre ces objectifs. Vos coûts essentiellement faire bouillir jusqu'à « temps de développement ».

D'abord, vous voulez tout fonctionne de continuer à travailler. Si vous avez quelque chose qui fonctionne, et il n'y a aucune bonne raison de le réécrire, le garder.

Si une partie de votre code existant a besoin de mettre à jour pour faire son travail, alors vous êtes à la recherche à des coûts d'entretien. À ce stade, vous devez déterminer si une ré-écriture permettra d'améliorer l'entretien assez frais pour valoir la peine. Ne pas oublier de soustraire les tests et le débogage des nouveaux bugs car il y aura de nouveaux bugs. Ne pas rejeter le code de travail juste parce qu'il est vieux.

Si votre code existant est suffisamment modulaire, vous pouvez habituellement puce loin à lui une seule pièce à la fois. Réécrire les composants de maintenance élevés en premier.

Si vous allez faire nouveau développement en C #, alors vous devriez être bien travailler avec des composants COM jusqu'à ce que vous avez une justification suffisante pour les remplacer.

Answer 2

Je pense que vous avez un bon plan. Ce qui finira par passer la majeure partie du code dans C #, en profitant de la meilleure panoplie d'outils.

Le code VB6 comprend des objets COM?

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

Answer 3

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

Un ancien projet Windows, je travaille sur un moteur avait des règles écrites en C qui travaillait alors nous avons laissé comme une DLL de boîte noire.

Nous avons construit une nouvelle extrémité avant et la base de l'utilisateur a été été impressionnés par la facilité d'utilisation nouveau look moderne de l'application. Rien dans les entrailles avait vraiment changé.

La couche d'accès de base de données SQL Server utilisait DBLIB et n'a pas été re-wrtten jusqu'à ce que nous avons amélioré SQL Server.

Answer 4

Nous avons plusieurs systèmes de ce genre. La partie inquiétante de tout cela est l'état de soutien du cycle de vie de VB6. Il y a un risque (si petit) que vous ne serez pas en mesure d'obtenir l'aide de Microsoft avec un problème de Showstopper avec par exemple une future mise à niveau du serveur, et ne pas avoir la capacité de réparer vous-même (par exemple, en raison d'incompatibilités entre la DLL VB6 et le serveur patché O / S). Ce risque est votre gestion pourrait être intéressé - mais, si vous le faites, ils sont peut-être pas des accords de soutien maintenant à l'aise avec ça?

Nous cherchons en fait à la réécriture et redessiner quelques-unes des plus critiques. Nous avons essayé l'évolution progressive, et il peut fonctionner, mais en fait un (disons) opérations intéressantes et la situation d'entretien. Je recommande fortement tout instrumentant (ancien et nouveau code) avec beaucoup d'exploitation forestière configurable, si vous n'êtes pas déjà, pour aider à l'isolement de défaut.

COM sonne comme une interface raisonnable entre héritage et nouvelle. Sauf si vous avez très simples interactions entre les composants, je ne vois vraiment pas pourquoi vous souhaitez revenir à un mécanisme IPC plus basique. COM a sa complexité, mais il offre aussi beaucoup d'abstractions utiles pour exemple la saisie des données et des versions que vous auriez à réinventer et à maintenir ...

Answer 5

Je pense que vous devez regarder vos chemins de mise à niveau pour vos clients. Le fait est que, à un moment donné quand ils ont 16 unités centrales de base que vous allez vouloir accélérer les choses à la concurrence vers le haut. Vous avez donc un cas d'affaires pour se éloigner forme VB6 et vers WCF. WCF a construit dans le support de la simultanéité et la synchronisation. Il peut être utilisé pour la communication locale en proc ainsi que inter-processus et la communication inter-machine. Il a aussi l'avantage de vous permettre de faire plus des émissions de type AOP.

Answer 6

Je suis actuellement un des développeurs travaillant sur un grand système existant qui a commencé comme une combinaison de C et C ++ avec Win32 et, plus tard, MFC avec une poignée d'assemblage entre le code extrémité C retour. Nous avons récemment fait un bond de VC ++ 6 à Visual Studio 2005 (et ont depuis mis à niveau vers 2008) pour la dernière version du projet que nous travaillons. Depuis la mise à niveau IDE / compilateur, nous avons nettoyons certains de l'apparence et ont ajouté géré C ++ avec WinForms et maintenant C # avec WCF.

Alors que les fondements de notre système, y compris l'arrière, restent presque certainement en C (au moins pour l'avenir prévisible), quelque chose de nouveau à l'avant sera très probablement fait en C # / WCF. Lorsque nous avons le temps et / ou le besoin, nous avons l'intention de commencer à remplacer les pièces plus anciennes de l'avant avec l'équivalent C # / code WCF.