Avez-vous déjà participé à une grande réécriture? [fermé]

Joel Spolsky a déclaré dans l'un de ses messages célèbres:

La pire erreur stratégique que toute société de logiciels puisse commettre: réécrire le code à partir de zéro.

Chad Fowler a écrit:

Vous avez vu les vidéos, les articles de blog et le battage publicitaire, et vous avez décidé de réimplémenter votre produit dans Rails (ou Java, ou .NET, ou Erlang, etc.).

Il faut se méfier. Il s’agit d’un chemin plus long, plus difficile et plus sujet aux défaillances que prévu.

Avez-vous déjà participé à une grande réécriture?
Je suis intéressé par votre expérience sur ce sujet tragique, et en particulier par toute grande réécriture qui a été réalisée avec succès (le cas échéant).

J'ai participé à plusieurs réécritures au cours de ma carrière et elles ont toutes été des désastres. Je pense qu'ils échouent tous pour les mêmes raisons

• Vaste sous-estimation des efforts requis: chaque fois que quelqu'un souhaite une réécriture, c'est parce que l'ancien système utilise une technologie ancienne et difficile à maintenir. Ce qu’ils ne tiennent pas compte, c’est qu’à cause de leur âge, 30 à 40 années d’efforts de développement peuvent être nécessaires. Penser que vous pouvez ensuite réécrire le tout en 6 mois avec une équipe de 5, c'est idiot.
• Connaissances perdues: L'ancien système existe depuis si longtemps, il fait beaucoup de choses et est accroché à tout. Il n’existe pas de documentation à jour, ni de point d’autorité unique connaissant réellement tout ce que fait le système. Il y aura des connaissances avec des utilisateurs particuliers dans des départements particuliers, et les trouver toutes est difficile, voire impossible.
• Mauvaises décisions de gestion: Les réécritures dans lesquelles j'ai été impliqué avaient des attentes similaires de la part de la direction: le nouveau système devait être «terminé» et l'ancien système pouvait simplement être désactivé à une date et une période données. Aucune autre option n'était acceptable. Je pense qu'ils ont cela en tête, parce qu'ils dépensent tout cet argent pour embaucher de nouveaux employés pour cet énorme projet. En réalité, la meilleure stratégie d’atténuation des risques consiste à réécrire les principales fonctions de l’ancien système, par exemple en s’attaquant à 50-75% de l’ancien système pour une première version, puis de voir comment cela fonctionne! En raison des points 1 et 2 ci-dessus, cela fonctionnerait probablement beaucoup mieux, car nous découvrons certaines des fonctionnalités manquantes et ce qui est nécessaire pour réellement désactiver l'ancien système.

Les réécritures peuvent être très efficaces si vous les définissez correctement. Je ne sais pas s'ils répondent à votre seuil de projets "BIG" (TM), mais laissez-moi vous décrire quelques réécritures plus réussies.

Projet 1

La société pour laquelle je travaillais disposait d’un système d’impression sur bande pour générer les étiquettes que vous voyez sur les rayons des magasins à partir d’un planogramme . Le planogramme a été généré dans un logiciel standard de l'industrie et nos outils ont lu ce document pour créer les barrettes d'étagères à l'aide d'un modèle pour le magasin cible. Le logiciel de gabarit était un fouillis avec des machines à états finis imbriqués qui couvraient plusieurs classes et 3 DLL. Lorsque le moment est venu de mettre en œuvre l'approche (alors en attente de brevet) de fabrication de panneaux perforés, il était clair que le code actuel ne pouvait pas soutenir ce que nous voulions faire.

Solution: Nous avons limité la réécriture au moteur de modèle. Nous avons utilisé la conception OO appropriée pour prendre en compte les exigences actuelles, ainsi que pour répondre aux nouvelles exigences en matière de panneaux perforés. Le temps pour la réécriture était de 1 mois. Si nous avions procédé à une réécriture complète de toute la chaîne d'outils, cela aurait pris bien plus d'un an - mais nous n'avions pas besoin de le faire.

Projet 2

Une application Web que notre équipe a créée à partir de la base commençait à dépasser sa conception d'origine. Notre client avait également une série de nouvelles exigences qui rendraient le site bien meilleur pour nos utilisateurs, plus conforme au Web 2.0 si vous voulez. Même si nous pouvions intégrer notre conception existante dans la structure que nous avions actuellement, l'entretien était un cauchemar. Nous connaissions intimement l'application et nous savions quelles parties nous devions présenter et quelles parties disparaissaient dans la nouvelle version.

Solution: Cela a pris 3 mois à notre équipe - ce n'était pas anodin. Le produit final était plus rapide, plus évolutif et plus agréable pour les utilisateurs finaux. Nous avons dépassé les attentes de nos clients. Cela dit, nous avons dû scinder notre équipe afin que les corrections de bogues les plus immédiates et les correctifs d'aide à la résolution des problèmes soient résolus sur le système existant, tandis que l'autre moitié travaillait sur le nouveau système. Nous avons mis en place de nombreux tests et les avons incorporés au début du processus. Cela a si bien fonctionné, c'est parce que nous connaissions intimement cette application et notre client.

Projet 3

Je dois inclure un échec ici. Nous aidions un client qui avait besoin d'un outil de gestion de l'information à utiliser en cas de catastrophe ou de crise. Nous avons hérité d'une application Java Swing que les développeurs d'origine ont écrite sans vraiment comprendre Swing. J'entends par là qu'ils n'ont pas suivi les recommandations de Sun concernant le traitement de Swing et la gestion de l'interface utilisateur correctement. En conséquence, vous vous retrouveriez dans des boucles d'événements infinies et d'autres problèmes étranges et difficiles à suivre. En conséquence, il était chargé de bugs, de problèmes d'interface utilisateur, etc. Il s'agissait d'une application très compliquée. Afin de préserver notre santé mentale, nous avons tenté de réécrire l'application Swing mal écrite en une application Swing bien écrite.

Solution: Nous avons terminé la réécriture au bout de 4,5 mois environ, après une estimation de 3 mois. L'application fonctionnait mieux, à la fois dans l'interface utilisateur et dans la quantité de données qu'elle pouvait gérer. Puis le tsunami de 2004 s'est produit. L’importance considérable du nombre de personnes qu’ils devaient suivre a démontré que Swing était la mauvaise technologie pour ce dont ils avaient vraiment besoin. Nous ne pouvions pas suivre notre optimisation des performances et ils ont finalement abandonné l'outil au profit d'une application Web pavée créée par l'équipe Oracle qu'ils avaient en interne. Bien sûr, nous pouvions justifier ce que nous avions fait sur la base des connaissances dont nous disposions à l'époque, mais la réécriture n'était pas assez agressive et nous n'avons pas réussi à dire à notre client que leurs exigences concernant le nombre de personnes pouvant nécessiter un suivi étaient également trop importantes. faible.

Conclusion

Les réécritures sont parfois nécessaires et peuvent être complétées avec succès si vous les planifiez correctement. Vous pouvez aller plus loin avec des réécritures ciblées pour des parties d'un système que pour des réécritures en gros. Enfin, ce qui fait échouer un projet n'est pas nécessairement la réécriture elle-même. Bien que nous ne puissions jamais être clairvoyants, nous pouvons proposer certains scénarios pires. J'ai appris à concevoir mes systèmes pour supporter deux fois le pire scénario auquel je puisse penser. Dans le cas du système de gestion de crise, cela ne suffisait pas: les chiffres réels étaient 20 fois le pire des scénarios. Mais ce n’était pas le pire scénario auquel nous puissions penser.

• Les réécritures pour réécrire ne sont pas vos amis. Il y a toujours beaucoup de complexité que vous ne voyez pas et vous constaterez que les choses laides que vous voyez sont des outils de formation pour votre client. Indiquez toujours vos progrès actuels à votre client à intervalles réguliers pour qu'il puisse vous aider à attraper les pires infractions.
• Les réécritures ciblées sont utiles pour traiter les pires infractions de votre base de code. Ne faites pas une réécriture complète si vous pouvez limiter la portée et résoudre la majorité de vos problèmes.

J'ai participé à plusieurs réécritures allant de VB6 à .NET. Dans 2 cas, les réécritures se sont bien déroulées et nous avons été terminés plus tôt que prévu. L’autre réécriture a pris plus de temps que prévu, mais elle s’est achevée sans problèmes majeurs.

Dans notre cas particulier, la réécriture n'était PAS la pire décision que notre société ait pu prendre. Les résultats finaux étaient en réalité beaucoup plus stables que les originaux et nous mettaient dans un bien meilleur endroit.

L'un des plus gros pièges lors de la réécriture complète d'un système existant est de se dire: "Nous n'avons pas besoin de spécifier ce que le nouveau système doit faire - c'est très simple, il doit simplement faire exactement ce que l'ancien système fait!" .

Le problème est que très probablement personne ne sait exactement ce que fait l’ancien système, et vous passerez d’innombrables heures à faire fonctionner votre nouveau système en fonction de la façon dont différents utilisateurs de l’ancien système pensent que cela devrait fonctionner. Les exigences d'origine de l'ancien système ne sont probablement pas disponibles.

La mienne est une histoire de "réussite". Mon projet impliquait un site principal avec 4 sites satellites gérés et écrits indépendamment (sous-domaines avec différentes applications). Nous avions 4 bases d'utilisateurs principaux (toutes dans des répertoires actifs séparés) et aucune n'avait un système d'authentification commun. 3 étaient des applications bien établies et en silo et le 4ème satellite était tout neuf et avait copié une grande partie de sa base de code à partir de notre site le plus connu.

Objectif: Mettre en œuvre un système large identité de l' entreprise qui pourrait authentifier les comptes dans 4 domaines et complète gérer (avec self-service) représente dans 1 des domaines. Comme .Net était déjà implémenté sur les satellites, il fallait réécrire le site asp classique utilisé comme "introduction", ajouter une gestion des identités et tous les sites nécessiteraient des tests de régression pour s'assurer qu'aucun service n'était impacté.

Ressources: 3 architectes principaux - programmeur, gestion des identités, chef de projet. Environ 20 développeurs, 10 analystes, 10 testeurs.

Délai d'achèvement (du début à la fin): 1,5 ans

Lancement réussi: presque échec

Succès de longévité: Terrific

J'étais l'architecte de la gestion des identités. J'ai donc conçu les bases de données, les sous-systèmes et les interfaces logiques permettant à tous les satellites d'interagir. L’architecte «programmeur» était un développeur principal possédant une connaissance approfondie de tous les satellites et une expérience des applications et de leur développement jusqu’à maintenant.

Après plusieurs mois de collecte des exigences avec une cinquantaine de personnes différentes appartenant à différents départements de notre société, nous avons réussi à affiner l'architecture logique et à commencer à faire sauter du code. En raison de la nature du changement, nous avons dû réécrire notre propre site Web et toutes les fonctionnalités qu’il contenait dans .Net. Dans certains cas, il ne s'agissait que d'une refactorisation. Dans de nombreux cas, cela impliquait une réécriture complète des processus qui l’entouraient. Dans 2 cas, nous avons simplement abandonné la fonctionnalité d'origine car ce n'était pas important. Nous avons manqué deux délais dans le processus (mais nous avons fini par respecter le délai initial que j'avais proposé - à peine). Le jour du lancement, rien n'a fonctionné. Notre lancement ayant eu lieu un samedi, l'impact a été relativement minime, mais j'ai passé toute la journée à parcourir les journaux, à réécrire les morceaux et à évaluer la charge des serveurs. Plus de tests auraient pu aider.

À la fin du premier jour, tous les sites étaient opérationnels et tout fonctionnait (je dirais un succès nominal). Au cours des 2,5 dernières années, tout a été un succès retentissant. Le fait d'avoir tous nos sites sur une architecture commune avec une base de cadre commune a grandement facilité le développement et le travail entre développeurs. Les caractéristiques que j'ai écrites sur notre site il y a deux ans et demi (lors de notre réécriture) ont depuis été vues / adoptées par deux ou trois silos satellites.

Nous avons augmenté la journalisation, le suivi des utilisateurs, le temps d’utilisation, une application unique responsable de l’authentification / autorisation / identification. Les silos satellites peuvent se concentrer entièrement sur leurs applications et peuvent faire confiance à tout problème d'authentification / autorisation avec l'application de gestion des identités.

Notre projet comportait beaucoup de frustration, de chagrin d'amour et de catastrophes. En fin de compte, cela a porté ses fruits et plus encore. Je suis à 100% en accord avec l'évaluation de Joel Spolsky sur les réécritures en règle générale, mais il y a toujours des exceptions. Si vous envisagez une réécriture, vous devez simplement vous assurer que c'est exactement ce dont vous avez besoin. Si c'est le cas, préparez-vous à toutes les douleurs qui l'accompagnent.

Je suis impliqué dans une énorme réécriture de code maintenant ... le seul problème est que je suis le seul à travailler dessus! Les coûts de maintenance de nos logiciels actuels sont exorbitants, ils comportent de nombreux bogues et 1 employé de FT les entretient. Nous avons donc décidé de créer le nôtre.

C’est beaucoup plus lent que je ne l’espérais, mais au final, je pense que ce sera beaucoup mieux, car nous aurons notre propre base de code afin que tous les changements souhaités puissent être facilement implémentés à l’avenir (le logiciel doit être fréquemment modifié pour pouvoir suivre le rythme heure actuelle). Nous apportons également des modifications majeures à la conception pendant que nous la réécrivons.

J'ai pris part à une réécriture complète de mon travail précédent. Et nous étions très heureux de l'avoir fait. Disons simplement que parfois la base de code est tellement pourrie qu'il vaut mieux recommencer.

C'était une application interne - l'application métier principale, en fait.

Nous avons maintenu l'ancien système en écrivant la version 2. Si je me souviens bien, cela nous a pris environ un an (deux programmeurs, puis un troisième). Nous n'avions pas besoin de toucher à la base de données, donc au moins la migration des données n'était pas un problème.

Tout dépend. Dans mon cas, j'ai suivi les conseils de Joel Spolsky et je me suis trompé . Il s'agissait d'un site Web d'assurance. Le site était horrible et voici ce que j'ai fait, alors ce que j'aurais dû faire:

Mauvaise stratégie: j'ai supervisé un groupe de 4 étudiants pour:

• Etudiant # 1 - réécrit les accès / requêtes de la base de données pour les sécuriser
• Étudiant # 2 - déplacé tous les css "up"
• Student # 3 - a rendu toutes les pages compatibles avec le w3c
• Étudiant # 4 - a résolu tous les bogues en suspens
• Moi-même: enlevé tous les avertissements php et les trucs merdiques (code dupliqué, etc.)

Cela a pris 2 mois. Ensuite, nous avons repensé le site. Ensuite, nous l'avons fait en plusieurs langues. Dans l'ensemble, nous avons dû conserver une grande partie du code de merde et la structure de la base de données est restée la même. Donc, je travaille toujours sur des trucs pourris depuis un an et ça ne sera jamais fini tant que nous n'aurons pas décidé d'une réécriture complète, ce qui ne se produira jamais.

Bonne stratégie:

• Etudiez l’ensemble du site, faites un bon "Document sur les exigences du produit".
• Re-concevoir correctement la base de données
• Partir de zéro avec mon propre framework (qui fonctionne déjà)
• Re-conçu le site.
• Avez multilingue.

Le temps que cela aurait pris: deux mois ( peut-être moins ).

• Bon code.
• Bon entretien.
• Productivité.
• Aucune réponse comme "nous ne pouvons pas faire cela, le site Web ne peut pas gérer de tels produits".

Donc, mes derniers mots: tout dépend de la complexité des éléments à réécrire .

N'hésitez pas à corriger mon message pour qu'il soit bien anglais s'il vous plaît, merci beaucoup

Olivier Pons

Une entreprise pour laquelle j'ai travaillé a démarré un refactor majeur de la base de code.

La moitié de l'équipe était prête à travailler sur le refactor et l'autre moitié à maintenir et à améliorer le produit existant.

Comme vous pouvez l'imaginer, le refactor n'a jamais vraiment atteint un point où tout a fonctionné - il s'agissait simplement d'un processus continu qui n'avait jamais vraiment rien montré pour lui-même.

L'idée était que la base de code refactorisée serait meilleure pour fonctionner et que nous pourrions simplement "introduire" les nouvelles fonctionnalités que l'équipe avait ajoutées au produit existant une fois celles-ci terminées et les "rattraper".

Mais cela a fini par être la chute de la société.

Je suis sur une grande réécriture pour les 3 dernières années. Original, nous avions estimé le projet à 2 ans. L'idée de base était de remplacer le matériel, d'utiliser un système d'exploitation existant, de réécrire la logique métier (du c au CPP), de créer une nouvelle carte d'E / S et d'écrire une nouvelle interface utilisateur.

En cours de route, nous avons pris des décisions terribles. Nous n’avons aucune expérience réelle du RPC et aucun mentor pour bien l’enseigner. Nous avons essayé de construire nous-mêmes un cadre d'interface utilisateur basé sur win32. Le matériel était bon marché et le BSP imparfait avec des bugs. Le logiciel était super flexible mais difficile à maintenir. L'année dernière, nous avons jeté l'interface utilisateur développée à la maison et développé une interface utilisateur dans .net. Nous avons également complètement réécrit notre mécanisme de persistance et notre protocole de communication de données.

Cela a demandé beaucoup d'efforts supplémentaires, mais maintenant le projet est presque terminé et les premières unités sont testées sur le terrain. Le projet risquait fort d’être modifié. Il y avait des aspects positifs dans le projet. Nous avons commencé à utiliser SVN (au lieu de VSS), nous avons pris le temps d'écrire des tests unitaires et avons mis en place une construction nocturne. Nous avons également commencé à utiliser Scrum pour améliorer le processus.

Rétrospectivement, je pense que la réécriture de la logique métier n’était pas nécessaire, nous aurions seulement dû re-factoriser les parties les plus laides. Et pour écrire une interface utilisateur à partir de zéro, ne le faites pas sauf si c'est votre cœur de métier.

En fait, je commence un grand refactoring. 4MLocs devrait probablement être réduit à 800KLocs ou moins. Ce projet a beaucoup de Copier-Coller, des fonctionnalités de langage incompréhensibles, de nombreux commentaires inutiles répétitifs, de mauvaises décisions, du piratage temporaire et davantage de piratage devenu permanent (y compris des solutions de contournement), un manque complet de connaissances sur les principes de base en informatique ou en génie logiciel. Une équipe de maintenance composée de 32 mauvais programmeurs sera probablement remplacée par deux bons après la refactorisation.

J'ai écrit un moteur de blogs en 3 semaines. Je l'ai réécrit en 8 heures.

La planification est la clé du succès de la réécriture. Connaître le système à l'intérieur et à l'extérieur est également un avantage.

Il y a un peu plus de dix ans, j'ai travaillé pour une entreprise qui a décidé de "refondre" son produit vieillissant. Depuis lors, la mention du mot "refonte" est une infraction punissable. Cela a pris beaucoup plus de temps que prévu, a évidemment coûté plus cher, et le nouveau produit était beaucoup plus semblable à l'ancien produit que prévu initialement.