Existe-t-il des études de cas sur la réécriture des taux de réussite / d’échec des logiciels?

J'ai vu de nombreux articles sur la réécriture d'applications mauvaises, sur l'expérience des gens à ce sujet chez Programmers et sur un article de Joel Spolsky que j'ai préparé sur le sujet, mais pas de preuves tangibles ni d'études de cas. Outre les deux exemples cités par Joel et quelques autres articles ici, que faites-vous avec une base de code incorrecte et comment décidez-vous quoi faire avec de vraies études?

Pour le cas d'espèce, je connais deux clients qui ont tous deux un ancien code hérité. Ils n'arrêtent pas de le suivre parce que, comme l'un d'entre eux l'a découvert, une réécriture était une catastrophe, elle coûtait cher et ne permettait pas vraiment d'améliorer le code. Ce client a une logique d’affaires très compliquée que les réécrivains ont rapidement découverte.

Dans les deux cas, il s’agit d’applications essentielles à la mission qui génèrent beaucoup de revenus pour l’entreprise. Celui qui a tenté la réécriture a eu l’impression de se heurter à un mur de briques si l’ancien logiciel n’était pas mis à niveau ultérieurement. Pour moi, ce genre de risque justifie des recherches et des analyses pour assurer le succès de la démarche.

Y a-t-il eu des études de cas réelles qui ont étudié cela? Je ne voudrais pas tenter une réécriture majeure sans connaître certaines des meilleures pratiques, des pièges et des succès basés sur des études réelles.

Après: OK, après plus de recherches, j'ai trouvé trois articles intéressants sur des études de cas:

1. Réécrire ou réutiliser . Ils ont réalisé une étude sur une application Cobol convertie en Java.
2. L'autre portait sur la réutilisation des logiciels: expériences et perceptions des développeurs .
3. Réutiliser ou réécrire Une autre étude sur les coûts de maintenance par rapport à une réécriture.

J'ai récemment trouvé un autre article sur le sujet: The Great Rewrite . Là, l'auteur semble s'attaquer à certains des problèmes majeurs. Parallèlement à cela, nous avons eu l’idée de créer un prototype en utilisant la nouvelle pile de technologies proposée et en mesurant la rapidité avec laquelle les développeurs l’ont prise. C'était tout le prélude à une réécriture, ce qui m'a semblé être une excellente idée!

Je ne peux pas prendre le crédit pour ces excellents commentaires, mais ils n'ont jamais été intégrés dans une réponse par l'auteur original, alors je le marque comme wiki de la communauté.

Je ne connais pas les études de cas, mais je pense que la réponse standard pour une approche est probablement "ajouter des tests unitaires et un refactor".

Cela me semble être l’approche la moins risquée possible. Bien sûr, je ne connais pas assez de détails pour être certain que c'est la bonne approche, mais sur la base de ce que je sais jusqu'à présent, je ne connais pas grand-chose de particulièrement susceptible d'être bien meilleure.

S'ils effectuent des tests unitaires (correctement - en capturant réellement toutes les exigences), il est difficile de trouver un moyen de refactoriser afin de créer un véritable désastre. Le pire qui puisse arriver est que vous ne faites pas autant de progrès aussi vite que vous le souhaitez. Dans le même temps, si leur code est en mauvais état comme le suggère la question, il est fort probable qu'un effort sérieux soit nécessaire pour permettre des progrès, quel que soit le chemin emprunté.

Je suppose que le taux d'échec des projets de réécriture n'est pas très différent de celui des projets en général et que je ferais référence au dernier rapport de CHAOS pour obtenir les meilleures informations.

Il y a quelque temps, j'ai écrémé travailler efficacement avec le code hérité de Michael Feathers et j'ai trouvé que cela fournissait de bonnes informations sur la pratique du maintien du code hérité dans le monde réel, y compris l'écriture de tests (même si vous ne savez pas à quoi le code était destiné). bien sûr refactoring / rewriting. C'est un peu daté mais très bien noté sur Amazon.

Parlant d'expérience et vivant dans une entreprise dont l'architecture d'entreprise est mal conçue depuis le début, je peux dire en toute honnêteté que le plus gros problème est de développer une compréhension globale.

Cette idée qu'un système peut être décomposé et compris individuellement est viciée. À un moment donné, un seul individu ou plusieurs individus devaient être capables de concevoir le problème dans son ensemble. Si ce problème est une série de problèmes commerciaux et les technologies qui les conduisent; plusieurs années peuvent être nécessaires à une personne de l'entreprise pour comprendre tous les systèmes à un niveau où il est possible de les remplacer sans incident ni catastrophe. Ce fut certainement le cas dans mon entreprise lorsque j'ai pris mes fonctions de directeur de la technologie. Sans le fait que je sois moi-même codeur, je n'aurais pas été en mesure de comprendre lentement tous les détails de l'architecture et de l'intégration de la technologie mal organisées, étroitement couplées, étroitement liées. Si petits détails cachés, non documentés comme"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" les résultats peuvent être désastreux, et la seule façon de le savoir est de découvrir tout cela lentement.

Si une personne est invitée à remplacer le moteur d'un avion en vol ou si elle doit faire face à une mort certaine, étant donné la quantité appropriée d'outils et de ressources dont elle aurait besoin pour savoir comment contourner les capteurs, le système hydraulique, comment rediriger le flux de carburant , manipulent des systèmes qui n’ont jamais été conçus pour être modifiés ou manipulés à l’extérieur ou à partir du cockpit. C'est souvent ce à quoi ressemble la perspective de réécrire une application métier. L’application est généralement intégrée à l’entreprise entre de nombreuses autres technologies.

Je suppose que mon point principal est que le système doit être compris dans presque toute sa complexité, et à un moment donné, il doit être compris dans son intégralité pour que le nouveau système soit correctement "conçu" et pas simplement "créé".

Les cookies sont faits, le logiciel (devrait être) conçu.

Il existe de nombreux exemples d'entreprises décédées après une réécriture, comme Netscape . Il existe également des entreprises qui ont survécu à une réécriture sans problème, comme Twitter .

Il n'y a pas d'études de cas quantifiées, car il n'est pas possible de mener une expérience de contrôle qui examine le succès de la non-réécriture de l'entreprise par rapport à celui de la réécriture. Chaque application est différente.

Il existe des cas évidents où une réécriture a du sens et de nombreux autres cas. J'ai préparé une petite recette pour déterminer si une réécriture aurait un sens dans votre cas.

Je pense que les réécritures ont plus de sens de nos jours car nous codons rapidement sur les épaules de frameworks invasifs en constante amélioration, tels que Rails, Grails, AngularJS. Si vous voulez passer de plain js à Angular, une réécriture est à peu près tout ce que vous pouvez faire. Cela pourrait encore faire des tonnes de sens. Si vous remplacez une implémentation diy par une autre (comme tous les exemples de l'article de Joel Spolsky ), vous êtes probablement fou.

Vous ne trouverez pas de nombreuses études de cas non biaisées qui ne sont pas des comptes rendus après action - la plupart des gens ne paieront pas pour que le même travail soit fait au moins deux fois (une fois pour une réécriture, une fois pour une mise à niveau, mieux cas serait plusieurs réécritures / mises à niveau par différentes équipes).

L’étude de cas que vous avez trouvée semble avoir été réalisée par Fujitsu et, sans surprise, le résultat est qu’il était préférable d’utiliser les outils de Fujitsu.

D'un point de vue organisationnel, une réécriture n'est clairement un échec que si l'application réécrite ne fonctionne pas ou si le projet est annulé avant la fin. Sinon, il est impossible de savoir si le retard dans la publication de la version réécrite a été le même. cause de la perte que vous avez subie ou simplement fortuite. En cas d'annulation avant la fin, c'est généralement considéré comme une perte totale de temps et de ressources. Une mise à niveau peut potentiellement poser le même problème, mais être incrémental a peu de chances d'être à la même échelle (vous en avez pour votre argent).

Le meilleur des cas du point de vue de la programmation est de faire les deux: mises à niveau incrémentielles lors de la réécriture, tout en se soutenant et en s’inspirant. À moins d’avoir différentes équipes, cela prendra naturellement plus de temps.

Notez que ceci fournit une indication approximative pour le moment où vous devriez envisager une réécriture totale: le projet est suffisamment petit pour que vous puissiez le faire facilement, ou l'organisation est suffisamment grande pour pouvoir se permettre les deux, en comptant l'effort ou le coût d'apprentissage. digne d'intérêt. Notez également que si la réécriture ne rattrape jamais la retouche, cela peut vouloir dire plusieurs choses, mais toutes choses étant égales par ailleurs, cela signifie probablement qu'une réécriture était inutile.