S'il est décidé que notre système nécessite une refonte, quelle est la meilleure façon de s'y prendre?

Question

Nous maintenons une application Web construite sur Classic ASP en utilisant VBScript comme langue principale. Nous sommes d’accord sur le fait que notre backend (cadre si vous voulez) est périmé et ne nous fournit pas les outils nécessaires pour aller de l’avant rapidement. Nous avons à peu près adopté le modèle WebMVC actuel qui est omniprésent et nous ne pouvons pas le faire de manière raisonnable avec la technologie actuelle. Les principales caractéristiques manquantes sont, entre autres, la répartition correcte et la modélisation avec héritage.

Actuellement, deux chemins sont en cours de discussion:

1. Portez l’application existante vers ASP classique à l’aide de JScript, ce qui nous permettra, espérons-le, d’aller de là-bas à MSJscript .NET sans trop de peine et d’aboutir finalement sur la plate-forme .NET (de préférence le travail sur MVC sera terminé , ASP.NET n’est pas bien meilleur qu’on ne l’est actuellement, à notre avis). Cela a été présenté comme la voie la plus sûre avec moins de risques que la suivante, bien que cela puisse prendre un peu plus longtemps.
2. Réécrivez complètement l’application en utilisant une autre technologie. À l’heure actuelle, Python WSGI en est le leader, avec un cadre personnalisé, ORM, et une bonne solution de création de modèles. Il y a une marge de manœuvre ici même pour django et d'autres solutions préconfigurées. Nous espérons que cette méthode sera la solution la plus rapide, car nous lancerions probablement une version bêta à côté du produit réel, mais elle risque de causer une grosse perte de temps si nous ne pouvons pas / ne pouvons pas bien faire les choses.

Cela ne signifie pas pour autant que notre logique a disparu, car ce que nous avons construit au fil des ans est assez stable, comme il a été dit, il est difficile de traiter avec. Il est construit sur SQL Server 2005 avec un usage intensif des procédures stockées et publié sur IIS 6, juste pour vous donner un peu plus d’information.

Maintenant, la question. Quelqu'un a-t-il emprunté l'un des deux chemins ci-dessus? Si oui, cela a-t-il réussi, comment aurait-il pu être meilleur, etc. Nous ne cherchons pas à nous écarter de l'une de ces choses, mais quelques suggestions ou solutions pourraient être potentiellement utiles.

Answer 1

Ne jetez pas votre code!

C’est la pire erreur que vous puissiez commettre (sur une base de code volumineuse). Voir choses que vous ne devriez jamais faire, première partie .

Vous avez investi beaucoup d’efforts dans cet ancien code et corrigé de nombreux bugs. Le jeter est une erreur classique des développeurs (et une erreur que j'ai souvent répétée). Cela vous fait sentir "mieux", comme un nettoyage de printemps. Mais vous n'avez pas besoin d'acheter un nouvel appartement et tous les nouveaux meubles pour équiper votre maison. Vous pouvez travailler sur une pièce à la fois ... et peut-être que certaines choses nécessitent juste un nouveau travail de peinture. C’est pourquoi la refactorisation entre en jeu.

Pour de nouvelles fonctionnalités dans votre application, écrivez-le en C # et appelez-le à partir de votre ASP classique . Vous serez obligé d'être modulaire lorsque vous réécrivez ce nouveau code. Lorsque vous en avez le temps, reformulez des parties de votre ancien code également en C # et corrigez les bugs au fur et à mesure. Finalement, vous aurez remplacé votre application par tout nouveau code.

Vous pouvez également écrire votre propre compilateur. Nous en avons écrit un pour notre application ASP classique il y a longtemps pour nous permettre de générer du PHP. Cela s'appelle Wasabi et je pense que c'est la raison pour laquelle Jeff Atwood pensait que Joel Spolsky sortit de sa bascule. En fait, nous devrions peut-être simplement l'expédier, et vous pourrez ensuite l'utiliser.

Cela nous a permis de basculer l'intégralité de notre base de code vers .NET pour la prochaine version en ne réécrivant qu'une très petite partie de notre source. Cela a également amené beaucoup de gens à nous traiter de fous, mais écrire un compilateur n’est pas si compliqué, et cela nous a donné beaucoup de flexibilité.

En outre, s'il s'agit d'une application interne uniquement, laissez-la simplement. Ne le réécrivez pas - vous êtes le seul client et si l'exigence est de l'exécuter en tant qu'asp classique, vous pouvez y répondre.

Answer 2

Utilisez cette opportunité pour supprimer les fonctionnalités inutilisées! Allez certainement avec la nouvelle langue. Appelez ça 2.0. Ce sera beaucoup moins de travail de reconstruire les 80% dont vous avez vraiment besoin.

Commencez par nettoyer votre cerveau de toute l'application. Asseyez-vous avec une liste de ses objectifs globaux, puis décidez quelles fonctionnalités sont nécessaires en fonction de celles qui sont utilisées. Puis modifiez-le en fonction de ces fonctionnalités et construisez-le.

(J'aime supprimer le code.)

Answer 3

Cela fonctionne mieux que vous ne le croyez.

Récemment, j’ai fait un gros travail d’ingénierie inverse sur une vieille collection hideuse de code C. Fonction par fonction, j'ai réaffecté les fonctionnalités toujours pertinentes aux classes, rédigé des tests unitaires pour les classes et créé ce qui ressemblait à une application de remplacement. Il présentait une partie du "flux logique" d'origine. à travers les classes, et certaines classes étaient mal conçues [C'était principalement à cause d'un sous-ensemble de variables globales qu'il était trop difficile de séparer.]

Il a réussi les tests unitaires au niveau classe et au niveau application global. La source existante était principalement utilisée comme une sorte de "spécification en C". pour dénicher les règles commerciales vraiment obscures.

L'année dernière, j'ai rédigé un plan de projet visant à remplacer COBOL, âgé de 30 ans. Le client était penché vers Java. J'ai prototypé le modèle de données révisé en Python en utilisant Django dans le cadre de l'effort de planification. Je pouvais faire la démonstration des opérations principales avant d’avoir terminé la planification.

Remarque : Il était plus rapide de créer un modèle et une interface d'administration dans Django que de planifier le projet dans son ensemble.

En raison de l'option "Nous avons besoin d'utiliser Java". mentalité, le projet résultant sera plus grand et plus coûteux que de terminer la démo de Django. Sans valeur réelle pour équilibrer ce coût.

De plus, j’ai fait le même "prototype de base" dans Django " pour une application de bureau VB devant devenir une application Web. J'ai construit le modèle dans Django, chargé les données existantes et je suis devenu opérationnel en quelques semaines. J'ai utilisé ce prototype fonctionnel pour spécifier le reste de l'effort de conversion.

Remarque : je disposais d'une implémentation Django de travail (pages de modèle et d'administration uniquement) avec laquelle je planifiais le reste de l'effort.

La meilleure partie de ce type de prototypage dans Django est que vous pouvez jouer avec le modèle, les tests unitaires et les pages d’administrateur jusqu’à ce que vous obteniez droit . Une fois que le modèle est correct, vous pouvez passer le reste de votre temps à manipuler l'interface utilisateur jusqu'à ce que tout le monde soit heureux.

Answer 4

Quoi que vous fassiez, voyez si vous parvenez à suivre un plan ne vous obligeant pas à porter l’application en un seul coup. Il est tentant de tout rejeter et de repartir de zéro, mais si vous parvenez à le faire progressivement, les erreurs que vous commettez ne coûteront pas si cher et causeront autant de panique.

Answer 5

Il y a un an et demi, j'ai repris une grande application Web (heureusement déjà en Python) qui présentait certaines lacunes architecturales majeures (modèles et code mélangés, duplication de code, vous l'appelez ...).

Mon objectif est que le système réponde éventuellement à WSGI, mais je n’y suis pas encore. J'ai trouvé le meilleur moyen de le faire, c'est par petites étapes. Au cours des 6 derniers mois, la réutilisation de code a augmenté et les progrès ont été accélérés.

Principes généraux qui ont fonctionné pour moi:

1. Jeter le code qui n'est ni utilisé ni commenté
2. Jetez tous les commentaires inutiles
3. Définissez une hiérarchie de couche (modèles, logique métier, logique d'affichage / contrôleur, logique d'affichage, etc.) de votre application. Cela ne doit pas être une architecture très claire, mais plutôt vous aider à réfléchir aux différentes parties de votre application et à mieux catégoriser votre code.
4. Si quelque chose viole de manière flagrante cette hiérarchie, modifiez le code incriminé. Déplacez le code, recodez-le à un autre endroit, etc. Simultanément, ajustez le reste de votre application pour utiliser ce code à la place de l'ancien. Jetez l'ancien s'il n'est plus utilisé.
5. Conservez des API simples!

Les progrès peuvent être laborieusement lents, mais devraient en valoir la peine.

Answer 6

Je ne recommanderais pas JScript, car c’est définitivement la route la moins fréquentée. ASP.NET MVC évolue rapidement et je pense que vous pourriez commencer sa migration vers celle-ci, en augmentant simultanément l’environnement ASP.NET MVC au fur et à mesure de la finalisation. Une autre option serait d’utiliser quelque chose comme ASP.NET w / Subsonic ou NHibernate.

Answer 7

N'essayez pas de passer à la version 2.0 (davantage de fonctionnalités existent actuellement ou sont planifiées), mais construisez votre nouvelle plate-forme dans le but de résoudre les problèmes actuels avec la base de code (maintenabilité / vitesse / wtf).

Answer 8

Si vous envisagez de passer à Python, commencez par réécrire votre interface administrateur dans Django. Cela vous aidera à résoudre certains problèmes pour que Python soit opérationnel avec IIS (ou pour le migrer vers Apache). En parlant de cela, je recommande isapi-wsgi . C’est de loin le moyen le plus simple de se familiariser avec IIS.

Answer 9

Je suis d'accord avec Michael Pryor et Joel sur le fait qu'il est presque toujours préférable de continuer à faire évoluer votre base de code existante plutôt que de réécrire à partir de zéro. Il existe généralement des possibilités de ré-écrire ou de re-factoriser certains composants pour améliorer les performances ou la flexibilité.