Démarrage d'une architecture cohérente dans une application héritée

J'ai la responsabilité d'un grand site Web basé sur Asp.Net. Il s'agit actuellement d'un site Web (et non d'une application Web), de certains services Windows et d'un certain nombre de bibliothèques de classes.

La couche de données utilise un mélange de LLBLGEN et Linq To LLBGen, ainsi qu'un certain nombre d'instances de SQL inline hérité qui n'ont pas été refactorisées.

Il existe certaines implémentations de type gestionnaire, mais dans de nombreux cas, l'application présente l'anti-modèle Smart UI (c'est-à-dire trop de logique métier dans le code derrière les classes)

Le site est relativement fréquenté et les performances sont bonnes, mais nous augmentons notre capacité de développement à une équipe d'environ 10 personnes, et il est de plus en plus clair que nous avons besoin d'une conception en couches globale au-dessus du middleware existant.

Ma question est par où commencer? Nous avons 10 ans de code (dont une partie vient encore de migrer des éléments ASP Classic), de nombreuses approches et styles différents.

La refactorisation de la base de code entière n'est pas réaliste et, probablement pas souhaitable

Je sais que ce n'est pas une situation nouvelle, y a-t-il des idées ou des concepts utiles sur la façon d'aborder ce problème?

J'ai également travaillé dans des situations similaires et je peux vous donner les conseils suivants.

1. Vous devez réduire la dette technique . Maintenant. Pourquoi? Parce que la dette technique est comme la dette financière. Vous paierez des intérêts dessus.
2. Étant donné que la refactorisation de la base de code entière n'est pas possible, demandez-vous: qu'est-ce qui l'empêche? Est-ce simplement trop de travail? Pourquoi?
3. Créez un plan pour réduire la dette technique à temps. Par exemple, en définissant des règles comme " chaque bit de code touché par l'équipe doit être corrigé / refactorisé selon la nouvelle norme ". Typiquement: les tests unitaires doivent être écrits, le code doit être déplacé dans les bonnes couches, etc. Cela vous permet de corriger beaucoup de code sans avoir recours à des projets de «refactoring» ridiculement chers et de faible valeur.
4. Enveloppez la merde. Le découplage est la clé du refactoring et d'une bonne architecture. Si vous pouvez partitionner la base de code d'une manière ou d'une autre, vous pouvez peut-être refaçonner des bits plus petits.
5. N'augmentez pas davantage la dette technologique. N'augmentez pas davantage la dette technologique. N'augmentez pas davantage la dette technologique. Ne pas...

Vous avez raison de penser que la refactorisation de la base de code entière n'est pas souhaitable. La refactorisation est quelque chose que vous faites avant un nouveau développement pour rendre ce développement plus fluide. Si vous ne prévoyez pas de modifier tout le code de votre base de code, le refactoring va s'avérer une utilisation inefficace du temps.

Quelques conseils en plus de ce que dit Sklivvz:

1. Séparez le code en sections fréquemment et rarement modifiées. Seules les sections fréquemment modifiées doivent être pleinement intégrées dans la nouvelle architecture. Intégrez le code rarement modifié à la nouvelle architecture en utilisant le moins de changements possible (ou aucun changement si vous pouvez vous en sortir). Résistez à la tentation de la réécriture complète, cela coûtera plus que ce que vous en gagnez. Appréciez que le code existant fonctionne, même s'il est moche.

2. Découvrez quel est votre objectif de refactoring. Voulez-vous faciliter l'accès au contenu du site? Vous avez beaucoup de bugs et souhaitez améliorer la qualité perçue par l'utilisateur? Souhaitez-vous plutôt réduire le temps de développement des fonctionnalités? Ou voulez-vous principalement une meilleure UX? Votre architecture devrait faciliter la refactorisation du code pour atteindre les objectifs que vous vous êtes fixés. N'oubliez jamais que le principal bénéficiaire de votre refactoring doit être votre utilisateur / client / entreprise. Un code plus propre n'est pas un objectif en soi, c'est une méthode pour une fin, et la fin implique un utilisateur.

3. Essayez de trouver autant d'architectures de référence que possible et n'hésitez pas à les copier. Ne réinventez pas la roue. Si quelqu'un d'autre a une architecture qui fonctionne bien pour des sites comme le vôtre, apprenez d'eux.

4. Pensez à l'aspect gestion des personnes. Dans mes propres projets de migration, la partie la plus difficile a été de faire apprendre aux gens les nouvelles manières et de s'y tenir. Vous aurez besoin d'implémentations de référence et d'un moyen d'enseigner l'architecture à tous les membres de l'équipe (anciens et nouveaux). Pour réduire la résistance au changement, demandez l'avis de tous les membres de l'équipe avant de prendre des décisions. Assurez-vous que le nouveau design améliore réellement les choses du point de vue personnel des développeurs, et n'est pas un si grand bond qu'ils se sentent hors de leur profondeur.

La chose la plus importante que j'ai vue en essayant de gérer une ancienne base de code est de NE PAS continuer à changer ce que vous visez. Autrement dit, déterminez l'architecture que vous souhaitez, puis COLLEZ AVEC CE PLAN! L'un des gros problèmes de ma dernière position était que la base de code avait plusieurs idées différentes de ce à quoi elle devrait ressembler au fil du temps. Chaque fois qu'une nouvelle idée était essayée, une partie du code était convertie, d'autres non, puis quelqu'un d'autre avait une «meilleure» idée. Il est devenu de plus en plus incohérent au fil du temps et a finalement été abandonné.

Il y a un très bon livre / pdf gratuit sur la réingénierie des anciens logiciels: http://scg.unibe.ch/download/oorp/

Il indique OO dans le titre, mais la plupart des idées s'appliquent à n'importe quel logiciel. Il explique par où commencer, comment gérer les différentes parties d'un système pendant la restructuration et beaucoup plus de ces sujets.

S'il n'a pas une architecture cohérente, c'est parce que la direction ne comprend pas / ne se soucie pas du problème. Il suffit de coder. Vous devez introduire une nouvelle bonne architecture lorsque vous écrivez du nouveau code.

Vous ne devriez ré-architecturer les choses que si elles commencent à avoir des bugs vraiment sérieux, vous devez les étendre et tout simplement pas, ou cela ne correspond tout simplement pas à ses exigences.

Je dis essentiellement que vous vous souciez uniquement des problèmes qui préoccupent réellement vos gestionnaires, et non des problèmes dont ils se soucieraient s'ils avaient vos connaissances.

Si vous pouvez vendre une réarchitecture à la direction, commencez par tester. S'ils ne veulent pas investir dans les tests, vos efforts ne vous causeront que des ennuis.