Quelles techniques utilisez-vous pour optimiser la réutilisation du code?

Question

Il y a quelques années, on m'a parlé d'une étude sur la réutilisation du code. Apparemment, il a été constaté qu'en moyenne, les programmeurs ont une fenêtre de 7 minutes lorsqu'ils recherchent du code à réutiliser. S'ils ne trouvent pas le code qui convient à leurs besoins dans cette fenêtre, ils écriront le leur.

Cela a été présenté dans le contexte de la nécessité de gérer avec soin votre code pour le réutiliser afin de vous assurer que vous pouvez trouver ce dont vous avez besoin dans la fenêtre.

Comment vous (individus et organisations) gérez-vous votre source pour faciliter sa réutilisation? Maintenez-vous spécifiquement une bibliothèque de réutilisation? Et si oui, comment l'indexez-vous pour maximiser votre taux de réussite?

Answer 1

Une question complexe:

• Certaines parties du code peuvent être généralisées en tant que bibliothèques ou API. Nous avons une bibliothèque commune qui est mise à jour avec des solutions aux problèmes communs. En règle générale: validation, mise en cache, classes d'accès aux données, journalisation, etc.

• Certaines parties sont spécifiques à l'application. Ils ne peuvent pas être généralisés facilement. Nous les convertissons en HowTos et donnons des présentations internes. Le code est également recyclé en utilisant un SCM facilement navigable (dans notre cas, le SVN).

• Nous avons également des outils qui génèrent du code qui, d’une part, ne peut pas être recyclé, de l’autre, il est toujours similaire (pensez à appeler une procédure stockée).

• La programmation par paires est également un moyen utile de diffuser la connaissance des solutions existantes. Nous l'utilisons lorsque cela est possible ou approprié.

• La dernière technique est l'enseignement. Chaque codeur a un tuteur auquel se référer. Comme les tuteurs sont peu nombreux, il y a beaucoup de partage entre eux et cette connaissance peut être diffusée de haut en bas.

Answer 2

Refacturez impitoyablement et espérez le meilleur.

Mise à jour (4 ans plus tard et, espérons-le, plus sage)

• Comme le dit le commentaire de S.Lott: Faites attention à la dénomination. Passez le mot à tous les «committers» de l'équipe. Les bons noms rendent les recherches accessibles et réduisent ainsi les doublons.
• Ayez UNE SEULE façon de faire quelque chose et gardez-le ACCESSIBLE et RECHERCHABLE.
• Ecrivez le code du programmeur moyen (L.C.D.) .. Ne soyez pas malin là où cela suffirait. (Cela inclut la compulsion de chaussure et les désordres connexes)
• Adoptez un ensemble commun de conventions, de styles, de directives, de normes, etc. Assurer l'adhésion et donc la conformité au sein de l'équipe. (Cela signifie que tout le monde utilise les onglets (ou espaces)!). Peu importe ce que vous choisissez - l'objectif est que le code apparaisse cohérent
• Avoir un gardien (respecté par l'équipe) qui surveille de près tous les enregistrements des drapeaux rouges.
• Écrivez le code test-first / outside-in. Cela garantit généralement que votre code est utilisable par plusieurs clients. (Voir la balle du GOOS sur l'indépendance du contexte)

Answer 3

• Avoir un framework activement supporté.

• Connaître la base de code existante / informer les autres développeurs de la base de code. Si votre groupe / entreprise est assez grand, demandez à quelqu'un de connaître la base de code et de demander des conseils.

• Document, document, document. Le code non documenté est inutile pour une réutilisation car il prend trop de temps pour comprendre son fonctionnement interne.

• Avoir de bonnes interfaces. Types faciles, structures ou classes faciles. Plus quelque chose est compliqué, moins il sera utilisé dans un autre projet.

• Optimiser et déboguer du code réutilisable. Les développeurs qui rencontrent des bogues dans le code d’autres personnes pour la nième fois commenceront à coder à nouveau du code déjà existant.

Answer 4

Essayez d’utiliser TDD si vous ne l'êtes pas déjà, c'est ma réponse initiale.

Je pense que l'utilisation de TDD est un excellent moyen de limiter le couplage de code, entre autres avantages. Bien que cela n'empêche pas intrinsèquement le même comportement d'être implémenté deux fois, cela facilite grandement la tâche lorsque vous identifiez un domaine dans lequel vous pouvez supprimer les doublons.

Un autre avantage est que TDD dispose d’une étape pour éliminer la duplication (refactoring) dans le cadre du cycle.

De plus, les tests font partie de la documentation de vos codes, ce qui facilite l'identification du comportement en double.

Answer 5

L'organisation est la clé. Si les espaces de noms et intellisense sont disponibles, la fonction appropriée peut être réduite et éventuellement trouvée. S'ils ne trouvent pas exactement ce qu'ils veulent, ils peuvent trouver quelque chose de proche ou de proche. Le code qui vient d’être mélangé dans un grand groupe facilite la recherche, mais les utilisateurs ne trouveront jamais assez rapidement la méthode qu’ils souhaitent.

La cohérence est également essentielle, à la fois avec le nom et l’emplacement. Si vous décidez de changer de style à un moment donné du projet, revenez en arrière et modifiez tout pour l'adapter à ce style. Cela peut facilement être un processus très long et fastidieux, mais il vaut mieux que d’essayer d’utiliser une bibliothèque incohérente.

Answer 6

Décrivez l’ensemble de l’application et commencez à refactoriser la section de code la plus lourde. (80% du temps passé sur 20% du code le plus utilisé)

Utilisez un outil de profilage permettant d'identifier les fuites de mémoire, les appels répétés, appels longs, mémoire non libérée, ressources non réparties, etc.,

Par règle, le nouveau code utilise toujours les meilleures pratiques.

Answer 7

  

Comment vous (individus et organisations) gérez-vous votre source pour faire   est-il plus facile de réutiliser? Maintenez-vous spécifiquement une bibliothèque de réutilisation? Et   Si oui, comment l’indexez-vous pour maximiser votre taux de réussite?

Je n'ai pas et j'ai un avis certes controversé ici, mais je trouve l'idée de maximiser la réutilisation du code contre-productive (j'interprète "maximiser" comme donnant la priorité à toute autre chose plutôt que de la considérer comme ayant les deux les avantages et les inconvénients de l’équilibre). Je préfère au contraire permettre aux équipes de faire beaucoup d'efforts redondants pour favoriser le découplage et l'isolement des modules de chaque développeur. Avant que tout le monde ne commence à ne pas être d’accord avec moi, je pense que nous pouvons nous mettre d’accord sur certaines choses:

1. Il n'est pas souhaitable de réutiliser du code qui vous oblige à passer des heures à déboguer le code d'autres personnes.
2. Réutiliser un code qui équilibre un si grand nombre de besoins disparates qu’il répond à peine à vos propres besoins et vous oblige à franchir des étapes considérables pour aboutir à une solution peu pratique et peu efficace n’est pas souhaitable.
3. Il est indésirable de réutiliser du code qui nécessite en permanence des modifications de conception et des dépréciations vous obligeant à le réécrire tous les six mois. Si vous pouviez vous-même implémenter la solution en une demi-heure, t besoin de modifications de conception dans le futur car il ne sert que vos besoins précis.
4. Une base de code remplie de code extraterrestre est indésirable par rapport à une base qui utilise davantage le langage et la bibliothèque standard de manière idiomatique et familière, même si cela nécessite un peu plus de code.
5. Les développeurs se bousculent mutuellement parce qu'ils veulent tous les deux apporter des modifications incompatibles à la même conception tout en se disputant et en apportant des modifications causant des bugs dans les implémentations des uns et des autres n'est pas souhaitable.
6. Il est indésirable de créer un ensemble de dépendances pour des conceptions immatures qui n’ont pas fait leurs preuves (pas de couverture de test complète, pas assez de temps pour insonoriser la conception et s’assurer qu’elle répond effectivement aux besoins des utilisateurs finaux sans nécessiter de modifications supplémentaires). .
7. Il n'est pas souhaitable de devoir inclure / importer / lier un ensemble de bibliothèques et de classes / fonctions au script de construction le plus complexe pour écrire quelque chose de simple.
8. Surtout, il n'est pas souhaitable de réutiliser le code d'une manière qui coûte beaucoup plus de temps à court et à long terme que de ne pas le réutiliser.

Espérons que nous pourrons au moins nous mettre d’accord sur ces points. Le problème que j'ai trouvé avec la maximisation de la réutilisation du code de collègues trop enthousiastes était que cela conduisait souvent à un ou plusieurs des problèmes ci-dessus. Le problème fondamental n’était pas directement lié à l’enthousiasme suscité par la réutilisation du code, mais bien aux priorités: réutiliser le code plutôt que de couvrir les tests, d’insonoriser les conceptions et de s’assurer que les choses sont suffisamment matures avant de les réutiliser de manière folle, et ainsi de suite.

Naturellement, si tout le code que nous avons réutilisé a fonctionné à merveille, avait une couverture de test complète, il était prouvé qu'il répondait aux besoins de tout ce qui était utilisé. Il était donc beaucoup plus productif que de ne pas le réutiliser, et ne nécessitait aucune conception. changements pendant des années, je serais ravi de la réutilisation du code. Mais mes expériences ont souvent révélé que cet idéal n’atteignait pas tous les objectifs envisageables pour que la réutilisation du code devienne le problème de la maintenance plutôt que la solution.

  

Comment vous (individus et organisations) gérez-vous votre source pour faire   est-il plus facile de réutiliser? Maintenez-vous spécifiquement une bibliothèque de réutilisation? Et   Si oui, comment l’indexez-vous pour maximiser votre taux de réussite?

Donc, encore une fois, je ne cherche pas à "maximiser" réutilisation de code entre du code propriétaire écrit en interne au sein de l'équipe. Je cherche à m'assurer que l'équipe ne consacre pas énormément de temps à des efforts redondants, mais je laisse les choses glisser un peu si les physiciens et les responsables du rendu implémentent tous les deux leur propre classe de cadre de sélection, par exemple. Ce n'est même pas nécessairement aussi redondant, car le physicien pourrait utiliser des représentations min / max plus efficaces à ses fins, tandis que le développeur du rendu pourrait utiliser des représentations centre / demi-taille. J'essaie de faire en sorte de réutiliser le plus possible la bibliothèque standard lorsque c'est possible, car il s'agit d'une réutilisation de code dont le caractère pratiquement garanti est solide, très bien testé et qui ne nécessite aucune modification supplémentaire de la conception (d'autres équipes dépensent beaucoup de leur temps pour s’assurer de cela).

Au lieu de cela, je me concentre sur les tests. Un module dupliquant un peu de code ici et là est tout à fait correct si vous me demandez si cela fonctionne à merveille de manière à rendre les utilisateurs vraiment heureux, si la couverture de test est complète et si les modifications ne sont pas infinies. Nous acceptons ce type de duplication à tout moment lorsque nous utilisons des bibliothèques tierces susceptibles de dupliquer du code que nous avons également dans notre base de code interne. Ce n'est pas un problème là où la redondance ne conduit pas à des efforts de maintenance redondants.

Je suggère donc d'atténuer un peu l'idée de maximiser la réutilisation du code. Mais si vous souhaitez simplifier au maximum la réutilisation d'un code non-trivial vraiment solide, bien testé, alors je trouve qu'il est bien plus utile d'organiser des bibliothèques à vocation très singulière, comme un "maths". bibliothèque, une " image " bibliothèque de traitement, etc. - au lieu d’essayer de les fusionner en quelque chose comme "noyau" ou "commun". Ces derniers types ont tendance à inciter les développeurs à intégrer toutes sortes de fonctions utilitaires éclectiques qui ne profitent guère à l’équipe qui les utilise, et la plupart du temps, elles ont tendance à devenir compliquées, de sorte qu’il devient difficile de trouver quoi que ce soit d’intérêt.