Voici dabord mes 2 règles pour éviter le syndrome du gaspillage de framework:

• Labsence dun existant, couvrant 80% des mes besoins et extensible pour correspondre aux derniers 20%
• Le proche certitude que je vais lutiliser à nouveau, dans une autre application

Une fois que vous les avez passés, vérifiez ceci:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

Commentaires

• Jajouterais que si vous pouvez ‘ trouver un cadre qui répond à votre règle 80/20, soit vous travaillez dans un domaine extrêmement unique OU vous ne ‘ ne comprenez pas assez bien votre domaine.

1) Les fonctionnalités ne doivent être ajoutées à un Framework que lorsquelles sont extraites du code de travail. En dautres termes, avant dajouter votre nouvelle idée à votre nouveau framework, assurez-vous quelle ajoute réellement de la valeur et réduit les répétitions dans une application réelle qui fonctionne.

2) Documentation, documentation, documentation.

3) Documentation, documentation, documentation.

Expérience douloureuse et beaucoup defforts gaspillés conduire à ce conseil: extraire ou refactoriser un framework à partir dun logiciel fonctionnel. Construisez ce logiciel en gardant à lesprit que vous pensez vouloir extraire un framework à lavenir, mais ne construisez pas dabord le framework.

Je suggérerais le livre Framework Design Guidelines . Il » a quelques années, mais les principes restent valables. Il contient une tonne de modèles et explique le raisonnement qui sous-tend les décisions que vous prendrez lors de la création dun cadre.

1) Tenez-vous en aux bonnes conventions dès le début, assurez-vous que vous avez documenté une convention très spécifique, les meilleurs frameworks sont ceux qui sont cohérents en interne.

2) Assurez-vous que tout est bien documenté, du bon des commentaires de code tout au long de lexplication de ce que les fonctions les plus importantes exigent et produisent, même si cela vous semble super simple, vous pourriez demander à quelquun de lutiliser à la 14e heure daffilée et ils ont juste besoin de cette chose alors.

3) Établissez un dossier de projet pour vous-même, avec ce que vous voulez que le cadre atteigne, des objectifs réalistes et des priorités globales.

4) Sil doit être disponible pour les utilisateurs, assurez-vous que vous avez mis en place une forme de processus dassistance / suivi des bogues. Il va y avoir des bogues, cela nous arrive à nous tous, mais si vous pouvez les gérer depuis le début, cela vous facilitera la vie.

Dans l’ensemble, une approche similaire à la création d’une application, mais les développeurs sont encore plus difficiles que les utilisateurs, et les meilleurs frameworks sont ceux que nous pouvons prendre, comprendre, et nous navons pas à nous battre.

Je ne suis pas daccord avec beaucoup de ce qui a été dit et je pense que dautres nont pas été mentionnés, donc je « repartirai de zéro.

Méthodologies agiles

Adoptez des méthodologies agiles lors du développement de votre framework afin de pouvoir vous adapter au changement, réagir rapidement aux obstacles et garantir un produit final fonctionnel et de qualité. Les méthodologies Agiles sont celles qui, selon le « Manifeste Agile », donnent la priorité:

Les individus et les interactions par rapport aux processus et outils
Logiciel de travail sur une documentation complète
Collaboration client sur négociation de contrat
Répondre au changement sur en suivant un plan

Cest vrai. Jai dit que la fonctionnalité est plus importante que la documentation. Notez que le « Manifeste Agile » mentionne que les priorités de droite sont toujours importantes, un peu moins que ceux de gauche.

Communication

Celui qui crée le framework doit savoir:

1. Comment il sera utilisé: le application cible
2. Quel problème est-il prévu de résoudre: le problème cible
3. Qui lutilisera: le public cible

Par exemple, si une entreprise avait lintention de développer une application finale avec ASP .NET, il serait insensé de dire à ses programmeurs « créer ce framework » sans leur dire ce qui précède. Si les programmeurs ne connaissaient pas lapplication cible, ils pourraient ne pas la rendre orientée Web. Sils ne connaissaient pas le problème, ils pourraient créer un cadre dans un but différent. Sils ne connaissaient pas le public, ils pourraient programmer le framework en C ++. Nimporte laquelle de ces circonstances rendrait le framework résultant inutile.

Style

Inutile de dire, établir un style de programmation / format et respectez-le.

Les E « s

1. Modularité : réutilisez le code par programme, pas littéralement.
2. Efficacité : votre code est destiné à être réutilisé . Tous les obstacles à la vitesse se multiplient.
3. Maintenabilité : vous voulez pouvoir modifier le framework pour mettre à jour plusieurs programmes, sans avoir à modifier lesdits programmes.
4. Ergonomie : les applications peuvent-elles réellement utiliser votre framework sans sauter à travers les cerceaux?
5. Pratique : Ne réinventez pas la roue si vous ne lavez pas faire cela. Votre framework peut dépendre dautres frameworks.
6. Redondance : Catch exceptions / erreurs. Partout. Manipulez-les. Partout. Ne faites jamais confiance à aucun code autre que celui de la portée locale pour gérer les erreurs, même si vous savez que cest le cas.

Commentaires

• Bienvenue à P.SE! Je ‘ ne suis pas daccord avec # 6 sur la capture des exceptions dans votre cadre. Je ‘ Je crois fermement que le framework devrait être un gosse absolu et lancer des exceptions et laisser au programmeur utilisant le framework pour les attraper ou (mieux encore) réorienter leur code afin pour éviter lexception – encourager la conformité aux conventions.

Je « suis sûr quil y a une certaine différence entre le développement dun framework ou dune bibliothèque et une application.

Les processus de développement sont essentiellement les mêmes. les différences peuvent résulter de problèmes de marketing et de déploiement, même si je trouve que les plus grandes différences concernent généralement la portée et la définition du projet. Noubliez pas quune application peut inclure ou utiliser un framework ou une bibliothèque, un framework peut être un ensemble de bibliothèques.

Jai des doutes sur la manière de gérer lorganisation et la gestion de ce projet: y a-t-il des règles générales à Quels sont les conseils, les bonnes pratiques ou quelque chose à garder à lesprit pour développer ce type de projet?

Lorganisation et la gestion du projet sont à nouveau les mêmes pour tout projet de développement . Encore une fois, cela revient à la portée. Cependant, lorsquil sagit décrire un framework, il est avantageux davoir une vision très claire de ce que vous essayez de réaliser, et de placer des règles de conception strictes sur linterface publique du framework pour assurer la cohérence en termes dAPI. Si vous permettez à chaque développeur de faire ce quil veut, vous vous retrouverez avec un désordre compliqué et une conception dAPI très inélégante.

Je « ll second Ryan Hayes » recommandation de lire les Directives de conception du cadre même si le livre lui-même vise à développer des frameworks basés sur .NET, car les conseils généraux sont applicables quelles que soient les technologies dimplémentation spécifiques que vous pourriez choisir dutiliser.

Par expérience, je vous conseillerais de vous en tenir à le principe classique de YAGNI en implémentant dabord les interfaces publiques les plus simplistes, puis en les développant pour offrir plus de contrôle et de profondeur plus tard, mais veillez à utiliser des noms utiles pour montrer pourquoi les méthodes ou les classes sont développées. Je nai jamais été fan de lajout de « Ex » ou dautres suffixes similaires aux noms de méthodes, ou de lajout de nombres aux définitions dinterface étendues. Différenciez-vous sur la fonctionnalité, et vos noms dinterface / méthode devraient devenir plus clairs et, espérons-le, moins obscurcis et déroutants.