Voulez-vous redessiner complètement sous .Net?

Question

Une application très vaste a commencé comme un système basé sur l'accès (pour le stockage de base de données). Les formulaires ont été écrits dans VB5 et / ou VB6. Comme .Net est devenu un incontournable dans la communauté du développement, certains modules ont été réécrits. Cela semble très maladroit et juste potentiellement coûteux à maintenir en raison des technologies transversales et du travail supplémentaire pour garder les deux technologies heureux les uns avec les autres. Bien sûr, l'application utilise un mélange de ODBC OleDb et MySql.

penseriez-vous passer le temps et les ressources pour complètement re-développer l'application en .Net serait plus rentable? Dans un effort pour développer une application plus stable, ne serait-il pas logique utiliser .Net? Ou continuer la poursuite des bugs d'accès, l'ajout de nouvelles fonctionnalités dans .Net (qui peut ou ne peut pas créer de nouveaux bogues entre .Net et Access), et la réécriture de vieux modules d'accès en modules .Net sous contraintes de temps qui empêchent la conception et le développement?

Mise à jour L'application utilise OleDb et MySql - je corrige ma déclaration précédente.

En outre, de prêter un soutien supplémentaire à la réécriture: J'ai découvert depuis que lorsque le « portage » .Net a commencé, le code VBA / VB6 qui existait a été essentiellement traduit à l'équivalent .Net . De ma compréhension, rien n'a été fait pour améliorer les performances, ou tirer profit des nouvelles bibliothèques ou technologies.

À mon avis, cela crée une application très fragile et instable. Avec chaque nouvelle mise à jour, cela devient de plus en plus visible. En tant que technicien help desk, je l'ai remarqué une augmentation des problèmes signalés. Les clients utilisant le logiciel ont remarqué une augmentation des problèmes et sont le commenter.

Answer 1

Beaucoup de gens découragent la réécriture d'une application à partir de zéro et parfois je suis d'accord avec le raisonnement. Mais la plupart du temps je trouve rewrting l'application de la solution moins douloureuse et quoi que ce soit écrit dans l'accès doit être porté sur .NET - période. Ne vous méprenez pas, l'accès a sa place et peut fournir beaucoup de fonctionnalités à une organisation, mais si elle se transforme en une application à part entière que les gens comptent sur il a un accès aux adulte.

Il ne serait probablement pas prendre beaucoup de temps au port le extisting VBA .NET dans un autre pour une conversion. Mais cela ne peut pas être une excellente solution si la VBA est pas très bon pour commencer. Une nouvelle conception / réécriture prendra plus de temps à écrire mais à long terme beaucoup plus facile à entretenir.

Je suis presque toujours dans le camp de réécrire à partir de zéro où l'accès est concerné et n'a pas regretté une fois.

Answer 2

Je suis d'accord avec l'approche de refactoring. Il est fort probable que ce sera un processus lent qui peut prendre plusieurs mois pour terminer, mais en déplaçant une caractéristique / section à la fois présente des avantages majeurs, notamment:

1. Caractéristiques du produit sont maintenues.
2. capacité à fournir une nouvelle version est maintenue.
3. La pression du temps est supprimée.

Bonne chance

Answer 3

Il est généralement une pratique découragée à « réécrire » une application à partir de zéro (ce qui est une envie normale la plupart des programmeurs ressenti au moins quelques fois dans leur vie) parce que vous passer d'une application avec jeu de fonctionnalités connues (et bugs connus aussi) à une application plus ensemble avec probablement moins de fonctionnalités et plus important encore - des bugs inconnus. Les utilisateurs peuvent être frustré, etc.

Vous serait probablement mieux si vous lentement refactorisé votre application sur une période de temps, évoluant ainsi l'architecture de sur une plus longue période de temps.

Answer 4

Un grand défi que j'ai vécu avec une ré-écriture de cette échelle est d'avoir à maintenir deux codebases en même temps. Si vous corrigez un bogue dans le système existant, vous devez vous assurer que la fonctionnalité fonctionne correctement dans le nouveau système, et vice versa. La mise à niveau d'un module à un minimise le temps que les maux de tête d'entretien.

Une suite de tests de régression complète qui fonctionne aussi bien sur l'héritage et des systèmes de remplacement serait également utile.

Answer 5

Je suis d'accord avec Jas, ne pas réécrire des applications pour le simple plaisir de réécriture. Ils ne peuvent jamais besoin d'être amélioré ou débogué, alors pourquoi perdre du temps? Toutefois, si vous pensez qu'il ya un changement en mouvement dans l'expertise de vos nouveaux employés de développement loin de l'accès à .NET, vous pouvez avoir à migrer avant qu'il ne soit trop tard. Cela semble peu probable, mais une considération possible.

Bien qu'il ne peut pas être rentable du point de vue du développement, comment ayant des applications réparties autour de perturber les utilisateurs? Est-il besoin de plus de formation de l'utilisateur? Sont-ils faire plus d'erreurs. Est-il augmenter le nombre d'appels de soutien parce qu'ils ne peuvent pas trouver quelque chose?

Answer 6

« penseriez-vous passer le temps et les ressources pour complètement redévelopper l'application en .Net serait plus rentable? »

Ce n'est pas une question qui peut répondre ici.

Du haut de la pyramide des besoins: quelqu'un a pris une décision qu'il espère pouvoir justifier d'un plan d'affaires. Dans ce plan d'affaires, il devrait indiquer combien d'heures + coûts supplémentaires qu'il faut pour convertir l'application et dans le même plan d'affaires les avantages sont exprimés aussi en termes sur l'argent.

C'est la façon de le faire. S'il n'y a pas de plan d'affaires pour elle. alors la réponse est d'abord travailler sur un plan d'affaires traçables à certains cas d'utilisation de haut niveau pour faire l'analyse d'impact pour vérifier le début du projet.

Si le pilote d'origine de l'objectif d'affaires menant au changement est même pas basée sur l'argent, alors cette personne est probablement celui de payer pour tout cela il faut le faire.

S'il n'y a pas de plan d'affaires, mais « il est juste fait » puis essayer de faire un et de le présenter à la haute direction. Inclure les utilisations de haut niveau cas, les coûts, les heures de refonte, la construction, le coût supplémentaire pour les opérations, une nouvelle formation pour les admin et endusers, gestion de projet et les risques potentiels.

à mon humble avis ce n'est pas question d'ordre technique.