Si MVP vs MVC est votre principal problème, vous pouvez probablement choisir librement.
Il y a trois facteurs qui influencent cette décision: votre expérience précédente, la prise en charge de votre infrastructure/bibliothèques et qui correspond mieux à la base de code existante. Dans mon expérience, les deux modèles s'inscrivent dans des applications C++ héritées comme le chat puke sur un gâteau de mariage. Vos principaux défis seront les suivants:
- Ne rien casser. Heck, il est probablement pas tout casser
- Remarquant que vous êtes réellement aller de l'avant
- Faire que de petits changements qui ne nécessitent pas une ré-écriture de trois mois de certains composants
Le reste est très générique pour traiter des applications héritées, non liées aux spécificités de votre question. Je vais le laisser ici puisque vous avez aussi une partie générique.
Rewrite vs Refactor Vous avez déjà déclaré votre décision, donc je viens de mettre en avant les arguments de réécriture pro à considérer: si vous avez une spécification claire et comprendre comment les utilisateurs actuels utilisent cette application, une ré-écriture peut être plus rapide et moins cher lorsque 30% ou plus du code nécessite des modifications. (Cela ne signifie pas « tout réécrire », cela peut vouloir dire aussi réduisant l'application à la logique seule, puis la plantation d'une nouvelle couche de présentation sur le dessus de celui-ci)
En supposant que vous allez pour refactor:
Définissez vos objectifs Pourquoi avez-vous besoin de refactoriser l'application? Les bonnes raisons pourraient être de nombreuses nouvelles fonctionnalités à mettre en œuvre, la couche de présentation doit être remplacée, ou à boguer pour rester sain d'esprit. À partir de là, décidez ce qui doit changer et ce qui peut rester tel qu'il est.
Vous avez déjà choisi votre objectif: MV *. Je veux juste que vous pensiez aux avantages pour le client et le propriétaire du code à long terme.
Lecture du code. Non, vraiment, prenez votre temps pour vous habituer à la base de code. Parcourez-le avec le débogueur. Essayez de comprendre les choses impliquées. Prenez des notes sur les améliorations que vous pensez que vous devriez apporter.
Créer des tests - principalement des tests de régression pour le comportement actuellement souhaité. Avec les bases de code héritées, elles sont le plus souvent manuelles, alors créez des protocoles de test qu'un crétin peut suivre, et essayez de trouver un non-crétin qui peut exécuter ces tests de temps en temps. Essayez d'obtenir des cas d'utilisation d'utilisateurs existants.
S'en tenir à de petits changements réversibles Si une étape de refactorisation se passe mal, elle doit être suffisamment petite pour être jetée sans hésitation. Parfois, ce n'est pas facile, mes étapes les plus défavorables typiques sont:
- décider quelle fonctionnalité remplacer. Faire des plans comment le nouveau code devrait ressembler. - déplacer le code existant derrière une interface qui fonctionne aussi pour le nouveau code - Test - remplacer la fonctionnalité avec votre nouveau code - Test - parfois, l'interface est « finale », vous Somethimes pouvez supprimer/réduire
Toujours améliorer Ne pas accepter les retraits de fonctionnalité qui "peuvent être corrigés plus tard".
La terminologie est-elle passée de "client lourd" à "client lourd"? Ou est-ce que FAT a d'autres significations au-delà de l'épaisseur? – Ants
@Ants: il a toujours été "gros" dans le contexte d'applications comme celle-ci. Vous pensez que les terminaux je pense? – Thorarin
Avec quel framework ou boîte à outils l'interface graphique est-elle implémentée? –