Quand est-ce qu'un gros réécrire la réponse?

Il suffit de lire la question sur les grands récrivains et je me suis souvenu d’une question à laquelle je voulais bien répondre moi-même.

J'ai un projet horrible qui m'a été transmis, écrit en vieux Java, en utilisant Struts 1.0, des tables avec des relations incohérentes ou aucune relation et même des tables sans clés primaires ni champs destinés à être des clés primaires mais pas uniques du tout. D'une manière ou d'une autre, la plupart des applications "fonctionnent". La plupart des pages sont réutilisées (code collé) et codées en dur. Tous ceux qui ont déjà travaillé sur le projet l'ont maudit sous une forme ou une autre.

J'avais depuis longtemps envisagé de proposer à la direction une réécriture totale de cette application épouvantable. J'essaie lentement de gagner du temps, mais j'estime vraiment que cela mérite des ressources dédiées pour y arriver. Après avoir lu les articles sur les grandes réécritures, je réfléchis. Et ce n’est pas bon quand je veux convaincre mes supérieurs d’appuyer ma réécriture. (Je travaille dans une assez petite entreprise, la proposition a donc la possibilité d'être approuvée)

TL; DR Quand est une grande réécriture de la réponse et quels arguments pouvez-vous utiliser pour le soutenir?

Désolé, cela va être long, mais c'est basé sur une expérience personnelle d'architecte et de développeur sur plusieurs projets de réécriture.

Les conditions suivantes devraient vous amener à envisager une sorte de réécriture. Je parlerai de la façon de décider laquelle faire après cela.

• Le temps de montée en charge du développeur est très élevé. Si cela prend plus de temps que ci-dessous (par niveau d'expérience) pour mettre en place un nouveau développeur, le système doit être repensé. Par temps de montée, j'entends le temps qu'il faut avant que le nouveau développeur soit prêt à faire son premier commit (sur une petite fonctionnalité)
  • Tout juste sorti du collège - 1 mois et demi
  • Toujours vert, mais j'ai déjà travaillé sur d'autres projets - 1 mois
  • Niveau moyen - 2 semaines
  • Expérimenté - 1 semaine
  • Niveau supérieur - 1 jour
• Le déploiement ne peut pas être automatisé en raison de la complexité de l'architecture existante
• Même les corrections de bogues simples prennent trop de temps en raison de la complexité du code existant
• Les nouvelles fonctionnalités prennent trop de temps et coûtent trop cher en raison de l'interdépendance de la base de code (les nouvelles fonctionnalités ne peuvent pas être isolées et affectent donc les fonctionnalités existantes)
• Le cycle de test formel prend trop de temps en raison de l'interdépendance de la base de code existante.
• Trop de cas d'utilisation sont exécutés sur trop peu d'écrans. Cela pose des problèmes de formation pour les utilisateurs et les développeurs.
• La technologie dans laquelle se trouve le système actuel l'exige
  • Les développeurs de qualité expérimentés dans la technologie sont trop difficiles à trouver
  • Il est obsolète (il ne peut pas être mis à niveau pour prendre en charge de nouvelles plates-formes / fonctionnalités)
  • Il existe simplement une technologie beaucoup plus expressive de haut niveau disponible
  • Le coût de maintenance de l'infrastructure de l'ancienne technologie est trop élevé

Ces choses sont assez évidentes. Quand décider d'une réécriture complète par opposition à une reconstruction incrémentale est plus subjectif et donc plus chargé politiquement. Ce que je peux affirmer avec conviction, c'est qu'affirmer catégoriquement que ce n'est jamais une bonne idée est une erreur.

Si un système peut être repensé progressivement et que vous bénéficiez du soutien total du parrainage de projet, vous devriez le faire. Voici le problème, cependant. De nombreux systèmes ne peuvent pas être repensés progressivement. Voici quelques-unes des raisons que j'ai rencontrées qui empêchent cela (à la fois techniques et politiques).

• Technique
  • Le couplage des composants est si élevé que les modifications apportées à un seul composant ne peuvent pas être isolées des autres composants. Une refonte d'un composant unique entraîne une cascade de modifications non seulement pour les composants adjacents, mais indirectement pour tous les composants.
  • La pile technologique est si compliquée que la conception de l'état futur nécessite de multiples changements d'infrastructure. Cela serait également nécessaire dans une réécriture complète, mais si cela est requis dans une nouvelle conception incrémentielle, vous perdez cet avantage.
  • La refonte d'un composant entraîne néanmoins une réécriture complète de celui-ci, car la conception existante est si complexe qu'il n'y a rien qui mérite d'être sauvegardé. Encore une fois, vous perdez l'avantage si c'est le cas.
• Politique
  • On ne peut faire comprendre aux sponsors qu’une refonte progressive nécessite un engagement à long terme dans le projet. Inévitablement, la plupart des organisations perdent l'appétit pour la perte de budget permanente créée par une refonte progressive. Cette perte d’appétit est également inévitable pour une réécriture, mais les promoteurs seront plus enclins à continuer, car ils ne veulent pas être séparés entre un nouveau système partiellement complet et un ancien système partiellement obsolète.
  • Les utilisateurs du système sont trop attachés à leurs "écrans actuels". Si tel est le cas, vous ne disposez pas de la licence nécessaire pour améliorer une partie essentielle du système (le système frontal). Une refonte vous permet de contourner ce problème, car ils commencent par quelque chose de nouveau. Ils insisteront toujours pour obtenir «les mêmes écrans», mais vous avez un peu plus de munitions à repousser.

N'oubliez pas que le coût total de la reconception incrémentielle est toujours supérieur à celui d'une réécriture complète, mais l'impact sur l'organisation est généralement moindre. À mon avis, si vous pouvez justifier une réécriture et que vous avez des développeurs superstar, faites-le.

Ne le faites que si vous pouvez être certain qu'il existe une volonté politique de le mener à bien. Cela signifie une adhésion des dirigeants et des utilisateurs finaux. Sans cela, vous échouerez. Je suppose que c'est la raison pour laquelle Joel dit que c'est une mauvaise idée. L’adhésion des dirigeants et des utilisateurs finaux ressemble à une licorne à deux têtes pour de nombreux architectes. Vous devez le vendre agressivement et faire campagne pour qu'il soit maintenu jusqu'à ce qu'il soit terminé. C'est difficile, et vous parlez de mettre votre réputation sur quelque chose que certains ne voudront pas voir réussir.

Quelques stratégies pour réussir:

• Si vous le faites toutefois, n'essayez pas de convertir le code existant. Concevez le système à partir de zéro. Sinon, vous perdez votre temps. Je n'ai jamais vu ni entendu parler d'un projet de "conversion" qui ne s'est pas avéré lamentable.
• Migrez les utilisateurs vers le nouveau système, une équipe à la fois. Identifiez les équipes qui souffrent le plus avec le système existant et migrez-les d'abord. Laissez-les annoncer la bonne nouvelle de bouche à oreille. De cette façon, votre nouveau système sera vendu de l'intérieur.
• Concevez votre cadre selon vos besoins. Ne commencez pas par une construction I-a passé-6-mois-ce cadre qui n'a jamais vu de code réel.
• Gardez votre pile de technologie aussi petite que possible. Ne pas trop concevoir. Vous pouvez ajouter des technologies si nécessaire, mais les retirer est difficile. En outre, plus vous avez de couches, plus les développeurs ont du travail à faire. Ne le rendez pas difficile dès le départ.
• Impliquez les utilisateurs directement dans le processus de conception, mais ne les laissez pas dicter comment le faire. Gagnez leur confiance en leur montrant que vous pouvez leur donner ce qu'ils veulent mieux si vous suivez de bons principes de conception.

J'ai participé à deux grandes réécritures. Le premier était un petit projet. Le second était le produit principal d’une société de logiciels.

Il y a plusieurs pièges:

• les réécritures prennent toujours plus de temps que prévu.
• les réécritures n'ont aucun effet / bénéfice direct pour le client.
• la capacité consacrée à la réécriture n'est pas utilisée pour aider le client.
• vous perdrez des fonctionnalités avec une réécriture, sauf si vous avez une documentation à 100%.

Les réécritures sont rarement la vraie réponse. Vous pouvez refactoriser une grande partie du code sans rien perdre et sans prendre beaucoup de risques.

Les réécritures peuvent être la réponse si:

• vous passez à une autre langue ou plate-forme.
• vous changez de framework / de composant externe.
• la base de code existante n'est plus maintenable.

Mais je conseille fortement l'approche lente utilisant la refactorisation. C'est moins risqué et vous gardez vos clients heureux.

Il est temps de réécrire quand:

Le coût de la réécriture de l'application et de la maintenance de l'application réécrite est inférieur au coût de la maintenance du système actuel dans le temps.

Quelques facteurs qui rendent le maintien de l'actuel plus coûteux:

• La langue est si ancienne que vous devez payer aux personnes qui le connaissent beaucoup d’argent pour la programmer (COBOL).
• (Malheureusement, par expérience) Le système repose sur une architecture matérielle si ancienne qu’ils doivent parcourir les pièces Ebay et COLLECT pour les ajouter à la machine sur laquelle il est exécuté, car elles ne sont plus fabriquées. C'est ce qu'on appelle le "support vital matériel" et cela coûte cher car, à mesure que les pièces deviennent plus rares, leur prix peut augmenter ou finir par être épuisé.
• C'est devenu tellement complexe que le //Here be dragons.commentaire est partout dans votre code.
• Vous ne pouvez pas écrire d'autres projets et ajouter de la valeur à l'entreprise, car vous corrigez en permanence cette horrible bête.

Si vous souhaitez modifier radicalement l’architecture du projet, il est peut - être temps de tout recommencer.

Même avec cela, il y aura potentiellement de grandes quantités de code qui mériteront d'être réutilisées dans votre nouveau projet.

Tenez compte de l'avertissement juste. Les règles commerciales d’un projet en cours ont été testées et perfectionnées avec d’innombrables heures d’heures d’utilisation réelle, ce qui n’est pas le cas d’un projet démarré à partir de zéro.

Je doute qu'un délai ou un instinct soit une mesure appropriée d'une mesure aussi radicale. Vous devez avoir des raisons claires , défendables et bien comprises de participer à cette démarche.

Bien que je sois d'accord avec la réponse de Kramii et avec l'opinion de Joel, il est parfois approprié de faire une réécriture. Dans les applications à longue durée de vie (10-20 ans ou plus), la maintenance devient de plus en plus coûteuse au fil du temps. Cela est dû au fait que le code devient de plus en plus spaghetti, car l'architecture originale est sacrifiée pour des correctifs de maintenance rapides. En outre, les développeurs de technologies plus anciennes deviennent plus rares et plus coûteux. Enfin, le matériel commence à vieillir et il devient de plus en plus difficile de trouver du nouveau matériel, des systèmes d'exploitation, des infrastructures, etc. pour exécuter l'ancienne application par dessus. En outre, les entreprises évoluent et il est fort probable qu'un ancien système ne répondra plus aux besoins de l'entreprise, contrairement à un tout nouveau système.

Il faut donc peser tous les coûts de maintenance en cours, ainsi que les avantages potentiels d'un nouveau système pour l'entreprise, par rapport au coût de la réécriture à partir de zéro. Soyez très pessimiste dans vos estimations concernant le coût d’une réécriture. Cela coûte presque toujours plus cher et prend plus de temps que vous ne le pensez.

Arrêtez! La réécriture n'est presque jamais la solution. Plus souvent qu'autrement, le refactoring est un meilleur pari.

Bien sûr, il y a des moments où une réécriture est justifiée:

• Vous passez à une nouvelle plate-forme sur laquelle les outils de migration n'existent pas (ou ne peuvent pas être écrits assez cher).
• L'application à réécrire est triviale.
• Le code source de l'application d'origine est perdu et la récupération coûte plus cher que la réécriture.
• La grande majorité des règles métier encapsulées par l'application existante ne sont plus applicables.
• Il y a peu d'utilisateurs actifs du code existant.
• Vous avez la ressource (temps, talent et outils) pour entreprendre la réécriture.
• L'application existante ne peut pas être exécutée dans un environnement de production, pour des raisons juridiques ou pratiques.

Pour comprendre pourquoi je recommande de refactoriser plutôt que de réécrire, réfléchissez à ce qu’est une réécriture. Vous devez:

1. Comprendre les nuances de ce que fait l'application existante. Cela n’est généralement pas anodin lorsque vous tenez compte de toutes les règles métier subtiles qu’il englobe, de son environnement (humain et technique) et des avantages et inconvénients de la solution actuelle. Plus souvent qu'autrement, le seul endroit où cette information existe (le cas échéant) est dans le code source de l'application existante. Il est regrettable que l’une des principales raisons d’exécuter une réécriture soit que le code existant est difficile à comprendre et à maintenir.

2. Reproduisez cette fonctionnalité (ou une version mise à jour) dans une nouvelle application testée et fiable. Le code existant peut ne pas être compris par les développeurs, mais est généralement bien compris par ses utilisateurs. Cela ne répond peut-être pas à leurs besoins commerciaux actuels, mais ils peuvent au moins vous dire ce que l'application fait dans diverses circonstances.

Les principaux avantages de la refactorisation sont les suivants:

• Vous pouvez prendre les choses un petit morceau à la fois.
• Toute modification peut être testée dans le contexte de l’application existante et active.
• Des hypothèses sur le fonctionnement du code existant peuvent être testées en apportant de petites modifications et en observant ce qui se passe.
• Les modifications peuvent souvent être transmises aux utilisateurs par phases plutôt que toutes en même temps.
• Apprendre dès les premières étapes de la refactorisation peut éclairer les étapes ultérieures de la refactorisation.
• Si vous abandonnez le processus à mi-chemin, il restera des avantages en termes de base de code plus propre (par opposition à une réécriture qui doit être complétée pour offrir des avantages à l'utilisateur ou aux développeurs).

N'oubliez pas non plus que si vous effectuez une réécriture, vous êtes assuré d'introduire de nombreux nouveaux bogues et des problèmes dans la nouvelle base de code.

Ce graphique pourrait vous aider, il est fonction de la qualité de la base de code et de la valeur commerciale de l'application:

Le graphique prétend servir de guide pour savoir quand une réingénierie d'un logiciel hérité est justifiée et quand ce n'est pas le cas. Par exemple, si le logiciel a une valeur commerciale élevée et que la qualité du code est médiocre, une réingénierie est alors justifiée.

Je pense que je suis dans la seule situation de ma carrière où la grande réécriture est la réponse:

Fusion de sociétés, superposition importante de la fonctionnalité des systèmes. Beaucoup, beaucoup de systèmes ont été fusionnés et mis à la retraite, et d'autres sont encore en cours.

J'ai hérité d'un système de l'autre société qui existe toujours. Il possède une base de code énorme, qui supportait auparavant plusieurs départements très similaires aux nôtres, mais avec une conception et des cadres complètement différents. Il ne reste plus qu’un secteur d’affaires qui l’utilise, ce qui lui rapporte suffisamment d’argent pour le garder en vie dans un État zombie. Toute l'ancienne expertise est partie, il n'y a pas de documentation. Le fardeau de soutien est élevé, avec des échecs chaque semaine. Il n'a pas été intégré aux systèmes de nos entreprises, car notre entreprise n'a jamais pris en charge ce secteur d'activité. Nous ne disposons donc ni de la fonctionnalité ni de l'expertise requises.

Il semble que ce soit le seul cas où la réécriture est nécessaire. Il semble que je vais devoir trouver ce monstre, extraire les fonctionnalités dédiées à cette activité et réécrire les éléments à ajouter à nos systèmes existants. Une fois que cela est fait, nos systèmes existants peuvent prendre en charge ce nouveau secteur et cette bête peut être mise hors de combat. Sinon, je vais perdre ma santé mentale.

J'ai travaillé pour une petite entreprise de logiciels qui avait quelques applications DOS mises à niveau pour prendre en charge l'an 2000, réécrites en tant qu'application Windows 16 bits, puis totalement réécrites en tant qu'application 32 bits avec une 'petite' fonctionnalité supplémentaire (finalement utilisée uniquement par un client) qui a affecté l’ensemble de la structure.

Déplacer le code 16 bits à 32 aurait pu être fait en un mois par une seule personne, mais NOOOOOOOOO, nous avons dû le réécrire pour rendre Soooooooooo beaucoup mieux. Cette chose pourrait être adaptée à d’autres industries, aurait des spécifications complètes et un code psuedo avant même d’avoir commencé. Les spécifications ont été créées, mais cela a pris si longtemps qu'il n'a même pas eu le temps d'écrire le code réel. Il a été publié tardivement, avec plus de bogues que le 16 bits avec lequel il avait commencé (c'était sur v.3.0 et finalement au point où nous avons presque passé une semaine sans que quelqu'un ait signalé un nouveau bogue).

On pourrait penser que la réécriture de la même application 3 à 4 fois apporterait des améliorations, mais je ne pense tout simplement pas qu'un système d'interface graphique puisse être justifié à ce point.

C'était mon premier emploi en tant que responsable du support technique. Je devrais écrire un livre sur la façon de ne pas développer de logiciels pour la distribution. Évidemment, nous avons commis de nombreuses erreurs, mais le fait de continuer à réécrire les applications a aggravé l’incompétence.

J'ai eu un cas très semblable au vôtre, seulement le code n'utilisait même pas Struts. Ce que j'ai fait à la place, ce sont des zones ciblées qui sont particulièrement nulles et qui posent beaucoup de problèmes. Cette approche ciblée nous a progressivement améliorés.

Au cours d'une période de deux ans, nous avons travaillé sur la refactorisation d'éléments de base, parallèlement à des travaux d'amélioration. Nous avons toujours intégré une tâche de «durcissement» à un plan de projet. En nous concentrant sur les domaines spécifiques qui ne fonctionnaient pas bien, nous en avons eu le plus pour notre argent. Les trucs qui ont fonctionné, nous les avons laissés seuls. Il est également essentiel que ce travail ait été effectué au cours du développement normal et ait été publié. Le problème avec une grosse réécriture est que vous partez pour un an ou plus, puis au moment où vous revenez, tout a changé, de toute façon, et certains des méchants bugs ont été lissés et vous avez perdu votre retour sur investissement.

Nous n'avons jamais réécrit le tout. Nous avons toutefois cessé d'utiliser cette plate-forme pour effectuer de nouveaux travaux et avons mis au point une nouvelle plate-forme nouvelle pour un nouveau grand projet. Cela a été approuvé et nous avons livré un excellent produit dans un délai raisonnable.

Donc, me voilà assis à mon bureau, j'ai commencé à réécrire le code pour ce fouillis absolu d'un gros fichier aspx, la base de données qui le cache, et à remplacer l'interface MS Access de MsSQL.

Ce programme asp est parsemé de choses comme

• include(close.aspx) qui à l'intérieur a une ligne de code qui ferme la dernière connexion ouverte à la base de données.
• Le code hérité vient d'être commenté au hasard
• Aucune considération pour la sécurité
• Code spaghetti, des milliers de lignes de celui-ci. Tout dans un fichier.
• Fonctions et variables sans signification claire derrière leurs noms

Si nous avons besoin de faire un léger changement, c'est comme jouer à cinq jeux simultanés de kal-toh en mode cauchemar.

J'ai été embauché pour reproduire les fonctionnalités et créer un produit pouvant être personnalisé et vendu à d'autres acteurs du secteur. Le problème est que cette chose a été écrite au cours des 10 dernières années pour répondre à tous les besoins des entreprises (eh bien, je dirais qu’en tout cas cinq ou six sigma).

Si nous ne voulions pas vendre le produit, ils n'auraient probablement pas eu besoin d'une réécriture, comme c'est le cas pour la plupart de ce qu'ils veulent - peut-être pas avec élégance, mais il n'était pas prudent de dépenser de l'argent pour faire du beau code 'faire la même chose.'

Joel Spolsky a un excellent article à ce sujet: Choses que vous ne devriez jamais faire, première partie

D'après le titre que vous pouvez dire, c'est un peu à sens unique (il explique pourquoi vous ne devriez jamais lancer de code) IMO, il y a beaucoup de vérité à ce sujet, j'ai récemment vu une vidéo de channel9 sur le 25e anniversaire d'Excel où certains développeurs ont dit, comment Même aujourd'hui, si vous examiniez la source, vous vérifieriez la révision et reviendriez au code utilisé par Excel, écrit il y a 20 ans.

Vous ne pouvez pas être sûr à 100% (même lorsque Netscape a commis des erreurs (tiré de Joels Article)), je me suis senti comme si l'article de Joël avait été envoyé par Dieu, car je peux être pessimiste et aimer jeter du code en pensant que je peux toujours l'écrire mieux une seconde. temps, mais je me suis rendu compte seulement maintenant que cela coûte beaucoup .

Pour donner une réponse concrète, je dirais simplement que vous devez effectuer une analyse approfondie du rapport coût / valeur .

Mon monde réel: Une application silverlight En développement v0.6, les appels asynchrones ont rendu le code si compliqué. Depuis que j'ai découvert Reactive Extensions cette semaine, je souhaite vraiment réécrire la plupart du code, mais que puis-je dire à mon client? Le programme fonctionne parfaitement (avec quelques fuites de mémoire) mais ne s’en fait-il pas? Je ne peux pas leur dire que je prends encore 2-3 semaines parce que je veux refaire quelque chose. Cependant, je vais créer une branche du code et réécrire / jouer avec ce code pendant mon temps libre .

Juste mes 2 cents ok !?

La solution existante ne s'adapte pas.

Je vous regarde, MS Access.

Selon Joel, les grandes réécritures sont la pire erreur stratégique qu'une entreprise puisse commettre:

Choses que vous ne devriez jamais faire, Partie I

... Il est important de se rappeler que lorsque vous partez de zéro, il n'y a absolument aucune raison de croire que vous ferez un meilleur travail que celui que vous avez fait la première fois. Tout d'abord, vous n'avez probablement même pas la même équipe de programmation qui a travaillé sur la première version, vous n'avez donc pas "plus d'expérience". Vous allez à nouveau commettre la plupart des erreurs anciennes et introduire de nouveaux problèmes qui ne figuraient pas dans la version originale.

L'ancien mantra à construire est dangereux lorsqu'il est appliqué à des applications commerciales à grande échelle. Si vous écrivez du code à titre expérimental, vous voudrez peut-être déchirer la fonction que vous avez écrite la semaine dernière en pensant à un meilleur algorithme. C'est très bien. Vous voudrez peut-être refactoriser une classe pour la rendre plus facile à utiliser. C'est bien aussi. Mais abandonner tout le programme est une folie dangereuse, et si Netscape avait réellement une supervision d'adultes avec une expérience dans l'industrie du logiciel, ils ne se seraient peut-être pas aussi bien tirés dans le pied.

Jamais, toujours refactor - la vérité est que si le code a été écrit par vous - vous ne pourrez pas faire mieux.

À moins que vous ne souhaitiez changer de technologie, le code manque de structure (je l'ai vu il y a très longtemps sur un site Web PHP, l'auteur suffit de copier / coller spahgetti au lieu d'inclure / classe / fonction) ou de reprendre quelque chose d'une autre personne très mal écrit.

Tout devrait être conçu comme une boîte noire. Modulaire, API simple, ce qui est à l'intérieur ... c'est moins important :) Si vous avez des spaghettis, vous pouvez peut-être les fermer à l'intérieur d'une boîte noire, pour ne pas contaminer le bon code.

Je pense que la raison principale qui justifie les réécritures est liée aux changements de plate-forme. Par exemple, si vous avez une application graphique de bureau Windows et que le propriétaire de la société décide qu'il souhaite que la prochaine version soit une application Web. Bien que pas toujours, selon mon expérience, cela nécessitera la plupart du temps une réécriture, à moins que les développeurs d'origine n'écrivent du code très modulaire et réutilisable (cela ne se produit presque pas).

Il y a la blague classique à propos de "si j'allais à XI ne partirais pas d'ici".

J'ai déjà occupé un poste où la motivation première de l'employeur était de faire appel à des talents pour lancer une réécriture attendue depuis longtemps d'une application stratégique. La question que je n'ai pas posée était: pourquoi vous êtes-vous retrouvés dans cette situation en premier lieu? Cela aurait dû être un drapeau rouge, si la cause était

• trop de pression pour ajouter des fonctionnalités pour maintenir et refactoriser progressivement la bête,

• trop peu de capacité dans le département,

• trop peu d'adhésion des clients ou de la direction pour un travail incrémentiel,

ou quoi que ce soit, et cette cause disparaît jusqu'à ce que le problème atteigne un niveau intolérable.

Je suis donc d’accord avec Joel sur le fait qu’une réécriture massive est probablement une très mauvaise idée - à moins que vous ne disposiez de preuves solides que toutes les raisons sous-jacentes de la nécessité d’une réécriture majeure semblent avoir été traitées , il est fort probable que vous va répéter le problème en temps voulu.

C'est la solution lorsque la réécriture permet à l'organisation de poursuivre une stratégie qui procure un avantage concurrentiel ou de mieux servir ses clients d'une manière que l'architecture actuelle ne peut pas prendre en charge.

Au lieu de cela, les réécritures atténuent souvent les problèmes de gestion:

• tout devrait être en .NET,
• nos développeurs disent que notre code est nul,
• nous sommes techniquement en retard,
• nous ne serons pas en mesure de trouver des ressources pour soutenir notre système ou, très souvent,
• ça fait dix ans alors il est temps.

La plupart de ces inquiétudes ne se concrétiseront pas et, si tel était le cas, elles pourraient être traitées. Ce dernier, cependant, est le pire. C'est essentiellement: nous n'avons pas de raison.

Oui, tout comme la voiture, un système commencera à montrer des signes d'usure. Cela peut être atténué par un entretien de routine. Vous savez ce qu'ils disent sur le fait qu'un peu d'entretien préventif va un long chemin. En tant qu’investissement, l’entretien courant (c’est-à-dire la refactorisation et la normalisation) aura presque toujours un coût inférieur à celui d’une réécriture.

Cependant, nous devons prévoir qu’une réécriture sera éventuellement nécessaire. Fixez les dates et planifiez-les provisoirement, mais au fur et à mesure que la date approche, vous réaliserez d'autres objectifs stratégiques jusqu'à ce que vous ayez une raison impérieuse comme ...

Ces dernières années, nous avons perdu la possibilité de gagner de gros comptes car nous ne pouvions pas répondre à leurs besoins de manière opportune et coûteuse. Notre système sera réécrit en utilisant une architecture extensible qui permet aux personnalisations d'être connectées (et non codées en dur comme nous le faisons actuellement). Cela réduira considérablement le temps et le coût nécessaires pour répondre aux besoins spécifiques des clients. Nous allons gagner plus de comptes et mieux répondre aux besoins de nos clients actuels.

Lorsque vous passez à une toute nouvelle technologie, vous devez disposer des fonctionnalités souhaitées.

"Complètement nouveau": si vous envisagez de réécrire mais que vous utilisez la même plate-forme, le refactoring et une restructuration judicieuse sont certainement la meilleure solution. Le terme "plate-forme", tel qu'il est utilisé ici, est quelque peu vague. Considérez-le comme incluant le langage et peut-être même le système d'exploitation (allant de Linux à Windows ou vice-versa), mais probablement pas de cadre (par exemple, remplacer Struts par Spring).

"Nécessaire pour fournir les fonctionnalités souhaitées": dès l'an 2000, j'ai initié un projet de réécriture d'un composant serveur majeur en Java à partir de C ++ afin d'activer le threading prêt à l'emploi, un cache d'objets et des transactions contrôlées par le client. À l'époque, nous aurions dû prendre en charge plusieurs bibliothèques de threads pour C ++, et une grande partie du code de notre base de données nécessitant une thread aurait nécessité une réécriture quasi totale. En ce qui concerne les transactions contrôlées par le client, cela ne se produira pas avec l'ancienne architecture.

Même dans ce cas, je ne suis pas sûr d’avoir procédé à la réécriture, si ce n’était que j’avais une connaissance détaillée du comportement du système actuel et que c’était un code relativement propre qui n’avait pas développé beaucoup de verrues au cours de ses 11 années de vie.

Pour décider du moment où vous devez recommencer, vous devez déterminer où la valeur de la poursuite de votre projet actuel est inférieure à la valeur de la reprise.

La raison pour laquelle cela est si difficile est que vous faites une estimation précise de la vitesse de développement de l'équipe sur le nouveau projet jusqu'à ce que vous le commenciez réellement. Cela dit, si, en utilisant une estimation TRÈS prudente de votre vitesse de développement sur le nouveau projet, on estime que le projet rapportera un retour sur investissement intéressant, alors vous avez une analyse de rentabilisation pour recommencer à zéro.

Avec ma métrique, vous devez remplir deux conditions pour justifier une réécriture:

1. Après la réécriture, les nouvelles fonctionnalités seront plus faciles / plus rapides / moins boguées à écrire
2. La réécriture prendra moins de temps ou autant que l'ajout de la nouvelle fonctionnalité actuelle.

Même dans ce cas, vous souhaitez limiter la portée de votre réécriture. Par exemple, une entreprise écrite en C ++ possédait des logiciels existants, dans l’esprit d’un programmeur C qui ne connaissait pas la modularité. Le résultat final était un code speghetti sous la forme d'une machine à états finis qui couvrait plusieurs classes et DLL. Nous avions une nouvelle exigence qui était très différente des hypothèses intégrées dans le code et allait faire partie de la valeur ajoutée brevetée de la société pour ses clients.

Après avoir passé du temps avec le code à implémenter d’autres fonctionnalités, j’avais une très bonne idée du temps qu’il faudrait pour déterminer laquelle des nombreuses instructions de basculement je devrais changer, etc. Ma proposition était de réécrire la section de code qui était l'énorme machine à états finis - il me faudrait moins de temps que d'étendre le code existant. J'ai été en mesure de consolider dans une seule DLL ce qui était auparavant trois et de fournir une structure beaucoup plus orientée objet qui faciliterait grandement la création de nouvelles fonctionnalités critiques et l'ajout de nouvelles fonctionnalités.

Il y avait trois autres applications utilisant les bibliothèques qui avaient besoin de la réécriture, donc je ne voulais pas avoir à réécrire complètement ces programmes. La portée était limitée à la bibliothèque et à ce qui était nécessaire pour lier la bibliothèque au logiciel existant. Mes estimations n’étaient pas loin, et le travail se rentabilisait. Peu de temps après la refonte, j'ai été chargé d'ajouter une nouvelle fonctionnalité. Ce qui m'aurait pris une semaine avec l'ancienne structure ne m'a pris qu'une journée avec la nouvelle structure.

Le PO n'indique pas la portée du projet, mais le principal indice que j'ai retenu était "écrit en vieux [langue / dialecte] en utilisant vieux [libs]", qui sont pour moi les principaux moteurs d'une réécriture. En fait, la plupart des projets sur lesquels je suis engagé, quelle que soit leur longévité sur le marché, finissent par se rendre compte que la mise à jour adaptée des compilateurs / interprètes / systèmes d'exploitation est une tâche importante pour la maintenance de la base de code.

En bref, je planifierais la réécriture par phases en donnant la priorité à la mise à jour dans les bibliothèques. Il se peut que, en cours de route, vous puissiez utiliser d’autres optimisations, mais le fait que vous envisagiez de reporter certaines modifications à une phase ultérieure peut être un excellent moyen de respecter votre calendrier et d’éviter de rester «bloqué».

Bien, je peux imaginer des scénarios hypothétiques dans lesquels je pourrais simplement rejeter la base de code existante (situations hypothétiques dans lesquelles les boules géniales ont un poids et un volume nul, où personne ne se soucie de perdre des semaines ou des mois de productivité alors que nous nous efforçons d'ajouter des fonctionnalités et des bugs négligés. le système est si trivial et tellement détesté par une organisation que je peux remplacer l’ensemble du serveur et son armée de serveurs par Notepad ++ et un netbook en dix minutes et ainsi améliorer la productivité et la moralité de chacun.)

Pour presque tous les scénarios du monde réel, je recommanderais simplement la refactorisation en place. ^ _ ^. Il y a généralement trop de coûts cachés et imprévus à réécrire lorsque des exigences légales et professionnelles non documentées commencent à apparaître et que le piratage de dernière minute des choses ensemble à la dernière minute commence à s'ensuivre.

== Refactoring in Place pour plus de bien, et tout ==

Refactoring du code hérité avec l'ancienne approche incrémentale classique,

1. Si vous avez la possibilité de convertir en UML et de documenter la petite architecture peu connue qui soit.
2. Si vous êtes sous contrôle de version, cherchez à générer des rapports de désabonnement du code et à déterminer quels fichiers et sections de fichier ont été modifiés le plus souvent. Notez-les, car ce seront probablement les domaines que vous voudrez aborder en premier.
3. Avant de modifier un code, essayez toujours d'ajouter une couverture de test (même des tests fonctionnels de pile complets laids feront l'affaire). Si vous avez affaire à une logique d'extraction de code procédurale volumineuse, vous avez l'intention de passer à une méthode ou à une fonction raisonnablement nommée et, si possible, d'ajouter des scénarios de test vérifiant votre nouvelle méthode. faites tout ce que vous voulez de mal et si possible paramétrez le changement s'il s'agit de quelque chose qui est généralement modifié comme la largeur de la marge ou le titre, il sera donc un peu plus simple de mettre à jour la prochaine fois.
4. Utilisez le modèle d'adaptateur et cachez des fragments de code hérités sous un tapis de classes et de méthodes nommées logiquement, de sorte que, pour la plupart des tâches courantes, vous-même et les autres développeurs effectuez des tâches sans avoir à vous soucier des éléments effrayants qui se cachent derrière. votre dos derrière ces jolies méthodes et classes propres vous avez caché votre code hérité derrière - comme ces jolies familles qui gardent des anciens membres de la famille zombie meurtriers dans des granges pour ne pas gâcher le quotidien des ferme. . . normalement.
5. Au fur et à mesure que vous continuez à nettoyer et à nettoyer les sections du code, vous augmentez la couverture de vos tests. Maintenant, vous pouvez creuser encore plus profondément et "réécrire" encore plus de code si nécessaire / souhaité avec une confiance toujours plus grande.
6. Répétez ou appliquez des approches de refactoring supplémentaires pour continuer à améliorer votre base de code.

Ramification par abstraction

1. Définissez le problème dans le code que vous souhaitez supprimer (la couche de persistance, le générateur de pdf, le mécanisme de décompte des factures, le générateur de widgets, etc.).
2. exécutez (écrivez si nécessaire) des scénarios de test fonctionnels (automatisés ou manuels mais que vous connaissez automatisés) sur la base de code qui cible cette fonctionnalité ainsi que le comportement général.
3. Extrayez la logique associée à ce composant de la source source existante dans une classe avec une interface raisonnable.
4. Vérifiez que tout le code utilise maintenant la nouvelle interface pour effectuer l'activité X précédemment dispersée de manière aléatoire dans le code (Grep la base de code, ajouter une trace à la nouvelle classe et vérifier les pages devant l'appeler, etc.), et que vous pouvez contrôler quelle implémentation sera utilisée en modifiant un seul fichier. (registre d'objets, classe d'usine, peu importe la classe IActivityXClass = Settings.AcitivtyXImplementer ();)
5. réexécutez des scénarios de test fonctionnels qui vérifient que tout fonctionne encore avec l'activité X introduite dans votre nouvelle classe.
6. Si possible, écrivez des tests unitaires autour de la nouvelle classe d’activité X wrapper.
7. implémentez une nouvelle classe avec une logique spaghetti moins insensée que l'implémentation héritée qui adhère à la même interface que la classe héritée.
8. vérifiez que la nouvelle classe réussit les tests unitaires que vous avez écrits pour la classe héritée.
9. Mettez à jour votre code en modifiant le registre / factorymethod / que vous utilisiez la nouvelle classe au lieu de l'ancienne.
10. vérifiez que vos tests fonctionnels réussissent toujours.

Principe Open Closed et couche de logique métier / persistance commune

Dans une certaine mesure, vous pourrez peut-être séparer votre présentation, votre activité et votre couche de persistance et écrire une nouvelle application totalement compatible avec la solution existante, ou au moins pouvez toujours gérer les données saisies par cette solution. Je ne recommanderais probablement pas cette approche, mais il s’agit parfois d’un compromis raisonnable en termes de temps / calendrier / ressources / nouvelles fonctionnalités requises.

• Séparez au moins la couche de présentation des couches métier et de persistance.
• implémenter une nouvelle couche d'interface utilisateur et de meilleure présentation qui utilise les mêmes couches métier et persistance communes.
• Vérifiez que les données créées avec la nouvelle interface utilisateur ne cassent pas l'ancienne interface utilisateur. (vous allez être dans l'eau chaude si les utilisateurs du nouvel outil interrompent les utilisateurs de l'ancien outil). Si vous aspirez à une compatibilité ascendante totale, vous devriez tout enregistrer dans les mêmes couches de persistance. Si vous souhaitez simplement une compatibilité en aval avec le nouvel outil, utilisez une nouvelle base de données et de nouvelles tables ou tables d'extension pour suivre les données qui ne sont pas dans le système hérité.
• Pour les nouvelles fonctionnalités et les besoins de la couche de persistance, ajoutez de nouvelles tables et méthodes ne modifiez pas la logique existante, ni ajoutez de colonnes, ni de contraintes aux tables existantes. Par exemple, si vous devez commencer à suivre les contacts d'urgence des employeurs et que certains autres champs ne modifient pas la table des employés existante (nous n'avons aucune idée des hypothèses que les données héritées font à propos de cette table), ajoutez une table d'extension employee_ext id, employee_id, emergency_contact_id, etc_id.
• Migrez lentement les utilisateurs sur un nouveau système. si possible, mettez l'ancien système en lecture seule ou ajoutez simplement un avertissement indiquant aux utilisateurs qu'il ne sera plus disponible après la date X.
• mettre en œuvre toute fonctionnalité ou les exigences professionnelles manquées salut priorité dans la nouvelle interface utilisateur
• survoler la base d'utilisateurs.
• poursuivre le nettoyage de la logique métier et de la persistance des utilisateurs des autres méthodologies de refactoring.

Je dirais qu'il existe une troisième catégorie dans l'espace Refactor vs Rewrite ... Et cela met à jour vos versions linguistiques, vos compilateurs et vos bibliothèques ... L'adoption de techniques de codage modernes présente parfois un grand avantage.

Prenons C #, par exemple, le code v7 écrit beaucoup plus propre, plus sûr et plus concis que v2. Des éléments comme Elvis et l’opérateur de coalescence nul apportent une aide considérable.

Changer de compilateur pourrait également insuffler une nouvelle vie à un code plus ancien. Il en va de même pour les nouvelles bibliothèques qui pourraient faciliter l’utilisation et l’implémentation des tâches… La mise en réseau est un excellent exemple de l’éventail des difficultés d’implémentation.

Aussi, les systèmes Linux intégrés ... Pensez à installer de nouveaux outils - passez de svn à git. ou ajoutez Vi à votre système, etc.

Cela ne doit pas toujours être un refacteur ou une réécriture. Votre architecture a probablement besoin d’être améliorée, mais cela fonctionne ... vous devez peut-être simplement réfléchir à la façon dont votre code est écrit, etc.

Je ne pense pas avoir jamais vu des personnes réécrire une application héritée.

Ce qui se passe, c'est que les gens écrivent des applications totalement nouvelles avec une architecture, des technologies, etc. différentes, qui ont certaines caractéristiques communes avec la génération précédente. Et cela s'appelle app 2.0, mais en réalité, il a très peu de points communs avec l'original.

Mais ce n'est pas vraiment une "réécriture" de l'original dans le sens où vous essayez d'atteindre la parité des fonctionnalités.