it-swarm-fr.com

Avez-vous déjà été impliqué dans une grande réécriture?

Joel Spolsky dit dans l'un de ses postes célèbres:

La seule erreur stratégique pire que toute entreprise de logiciels peut faire: réécrire le code à partir de zéro.

Chad Fowler a écrit:

Vous avez vu les vidéos, les poteaux Weblog et le battage médiatique, et vous avez décidé que vous allez ré-implémenter votre produit dans Rails (ou Java, ou .NET, ou Erlang. , etc.).

Il faut se méfier. C'est un chemin plus long, plus difficile et plus encastré que prévu.

Avez-vous déjà été impliqué dans une grande réécriture?
[.____] Je suis intéressé par votre expérience de ce sujet tragique, et en particulier, dans une grande réécriture qui a été achevée avec succès (le cas échéant).

55
systempuntoout

Je suis impliqué dans quelques réécritures sur ma carrière et ils étaient tous les désastres. Je pense que tous ne parviennent pas pour les mêmes raisons

  • Vaste sous-évaluation de l'effort requis: Chaque fois que quelqu'un veut une ré-écriture, c'est parce que l'ancien système utilise la technologie ancienne et difficile à maintenir. Ce qu'ils ne parviennent pas à considérer est qu'en raison de son âge, il peut avoir 30-40 ans homme d'efforts de développement en elle. Penser que vous pouvez réécrire le tout en 6 mois avec une équipe de 5 est stupide.
  • Savoir perdu: Le vieux système a été si longtemps, il fait beaucoup de choses, et est accroché dans tout. Il n'y a pas mise à jour de la documentation, et aucun point d'autorité qui sait en fait toutes les choses que le système. Il y aura des morceaux de connaissances avec des utilisateurs particuliers dans certains départements, et les trouver tout est difficile, voire impossible.
  • Les décisions de gestion mauvais état: les réécritures que j'ai participé a eu une des attentes similaires de la direction: Le nouveau système devrait être " fait ", et l'ancien système pourrait tout simplement être mis hors tension à une date donnée, période. Aucune autre option était acceptable. Je pense qu'ils obtiennent ce dans leur tête, parce qu'ils dépensent tout cet argent pour embaucher de nouvelles personnes pour ce grand 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 lutter contre 50-75% de l'ancien système pour une première version, puis voir comment cela fonctionne! En raison de 1 et 2 ci-dessus, ce serait probablement beaucoup mieux, que l'on trouve quelques-unes des caractéristiques qui ont été manqués, et ce qui est nécessaire pour désactiver réellement l'ancien système.
62
Jay

J'ai été impliqué dans plusieurs réécritures qui venaient de VB6 à .NET. Dans 2 cas, les réécrites se sont déroulées en douceur et nous étions en fait terminés devant le calendrier. L'autre réécriture a pris plus de temps que prévu mais achevée sans aucun problème majeur.

Dans notre cas particulier, la rédaction n'est pas la pire décision que la société pouvait faire. Les résultats finaux étaient effectivement beaucoup plus stables que les originaux et nous mettent dans un endroit bien meilleur.

12
Walter

L'un des plus gros pièges pour une réécriture complète d'un système existant est de penser "Nous n'avons pas besoin de préciser ce que le nouveau système doit faire - c'est très simple, il suffit de faire exactement ce que fait l'ancien système!" .

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

11
Jesper

Le mien est une histoire "succès". Mon projet impliquait un site principal avec 4 sites satellites gérés/écrits indépendamment (sous-domaines avec différentes applications sur eux). Nous avions 4 bases d'utilisateurs principaux (tous dans des répertoires actifs distincts) et aucun n'a eu un système d'authentification commun. 3 étaient des applications bien établies et silo'd et le 4ème satellite était tout neuf et avait copié une grande partie de sa base de code de notre site le plus établi.

Objectif : Mettre en place un système d'identité large d'entreprise susceptible d'authentifier des comptes sur 4 domaines et des comptes de gestion complète (avec libre-service) dans 1 des domaines. Étant donné que .NET était déjà mis en œuvre sur les satellites, le site ASP classique servi de "plomb-in" devrait être réécrit, une gestion de l'identité ajoutée dans laquelle tous les sites auraient besoin d'essais de régression pour s'assurer qu'aucun service n'a été affecté.

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

Durée to terminal (début à la fin) : 1,5 ans

Lancement de la réussite : Près de l'échec

Succès de la longévité : Terre

J'étais l'architecte de la gestion de l'identité, j'ai donc conçu les bases de données, les sous-systèmes et les interfaces logiques permettant à tous les satellites interagiraient. L'architecte "programmeur" était un développeur principal avec une connaissance approfondie des entreprises de tous les satellites et de toutes les expériences avec les applications et leur développement jusqu'à ce point.

Après plusieurs mois d'exigences, collectant de 50 personnes différentes de divers départements de notre société, nous avons réussi à faire cuire l'architecture logique et commencée à frapper le code. En raison de la nature du changement, nous avons dû réécrire notre propre site Web et toutes les fonctionnalités qu'il contenaient dans .NET. Dans certains cas, il s'agissait d'une question de refactorisation. Dans de nombreux cas, il s'agissait d'une réécriture complète des processus qui l'entourent. Dans 2 cas, nous avons simplement abandonné la caractéristique d'origine comme non importante. Nous avons manqué 2 échéances dans le processus (mais nous avons fini par frapper la date limite d'origine que j'avais proposée - à peine). Le jour de lancement, rien n'a fonctionné. Nous avons lancé un samedi de sorte que l'impact était assez minime, mais j'ai passé toute la journée à peigner à travers des grumes, de réécrire des pièces et d'évaluer les charges de serveurs. Plus de tests auraient pu aider. Un SDLC plus complet aurait pu aider encore plus (nous avions un SDLC, mais il a été mélangé).

À 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 formidable. Avoir tous nos sites sur une architecture commune avec une base-cadre commune a rendu un développement de développement et de développeurs croisés beaucoup plus facilement. Caractéristiques J'ai écrit sur notre site il y a 2,5 ans (pendant notre réécriture) a depuis été vu/adopté par deux silos satellitaires.

Nous avons augmenté la journalisation, le suivi de l'utilisateur, l'augmentation du temps, une application singulière responsable de l'authentification/de l'autorisation/identification. Les silos satellites peuvent se concentrer sur leurs applications entièrement et peuvent faire confiance à tous les problèmes d'authentification/d'autorisation existant avec l'application de gestion des identités.

Notre projet était beaucoup de frustration, de chagrin d'amour et de catastrophe. À la fin, il a payé, puis certains. Je suis d'accord de 100% avec l'évaluation des réécritures de Joel Spolsky en règle générale, mais il y a toujours des exceptions. Si vous envisagez une réécriture, il vous suffit de vous assurer que c'est absolument ce dont vous avez besoin. Si c'est le cas, alors soyez prêt pour toutes les maux qui y viennent.

9
Joel Etherton

Je suis impliqué dans un code énorme réécrire maintenant ... Le seul problème est que je suis le seul qui travaille dessus! Les coûts de maintenance de notre logiciel actuel sont scandaleux, il a beaucoup de bugs et nous avons 1 employé de 1 FT le maintenant donc nous avons décidé de construire le nôtre.

C'est beaucoup plus lent alors je m'attendais à ce que ce soit, mais je pense que ce sera tant mieux parce que nous aurons notre propre codeBase afin que toute modification souhaitée dans le futur puisse être facilement mise en œuvre (le logiciel doit changer fréquemment pour suivre fois actuels). En outre, nous apportons des changements majeurs dans la conception pendant que nous le réécrivez.

4
Rachel

Tout dépend. Dans mon cas, j'ai suivi les conseils de Joel Spolsky et J'avais tort. 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:

mauvais Stratégie: J'ai supervisé un groupe de 4 étudiants à:

  • Étudiant # 1 - Réécrivez l'accès à la base de données/les requêtes pour les faire en sécurité
  • Étudiant n ° 2 - déplacé tout le CSS "up"
  • Étudiant # 3 - Fabriqué toutes les pages W3C Compatible
  • Étudiant # 4 - résolu tous les bugs en attente
  • Moi-même de supprimer tous les avertissements PHP et des trucs de merde (code dupliqué et ainsi de suite)

Il a fallu 2 mois. Ensuite, nous avons ré-conçu le site. Ensuite, nous l'avons fait multilingue. Dans l'ensemble, nous avons dû garder 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 de merde pendant un an maintenant et que cela ne sera jamais terminé avant de décider d'une réécriture complète, qui n'arrivera jamais.

bonne STRATÉGIE:

  • Étudiez tout le site, faites un bon "document" des exigences de produit ".
  • Re-concevoir correctement la base de données
  • Commencez à partir de zéro avec mon propre cadre (qui fonctionne déjà)
  • Repensez le site.
  • Faire multilingue.

Il 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 trucs que vous devez réécrire.

N'hésitez pas à corriger mon post pour le rendre bon anglais s'il vous plaît, merci beaucoup

Olivier Pons

3
Olivier Pons

J'ai participé à une réécriture complète dans mon emploi précédent. Et nous étions très heureux de l'avoir fait. Disons simplement que parfois le codebase est tellement pourri qu'il vaut mieux recommencer.

C'était une application interne - la principale application commerciale, en fait.

Nous avons maintenu l'ancien système comme nous l'avons écrit la version 2. Si je vous rappelle correctement, cela nous a fallu environ un an (deux programmeurs, puis un tiers). Nous n'avons pas besoin de toucher la base de données, donc au moins une migration de données n'était pas un problème.

3
Frank Shearar

Je suis sur une grande réécriture depuis 3 ans. Original Nous avons estimé le projet de 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 commerciale (de C à CPP), de créer une nouvelle IO carte et écrivez une nouvelle interface utilisateur.

En cours de route, nous avons pris des décisions terribles. Nous n'avions aucune expérience réelle dans le CPP et aucun mentor pour l'apprendre bien. Nous avons essayé de construire un cadre d'interface utilisateur sur notre base sur Win32. Le matériel était bon marché et le BSP est imprégné de bugs. Le logiciel était super flexible mais difficile à entretenir. L'année dernière, nous avons jeté l'interface utilisateur de la maison et avons développé une interface utilisateur dans .NET. Nous réécrivons également complètement notre mécanisme de persistance et notre protocole de communication de données.

Il a fallu beaucoup d'efforts supplémentaires, mais le projet est presque terminé et les premières unités sont testées sur le terrain. Le projet a eu beaucoup de risques pour avoir tout changement de succès. Il y avait des choses positives sur le projet, nous avons commencé à utiliser SVN (au lieu de VSS), nous avons pris le temps d'écrire des tests d'unité et de mettre en œuvre une construction nocturne. Nous avons également commencé à utiliser Scrum pour avoir un meilleur processus.

En rétrospective, je pense que la réécriture de la logique commerciale n'était pas nécessaire, nous ne devrions avoir que des conséquences sur les parties les plus laides. Et pour écrire une interface utilisateur à partir de zéro, ne le faites pas, à moins que ce soit votre activité principale.

2
refro

Une entreprise que j'ai travaillé pour a commencé un refacteur majeur du codeBase.

La moitié de l'équipe devait travailler sur le refacteur et l'autre moitié continuant de maintenir et d'améliorer le produit existant.

Comme vous pouvez l'imaginer, le refacteur n'a jamais été venu à un point où quelque chose a fonctionné - c'était juste un processus continu constant qui n'avait jamais rien à montrer pour lui-même.

L'idée était que le code de code refactored serait préférable de travailler avec et nous pourrions simplement "déposer" dans les nouvelles fonctionnalités que l'équipe avait ajouté au produit existant a été effectuée et "rattraper".

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

2
Jasarien

Il y a un peu plus d'une décennie, j'ai travaillé pour une entreprise qui a décidé de faire une "refonte" de leur produit de base de vieillissement. Depuis lors, mentionnant le mot "refonte" est une infraction punissable. Il a fallu beaucoup plus de temps que prévu, manifestement cher, et le nouveau produit était beaucoup plus similaire à l'ancien produit que prévu initialement.

1
user281377

En fait, je commence un gros refactoring. 4mlocs devrait probablement diminuer à 800 klocs ou moins. Ce projet a beaucoup de copie et de pâte, de caractéristiques de langage incompréhensifs, de terrains et de nombreux commentaires répétitifs inutiles, de mauvaises décisions, un piratage temporaire et plus de piratage transformé en permanence (y compris des solutions de contournement), un manque total de connaissances sur Principes sur l'informatique ou l'ingénierie logicielle. Une équipe de maintenance probablement de 32 nouveaux programmeurs sera remplacée par 2 bonnes suivantes après refactoring.

1
Maniero

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

Planification à venir est clé à une réécriture réussie. Connaître le système à l'intérieur et à l'extérieur.

1
Josh K