La réutilisation du code est une très bonne idée. Pas terrible .
J'ai une perspective tirée d'environ 30 ans d'ingénierie logicielle, qui tente de "réutiliser".
J'ai commencé à étudier la «réutilisation de code» comme sujet de recherche dans les années 80, après avoir découvert que j'avais réutilisé le design d'un système d'exploitation que j'avais construit au début des années 70, pour un autre installé à la fin des années 70.
La bonne partie de la réutilisation de code réside dans la possibilité de réutiliser parfois du code préexistant «dieu-dieu». Mais le monde est plein de code; comment trouver ce que tu veux Voici ce que j'appelle la malédiction de réutilisation :
Je suis le père Noël (ok Open Source), et j'ai un sac d'un milliard de composants logiciels. Vous pouvez avoir n'importe lequel d'entre eux.
Bonne chance pour choisir.
Pour résoudre correctement le problème de réutilisation:
- le ré-utilisateur doit en quelque sorte spécifier ce dont il a besoin (fonctionnellement, performances, langue cible, hypothèses d'environnement, ...)
- il doit exister une bibliothèque de code "réutilisable" qui a été indexée de différentes manières par ces critères potentiels
- il doit exister un mécanisme pour sélectionner les éléments candidats (pour un milliard d'éléments, vous ne pouvez pas tous les examiner personnellement)
- il doit y avoir un moyen de caractériser à quelle distance de la spécification les candidats choisis sont
- Un processus régulier doit exister pour permettre au réutilisateur de modifier le code réutilisable choisi (voici la contribution la plus importante de la POO: vous pouvez modifier un composant / objet existant en remplaçant ses emplacements. La POO ne fournit aucune autre aide).
- tout cela doit être nettement moins cher que de le recoder
La plupart du temps, on a découvert au fil des ans que pour que le code soit réutilisable, il doit en quelque sorte être conçu dans ce but, ou il contient trop d'hypothèses implicites. Les bibliothèques les plus réussies de réutilisation de code ont été plutôt petites. On peut soutenir que les librairies et les frameworks sont du code "réutilisable" et qu'ils ont un grand succès; Java et C # réussissent non pas parce qu’ils sont de très bons langages informatiques, mais plutôt parce qu’ils disposent d’énormes bibliothèques bien conçues, implémentées et documentées. Mais les gens ne regardent pas le code source dans les bibliothèques; ils appellent simplement une API bien documentée (conçue pour être généralement utilisable).
Ce que la réutilisation de code n’a pas encore fait (la POO non plus), c’est améliorer considérablement notre capacité à coder les systèmes.
Je pense que le principal inconvénient est que tout type de réutilisation de code est fondamentalement limité car le code contient trop d'hypothèses intégrées . Si vous réduisez le code de façon minuscule, vous réduisez les hypothèses au minimum, mais le coût de la création à partir de zéro n'est pas très élevé et les gains de réutilisation ne sont pas efficaces. Si vous créez des morceaux de code énormes, ils sont quasiment inutiles dans un nouveau contexte. Comme Gulliver, ils sont attachés à la plage par un million de petites ficelles, et vous ne pouvez tout simplement pas vous permettre de tous les couper.
Nous devrions travailler sur la réutilisation des connaissances pour construire du code . Si nous pouvons faire cela, alors nous pouvons appliquer cette connaissance à la construction du code dont nous avons besoin, en gérant l'ensemble actuel des hypothèses.
Pour ce faire, il faut toujours la même capacité de spécification pour caractériser les composants logiciels (vous devez toujours dire ce que vous voulez!). Mais ensuite, vous appliquez cette connaissance de "construction" aux spécifications pour générer le code souhaité.
En tant que communauté, nous ne sommes pas encore très bons à cela. Mais les gens le font tout le temps. pourquoi ne pouvons-nous pas l'automatiser? Il y a beaucoup de recherches et cela montre que cela peut être fait dans de nombreuses circonstances.
Les outils mécaniques nécessaires pour accepter les "descriptions de composants" (ce ne sont que des documents formels et peuvent être analysés comme des langages de programmation) constituent un élément clé de cette machinerie et leur appliquent des transformations de programme .
Les compilateurs le font déjà:} Et ils sont vraiment bons dans la classe de problèmes qu’ils abordent.
Les modèles UML avec génération de code constituent une tentative. Ce n'est pas une très bonne tentative. à peu près ce que l’on dit dans la plupart des modèles UML est "j’ai des données qui ressemblent à ceci". Assez difficile de générer un vrai programme si la fonctionnalité est laissée de côté.
J'essaie de construire des systèmes pratiques de transformation de programme, un outil appelé DMS . J'ai été assez distrait en appliquant des transformations de programme, non pas tant aux spécifications abstraites pour générer du code, mais plutôt au code hérité pour le nettoyer. (Ce sont le même problème dans l'abstrait!). (Construire de tels outils prend beaucoup de temps; je le fais depuis 15 ans et en attendant, il faut manger).
Mais DMS a les deux propriétés clés que j'ai décrites ci-dessus: la capacité de traiter des spécifications formelles arbitraires et la capacité de capturer des "connaissances en matière de génération de code" sous forme de transformations et de les appliquer à la demande. Et remarquablement, nous générons dans certains cas particuliers, du code plutôt intéressant provenant de spécifications; DMS est en grande partie construit en utilisant lui-même pour générer son implémentation. Cela nous a permis de réaliser au moins une partie de la promesse de réutilisation (du savoir): des gains de productivité extrêmement importants. J'ai une équipe d'environ 7 personnes techniques; nous avons probablement écrit 1 à 2 MSLOC de "spécifications" pour DMS, mais avons environ 10 LMS de code généré.
Résumé: la réutilisation des connaissances de la génération est la victoire, pas la réutilisation du code .