Garder la trace des classes d'utilité

Question

J'ai récemment été de plus en plus frustré par un problème que je vois émerger dans la base de code de mes projets.

Je travaille sur un projet Java de grande envergure qui compte plus d'un million de lignes de code. Les interfaces et la structure des classes sont très bien conçues et les ingénieurs qui écrivent le code sont très compétents. Le problème est qu'en essayant de rendre le code plus propre, les gens écrivent des classes utilitaires chaque fois qu'ils ont besoin de réutiliser une fonctionnalité, ce qui fait qu'avec le temps et la croissance du projet, de plus en plus de méthodes utilitaires apparaissent. Cependant, lorsque l'ingénieur suivant a besoin de la même fonctionnalité, il n'a aucun moyen de savoir que quelqu'un a déjà implémenté une classe (ou méthode) utilitaire quelque part dans le code et implémente une autre copie de la fonctionnalité dans une classe différente. Il en résulte une grande duplication du code et un trop grand nombre de classes utilitaires dont les fonctionnalités se chevauchent.

Existe-t-il des outils ou des principes de conception que nous pouvons mettre en œuvre en tant qu'équipe afin d'éviter la duplication et la faible visibilité des classes d'utilité ?

Exemple : L'ingénieur A a 3 endroits où il doit transformer le XML en String. Il écrit donc une classe utilitaire appelée XMLUtil et place un toString(Document) dans celui-ci. L'ingénieur B a plusieurs endroits où il sérialise les documents dans différents formats, y compris les chaînes de caractères, il écrit donc une classe utilitaire appelée SerializationUtil et possède une méthode statique appelée serialize(Document) qui renvoie une chaîne de caractères.

Notez que c'est plus qu'une simple duplication de code car il est tout à fait possible que les 2 implémentations de l'exemple ci-dessus soient différentes (disons que l'une utilise l'API du transformateur et l'autre Xerces2-J) donc cela peut être vu comme un problème de "meilleures pratiques" également...

Mise à jour : Je suppose que je décris mieux l'environnement actuel dans lequel nous évoluons. Nous utilisons Hudson pour le CI, Clover pour la couverture du code et Checkstyle pour l'analyse statique du code. Nous utilisons un développement agile comprenant des entretiens quotidiens et des revues de code (peut-être insuffisantes). Nous définissons toutes nos classes utilitaires dans un .util qui, en raison de sa taille, compte maintenant 13 sous-paquets et environ 60 classes sous la classe Root (.util). Nous utilisons également des bibliothèques tierces telles que la plupart des jars apache commons et certains des jars qui composent Guava.

Je suis certain que nous pouvons réduire de moitié le nombre d'utilitaires si nous confions à quelqu'un la tâche de remanier l'ensemble de ce paquet. Je me demandais s'il existe des outils qui peuvent rendre cette opération moins coûteuse et s'il existe des méthodologies qui peuvent retarder autant que possible la répétition du problème.

Answer 1

Ce problème est résolu lorsqu'on combine les fonctions de "complétion de code" des IDE avec des langages qui supportent les extensions de type (par exemple, C# et F#). Ainsi, en imaginant que Java dispose d'une telle fonctionnalité, un programmeur pourrait explorer toutes les méthodes d'extension d'une classe facilement dans l'IDE :

Document doc = ...
doc.to //list pops up with toXmlString, toJsonString, all the "to" series extension methods

Bien sûr, Java n'a pas d'extensions de type. Mais vous pourriez utiliser grep pour rechercher dans votre projet "toutes les méthodes publiques statiques qui prennent SomeClass comme premier argument" pour obtenir un aperçu similaire des méthodes utilitaires qui ont déjà été écrites pour une classe donnée.

Answer 2

Il est assez difficile de construire un outil qui reconnaît la "même fonctionnalité". (En théorie, c'est en fait impossible, et lorsque vous pouvez le faire en pratique, vous avez probablement besoin d'un vérificateur de théorèmes).

Mais ce qui se passe souvent, c'est que les gens clonent un clode qui est proche de ce qu'ils veulent, puis le personnalisent. Ce type de code que vous pouvez trouver, en utilisant un détecteur de clones.

Notre site CloneDR est un outil de détection de code cloné exact ou quasi exact basé sur l'utilisation d'arbres syntaxiques paramétrés. Il correspond aux versions analysées du code, de sorte qu'il n'est pas perturbé par la mise en page, les commentaires modifiés, les noms de variables révisés ou, dans de nombreux cas, les instructions insérées ou supprimées. Il existe des versions pour de nombreux langages (C++, COBOL, C#, Java, JavaScript, PHP, ...) et vous pouvez voir des exemples d'exécution de détection de clones sur le lien suivant lien fourni. Il trouve généralement 10 à 20 % de code dupliqué, et si vous abstrayez ce code dans des méthodes de bibliothèque sur une base religieuse, votre base de code peut effectivement diminuer (cela s'est produit avec une organisation utilisant CloneDR).

Answer 3

Vous cherchez une solution qui puisse vous aider à gérer ce problème inévitable, alors je peux vous suggérer un outil :

• TeamCity : un produit étonnant et facile à utiliser qui gère toute votre construction de code automatisée à partir de votre dépôt et exécute des tests unitaires, etc.
  C'est même un produit gratuit pour la plupart des gens.
  Ce qui est encore mieux il est doté d'un système de détection des doublons dans l'ensemble de votre code .

Plus de choses à lire :

• Outils pour détecter le code dupliqué (Java)

Answer 4

1. un projet d'utilitaire d'application standard. construisez un jar avec l'étendue d'extensibilité restreinte et un paquetage basé sur la fonctionnalité.
2. utiliser des utilitaires communs comme apache-commons ou google collections et fournir une abstraction
3. maintenir la base de connaissances et la documentation et assurer le suivi des bogues et des améliorations dans JIRA
4. refactoring évolutif
5. findbugs et pmd pour trouver des duplications de code ou des bogues
6. examiner et tester les performances des outils utilitaires
7. util karma ! demande aux membres de l'équipe de contribuer à la base de code, chaque fois qu'ils en trouvent un dans le code existant de la jungle ou qu'ils en demandent de nouveaux.