5 choses que les architectes d'entreprise envisagent de choisir Framework

Choisir un framework frontend n'est pas facile, mais une certaine clarté autour des critères peut aider tout le monde à comprendre la décision finale.

Le problème du choix d'un framework frontend est si vaste et amorphe que les architectes trouvent qu'il vaut la peine de résoudre le problème en critères qui peuvent être évalués individuellement. Cependant, cela réduit mais n’élimine pas la complexité, car il n’existe pas d’interface unique supérieure pour tous ces critères. Pourtant, en traitant chacun des cinq critères essentiels individuellement, les architectes obtiennent une certaine clarté sur ce qui compte.

Il y a aussi un sixième critère qui retient plus l'attention qu'il ne le devrait. Mais, d'un point de vue architectural, ce n'est pas aussi important que les cinq premiers.

Critères pratiques

Au moins trois critères sont implacablement pratiques et sont considérés en premier, principalement parce que ces critères permettent aux architectes de prendre certains candidats. hors de la table, réduisant la taille de l'espace de décision. Ces critères sont jugés si «évidents» qu'ils sont souvent appliqués sans reconnaissance explicite.

1. Compatibilité

Le premier critère de cette catégorie est la compatibilité . De nos jours, «compatibilité» signifie la prise en charge des normes Internet – les architectes veulent s'assurer qu'un cadre fonctionne bien avec HTML, CSS et la pléthore de bibliothèques JavaScript sans nécessiter de traitement «spécial». Blazor est un exemple de l'importance de la compatibilité. Parce que Blazor est basé sur WebAssembly plutôt que sur JavaScript, Blazor est en lice en tant que cadre le plus perturbateur. Pourtant, même Blazor exploite HTML et CSS et offre une interopérabilité avec JavaScript.

2. Domaines de préoccupation

Deuxièmement, et étroitement liés à la compatibilité, il y a toutes les questions liées aux « domaines de préoccupation de l’organisation». Par exemple, les organisations impliquées dans la cartographie sont guidées par leurs outils de systèmes d'information géographique et se seront engagées dans un ensemble d'outils spécifiques; une société de services financiers dépendra d'un ensemble d'outils qui génère des graphiques de négociation de volume basés sur des données en continu; Les ensembles d'outils hospitaliers seront conformes aux réglementations concernant qui peut voir quelles informations et dans quelles circonstances. Les organisations avec des backends spécialisés comme ceux-ci sacrifieront un certain nombre de critères pour un framework avec des composants qui prennent en charge cette fonctionnalité plutôt que d'abandonner l'ensemble d'outils dont ils dépendent.

Les outils de développement utilisés par l'organisation sont étroitement liés: la boutique de développement "zones d'inquiétude." Sauter vers un nouveau cadre qui nécessite des outils / composants complètement différents ne signifie pas que l’organisation abandonne son ancien ensemble d’outils: l’atelier doit toujours maintenir toutes ses applications existantes. Avoir deux ensembles d'outils disjoints n'est pas une bonne chose (il y a une raison pour laquelle des outils, comme Telerik, qui prennent en charge plusieurs frameworks s'efforcent de faire fonctionner les composants dans différents environnements de manière similaire).

3. Performance

Troisièmement: Performance . L'interface fonctionne-t-elle «suffisamment vite» pour le type d'applications dont l'organisation a besoin? Je ne pas suggérant aux architectes de choisir le cadre le plus rapide: «assez vite c'est assez bien». Mais les applications qui ne peuvent pas être facilement créées avec des performances «suffisamment rapides» obligeront les développeurs à enfreindre les meilleures pratiques pour atteindre des performances «suffisamment bonnes». Avec un cadre qui n’est pas «assez rapide», la conception sera sacrifiée à l’opportunisme. Les architectes n'aiment pas ça.

Critères moins mesurables

Les deux critères suivants sont plus philosophiques, cependant, et moins sujets à tout type de mesure.

4. Opinionated Software

La ​​quatrième question est de savoir comment opinionated un framework concerne la manière dont les applications doivent être construites: le paradigme qui décrit à quoi ressemble une application bien architecturée. Certains cadres sont plus «avisés» que d'autres lorsqu'il s'agit de mettre en œuvre les modèles de conception d'entreprise que les architectes apprécient (et il n'y a pas d'interface avec «aucune opinion»).

Angular, par exemple, est relativement avisé sur la façon dont il suppose des applications seront construites et, par conséquent, fournira tous les outils (gestion de l'état, routage, gestion des dépendances, etc.) nécessaires pour faciliter la création d'applications de cette façon. React, d'un autre côté, est moins avisé et suppose que vous ajouterez les outils que vous souhaitez créer votre application comme vous le souhaitez… tant que vous vous engagez à une liaison de données unidirectionnelle pour déplacer des données.

C'est une question sur laquelle les gens raisonnables ne seront pas d'accord. Si un architecte aime le paradigme d'un framework, un logiciel avisé qui empêche les développeurs de faire des choses stupides / mauvaises tout en les encourageant à faire la bonne chose est une bonne chose. De plus, en fournissant une boîte à outils fixe, un logiciel avisé favorise la croissance de l'expertise (savoir ce que signifient réellement les messages d'erreur, par exemple). Il y a cependant un inconvénient évident: s'il y a un cas particulier qui ne correspond pas au paradigme, le cadre peut forcer une conception maladroite ou même empêcher du tout de gérer le cas.

Les cadres avec moins d'opinions donnent aux magasins plus de flexibilité, quelle autre les architectes préfèrent. Mais il est facile d’exagérer cet avantage. Les architectes ne peuvent vraiment utiliser cette flexibilité qu'une seule fois, car des outils individuels sont ajoutés au cadre. En effet, chaque boutique devient opinion même si le cadre utilisé par la boutique ne l'est pas. Bien que l’atelier ait la possibilité d’apporter un nouvel outil pour gérer une situation particulière, les architectes estiment généralement qu’augmenter la taille de la boîte à outils n’est pas une décision judicieuse. Ainsi, ce que les logiciels sans opinion permettent aux architectes de faire, c'est de reporter la prise de décisions dans certains domaines jusqu'à ce que cela soit nécessaire. C’est évidemment une bonne chose et conduit au cinquième critère: des dessins à l’épreuve du temps .

5. Des conceptions à l'épreuve du futur

Peu importe ce que l'on dit, dans l'architecture d'entreprise, la vérité n'est pas immuable: la façon dont les applications sont conçues aujourd'hui n'est pas la façon dont elles seront conçues demain. Le cinquième critère évalue les cadres à la fois sur leur capacité à évoluer et sur la façon dont l'écosystème du cadre génère.

Par exemple, à l'avenir, les architectes utilisant des conceptions événementielles valoriseront les composants qui s'intègrent bien avec services gRPC en particulier pour les organisations où la performance est essentielle. Les frameworks avec des composants qui s'intégreront aussi bien avec les services gRPC qu'avec la récolte actuelle de services RESTful sont plus attrayants pour les architectes.

Et dans le monde JavaScript, les architectes utilisant React voudront s'assurer que leur suite de composants prend en charge React Hooks.

Mais qu'en est-il des développeurs?

Vous pouvez penser que j'ai omis un critère clé: Tirer parti des connaissances des programmeurs . Les architectes intelligents devraient valoriser cela comme un sixième critère potentiel… mais pas beaucoup.

Les architectes devraient certainement préférer un cadre qui exploite les connaissances des développeurs existants à un cadre qui ne le fait pas parce que le recyclage est coûteux. Mais, contrairement aux critères précédents, qui impliquent des coûts permanents, une organisation ne paie qu'une seule fois pour le recyclage. Et même lors du passage à un nouveau cadre, une grande partie des connaissances conceptuelles que les développeurs possèdent est transférable (surtout si le cadre leur permet d'utiliser des outils et des composants similaires). Il vaut mieux recycler votre personnel tous les dix ans (environ) que de s'accrocher à une interface qui ne prend pas en charge les cinq autres critères.

Dans ce domaine, la vraie préoccupation n'est pas l'expertise au sein de l'organisation, c'est dans quelle mesure l'expertise externe est disponible (et coûteuse). Si les ressources externes sont très chères, c'est le signe de l'un des deux problèmes suivants: soit vous vous accrochez à un framework qui devient de plus en plus obsolète et les développeurs restants plus chers (voir: COBOL), soit vous adoptez un framework que personne a beaucoup d'expérience et vous allez être seul lorsque vous rencontrez un problème (voir: l'outil obscur de votre choix).

Même avec tout cela, les architectes intelligents reconnaissent également que, quel que soit le cadre choisi, trois des mois plus tard, il y aura un problème qui aurait été plus facilement résolu avec un autre cadre. La vie est comme ça. Cependant, en utilisant explicitement ces critères, le processus reconnaît à la fois les compromis qui ont été faits et les raisons qui ont motivé ces compromis. La décision n'est peut-être pas «juste» dans un sens absolu, mais elle sera comprise. C'est à peu près tout ce que vous pouvez espérer.