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.