J'essaie de configurer un référentiel de code réutilisable. Je pensais que chaque module de code réutilisable ait une note de «niveau de maturité» certaine. La note serait définie comme le niveau à laquelle un code réutilisable réside dans un certain ensemble d'exigences. Le niveau de maturité le plus élevé sera le plus haut degré de norme dans un ensemble prédéfini d'exigences.
Par exemple:
Niveau; Conditions; Description
Niveau 0; Le code est légal à utiliser; Est le code légal à utiliser dans l'industrie commerciale / sur plusieurs contrats / etc?
Niveau 1; Codes de base et respecte les exigences de niveau 0; Code prototypé, outils 3ème partie, etc
Niveau 2; A une interface fonctionnelle et des commentaires et répond aux exigences de niveau 1; Documentation suffisante pour chaque classe et fonction; Capable de déterminer la fonctionnalité des commentaires de
Niveau 3; Adhère aux normes de codage et répond aux exigences de niveau 2; Suit les normes de codage définies et passe le code de code de code d'essai d'utilité
Niveau 4; Comprend les cas de test et répond aux exigences de niveau 3; Contient suffisamment de cas de test pour tester toutes les fonctionnalités du code de code
Niveau 5; Approuvé par la commission de réutilisation et répond aux exigences de niveau 4; Commenté par la réutilisation des experts et des pairs et vérifié, il répond à tous les niveaux de maturité
Je me demande si ce niveau de maturité devrait être une structure hiérarchique, où afin de passer au niveau suivant, vous devez répondre 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, nous rencontrons X des exigences de Y, nous pouvons passer au niveau suivant (les exigences seraient les mêmes que mentionnées ci-dessus).
niveau 0, rencontre 0 exigences sur 6
Niveau 1, répond à 1 exigences sur 6
...
Le problème que je vois avec l'approche du sous-ensemble est que certaines exigences devraient avoir une pondération plus forte, et dans cette approche qui ne sera pas prise en compte (à moins que je ne commence à devoir être spécifique, rencontre une sortie de b et x hors de Y, etc). Mais alors cela pourrait commencer à être compliqué.
Quelqu'un a-t-il déjà fait cela avant, et si oui, comment avez-vous configuré votre bibliothèque? Avez-vous un niveau de maturité ou une autre structure? Toute entrée serait grandement appréciée.
9 Réponses :
Je pense que vous pensez trop dans un non-problème.
Comment avez-vous configuré ma bibliothèque? facile, si vous utilisez la même méthode (ou presque la même) dans deux projets ou plus, déplacez-le à la bibliothèque.
Je pense que cela implique un peu plus que "le déplacer vers une bibliothèque". Qu'en est-il des logiciels tiers, des logiciels sous-traités, etc. Dans une grande entreprise, vous pourriez avoir beaucoup de projets dans lesquels des modules réutilisables pourraient être utilisés. Comment les gérons-nous?
Pour ma bibliothèque, je viens de mettre le code que j'ai écrit qui peut être utilisé sur plusieurs applications. Si le code est spécifique à une application particulière, il ne va pas dans la bibliothèque. Comme plus d'applications l'utilisent, les bugs sont élaborés pour que je ne m'attends donc jamais à ce qu'elle soit sans bug immédiatement. Les bugs seront constamment trouvés et fixés à mesure que votre bibliothèque mûrit et est stressée avec différentes applications. Il ne sera jamais sans bug, mais au fil du temps abordera la fiabilité.
De plus, lorsque je réalise que l'API pour certaines choses est fausse, je ne m'inquiète pas pour ça et refactorise l'API dès que possible. de
de
Voici ma bibliothèque en C ++
http://code.google.com/p/kgui/
Donc, vous n'avez pas de norme quant à quel code entre dans votre bibliothèque autre que l'exigence de base d'être entre les applications?
En réponse à SWDEVAN81, ma norme consiste à mettre le code qui peut être réutilisé dans d'autres applications dans ma bibliothèque. Juste parce que c'est dans la bibliothèque ne rend pas nécessairement les applications plus grandes que la lieur est généralement suffisamment intelligente pour inclure uniquement les bits de la bibliothèque qui sont réellement appelées / référencées dans chaque application.
Je pense que vous trouverez qu'il est difficile de faire en sorte que l'équipe de développement suit ces lignes directrices avec suffisamment de précision. Surtout quand les lignes directrices peuvent être interprétées d'une façon ou d'une autre. De plus, ce sera une douleur importante si quelqu'un améliore un morceau de code en ajoutant des tests et tout à coup, il doit passer à un autre projet. Plus que probable, un tel code restera dans le projet, il a été placé dans, et au fil du temps les niveaux de maturité perd tout son sens.
Une approche bien travailler, j'ai vu dans une grande entreprise est la suivante:
Infragistics alors ce morceau de code utilitaire va dans un InfragisticsUtils bibliothèque.
- Nos propres bibliothèques communes qui forment clairement identifiables « unités » aller dans des bibliothèques distinctes. Par exemple, une bibliothèque de code qui traite des titres de prix est un projet distinct.
- Tout le code réutilisable qui ne satisfait pas à l'un des passe au-dessus dans un fourre-tout
Utilitaires projet.
- Nos propres bibliothèques sont compilées et publié dans un emplacement partagé où les projets peuvent y faire référence. Il appartient à l'équipe de développement de projets de décider si elles veulent faire référence à un binaire compilé ou simplement inclure le projet d'utilité dans leur solution.
Il est évident que la qualité du code que vous trouverez dans le fourre-tout Utilitaires bibliothèque peut varier considérablement. Pour remédier à cela, nous fait qu'assurer que deux personnes de différentes équipes de développement ont examiné tous checkins à Utilitaires . Ce mauvaises herbes beaucoup de choses qui n'a pas sa place là-bas!
C'est considéré comme une bonne approche pour avoir sa propre bibliothèque, mais une des milliers de lignes est une ruine!
Regardez les "Confessions d'un vendeur d'un programme d'occasion" de Tracz, et des trucs de Rabbi de Rabbi de HP, Martin Griss.
Configuration du référentiel de réutilisation de code est une tâche difficile. La principale difficulté n'est pas dans la façon dont vous la configurez, mais dans J'aime l'idée des niveaux de maturité, mais comme d'autres ont posté, il y a probablement un peu de travail de configuration / construction à faire. J'ai pensé à une approche similaire de la construction d'une application - je les ai appelées niveaux de confiance. Dans l'arène de la construction d'applications, une baisse de confiance est faible qui n'a pas passé des tests d'unité; Une confiance moyenne peut inclure des tests d'unité passagers, mais pas des tests d'intégration, etc. C'était un bon mécanisme pour communiquer à QA et les utilisateurs à quoi s'attendre. Un mécanisme similaire pourrait être approprié pour les bibliothèques.
Les commentaires de la documentation sont indispensables et doivent également avoir autant de soin d'entre eux que vous mettez dans le code. Les commentaires doivent communiquer quoi, pourquoi, lorsque, comment, lequel, etc. Votre processus de construction doit publier la documentation à un endroit bien connu (à nouveau, la communication est la clé).
Le long des lignes de communication, cela ne fait pas mal de présenter de temps à autre que ce qui existe. De nouveau! communication.
Ainsi, au minimum, votre construction de chaque bibliothèque doit:
quant aux niveaux d'échéance, je les définirais avec un "nom de niveau" et une description de ce que le niveau signifie. Publier les critères de ce que cela signifie de monter ou de descendre un niveau. En fait, maintenant que j'y pense, peut-être que vous souhaitez peut-être un ensemble de critères orthogonaux: un niveau pour le code, un niveau pour la documentation, les polices d'utilisation (c'est-à-dire une licence pour XYZ) et d'autres attributs. Je vous recommande de vous approcher cela en petits incréments cependant. à la fin de la journée, ce qui compte.
Vous devez également communiquer une mentalité de bits réutilisables qui poussent naturellement dans le référentiel. Les développeurs doivent avoir une incitation à faire cela habituellement. Vérification du code statique des outils qui recherchent des révisions sur la duplication et les pairs ne vont que si loin. Quelqu'un doit réellement faire le travail de déplacer du code dans le référentiel.
Enfin, je vous recommande d'utiliser autant de support d'outil que possible dans la configuration, la construction, la maintenance et la communication du référentiel. Sinon, comme tout artefact non-code, vous ferez face à une certaine entropie qui réduit la valeur que l'artefact non-code devient daté.
+1 pour "Comment vous communiquez l'existence des différentes bibliothèques" et autrement ... un résultat encore pire est la prévalence de la culture "Cut N Coller", il ne fait pas tout à fait ce que vous voulez, le processus de libération de la bibliothèque est impénétrable, donc nous ... c'est effrayant combien de cela se passe.
Droit. Couper et pâte n'est vraiment que justifiée une fois, puis si la généralisation n'est pas immédiatement apparente et que vous êtes entassé pour temps. Cette troisième instance du code devrait être un drapeau rouge à généraliser. Convenu - Couper et pâte est trop répandu et peut être préjudiciable: plusieurs points d'entretien.
Pour des années, Microsoft a été un grand défenseur de ce que l'on appelle usines logicielles , une grande partie de laquelle est consacrée à la résolution des problèmes de réutilisation.
Quels sont les problèmes de réutilisation? Tout d'abord, c'est dur. Il est très difficile de proposer une bibliothèque et une API qui servira au-delà des besoins immédiats du projet. Comment prédisez-vous l'avenir? De plus, le problème d'un référentiel centralisé qui sert à la fois une base de connaissances et une communauté de pratique dynamique est très difficile. Comment faites-vous quelque chose qui est à la fois très flexible mais facile à utiliser? Beaucoup ont essayé et ont échoué. usines de logiciels et Lignes de produits logiciels tentative de résoudre ces problèmes.
bonne chance!
Je pense qu'un grand référentiel de code comprendrait un outil CM et un outil Wiki. L'outil CM doit être structuré à l'aide de l'idée de niveau (comme vous le proposez), car elle structure le code par qualité. Le wiki devrait servir de "publicité" de ce que le logiciel peut faire et comment cela peut vous aider. Ce wiki pourrait également conserver des informations comme, quels projets utilisent le code, évaluation de la manière dont il est utilisable, et des exemples de la manière de l'utiliser. Si quelqu'un s'inquiète de l'équipe de développement à la suite des directives de niveau, il convient de souligner comment l'auto-police fonctionne et donne l'exemple de la qualité de laquelle cela fonctionne avec Wikis.
Maintenant, la structuration de l'outil CM est importante. Il est conçu pour transmettre la qualité du code afin que vous sachiez ce que vous entrez lorsque vous l'utilisez. Par exemple, si vous écrivez une classe simple avec à peine des commentaires et que cela ne respecte pas vraiment les normes de codage (peut-être un prototype), il serait entré dans \ sw_repository \ niveau de niveau0 \ exempleprototype.
Peut-être que quelqu'un prend alors ce morceau de code et ajouté des commentaires et l'amène aux normes. Ensuite, cette personne le placerait dans \ sw_repository \ niveau1 \ exemple exemplototype.
Puis cette même personne, un moment plus tard, crée des tests unitaires pour l'exemplePrototype. Cela irait ensuite au niveau2 et ainsi de suite.
Définir les niveaux devrait prendre une pensée. Ils devraient vraiment être un peu séquentiels et même si, par exemple, vous avez eu des tests d'unité écrits pour le code de prototype, mais cela n'a pas satisfait à la norme de commentaires et de codage, il est ensuite placé dans le niveau de niveau0 de toute façon. Cependant, il serait facile d'aller au niveau2 si ces commentaires et normes étaient satisfaits.
kit mentionné Je veux dire, j'ai moi-même des difficultés à maintenir ma propre bibliothèque de réutilisation. Parfois, je fais une mise en œuvre qui est très spécifique au projet, ou je fais le N-ème prototype de certaines idées et aucun de ceux qui ne sont jamais dans ma bibliothèque.
Si vous réussissez vraiment à avoir une bibliothèque de réutilisation de code, elle est utilisée et maintenue par de nombreux développeurs, de manière disciplinée que la victoire. Vous avez besoin d'un système de contrôle de version et d'un suivi de bogue, ce dernier étant utilisé par les propriétaires de projets et les utilisateurs. Vous avez besoin de communication et de moyens de contribution. Avoir une poignée de devs en utilisant un projet améliore considérablement sa qualité. La mise en œuvre va mieux. La documentation est créée. L'API et la conception des caractéristiques sont sur un niveau beaucoup plus élevé. Un comité est une bonne chose, mais cela ne peut pas décider, quelle est la qualité du code donné, sans l'utiliser réellement. Il peut décider si le code répond aux normes spécifiques, mais les normes de réunion ne suffisent pas pour de bonnes bibliothèques.
Vous devez faire de votre mieux pour vous assurer que vous n'avez pas de tonnes d'extraits de code flottant autour, tout ce qui peut faire plus ou moins faire quelque chose. OK, toute décision de conception a des avantages et des inconvénients, mais je pense, il est plus logique de commencer par un projet pour une tâche donnée et de la branche, si nécessaire, mais de la communication vivante entre les équipes de projet et envisagez (partiellement) la fusion retour.
Ne vous inquiétez pas trop sur la catégorisation de la qualité de différents projets. Si un projet est mauvais, les utilisateurs / Devs le pousseront à un niveau supérieur. La plupart des gens sont assez intelligents pour voir, quand une bibliothèque est bonne, et quand ce n'est pas le cas. Vous avez vraiment besoin de mettre votre énergie dans ces effets symbiotiques, plutôt que d'essayer de faire face aux participants des règles strictes.
juste mes 2 cents ...;)
Oui, pas de règles strictes. S'il est craint de gâcher peut-être quelque chose dans la bibliothèque, les gens ne contribueront pas, et la valeur diminue. Avec suffisamment de bons outils tels que le refactoring, les tests unitaires, le contrôle des sources et la couverture - la peur devrait (j'espère!) Être réduit.
Je pense que lorsque vous devez vous inquiéter entretien d'un code réutiliser bibliothèque, vous êtes sur la mauvaise piste ...: P
@jalf - alors vous n'avez évidemment pas une bibliothèque de réutilisation :) Tout le code réutilisable que vous avez écrit n'a jamais eu des bugs ni des fonctionnalités nécessaires?
@jalf C'est pourquoi il met de l'effort et une attention particulière dans la conception et la structure maintenant, pour le sauver travailler plus tard ...
Mon expérience est que les référentiels de code ne fonctionnent jamais. Si le code est simple - vous pouvez le trouver sur Internet ou vous écrire avec quelques efforts. S'il est complexe - il est peu probable que ce soit réutilisé dans d'autres projets