Quand est-il plus productif de construire votre propre framework que d'en utiliser un existant? [fermé]

Je voudrais savoir pourquoi vous avez décidé de construire votre propre framework dans votre entreprise.

Par cadre, je ne veux pas dire peu de bibliothèques que vous utilisez souvent. Je veux dire une façon spécifique de créer des applications par-dessus, avec des classes de base, des conventions, etc.

Alors pourquoi avez-vous construit votre propre framework? Comment pourriez-vous justifier cela auprès de la personne qui vous emploie. En avez-vous mesuré l'impact positif et négatif?

En ce qui concerne vos expériences, avez-vous remarqué que dans certains cas, un cadre d'entreprise a produit de réels avantages, ou d'autre part, une augmentation des coûts de développement (courbe d'apprentissage, débogage, maintenance, ...)?

Réponse à pourquoi:

• Problèmes de licence
• Exigences spécifiques à l'entreprise qui n'existaient pas dans les cadres actuels
• L'entreprise souhaite contrôler le support et la maintenance du framework
• L'architecte ne savait pas mieux! Il / elle ne savait pas que ce cadre spécifique existait, alors ils ont décidé de réinventer la roue.

Mise à jour:

Les entreprises préfèrent réinventer la roue plutôt que d'utiliser de «petits» cadres. En gros, je fais référence à un cadre qui peut avoir un avenir incertain. Par exemple, le framework NET est plus sécurisé pour les entreprises qu'un framework créé par une petite communauté. Les entreprises ont besoin de sécurité car bon nombre de leurs applications sont essentielles à l'entreprise et ont une longue durée de vie. Le coût de réinventer la roue peut être plus à court terme. Mais le coût peut être plus élevé si le cadre utilisé dans les applications d'entreprise est obsolète et n'est plus pris en charge, ou si les licences sont modifiées. Ici, l'entreprise devra peut-être jeter le cadre actuel et en mettre un autre. Visual Basic est un bon exemple d'un langage qui n'est plus pris en charge par Microsoft. Et cela a coûté des milliards aux entreprises car elles doivent recommencer avec de nouveaux développements.

Pourquoi construire le vôtre?

1. car il n'a jamais été construit auparavant (rare, mais une possibilité néanmoins)
2. parce que vous voulez un contrôle total.
3. parce que vous n'avez besoin que d'un peu de fonctionnalités pour qu'il soit moins cher de le construire vous-même

Pourquoi ne pas construire le vôtre?

1. vous n'avez pas le temps de le faire
2. c'est probablement beaucoup moins cher si vous achetez un framework existant
3. vous gagnez beaucoup de temps et pouvez être productif beaucoup plus rapidement

Dans mon article sur quand il convient de réinventer la roue, j'énumère un certain nombre d'avantages d'une réimplémentation. Je pense que ces avantages s'appliquent particulièrement aux bibliothèques de framework. Par exemple, il est souvent impossible d'isoler l'utilisation d'une bibliothèque de framework dans une petite partie de votre application. Au lieu de cela, ils ont tendance à dicter la structure du code source du client, et il est donc souhaitable d'avoir un contrôle total sur la bibliothèque.

La seule vraie raison de réinventer la roue est s'il s'agit d'une application critique pour l'entreprise. Si votre entreprise utilisera pendant un certain temps à venir. Si ces applications / framework / etc. va probablement évoluer au-delà du cadre commercial existant a à offrir, alors avoir des codeurs d'entreprise faire leur mise en œuvre est certainement acceptable.

Les seules vraies raisons contre cela sont:

1. Le cadre existant est bien entretenu, convient parfaitement à votre tâche et se prolongera à l'avenir.

2. Ceci est juste un cas de syndrome « pas inventé ici »

3. Votre configuration actuelle ne sera pas en mesure de créer avec succès ce cadre dans un délai raisonnable pour un coût raisonnable.

Joel Spolsky a écrit un très bon article à ce sujet: À la défense du syndrome de Not-Invented-Here

Fondamentalement, lorsque vous utilisez le travail des autres, vous les ajoutez en tant qu'employeurs invisibles ou "mains supplémentaires".

S'ils sont bons, ils vous aideront. Sinon, vous devez faire leur travail en plus du vôtre - en d'autres termes, maintenir leur code. Cela pourrait être un risque inacceptable, mais je le considérerais comme très rare.

Le mot-clé est de rendre le framework échangeable, en codant sur une interface. Les interfaces les plus rigides du monde Java sont les spécifications Sun, qui sont prouvées par l'API servlet.

Alors je ne considérerais pas qu'il y ait une raison de ne pas utiliser de framework.

Nous avons un cadre assez mature où je travaille. Voici un résumé du cadre des fondations

L'une des principales raisons de son utilisation est la stabilité. Nous ne sommes pas redevables à Microsoft ou à tout autre fournisseur qui sont incités à ajouter de nouvelles fonctionnalités et de la complexité année après année.

(Mes propres opinions, pas celles de mon employeur, etc., etc.)

Je l'ai fait plusieurs fois, pour répondre à des exigences non couvertes par les frameworks existants (à l'époque).

Dans la plupart des cas, ces frameworks locaux ont plus tard été supprimés par des frameworks plus récents et entièrement développés. Par exemple, en 2000, j'ai créé un framework web Java, à certains égards comparable à Rails, utilisé pour créer un système de saisie de commande complexe avec plusieurs formulaires entaillés. Cela a bien fonctionné, mais bien sûr, quelques années plus tard, des cadres plus matures comme Struts et JSF l'ont rendu obsolète. Mais à l'époque, c'était la bonne chose à faire, cela fonctionnait bien et la vitesse de développement était impressionnante.

Un autre framework que j'ai développé est toujours utilisé (et également en développement actif); la première version a été écrite en 2004. Celle-ci est principalement utilisée pour les applications intralogistiques; l'entreprise qui l'utilise la considère toujours comme une caractéristique distinctive. La principale raison de sa création était de faciliter la création d'applications connectées à une base de données pour les scanners de codes à barres mobiles (exécutant une certaine version de Windows CE); cela a si bien fonctionné que les patrons ont décidé d'utiliser le même concept pour le logiciel PC également, et, bien, ils en sont toujours satisfaits.