Comment créer et entretenir une bibliothèque de réutilisation du code ?

Question

J'essaie de mettre en place un référentiel de code réutilisable. Je pensais que chaque module de code réutilisable aurait un certain "niveau de maturité". La note serait définie comme le niveau auquel un code réutilisable se situe par rapport à un certain ensemble d'exigences. Le niveau de maturité le plus élevé correspondra au degré de standardisation le plus élevé dans un ensemble prédéfini d'exigences.

Par exemple :
Niveau ; Exigences ; Description
Niveau 0 ; L'utilisation du code est légale ; L'utilisation du code est-elle légale dans l'industrie commerciale/à travers plusieurs contrats/etc ?
Niveau 1 ; ligne de code de base et satisfaction des exigences de niveau 0 ; code prototypé, outils tiers, etc.
Niveau 2 ; dispose d'une interface de fonction et de commentaires et répond aux exigences du niveau 1 ; documentation suffisante pour chaque classe et fonction ; capacité à déterminer la fonctionnalité à partir des commentaires.
Niveau 3 ; respecte les normes de codage et satisfait aux exigences de niveau 2 ; suit les normes de codage définies et réussit le test de l'utilitaire de vérification du code.
Niveau 4 ; inclut des cas de test et répond aux exigences du niveau 3 ; dispose de suffisamment de cas de test pour tester toutes les fonctionnalités du code.
Niveau 5 ; approuvé par le comité de réutilisation et répondant aux exigences du niveau 4 ; examiné par des experts en réutilisation et des pairs et vérifié qu'il répond à tous les niveaux de maturité.

Je me demande si ce niveau de maturité ne devrait pas être une structure hiérarchique, dans laquelle, pour passer au niveau suivant, il faut satisfaire aux exigences de tous les niveaux précédents (comme je l'ai montré ci-dessus) ?

Ou s'il doit s'agir d'un sous-ensemble d'exigences pour atteindre le niveau suivant ?

Par exemple, si nous avons satisfait à x exigences sur y, nous pouvons passer au niveau suivant (les exigences seraient les mêmes que celles mentionnées ci-dessus).

Niveau 0, répond à 0 des 6 exigences
Niveau 1, répond à 1 des 6 exigences

Le problème que je vois avec l'approche par sous-ensemble est que certaines exigences devraient avoir une plus grande pondération, et dans cette approche, cela ne sera pas pris en compte (à moins que je ne commence à devenir spécifique comme, satisfait a sur b et x sur y, etc). Mais dans ce cas, cela pourrait commencer à devenir compliqué.

Est-ce que quelqu'un a déjà fait cela, et si oui, comment avez-vous configuré votre bibliothèque ? Avez-vous un niveau de maturité ou une autre structure ? Toute contribution serait grandement appréciée.

Answer 1

La mise en place d'un référentiel de réutilisation des codes est une tâche difficile. La principale difficulté ne réside pas dans la manière dont vous le mettez en place, mais dans la manière dont vous communiquez l'existence des différentes bibliothèques dans le référentiel. Les bibliothèques de réutilisation ne sont bonnes que si elles sont utilisées, et elles ne sont utilisées que si elles sont connues, et elles ne sont utilisées à grande échelle que si la qualité du code est élevée et s'il répond aux besoins des utilisateurs.

J'aime l'idée des niveaux de maturité, mais comme d'autres l'ont dit, il y a probablement beaucoup de travail d'installation et de construction à faire. J'ai pensé à une approche similaire pour la construction d'une application - je l'ai appelée "niveaux de confiance". Dans le domaine de la construction d'applications, un niveau de confiance faible est une construction qui n'a pas passé les tests unitaires ; un niveau de confiance moyen peut inclure la réussite des tests unitaires, mais pas des tests d'intégration, et ainsi de suite. Il s'agissait d'un bon mécanisme pour communiquer à l'assurance qualité et aux utilisateurs ce à quoi ils devaient s'attendre. Un mécanisme similaire pourrait être approprié pour les bibliothèques.

Les commentaires de la documentation sont indispensables et doivent faire l'objet d'autant de soin que le code. Les commentaires doivent indiquer le quoi, le pourquoi, le où, le quand, le comment, le lequel, etc. Votre processus de construction doit publier la documentation à un endroit bien connu (là encore, la communication est essentielle).

Dans le cadre de la communication, il n'est pas inutile de présenter de temps en temps ce qui existe. Encore une fois, il s'agit de communication.

Ainsi, au minimum, la compilation de chaque bibliothèque devrait :

• publier la bibliothèque (éventuellement informer les abonnés)
• publier la documentation
• exécuter des tests unitaires
• publier le niveau de maturité

En ce qui concerne les niveaux de maturité, je les définirais par un "nom de niveau" et une description de ce que le niveau signifie. Publier les critères de passage d'un niveau à l'autre. En fait, maintenant que j'y pense, vous voulez peut-être un ensemble de critères orthogonaux : un niveau pour le code, un niveau pour la documentation, les politiques d'utilisation (c'est-à-dire qu'il faut avoir une licence pour XYZ) et d'autres attributs. Je vous recommande toutefois de procéder par petites étapes. En fin de compte, ce qui compte, c'est de fournir des fonctionnalités aux utilisateurs finaux.

Vous devez également communiquer un état d'esprit qui consiste à introduire naturellement des éléments réutilisables dans le référentiel. Les développeurs doivent être incités à le faire. Les outils de vérification statique du code qui lo

F

Answer 2

Je pense qu'il vous sera difficile de vous assurer que l'ensemble de l'équipe de développement suit ces lignes directrices avec suffisamment de précision. D'autant plus que ces lignes directrices peuvent être interprétées d'une manière ou d'une autre. En outre, il sera très pénible que quelqu'un améliore un morceau de code en y ajoutant des tests et qu'il doive soudainement le transférer à un autre projet. Le plus souvent, ce code restera dans le projet dans lequel il a été placé à l'origine et, avec le temps, les niveaux de maturité n'auront plus de sens.

Voici une approche que j'ai pu observer dans une grande entreprise et qui fonctionne très bien :

• Toutes les bibliothèques de tiers sont enregistrées dans un répertoire spécial et comportent toujours un numéro de version.
• Nos propres bibliothèques communes sont divisées en fonction de la les références qu'ils ont pour d'autres choses. Par exemple, si le code de l'utilitaire fait référence à l'élément Infragistics alors ce bout de code utilitaire est placé dans une bibliothèque InfragisticsUtils bibliothèque.
• Nos propres bibliothèques communes qui forment des "unités" clairement identifiables sont classées dans des bibliothèques distinctes. Par exemple, une bibliothèque de code qui traite de l'évaluation des titres est un projet distinct.
• Tout le code réutilisable qui ne satisfait pas à l'une des conditions ci-dessus est placé dans un fichier fourre-tout Utilities projet.
• Nos propres bibliothèques sont compilées et mises à disposition dans un emplacement partagé où les projets peuvent y faire référence. C'est à l'équipe de développement du projet de décider s'il veut référencer un binaire compilé ou simplement inclure le projet utilitaire dans sa solution.

Il est évident que la qualité du code que vous trouvez dans le fourre-tout Utilities peut varier de manière significative. Pour pallier ce problème, nous avons simplement veillé à ce que deux personnes appartenant à des équipes de développement différentes examinent tous les enregistrements à Utilities . Cela permet d'éliminer beaucoup de choses qui n'ont rien à faire là !

Answer 3

Je pense qu'un grand dépôt de code comprendrait un outil CM et un outil Wiki. L'outil CM devrait être structuré en utilisant l'idée de niveau (comme vous l'avez proposé), puisqu'il structure le code par qualité. Le wiki devrait servir de "publicité" pour ce que le logiciel peut faire et comment il peut vous aider. Ce wiki pourrait également contenir des informations telles que les projets qui utilisent le code, l'évaluation de son utilisation et des exemples d'utilisation. Si quelqu'un s'inquiète du fait que l'équipe de développement respecte les directives de niveau, il faut lui expliquer comment fonctionne l'autosurveillance et lui donner l'exemple du bon fonctionnement des wikis.

La structuration de l'outil CM est maintenant importante. Elle est conçue pour transmettre la qualité du code, de sorte que vous sachiez à quoi vous attendre lorsque vous l'utilisez. Par exemple, si vous écrivez une classe simple avec très peu de commentaires et qu'elle ne respecte pas vraiment les normes de codage (peut-être un prototype), elle sera saisie dans l'outil CM. \sw_repository\level0\ExamplePrototype.

Peut-être que quelqu'un reprend ce morceau de code et les commentaires qui y ont été ajoutés pour le mettre aux normes. Cette personne le placerait alors dans le \sw_repository\level1\ExamplePrototype.

Ensuite, cette même personne, un peu plus tard, crée des tests unitaires pour le ExamplePrototype. Elle passe alors au niveau 2 et ainsi de suite.

La définition des niveaux doit faire l'objet d'une certaine réflexion. Ils devraient être quelque peu séquentiels et même si, par exemple, vous avez écrit des tests unitaires pour le code prototype mais qu'il ne satisfait pas aux commentaires et à la norme de codage, il est placé au niveau 0 de toute façon. Cependant, il serait facile de passer au niveau 2 si ces commentaires et normes étaient satisfaits.

Answer 4

Pour ma bibliothèque, je me contente de mettre le code que j'ai écrit et qui peut être utilisé dans plusieurs applications. Si le code est spécifique à une application particulière, il ne va pas dans la bibliothèque. Au fur et à mesure que les applications l'utilisent, les bogues sont éliminés, donc je ne m'attends pas à ce qu'il n'y ait pas de bogues tout de suite. Des bugs seront constamment trouvés et corrigés au fur et à mesure que votre bibliothèque mûrit et est sollicitée par différentes applications. Elle ne sera jamais exempte de bogues, mais avec le temps, elle se rapprochera de la fiabilité. De même, lorsque je réalise que l'API pour certaines choses est erronée, je ne m'en inquiète pas et je remanie l'API dès que possible.

Voici ma bibliothèque en c++
http://code.google.com/p/kgui/

Answer 5

Kit mentionné le problème le plus important : la réutilisation . le reste de l'idée est bien, mais ce n'est pas plus qu'un détail.

Je veux dire que j'ai moi-même des difficultés à maintenir ma propre bibliothèque de réutilisation. Parfois, je réalise une implémentation qui est très spécifique à un projet, ou je fais le n-ième prototype pour une idée, et aucun d'entre eux ne se retrouve jamais dans ma bibliothèque.

Si vous réussissez vraiment à avoir une bibliothèque de réutilisation du code, qui est utilisée et maintenue par de nombreux développeurs, de manière disciplinée, c'est la victoire. vous avez besoin d'un système de contrôle de version et d'un système de suivi des bogues, ce dernier étant utilisé à la fois par les propriétaires et les utilisateurs du projet. vous avez besoin de communication et de moyens de contribution. le fait qu'une poignée de développeurs utilisent un projet améliore considérablement sa qualité. la mise en œuvre s'améliore. la documentation est créée. La conception des API et des fonctionnalités se situe à un niveau beaucoup plus élevé. un comité est une bonne chose, mais il ne peut pas décider de la qualité d'un code donné sans l'utiliser. il peut décider si le code répond à des normes spécifiques, mais le respect des normes n'est pas suffisant pour avoir de bonnes bibliothèques.

Vous devez faire de votre mieux pour vous assurer que vous n'avez pas des tonnes d'extraits de code flottant autour de vous, qui peuvent tous plus ou moins faire quelque chose. ok, toute décision de conception a des avantages et des inconvénients, mais je pense qu'il est plus logique de commencer avec UN projet pour une tâche donnée, et de le ramifier, si c'est vraiment nécessaire, mais de maintenir une communication vivante entre les équipes de projet, et d'envisager de fusionner (partiellement) en arrière.

Ne vous souciez pas trop de catégoriser la qualité des différents projets. si un projet est mauvais, les utilisateurs/développeurs le pousseront à un meilleur niveau. la plupart des gens sont assez intelligents pour voir quand une bibliothèque est bonne, et quand elle ne l'est pas. vous devez vraiment mettre votre énergie dans ces effets symbiotiques, plutôt que d'essayer d'accabler les participants avec des règles strictes.

juste mes 2 cents ... ;)