Qu’est-ce qui fait l’inheritance du code?

J’ai entendu de nombreux développeurs se référer au code comme “inheritance“. La plupart du temps, le code 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 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 élargir votre question? S.Lott

Je cherche les symptômes du code hérité qui le rendent inutilisable ou un cauchemar pour travailler avec. Quand est-il préférable de le jeter? Je pense que le code devrait être jeté plus souvent et que réinventer la roue fait partie intégrante du développement. L’idéal académique de ne pas réinventer la roue est un idéal mais ce n’est pas très pratique.

D’un autre côté, il y a évidemment du code hérité à conserver.

En utilisant du matériel, des logiciels, des API, des langages, des technologies ou des fonctionnalités qui ne sont plus pris en charge ou ont été remplacés, généralement combinés à la possibilité de remplacer ce code, il est utilisé jusqu’à ce que le système meure.

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

Comme dans le cas d’un inheritance clair, lorsque l’auteur est mort ou manquant, vous, en tant qu’héritier, obtenez tout ou partie de son code.

Vous avez versé des larmes et essayé de savoir quoi faire avec tous ces déchets.

Michael Feathers a une définition intéressante dans son livre Working efficacement avec Legacy Code. Selon lui, le code hérité est du code sans tests automatisés.

C’est un terme très général (et souvent abusé), mais l’une des raisons suivantes serait légitime pour appeler une application héritée:

  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 ledit fabricant a cessé ses activités).

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

  3. L’application prend en charge certains aspects de l’entreprise qui ne sont plus développés activement et pour lesquels les modifications sont extrêmement rares, normalement pour résoudre un problème totalement inattendu (l’exemple canonique étant le problème de l’an 2000) ou certaines forces de pression externes il. Comme les deux raisons sont pressantes et normalement inévitables, mais qu’aucun développement significatif ne s’est produit 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 été ou est remplacé par un autre. En tant que tel, le système peut être utilisé beaucoup moins que prévu à l’origine, ou peut-être uniquement comme un moyen de visualiser des données historiques.

Legacy fait généralement référence à un code qui n’est plus développé – ce qui signifie que si vous l’utilisez, vous devez l’utiliser dans ses termes d’origine – vous ne pouvez pas simplement l’éditer pour prendre en compte l’aspect actuel du monde. Par exemple, le code hérité doit s’exécuter sur du matériel qui n’existe peut-être pas aujourd’hui ou n’est plus pris en charge.

Selon Michael Feathers, l’auteur de l’excellent Working effective with Legacy Code , le code hérité est un code sans test. Quand il n’y a aucun moyen de savoir ce qui casse quand ce code change.

La principale chose qui distingue le code hérité du code non hérité est le test, ou plutôt le manque de tests. Nous pouvons avoir une idée de cela avec une petite expérience de reflection: à quel point serait-il facile de modifier votre base de code si elle pouvait mordre, si cela pouvait vous dire quand vous vous êtes trompé? Ce serait assez facile, n’est-ce pas? La peur de l’introduction de bogues subtils est la plus grande partie de la peur liée à la modification de bases de code volumineuses. peur de changer les choses par inadvertance. Avec des tests, vous pouvez améliorer les choses en toute impunité. Pour moi, la différence est tellement critique que cela dépasse toute autre distinction. Avec les tests, vous pouvez améliorer les choses. Sans eux, vous ne savez pas si les choses s’améliorent ou s’aggravent.

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

Un collègue m’a dit un jour que le code hérité était un code que vous n’aviez pas écrit vous-même.

Sans doute, c’est juste un terme péjoratif pour un code que nous n’aimons plus pour une raison quelconque (généralement parce que ce n’est pas cool ou à la mode, mais ça marche).

La brigade TDD pourrait suggérer que tout code sans test est un code hérité.

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

“Le code hérité est un code source qui concerne un produit non pris en charge ou fabriqué”

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

Pour moi, le code hérité est un code qui a été écrit avant un changement de paradigme. Il peut encore être très utilisé, mais il est en train d’être refait pour le mettre en conformité.
Par exemple, ancien code procédural dans un autre système OO.

Personne ne va lire ça, mais je pense que les autres réponses ne sont pas correctes:

  1. Il a de la valeur, si ce n’était pas utile, il aurait été jeté depuis longtemps
  2. Il est difficile de raisonner parce que l’un des
    1. Manque de documentation,
    2. L’auteur original ne peut pas être trouvé ou oublié (oui 2 mois plus tard, votre code peut aussi être un code hérité !!),
    3. Manque de tests ou de type de système
    4. Ne suit pas les pratiques modernes (c.-à-d. Pas de contexte à retenir)
  3. Il est nécessaire de le modifier ou de l’étendre. S’il n’y a pas besoin de le changer, ce n’est pas du code hérité car personne ne s’en soucie. Il fait son truc et il n’y a personne pour l’appeler code hérité.

Le code (ou n’importe quoi d’autre, vraiment) devient “hérité” quand il a été remplacé par quelque chose de nouveau / meilleur, et pourtant malgré cela, il est toujours utilisé et maintenu en vie “dans la nature”.

La préservation du code existant n’est pas un idéal académique, car il permet de conserver le code qui fonctionne, même si celui-ci est médiocre. Dans de nombreuses situations d’entreprise conservasortingces, cela serait considéré comme plus pratique que de le jeter et de repartir de zéro. Mieux vaut le diable que vous connaissez …

Je considère le code “hérité” si une ou toutes les conditions suivantes s’appliquent:

  • Il a été écrit en utilisant un langage ou une méthodologie qui est une génération derrière 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 et non orienté object.
  • Il est difficile de trouver des développeurs qui connaissent la langue parce qu’elle est trop ancienne

Contrairement à d’autres opinions, j’ai vu beaucoup d’applications modernes qui fonctionnent correctement sans tests unitaires. Les tests unitaires ne sont toujours pas connus. Peut-être que dans dix ans, la prochaine génération de programmeurs examinera nos applications actuelles et les considérera comme «héritées» pour ne pas contenir de tests unitaires, tout comme je considère que les applications non orientées object sont héritées.

Si peu de modifications doivent être apscopes à une base de code héritée, il est préférable de la laisser telle quelle et de suivre le stream. Si l’application nécessite des modifications drastiques des fonctionnalités, une refonte de l’interface graphique et / ou si vous ne trouvez personne connaissant le langage de programmation, il est temps de jeter et de recommencer. Un mot d’avertissement cependant: la réécriture à 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 voudrez probablement avoir des cas de test et des tests unitaires écrits pour l’application héritée et la nouvelle application.

Le code hérité est un code qui est douloureux / coûteux pour restr à jour avec les exigences changeantes.

Cela peut se produire de deux manières:

  1. Le code ne convient pas pour le changement
  2. La sémantique du code a été remplacée par le silicium

1) est le plus facile des deux à reconnaître. C’est un logiciel qui a des limites fondamentales, ce qui le rend incapable de suivre l’écosystème qui l’entoure. Par exemple, un système construit autour de l’algorithme O (n ^ 2) ne sera pas mis à l’échelle 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 non sockets en charge sur les dernières versions du système d’exploitation.

2) est plus difficile à reconnaître, mais tout code de ce type a la caractéristique que les gens ont peur de le changer. Cela peut être dû au fait qu’elle a été mal écrite / documentée au départ, parce qu’elle n’a pas été testée, ou parce qu’elle n’est pas sortingviale et que les auteurs originaux qui ont compris cela ont quitté l’équipe.

Les caractères ASCII / Unicode qui comprennent le code vivant ont une signification sémantique, le «pourquoi», le «quoi» et, dans une certaine mesure, le «comment», dans l’esprit des personnes qui y sont associées. Le code hérité n’est pas détenu ou les propriétaires n’ont pas de sens associé à 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, il faut que quelqu’un l’apprenne et le comprenne. Ce processus représente une fraction significative du temps nécessaire pour l’écrire.

En toute honnêteté, le code hérité est un code, un framework, une API, d’autres logiciels qui ne sont plus “cool”. Par exemple, COBOL est unanimement considéré comme un inheritance, contrairement à APL. Maintenant, on peut également faire valoir que COBOL est considéré comme hérité et APL, non pas parce qu’il a environ 1 million de fois la base d’installations APL. Cependant, si vous dites que vous devez travailler sur le code APL, la réponse ne serait pas “oh non, cet inheritance” mais plutôt “oh mon dieu, devinez que vous ne ferez rien pour le siècle prochain” voyez la différence?

Le code hérité est tout ce qui est écrit il y a plus d’un mois 🙂

C’est souvent n’importe quel code qui n’est pas écrit dans le langage de script du jour, et je ne plaisante qu’à moitié.

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