J'ai besoin de commencer la conception et le développement d'un nouveau framework pour interagir avec un ECM open source. Cela inclut un modèle de données personnalisé pour aider les développeurs de sites Web à interagir avec cet ECM, de sorte qu'ils n'ont pas besoin de se soucier des détails de la manipulation des nœuds et d'autres détails de bas niveau. C'est juste un tas de classes et de méthodes à développer.

J'ai des doutes sur la façon de gérer l'organisation et la gestion de ce projet: y a-t-il des règles générales à suivre, des conseils, des meilleures pratiques ou quelque chose à garder à l'esprit pour développer ce type de projet?

Je suis sûr qu'il y a une différence entre le développement d'un framework ou d'une bibliothèque et une application.

Voici d'abord mes 2 règles pour éviter le syndrome des déchets de cadre:

• L'absence d'un existant, couvrant 80% de mes besoins et extensible pour correspondre aux 20% précédents
• La quasi-certitude que je vais l'utiliser à nouveau, dans une autre application

Après les avoir 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

1) Les fonctionnalités ne doivent être ajoutées à un Framework que lorsqu'elles sont extraites du code de travail. En d'autres termes, avant d'ajouter votre nouvelle idée cool à votre nouveau cadre cool, assurez-vous qu'il ajoute réellement de la valeur et réduit la répétition dans une application réelle et fonctionnelle.

2) Documentation, documentation, documentation.

3) Documentation, documentation, documentation.

Une expérience douloureuse et beaucoup d'efforts gaspillés conduisent à ce conseil: extraire ou refactoriser un framework à partir d'un logiciel fonctionnel. Construisez ce logiciel en gardant à l'esprit que vous pensez que vous voudrez extraire un framework à l'avenir, mais ne construisez pas le framework en premier.

Je suggère le livre Framework Design Guidelines . Cela fait quelques années, mais les principes restent vrais. Il a une tonne de modèles et explique le raisonnement derrière les décisions que vous prendrez lors de la création d'un cadre.

1) Respectez les bonnes conventions dès le début, assurez-vous d'avoir documenté une convention très spécifique, les meilleurs cadres sont ceux qui sont cohérents en interne.

2) Assurez-vous que tout est très documenté, des bons commentaires de code à l'explication des fonctions les plus importantes que vous devez produire et produire, même si cela vous semble très simple, vous pourriez demander à quelqu'un de l'utiliser à la 14e heure consécutive et ils juste besoin de cette seule chose.

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

4) S'il est disponible pour les utilisateurs, assurez-vous que vous disposez d'une forme de processus de support / suivi des bogues. Il va y avoir des bugs, cela nous arrive à tous, mais si vous pouvez les gérer dès le départ, cela vous facilitera la vie.

Dans l'ensemble, une approche similaire pour la création de n'importe quelle application, mais les développeurs sont encore plus compliqués que les utilisateurs, et les meilleurs cadres sont ceux que nous pouvons prendre, comprendre et que nous n'avons pas à combattre.

Je suis en désaccord avec beaucoup de ce qui a été dit et j'estime que plus n'a pas été mentionné, alors je vais recommencer à zéro.

Méthodologies Agiles

Adoptez des méthodologies agiles lors du développement de votre framework afin de vous adapter au changement, de réagir rapidement aux barrages routiers et d'assurer un produit final fonctionnel et de qualité. Les méthodologies agiles sont celles qui, selon le "Manifeste Agile", privilégient:

Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration avec le client sur la négociation des contrats
Répondre au changement en suivant un plan

C'est vrai. J'ai 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 celles de gauche.

la communication

Celui qui crée le cadre doit savoir:

1. Comment il sera utilisé: l' application cible
2. Quel problème il est censé résoudre: le problème cible
3. Qui l'utilisera: le public cible

Par exemple, si une entreprise avait l'intention de développer une application finale avec ASP .NET, il serait stupide de dire à ses programmeurs de "créer ce cadre" sans leur dire ce qui précède. Si les programmeurs ne connaissaient pas l'application cible, ils pourraient ne pas la rendre orientée Web. S'ils ne connaissaient pas le problème, ils pourraient créer un cadre à des fins différentes. S'ils ne connaissaient pas le public, ils pourraient programmer le framework en C ++. N'importe laquelle de ces circonstances rendrait le cadre résultant inutile.

Style

Inutile de dire, établir un style / format de programmation et s'en tenir à lui.

Les E

1. Modularité : Réutilisez le code par programmation, pas littéralement.
2. Efficacité : votre code est destiné à être réutilisé. Tous les inconvénients de la vitesse sont multipliés.
3. Maintenabilité : Vous souhaitez pouvoir éditer le framework pour mettre à jour plusieurs programmes, sans avoir à modifier lesdits programmes.
4. Convivialité : les applications peuvent-elles réellement utiliser votre framework sans passer par des cerceaux?
5. Aspect pratique : ne réinventez pas la roue si vous n'êtes pas obligé de le faire. Votre framework peut dépendre d'autres frameworks.
6. Redondance : intercepter les exceptions / erreurs. Partout. Manipulez-les. Partout. Ne faites jamais confiance à un code autre que celui de la portée locale pour gérer les erreurs, même si vous savez qu'il le fait.

Je suis sûr qu'il y a une différence entre le développement d'un framework ou d'une 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, bien que je trouve que les plus grandes différences concernent généralement la portée et la définition du projet. N'oubliez pas qu'une application peut inclure ou utiliser un cadre ou une bibliothèque, un cadre peut être une collection de bibliothèques.

J'ai des doutes sur la façon de gérer l'organisation et la gestion de ce projet: y a-t-il des règles générales à suivre, des conseils, des meilleures pratiques ou quelque chose à garder à l'esprit pour développer ce type de projet?

L'organisation 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, quand il s'agit d'écrire un framework, il est avantageux d'avoir une vision très claire de ce que vous essayez de réaliser et de placer des règles de conception strictes sur l'interface publique du framework pour assurer la cohérence en termes de présentation de l'API. Si vous autorisez chaque développeur à faire son propre travail, vous vous retrouverez avec un gâchis compliqué et une conception d'API très inélégante.

Je seconderai la recommandation de Ryan Hayes de lire les directives de conception de cadre même si le livre lui-même vise à développer des cadres basés sur .NET, car les conseils généraux s'appliquent indépendamment des technologies de mise en œuvre spécifiques que vous pourriez choisir d'utiliser.

Par expérience, je vous conseille de vous en tenir au principe classique de YAGNI en implémentant d'abord les interfaces publiques les plus simplistes, puis en 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 n'ai jamais été fan de l'ajout de "Ex" ou d'autres suffixes similaires aux noms de méthode, ou de l'ajout de nombres aux définitions d'interface étendues. Différenciez les fonctionnalités et les noms de vos interfaces / méthodes devraient devenir plus clairs et, espérons-le, moins obscurs et déroutants.