Réutilisation du code: cela en vaut-il la peine?

https://stackoverflow.com/questions/325514

11-07-2019
|

Question

Nous écrivons tous des classes et du code réutilisables.

Nous prenons en compte la configurabilité pour nous permettre de réutiliser cette fantastique nouvelle classe encore et encore.

Nous disons à nos patrons que le fait de passer plus de temps maintenant nous fera économiser temps et argent plus tard.

Mais en réalité, pour ceux d'entre nous qui n'écrivons pas de bibliothèques tierces et ne consacrent pas notre temps à une application dans son ensemble, combien de fois un cours que vous avez passé plus de temps à écrire à être réutilisé est réellement réutilisé dans un autre projet?

Combien de classes sur mesure avez-vous dans votre bibliothèque qui seront utilisées dans plusieurs projets?

La solution

Ma règle commune est la suivante:

Si vous le répétez une fois, copiez-le.
Si vous le répétez deux fois, modifiez-le.

Autres conseils

Excellente question!
Je pense "concevoir pour la réutilisation" est le mauvais sens autour. Je trouve que le code que j'écris fonctionne, qu'il est propre et joli, est réutilisable. La conception à réutiliser ne se produit que la première fois que le code est réellement réutilisé!

Passer du temps à essayer de rendre quelque chose de réutilisable a tendance à être une perte de temps, car on ne sait jamais ce qui doit être réutilisé.

Cela étant dit, dans mon travail, nous avons une collection de bibliothèques (de grande taille, de 500 Mo ou plus) qui peut être réutilisée pour presque tous les projets - principalement des éléments spécifiques à un domaine.

leppie a écrit:

Ma règle commune est la suivante:


Si vous le répétez une fois, copiez-le.

Si vous le répétez deux fois, modifiez-le

Et j'ajouterais, assurez-vous qu'un commentaire est ajouté aux deux parties du code pour indiquer la duplication en cas de bogue. Vous ne voulez pas le réparer dans une partie et pas dans l'autre (BTDTGTT).

Rob

Je ne suis pas un expert en méthodologie XP (ni en méthodologie), mais je pense que le YAGNI Le principe pourrait être appliqué ici.

Modifiez le code pour le réutiliser uniquement lorsque vous devez le réutiliser.

Il y a une différence entre configurabilité et réutilisabilité - la première peut être extrêmement utile dans de nombreuses situations différentes, lorsque l'environnement change ou quoi que ce soit d'autre - rendant les choses configurables de la manière que je comprends, consiste principalement en une séparation de code et des données, c’est vraiment une bonne pratique.

La conception de la réutilisation n’est vraiment utile que si vous créez quelque chose que vous prévoyez d’utiliser comme bibliothèque pour plusieurs projets. Au fil des années, j'ai pris conscience du principe YAGNI et, à l'heure actuelle, mon objectif est simplement d'écrire du code propre et robuste pour la tâche à accomplir. Mon expérience m'a montré que si quelque chose devait être réutilisé, il est très peu probable que vous prédisiez exactement comment il sera nécessaire de le réutiliser. Il est donc bien mieux d'ajouter uniquement le code dont vous avez besoin pour l'instant. . Ainsi, si vous devez le réutiliser ultérieurement, vous pouvez ajouter de nouveaux éléments qui font exactement ce dont vous avez besoin sans devoir casser les fonctionnalités existantes que vous avez écrites dans le passé, en essayant de prévoir comment vous pourriez en avoir besoin maintenant.

Vous constaterez peut-être qu'après avoir effectué cela plusieurs fois, vous avez une bibliothèque stable et robuste et que vous n'avez pas besoin de la modifier, car elle fait tout ce dont vous avez besoin. Pour moi, il est beaucoup plus facile de permettre cela. de manière évolutive que de perdre trop de temps à deviner l’avenir.

Je pense que la meilleure approche consiste à essayer de concevoir un code avec de bonnes interfaces et une séparation des responsabilités entre les classes sans trop se soucier de la réutilisation. Mais au moins si vous concevez de cette façon, vous laissez ouverte la possibilité de réutilisation. En règle générale, demandez-vous "si je reviens à ce code au bout de 3 mois, vais-je le comprendre et puis-je le prolonger s'il le fallait?"

L’OMI est l’une des pires pratiques de l’industrie lorsqu’une équipe est autorisée à partir et à écrire son propre message "réutilisable". cadre ....

J'aime le modèle LISP dans lequel vous élargissez continuellement le langage. Finalement, vous vous retrouvez avec une langue spécifique au domaine pour votre domaine problématique. Ce n’est pas que j’écrive réellement de lisière, mais dans les langages que j’utilise le plus souvent --- Lua et C à l’heure actuelle --- j’ai l'habitude d'extraire quelque chose dans un module et de le réutiliser plutôt que de le copier et le modifier.

Pour un programmeur C, l'exemple le plus typique de cette approche est le livre Interfaces C et Implémentations . Dave a pris toutes les idées réutilisables qu'il avait eues en écrivant trois ou quatre compilateurs et les a toutes mises dans un livre - et le logiciel est gratuit. Des trucs fabuleux. Maintenant, si j'écris du code C et que je veux l'utiliser une seconde fois, je crée une interface dans le style Hanson. Certaines choses que j'ai faites ce terme: tableaux bidimensionnels, tableaux bidimensionnels avec blocage, bitmaps bidimensionnelles, lecteurs et graveurs de fichiers pbmplus, etc. Avec cette infrastructure en place, il était facile d’écrire un programme que je désirais depuis des années, qui consiste à supprimer les bords noirs des numérisations de photocopies de pages de livres.

Je suis donc d'accord avec qui que ce soit qui a dit que vous voulez le réutiliser, retirez-le --- mais pas avant.

IMHO, certains codes risquent d’être réutilisés souvent, et il est logique de les préparer à une réutilisation fréquente. Les autres codes ne sont pas et n’auront probablement pas besoin d’être développés au-delà de la résolution du problème immédiat.

Bien sûr, sachez que faire la différence est NP-difficile. :)

Si vous êtes sûr de ne plus en avoir besoin, ne vous embêtez pas. Même si vous pensez que cela pourrait être utile. Refacturez-le quand vous en aurez vraiment besoin à nouveau ...

Cependant, ne pas le rendre réutilisable n’est pas une excuse pour ne pas le rendre transparent. Chaque fois que j'écris du code de la manière la plus transparente possible, il est déjà réutilisable à 99% ...

Une fois que vous avez dépassé le niveau des utilitaires techniques, j'ai constaté très peu de réutilisation dans le monde réel.

Si vous y réfléchissez, les raisons sont claires. Supposons que l'application widget_bodger contienne 90% de la fonctionnalité requise par rapport à celle que vous auriez simplement ajoutée à la fonctionnalité manquante.

Ou dites que l'entreprise admirait un "bip" vraiment cool. fonction dans le widget_bodger et souhaitait l'intégrer à l'application gernerate_executive_expenses. Vous pouvez penser que vous pouvez réutiliser le code et découvrir que l'application GEE est l'une des applications les plus anciennes de la société. Elle est écrite en C et doit être exécutée sur du matériel hautement disponible. La seule chose qui peut être restaurée est l'algorithme de base. .

Il existe des opinions très différentes sur ce qui rend le code réutilisable. Je dirais que votre temps est bien passé à clarifier le code et à le prendre en compte (c.-à-d. La séparation des responsabilités).

L’un des avantages de cette solution est une meilleure capacité de réutilisation. Le principal avantage est de rendre le code plus facile à comprendre, à modifier et à déboguer.

Pour envelopper. Ne faites pas de schémas de configuration complexes, de points d’extension et d’événements pour le rendre réutilisable. Essayez de trouver les bonnes pièces mobiles afin que le code puisse être composé en réponse à de nouveaux besoins.

Souvent " réutilisable " Le code est un code résumé et modularisé. Pour moi, le principal avantage n'est pas la réutilisabilité, mais plutôt une testabilité accrue. Parce que lorsque vous isolez et modulez du code, il devient généralement plus testable. La réutilisation est un effet secondaire pratique mais souvent inutilisé.

Et sur une autre note, Juval Lowry plaide pour une programmation basée sur une interface car il maintient que les interfaces sont le seul composant de la réutilisation. Tout le reste a une fonctionnalité implicite (difficile à réutiliser) tandis que les interfaces définissent uniquement un contrat implicitement réutilisable.

Je suis d'accord avec vous dans la mesure où il ne sert à rien de coder de manière à rendre la classe facile à utiliser en dehors de l'application actuelle. La plupart si nous ne le faisons pas et dans les environnements professionnels, il n’est pas nécessaire de le faire. Si une autre application a besoin de cette fonctionnalité à une date ultérieure, l'extraction et la communalisation du code peuvent être effectuées dans le cadre de ce second projet et la direction est susceptible de partager ce point de vue.

Cependant, il est judicieux de rendre votre code réutilisable dans les contraintes de l'application actuelle. Refacturez votre code afin d’éviter les doubles emplois dans le cadre de votre travail actuel. De cette façon, vous faciliterez le travail à une date ultérieure. Ne codez pas autant pour la réutilisation que pour le changement, le changement est beaucoup plus courant.

L’une des raisons pour lesquelles la SOA a échoué ou n’a pas encore été résolue est qu’il est difficile de réutiliser un service: soit il est trop spécifique et il ne peut pas être utilisé ailleurs, soit trop générique (et généralement très complexe). complexe) et ne répond pas aux besoins des différents clients.

Ce n'est pas une "réutilisation de code", c'est une "réutilisation de service", mais certains concepts sont courants.

Mon 2c est que l'éthique de la réutilisation de code doit être une affaire de société, pas seulement une chose de projet. Cela signifie que lorsque vous démarrez un nouveau projet, la préoccupation principale est "De quels autres projets puis-je voler du code pour que ce travail soit effectué aussi rapidement que possible?".

Cela sera en conflit avec la question de "quel est le meilleur langage / l’outil le plus à la mode pour cet emploi?"

Les entreprises qui adoptent cette approche se retrouvent avec un groupe d’ingénieurs qui peuvent facilement basculer d’un projet à l’autre, car le langage, la structure et la base de code interne sont tous cohérents.

L’inconvénient est que le passage à un "nouveau" le langage ou le cadre est beaucoup plus difficile politiquement, même si cela devra arriver à un moment donné.

Un autre avantage de la réutilisation est que vous pouvez facilement savoir où cela se passe dans la base de données. Si vous avez un million de lignes de code, cela peut prendre des heures pour trouver tous les endroits où l'application se comporte d'une certaine manière. Avec un IDE moderne, vous pouvez simplement cliquer sur "Rechercher des références". et vous trouverez, en quelques secondes, tous les endroits où votre composant / méthode est utilisé. Cela peut être utile lorsque vous souhaitez ajouter de nouvelles fonctionnalités, corriger des bugs ou simplement savoir comment fonctionne le système.

Nous en avons quelques-uns, mais nous en avons beaucoup plus avec des projets avec les fonctionnalités souhaitées mais réalisés à leur manière. Ainsi, vous finissez le plus souvent par cannibaliser des fonctionnalités d'anciens projets et les réimplémenter dans votre nouveau. Je dirais que cela compte toujours - vous bénéficiez toujours de l’avoir écrit le code auparavant et vous économisez toujours du temps.

En outre, j’ai constaté que c’est seulement la deuxième fois que vous essayez d’utiliser la fonctionnalité et qu’il devient évident de savoir où se trouve la possibilité de le réutiliser. Si vous essayez de généraliser de manière spéculative, vous vous trompez presque et devez le changer la prochaine fois.

Comme d’autres affiches l’ont dit, si vous voulez copier le code puis le réutiliser, vous serez heureux de le faire une fois que vous avez commencé à déboguer votre code copié.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow