Qu'est-ce qui rend le code hérité?

Question

J'ai entendu de nombreux développeurs qualifier le code de & "héritage &"; La plupart du temps, c'est du code qui a été écrit par quelqu'un qui ne travaille plus sur le projet. Qu'est-ce qui fait du code, du code hérité?

Mise à jour en réponse à: & «Quelque chose qui a été transmis par un ancêtre ou un prédécesseur ou par le passé &»; http://www.thefreedictionary.com/legacy . Clairement, vous vouliez savoir autre chose. Pourriez-vous clarifier ou développer votre question? S.Lott

Je recherche les symptômes du code hérité qui le rendent inutilisable ou le cauchemar avec lequel travailler. Quand est-il préférable de le jeter? À mon avis, le code devrait être jeté plus souvent et la réinvention de la roue est un élément précieux du développement. L’idéal académique de ne pas réinventer la roue est beau mais pas très pratique.

D'autre part, il est évident que le code hérité mérite d'être conservé.

Answer 1

En utilisant du matériel, des logiciels, des API, des langages, des technologies ou des fonctionnalités qui ne sont plus prises en charge ou qui ont été remplacées, il est généralement associé à une possibilité très limitée, voire aucune, de remplacer ce code, mais de l’utiliser jusqu’à ce que le système meure.

Answer 2

  

Qu'est-ce qui fait du code, du code hérité?

Comme pour Plain Legacy, lorsque l'auteur est mort ou manquant, vous obtenez en tant qu'héritier tout ou partie de son code.

Vous versez des larmes et essayez de comprendre quoi faire avec toutes ces ordures.

Answer 3

Michael Feathers a une définition intéressante dans son livre Working Efficiency with Legacy Code. Selon lui, le code existant est un code sans tests automatisés.

Answer 4

Il s'agit d'un terme très général (et souvent utilisé de manière abusive), mais l'une des raisons suivantes constitue une raison légitime d'appeler un héritage d'application:

1. La base de code est basée sur un langage / une plate-forme totalement non pris en charge par le fabricant du produit d'origine (souvent, le fabricant en question a cessé ses activités).

2. (vraiment 1a) La base de code ou la plate-forme sur laquelle il est construit est si ancienne qu'il est à la fois difficile et coûteux de trouver des développeurs qualifiés ou expérimentés pour le système.

3. L’application prend en charge certains aspects de l’activité qui ne sont plus développés de manière active et pour lesquels les modifications sont extrêmement rares, normalement pour y remédier si quelque chose de tout à fait inattendu change (l’exemple canonique étant le problème de l’an 2000) ou une régulation / pression externe le force. Étant donné que les deux raisons sont pressantes et normalement inévitables, mais qu’aucun développement significatif n’a eu lieu sur le projet, il est probable que les personnes affectées à cette tâche ne connaîtront pas le système (et ses comportements et complexités accumulés). Dans ces cas, cela serait souvent une raison pour augmenter le risque perçu et planifié associé au projet.

4. Le système a / ou est remplacé par un autre. En tant que tel, le système peut être utilisé pour beaucoup moins que prévu, ou peut-être uniquement comme moyen de visualiser des données historiques.

Answer 5

Héritage fait généralement référence à du code qui n'est plus développé - ce qui signifie que si vous l'utilisez, vous devez l'utiliser comme il était à l'origine - vous ne pouvez pas le modifier simplement pour prendre en compte l'apparence actuelle du monde. Par exemple, le code existant doit s’exécuter sur du matériel qui n’existe peut-être pas aujourd’hui ou n’est plus pris en charge.

Answer 6

Selon Michael Feathers, l'auteur de l'excellent Travailler efficacement avec du code hérité , le code hérité est un code qui n’a pas de tests. Lorsqu'il n'y a aucun moyen de savoir ce qui se brise lorsque ce code change.

  

La principale chose qui distingue   le code hérité du code non hérité est   tests, ou plutôt un manque de tests. nous   peut avoir une idée de cela avec un peu   expérience de pensée: serait-ce facile   être de modifier votre base de code si elle   pourrait mordre en arrière, si cela pouvait vous dire   quand vous avez fait une erreur? Ce serait   assez facile, n'est-ce pas? La plupart   la peur impliquée dans apporter des modifications à   grandes bases de code est la peur de   l'introduction de bugs subtils; crainte de   changer les choses par inadvertance. Avec   tests, vous pouvez améliorer les choses avec   impunité. Pour moi, la différence est tellement   critique, il écrase tout autre   distinction. Avec des tests, vous pouvez faire   les choses vont mieux. Sans eux, vous venez   ne pas & # 8217; ne sais pas si les choses se compliquent   mieux ou pire.

Answer 7

Un collègue m'a dit un jour que l'ancien code était un code que vous n'aviez pas écrit vous-même.

On peut dire que c’est un terme péjoratif pour désigner un code que nous n’aimons plus pour quelque raison que ce soit (généralement parce que ce n’est pas cool ou à la mode mais que ça marche).

La brigade TDD pourrait suggérer que tout code sans test soit du code hérité.

Answer 8

Le code hérité est un code source associé à un système d'exploitation qui n'est plus pris en charge ou fabriqué autre technologie informatique.

Answer 9

Personne ne va lire ceci, mais je sens que les autres réponses ne donnent pas tout à fait raison:

1. Cela a de la valeur, s'il n'avait pas été utile, il aurait été jeté il y a longtemps
2. Il est difficile de raisonner parce que
   1. Manque de documentation,
   2. L’auteur original est introuvable ou oublié (oui 2 mois plus tard, votre code peut être un code hérité aussi !!),
   3. Absence de test ou de système de types
   4. Ne suit pas les pratiques modernes (c.-à-d. qu'il n'y a pas de contexte à conserver aussi)
3. Il est nécessaire de le modifier ou de l'étendre. S'il n'est pas nécessaire de le changer, ce n'est pas du code hérité puisque personne ne s'en soucie. Il fait sa chose et il n'y a personne autour de l'appeler le code hérité.

Answer 10

http://en.wikipedia.org/wiki/Legacy_code

& "; Le code hérité est un code source qui se rapporte à un &";

Answer 11

Tout code avec support (ou documentation) manquant. Que ce soit:

• commentaires en ligne
• documentation technique
• documentation parlée (la personne qui l'a écrite)
• tests unitaires documentant le fonctionnement du code

Answer 12

Pour moi, le code hérité est un code qui a été écrit avant un changement de paradigme. Il est peut-être encore très utilisé, mais il est en train d'être refondu pour le rendre conforme.
par exemple. Ancien code de procédure traînant dans un système par ailleurs OO.

Answer 13

Le code (ou toute autre chose, en réalité) devient & "; héritage &"; quand il a été remplacé par quelque chose de plus récent / meilleur, et pourtant, malgré cela, il est toujours utilisé et maintenu en vie & "; dans la nature &";.

Answer 14

La préservation du code hérité n’est pas un idéal académique, c’est un code qui fonctionne, quel que soit le résultat. Dans de nombreuses situations d'entreprise conservatrices, cela serait considéré comme plus pratique que de le jeter et de recommencer à zéro. Mieux vaut le diable que vous connaissez ...

Answer 15

Le code hérité est un code douloureux / coûteux à actualiser en fonction de l'évolution des exigences.

Cela peut se produire de deux manières:

1. Le code ne peut pas être modifié
2. La sémantique du code a été remplacée par du silicium

1) est le plus facile des deux à reconnaître. C'est un logiciel qui a des limites fondamentales le rendant incapable de suivre l'écosystème qui l'entoure. Par exemple, un système construit autour de l'algorithme O (n ^ 2) ne pourra pas évoluer au-delà d'un certain point et doit être réécrit si les exigences évoluent dans cette direction. Un autre exemple est le code utilisant des bibliothèques qui ne sont pas prises en charge par les dernières versions du système d’exploitation.

2) Est plus difficile à reconnaître, mais tous les codes de ce type partagent la caractéristique que les gens ont peur de le changer. Cela pourrait être dû au fait qu’il a été mal écrit / documenté au début, parce que cela n’a pas été testé, ou parce que ce n’est pas trivial et que les auteurs originaux qui l’ont compris ont quitté l’équipe.

Les caractères ASCII / Unicode qui composent le code vivant ont une signification sémantique, le & "Pourquoi est-ce que &"; & "Qu'est-ce que &"; et dans une certaine mesure, le & «Comment va &» dans l'esprit des personnes qui y sont associées. Le code hérité n’est pas possédé ou les propriétaires n’ont pas de signification associée à de grandes parties de celui-ci. Une fois que cela se produit (et cela pourrait arriver le lendemain avec un code très mal écrit), pour changer ce code, quelqu'un doit l'apprendre et le comprendre. Ce processus représente une fraction importante du temps nécessaire pour l'écrire.

Answer 16

Le jour où vous avez peur de refactoriser votre code, c'est le jour où votre code est devenu hérité.

Answer 17

Je considère le code " hérité " si une ou plusieurs des conditions suivantes sont applicables:

• Il a été écrit en utilisant un langage ou une méthodologie qui est une génération en retard sur les normes actuelles
• Le code est un désordre complet sans planification ni conception
• Il est écrit dans des langages obsolètes et dans un style obsolète, non orienté objet
• Il est difficile de trouver des développeurs connaissant la langue car elle est si ancienne

Contrairement à certaines opinions exprimées ici, j’ai vu de nombreuses applications modernes qui fonctionnent correctement sans tests unitaires. Les tests unitaires n'ont toujours pas attiré l'attention de tout le monde. Dans dix ans peut-être, la prochaine génération de programmeurs se penchera sur nos applications actuelles et les considérera & "; Héritées &"; pour ne pas contenir de tests unitaires, tout comme je considère que les applications non orientées objet sont héritées.

Si peu de modifications doivent être apportées à une base de code héritée, il est préférable de simplement la laisser telle quelle et de suivre le courant. Si l'application nécessite des modifications radicales de fonctionnalités, une refonte de l'interface graphique et / ou que vous ne trouvez personne qui connaisse le langage de programmation, il est temps de jeter les bases et de recommencer. Un mot d'avertissement cependant: réécrire à partir de zéro peut prendre beaucoup de temps et il est difficile de savoir si vous avez répliqué toutes les fonctionnalités. Vous souhaiterez probablement que des scénarios de test et des tests unitaires soient écrits pour l’application héritée et la nouvelle application.

Answer 18

Honnêtement, le code hérité est un code, un framework, une API, d’une autre construction logicielle qui ne soit pas & "cool &"; plus. Par exemple, COBOL est unanimement considéré comme un héritage, contrairement à APL. Désormais, on peut également affirmer que COBOL est considéré comme un héritage et APL, car il contient environ 1 m fois la base d’installation en tant que APL. Cependant, si vous dites que vous devez travailler sur du code APL, la réponse ne sera pas & "Oh non, ce matériel hérité &"; mais plutôt & "Oh mon dieu, suppose que tu ne feras rien pour le siècle prochain &"; voir la différence?

Answer 19

Il s’agit d’un terme général utilisé assez souvent (et de manière générique) dans l’écosystème logiciel.

J'aime penser au code hérité en tant que code hérité . C'est simplement du code qui a été écrit dans le passé. Dans la plupart des cas, les codes existants ne suivent pas les pratiques nouvelles / actuelles et sont souvent considérés comme archaïques.

Answer 20

Le code hérité est tout ce qui a été écrit il y a plus d'un mois: -)

Answer 21

C'est souvent un code qui n'est pas écrit dans le langage de script à la mode du jour, et je ne plaisante qu'à moitié.