Avons-nous abandonné l’idée de réutilisation du code ?

https://stackoverflow.com/questions/356275

21-08-2019
|

Question

Il y a quelques années, les médias étaient en proie à toutes sortes d'articles sur la façon dont l'idée de réutilisation du code était un moyen simple d'améliorer la productivité et la qualité du code.

D'après les blogs et les sites que je vérifie régulièrement, il semble que l'idée de "réutilisation du code" soit démontrée.Peut-être que les défenseurs de la «réutilisation du code» ont tous rejoint la foule SOA à la place?:-)

Chose intéressante, lorsque vous recherchez la `` réutilisation du code '' dans Google, le deuxième résultat est intitulé:

« La réutilisation du code interne est considérée comme dangereuse » !

Pour moi, l'idée de la réutilisation du code n'est que du bon sens, après tout, regardez le succès du projet Apache Commons!

Ce que je veux savoir c'est :

Est-ce que vous ou votre entreprise essayez de réutiliser le code ?
Si oui, comment et à quel niveau, c'est-à-direAPI de bas niveau, composants ou logique commerciale partagée?Comment vous ou votre entreprise réutilisez-vous le code ?
Est-ce que ça marche?

Discuter?

Je suis pleinement conscient qu'il existe de nombreuses bibliothèques open source disponibles et que quiconque a utilisé .NET ou Java a réutilisé du code sous une forme ou une autre.C'est du bon sens !

Je faisais davantage référence à la réutilisation du code au sein d'une organisation plutôt qu'à l'échelle d'une communauté via une bibliothèque partagée, etc.

J'ai initialement demandé ;

Est-ce que vous ou votre entreprise essayez de réutiliser le code ?
Si oui, comment et à quel niveau, c'est-à-direAPI de bas niveau, composants ou logique métier partagée ?Comment vous ou votre entreprise réutilisez-vous le code ?

D'où je suis, je vois très peu d'exemples d'entreprises essayant de réutiliser du code en interne ?

Si vous disposez d'un morceau de code qui pourrait potentiellement être partagé dans une organisation de taille moyenne, comment feriez-vous pour informer les autres membres de l'entreprise que cette lib/api/etc existait et pourrait être utile ?

La solution

Le titre de l'article que vous faites référence est trompeur, et est en fait une très bonne lecture. La réutilisation de code est très bénéfique, mais il y a des inconvénients avec tout. En fait, si je me souviens bien, l'essentiel de l'article est que vous scellez le code dans une boîte noire et non revisiter, afin que les développeurs originaux vous laisser perdre les connaissances. Alors que je vois le point, je ne suis pas nécessairement avec elle -. Au moins pas à l'égard « ciel est en baisse »

Nous avons en fait la réutilisation du code de groupe en plus de cours seulement réutilisables, nous examinons l'ensemble de l'entreprise. Les choses qui sont plutôt des préoccupations transversales amélioration du cadre ou d'adresse sont mis dans un cadre de développement que toutes nos applications utilisent (penser des choses comme la validation avant et après, l'exploitation forestière, etc.). Nous avons aussi la logique métier qui est applicable à plus d'une application, de sorte que ces sortes de choses sont déplacés à un noyau BAL qui est accessible partout.

Je pense que la chose importante est de ne pas promouvoir les choses pour la réutilisation si elles ne vont pas être réutilisés vraiment. Ils doivent être bien documentés, de sorte que les nouveaux développeurs peuvent avoir une ressource pour les aider à trouver la vitesse, aussi bien. Les chances sont, si les connaissances ne sont pas partagées, le code sera finalement réinventé ailleurs et conduira à double emploi si vous n'êtes pas rigoureux dans la documentation et le partage des connaissances.

Autres conseils

Nous réutilisons le code. En fait, nos développeurs écrivent spécifiquement du code qui peut être réutilisé dans d'autres projets.Cela s'est avéré très payant : nous sommes capables de démarrer de nouveaux projets rapidement et nous renforçons nos bibliothèques principales de manière itérative.

Mais on ne peut pas simplement écrire du code et s’attendre à ce qu’il soit réutilisé ; la réutilisation du code nécessite une communication entre les membres de l'équipe et d'autres utilisateurs afin que les gens sachent quel code est disponible et comment l'utiliser.

Les éléments suivants sont nécessaires pour que la réutilisation du code fonctionne efficacement :

Le code ou la bibliothèque elle-même
Demande de code pour plusieurs projets ou efforts
Communication des fonctionnalités/capacités du code
Instructions sur la façon d'utiliser le code
Un engagement à maintenir et à améliorer le code au fil du temps

La réutilisation de code est essentiel. Je trouve que cela me oblige aussi à généraliser autant que possible, le code rendant également plus adaptables à des situations différentes. Idéalement, presque toutes les bibliothèques de niveau inférieur, vous écrivez doit être en mesure d'adapter à une nouvelle série d'exigences pour une autre application.

Je pense que la réutilisation du code est fait à travers des projets open source pour la plupart. Tout ce qui peut être réutilisé ou prolongée est fait par les bibliothèques. Java a un nombre incroyable de bibliothèques open source disponibles pour faire un grand nombre de choses. Comparez cela à C ++ et de la précocité sur tout devrait être mis en œuvre à partir de zéro en utilisant MFC ou l'API Win32.

RÉCUPÉRER.

Sur une petite échelle, nous essayons d'éviter la duplication de code, autant que posible. Et nous avons une bibliothèque complète avec beaucoup de code fréquemment utilisé.

Code Normalement est développé pour une application. Et si elle est suffisamment générique, il est promu à la bibliothèque. Cela fonctionne excelent.

L'idée de la réutilisation de code n'est plus une idée nouvelle ... d'où le manque apparent d'intérêt. Mais il est encore très bien une bonne idée. L'ensemble du framework .NET et l'API Java sont de bons exemples de réutilisation de code dans l'action.

Nous nous sommes habitués à développer des bibliothèques OO de code pour nos projets et de les réutiliser dans d'autres projets. Sa partie du cycle de vie naturel d'une idée. Il est vivement débattue pendant un certain temps et puis tout le monde accepte et il n'y a aucune raison pour discussion.

Bien sûr, nous réutilisons code.

Il y a une quantité presque infinie de paquets, les bibliothèques et les objets partagés disponibles pour toutes les langues, avec les communautés de développeurs behing les soutenir et la mise à jour.

Je pense que le manque de « l'attention des médias » est due au fait que tout le monde le fait, il est donc plus la peine d'écrire au sujet. Je ne l'entends pas beaucoup de gens de sensibilisation de la programmation orientée objet et tests unitaires que je soit. Tout le monde est déjà au courant de ces concepts (qu'ils les utilisent ou non).

Niveau de l'attention des médias sur une question n'a rien à voir avec son importance, que l'on parle le développement de logiciels ou de la politique! Il est important d'éviter de gaspiller les efforts de développement en réinventant (ou re-en maintenant!) La roue, mais cela est si bien connu maintenant qu'un éditeur ne va probablement pas se énerver par un autre article sur le sujet.

Plutôt que de regarder le nombre d'articles actuels et messages de blog comme une mesure d'importance (ou d'urgence) examiner les concepts et les buzz phrases qui sont devenues des classiques ou entrés dans le jargon (une autre forme de réutilisation!) Par exemple, Google pour les utilisations de l'acronyme SEC pour une bonne discussion sur les nombreuses formes de redondance qui peuvent être éliminés dans les processus logiciels et de développement.

Il y a aussi un rôle pour Discernement en ce qui concerne les coûts de la réutilisation par rapport à où les avantages sont atteints. Certains auteurs préconisent d'attendre à vous soucier de la réutilisation jusqu'à ce qu'un deuxième ou troisième utilisation émerge en fait, plutôt que de dépenser des efforts pour généraliser peu de code la première fois qu'il est écrit.

Mon point de vue personnel, basé sur la pratique dans mon entreprise:

Avez-vous ou votre entreprise essayer de réutiliser le code?

Il est évident que, si nous avons un autre morceau de code qui correspond déjà à nos besoins, nous allons réutiliser. Nous ne sortons pas de notre façon d'utiliser des chevilles carrées dans des trous ronds bien.

Si oui, comment et à quel niveau, à savoir api bas niveau, les composants ou la logique métier partagée? Comment avez-vous ou votre code de réutilisation de l'entreprise?

A tous les niveaux. Il est écrit dans nos normes de codage que les développeurs doivent toujours assumer leur code sera réutilisé - même si, en réalité, qui est très peu probable. Voir ci-dessous

Si votre modèle OO est bon, votre API reflète probablement votre domaine d'activité, de sorte que les classes réutilisables équivaut probablement à la logique métier réutilisable sans effort supplémentaire.

Pour la réutilisation réelle, un point clé est de savoir ce que le code est déjà disponible. Nous décidons en ayant tout documenté dans un emplacement central. Nous avons juste besoin d'un peu de discipline pour assurer que la documentation est mise à jour et consultable de manière significative.

Est-ce que ça marche?

Oui, mais pas à cause de la réutilisation potentielle ou réelle! En réalité, au-delà de quelques bibliothèques de base et les composants de l'interface utilisateur, il n'y a pas une grande quantité de réutilisation.

A mon avis, la valeur réelle est en fait le code réutilisable . Ce faisant, à part un, espérons-propre API, le code (a) être documenté suffisamment pour un autre développeur pour l'utiliser sans pêche au chalut le code source , et (b) il sera également remplaçable . Ces points sont un grand avantage pour l'entretien continu du logiciel.

Alors que je pense que la réutilisation du code est valable, je peux voir où ce sentiment est enraciné. Je travaille sur beaucoup de projets dans lesquels beaucoup de soin supplémentaire a été prise pour créer du code réutilisable qui a ensuite été jamais réutilisé. La réutilisation cours est bien préférable de dupliquer du code, mais je l'ai vu beaucoup de modèles d'objets très extenisve créés dans le but d'utiliser les objets à travers l'entreprise dans plusieurs projets (type de la manière peut être utilisé dans le même service dans SOA différent applications), mais ont jamais vu les objets effectivement utilisés plus d'une fois. Peut-être que je viens pas fait partie des organisations qui bon avantage du principe de la réutilisation.

Les deux projets de logiciels que j'ai travaillé deux ont été le développement à long terme. L'un est d'environ 10 ans, l'autre a été autour depuis plus de 30 ans, réécrite dans une version de couple de Fortran le long du chemin. Les deux font la réutilisation étendue de code, mais les deux se fondent très peu sur les outils externes ou des bibliothèques de code. DRY est un grand mantra sur le plus récent projet, qui est en C ++ et se prête plus facilement à le faire dans la pratique.

Peut-être la meilleure question est quand pouvons-nous pas réutiliser le code de nos jours? Nous sommes soit dans un état sur la construction à l'aide de quelqu'un d'autre observé les « meilleures pratiques » ou prediscovered « design patterns » ou la construction juste en fait le code existant, les bibliothèques, ou la copie.

Il semble que le degré auquel le code A est réutilisé pour rendre le code B est souvent basé autour de combien les idées dans le code A pris au code B sont extraites dans des modèles de conception / idiomes / livres / pensées fugaces / code réel / bibliothèques. La partie difficile est l'application de toutes ces bonnes idées à votre code actuel.

Types de non-techniques se excès de zèle de la chose réutilisation. Ils ne comprennent pas pourquoi tout ne peut pas être copier-coller. Ils ne comprennent pas pourquoi le greemelfarm a besoin d'un adaptateur spécial pour communiquer les mêmes informations qu'il sert à l'ancien système au nouveau système, et que, malheureusement, nous ne pouvons pas changer soit en raison d'une bazillion d'autres raisons.

Je pense que les technophiles ont été réutilisent du jour 1 dans les mêmes musiciens de façon ont été la réutilisation du jour 1. Son une évolution organique en cours et sythesis qui gardera en cours.

La réutilisation de code est une question extrêmement importante -. Où le code ne sont pas réutilisés, les projets prennent plus de temps et sont plus difficiles pour les nouveaux membres de l'équipe pour entrer dans
Cependant, l'écriture de code réutilisable prend plus de temps.

Personnellement, j'essaie d'écrire tout mon code d'une manière réutilisable, cela prend plus, mais il en résulte dans le fait que la plupart de mon code est devenu infrastructures officielles dans mon organisation et que de nouveaux projets basés sur ces infrastructures prendre beaucoup moins de temps. < br>
Le danger dans la réutilisation du code, est si le code réutilisé n'est pas écrit comme une infrastructure - d'une manière générale et encapsulé avec aussi peu que les hypothèses possibles et autant que la documentation possible et les tests unitaires, que le code peut finir par faire des choses inattendues.
De plus, si les bugs sont détectés et résolus, ou les dispositifs ajoutés, ces changements sont rarement retournés au code source, ce qui entraîne dans les différentes versions du code réutilisé, que personne ne connaît ni ne comprend.

La solution est:
1. Concevoir et écrire le code avec non seulement un projet à l'esprit, mais de penser des besoins futurs et essayer de faire la conception suffisamment souple pour les couvrir avec le changement de code minimal.
2. Pour clôturer le code dans les bibliothèques qui doivent être utilisées en l'état et non modifiés dans l'utilisation de projets.
3. Pour permettre aux utilisateurs de visualiser et de modifier le code de la bibliothèque sont acceptés dans les son solution (pas dans la solution du projet à l'aide).
4. Pour la conception des futurs projets à appuyer sur les infrastructures existantes, apporter des modifications aux infrastructures, au besoin.
5. Pour charger le maintien de l'infrastructure à tous les projets, ce qui maintient l'infrastructure financée.

Avez-vous ou votre entreprise et essayez de réutiliser le code? Si oui, comment et à quel niveau, à savoir api bas niveau, les composants ou la logique métier partagée? Comment vous ou votre code de réutilisation de l'entreprise?

Je travaillais dans une base de code avec la réutilisation de code uber, mais il était difficile de maintenir parce que le code réutilisé était instable. Il était enclin à concevoir des changements et deprecation de façon que tout montés en cascade pour l'utiliser. Avant que je travaille dans une base de code sans réutilisation de code où les personnes âgées réellement encouragé le copier-coller comme un moyen de réutiliser le code même spécifique à l'application, donc je suis arrivé à voir les deux extrémités et je dois dire que l'on est pas nécessairement beaucoup mieux que l'autre lorsqu'il est pris aux extrêmes.

Et je l'habitude d'être une sorte de programmeur bottom-up uber. Vous me demandez de construire quelque chose de spécifique et je finis par la construction d'outils généralisés. Ensuite, en utilisant ces outils, je construis des outils généralisés plus complexes, puis commencer à construire des abstractions DIP pour exprimer les exigences de conception pour les outils de niveau inférieur, puis je construis des outils encore plus complexes et répéter, et à un moment donné, je commence à écrire du code qui ne fait ce que vous voulez que je fasse. Et comme contre-productif qui sonnait, j'étais assez vite à elle et pourrait expédier des produits complexes de façon que les gens ont vraiment surpris.

Le problème était l'entretien au cours des mois, des années! Après avoir construit des couches et des couches de ces bibliothèques généralisées et réutilisai l'enfer hors d'eux, chacun a voulu servir un but beaucoup plus que ce que vous me demandez de faire. Chaque couche voulait résoudre les besoins de la faim du monde. Donc, chacun était très ambitieux: une bibliothèque mathématique qui veut être incroyable et résoudre les besoins de la faim du monde. Puis quelque chose construit au-dessus de la bibliothèque de mathématiques comme une bibliothèque de géométrie qui veut être incroyable et résoudre les besoins de la faim du monde. Vous savez quelque chose qui ne va pas quand vous essayez d'expédier un produit, mais votre esprit est ressassant la façon dont votre bibliothèque de géométrie généralisée uber usine pour le rendu et la modélisation quand vous êtes censé travailler sur l'animation car le code d'animation vous travaillez sur les besoins quelques nouvelles fonctions géométriques.

équilibre entre les besoins de chacun

Je trouve dans la conception de ces bibliothèques généralisée uber-que je devais devenir obsédé par les besoins de chaque membre de l'équipe, et je devais apprendre comment raytracing a travaillé, comment les fluides dynamiques travaillées, la façon dont le moteur de maillage a travaillé, comment la cinématique inverse travaillé, comment l'animation de personnages travaillé, etc., etc., etc. Je devais apprendre à faire le travail de tout le monde à peu près sur l'équipe parce que je soupesé tous leurs besoins spécifiques dans la conception de ces uber bibliothèques généralisée je laissais derrière en marchant un corde raide équilibre des compromis de conception de toute la réutilisation de code (en essayant de faire les choses pour Bob travailler sur raytracing qui utilise l'une des bibliothèques mais sans nuire à John trop qui travaille sur la physique qui utilise aussi, mais sans compliquer la conception de la bibliothèque trop pour les rendre heureux tous les deux).

Il est arrivé à un point où je tentais de paramétrisation des boîtes englobantes avec les classes politiques afin qu'ils puissent être stockés soit en tant que centre et demi-taille d'une personne recherchée ou min / degrés max comme quelqu'un d'autre voulait, et la mise en œuvre était s'alambiquée essayer très vite de garder frénétiquement avec les besoins de chacun.

Design By Comité

Et parce que chaque couche a essayé de servir un large éventail de besoins (beaucoup plus large que nous avions besoin en fait), ils ont trouvé de nombreuses raisons d'exiger des changements de conception, parfois par des conceptions demandé comité (qui sont généralement type de brut). Et puis ces changements de conception seraient en cascade vers le haut et affecter tout le code de niveau supérieur en utilisant, et l'entretien d'un tel code a commencé à devenir un véritable PITA.

Je pense que vous pouvez potentiellement partager plus de code dans une équipe partageant les mêmes idées. La nôtre était pas comme d'espritdu tout. Ce ne sont pas les vrais noms, mais je devrais le projet de loi ici qui est un programmeur graphique de haut niveau et scripteur qui crée de belles conceptions de l'utilisateur final, mais le code douteux avec beaucoup de hacks, mais il a tendance à être d'accord pour ce type de code. Je suis Bob ici qui est une vieille horloge qui a été la programmation depuis l'ère de cartes perforées qui aime écrire 10.000 fonctions en ligne avec GOTO en eux et ne comprend toujours pas le point de la programmation orientée objet. Je suis Joe ici qui est comme un assistant mathématique, mais le code écrit personne d'autre ne peut comprendre et toujours faire des suggestions qui sont mathématiquement alignées mais pas nécessairement efficaces du point de vue informatique. Ensuite, je suis Mike ici qui est dans l'espace qui nous veut porter le logiciel pour iPhone et pense que nous devrions suivre toutes les conventions d'Apple et les normes techniques.

Essayer de satisfaire les besoins de tout le monde ici en venant avec un design décent est, sans doute avec le recul, impossible. Et dans tout le monde essaie de partager le code de l'autre, je pense que nous sommes devenus contre-productifs. Chaque personne est compétente dans une zone mais en essayant de trouver des modèles et des normes que tout le monde est heureux avec tête juste à toutes sortes d'instabilité et a ralenti tout le monde vers le bas.

ARBITRAGES

Alors ces jours, j'ai trouvé l'équilibre est d'éviter la réutilisation du code pour les choses au niveau le plus bas. J'utilise une approche descendante du niveau moyen, peut-être (quelque chose de pas aussi far Séparée de ce que vous me demandez de le faire), et de construire une bibliothèque indépendante il que je peux encore faire dans un court de temps, mais la bibliothèque n'a pas l'intention de produire des mini-libs qui tentent de résoudre les besoins de la faim du monde. En général, ces bibliothèques sont un peu plus étroit but que ceux de niveau inférieur (ex: une bibliothèque de physique, par opposition à une bibliothèque d'intersection de la géométrie généralisée).

YMMV, mais s'il y a quelque chose que j'ai appris au fil des années dans les façons les plus difficiles possibles, il est qu'il pourrait y avoir un équilibre et un point où nous pourrions vouloir éviter délibérément la réutilisation du code dans un cadre de l'équipe à un niveau granulaire , abandonnant une certaine généralité pour le code plus bas niveau en faveur du découplage, avec le code malléable, nous pouvons améliorer la forme pour répondre aux besoins plus spécifiques plutôt que généralisées, et ainsi de suite - peut-être même simplement laisser tout le monde a un peu plus de liberté pour faire les choses à leur sa propre façon. Mais bien sûr, tout cela est dans le but de produire encore une très réutilisable, bibliothèque généralisée, mais la différence est que la bibliothèque pourrait ne pas se décomposer dans les teeniest bibliothèques généralisées, parce que je trouvais que le franchissement d'un certain seuil et essayer de faire trop Teeny, les bibliothèques généralisées commence à devenir réalité une entreprise extrêmement contre-productif à long terme - pas à court terme, mais à long terme et large des choses

Si vous avez un morceau de code qui pourrait être partagée entre un taille moyenne organisation comment feriez-vous pour informer les autres les membres de la société que cette lib / api / etc existé et pourrait être de bénéficier?

En fait, je suis plus réticent ces jours-ci et de trouver plus pardonnable si les collègues font un travail inutile parce que je voudrais vous assurer que le code fait quelque chose assez utile et non triviale et est aussi très bien conçu et testé avant d'essayer de le partager avec les gens et accumuler un tas de dépendances à elle. La conception devrait avoir très, très peu de raisons d'exiger des modifications à partir de ce moment-là si je partage avec le reste de l'équipe.

Dans le cas contraire, il pourrait causer plus de douleur qu'elle sauve en fait.

Je l'habitude d'être si intolérant de la redondance (en code ou efforts), car il semble se traduire par un produit qui a été très buggy et explosive dans l'utilisation de la mémoire. Mais je zoomé trop sur la redondance comme le principal problème, alors qu'en réalité, le vrai problème était de mauvaise qualité, le code écrit à la hâte, etmanque de tests solides. Bien-testé, le code fiable, efficace ne souffrirait pas ce problème à peu près aussi grande d'un degré, même si certaines personnes en double, par exemple, certaines fonctions mathématiques ici et là.

L'une des choses de bon sens à regarder et se rappeler que je ne l'ai pas au moment de la façon dont nous ne nous dérange pas une certaine redondance lorsque nous utilisons une bibliothèque tierce partie très solide. Il y a des chances que les gars utilisent une bibliothèque tierce partie ou deux qui a un travail redondant avec ce que votre équipe est en train de faire. Mais ne nous dérange pas dans ces cas parce que la bibliothèque tierce partie est grande et bien testé. Je recommande l'application de cette même état d'esprit à votre propre code interne. L'objectif devrait être de créer quelque chose de génial et bien testé, sans chichi sur un peu de redondance ici et là, comme je l'ai fait à tort, il y a longtemps.

Alors ces jours, j'ai déplacé mon intolérance à l'égard d'un manque de tests à la place. Au lieu de se fâcher sur les efforts redondants, je trouve qu'il est beaucoup plus productif de se fâcher sur le manque d'autres personnes de tests unitaires et d'intégration! :-D

Maven a résolu la réutilisation du code. Je suis tout à fait sérieux.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow