Lors de la conception d'un système, est-il préférable de prendre en compte la conception autour du cadre que vous utiliserez?

Lorsque vous développez un système ou une application que vous prévoyez d’utiliser avec un certain cadre, est-il préférable de concevoir le système sans le garder à l’esprit, ou est-il préférable de concevoir le système avec l’état d’esprit «le cadre aurait plus de facilité» avec ça".

development-process systems

— Robert Pounder
source

De quel type de cadre parlez-vous? Voulez-vous dire un cadre spécifique à une activité de niche conçu pour résoudre des problèmes très spécifiques à un domaine particulier pour un secteur particulier? (par exemple médical, nucléaire, défense, aviation, etc.). Ou parlez-vous de cadres généraux conçus pour résoudre des problèmes techniques?

— Ben Cottrell

frameworks polyvalents conçus pour résoudre des problèmes techniques

— Robert Pounder

Petite échelle faute de temps (je suis au travail, je pourrais élaborer plus tard): je suis en train d'écrire un système qui génère des emails basés sur des designs. - Si j'écrivais ceci à Laravel, j'utiliserais probablement leur "lame" de moteur de modélisation pour concevoir les courriels, ce qui simplifierait considérablement la conception du système en termes de flux. Cependant, je devrais écrire un moteur de templates si je le faisais avec PHP vanille, ou trouver un autre système de templates approprié. Cela ajouterait au processus de conception, auquel la question fait également référence.

— Robert Pounder

Cette question va générer un tas de réponses très différentes parce que "framework" et "design" sont des mots surchargés de significations multiples dans notre secteur. En outre, même pour une définition unique du cadre en tant que "cadres généraux conçus pour résoudre des problèmes techniques", cela dépendra du cadre spécifique - certains cadres ont plus d'opinion que d'autres.

— Stannius

Il serait dommage de se faire renverser par un bus alors que vous êtes perdu dans vos pensées en essayant de concevoir un véhicule de transport en commun à roues.

Réponses:

Votre conception doit répondre aux besoins des clients aussi étroitement que possible. Rappelez-vous que le design comprend de petites choses comme:

Expérience utilisateur
La fonctionnalité
Comment certaines parties de votre application communiquent (avec elle-même ou des entités externes)

Aucune de ces choses ne devrait être dictée par le cadre. S'il est clair que vous combattez votre cadre pour atteindre ces objectifs, choisissez un nouveau cadre qui vous aidera à atteindre ces objectifs avant de commencer à écrire du code.

Une fois que vous avez choisi un ensemble d'outils approprié (le cadre est un outil), je vous recommande d'utiliser les outils tels qu'ils ont été conçus. Plus vous vous écartez du cadre, plus vous augmentez la courbe d'apprentissage de votre équipe et plus il y a de chances que quelque chose se passe mal.

En bref

Concevoir pour vos utilisateurs
Choisissez les outils appropriés pour réaliser votre conception
Utilisez vos outils tels qu'ils sont conçus pour être utilisés

Autres réflexions:

Après plus de 20 ans d'ingénierie logicielle et l'utilisation de plusieurs cadres, j'ai appris quelques leçons. Tous les frameworks sont une arme à double tranchant: ils contraignent et permettent à la fois. Le problème avec le choix de votre cadre avant de vous pencher sur le grand 3 que j'ai mentionné ci-dessus est que vous pourriez compromettre une bonne expérience utilisateur pour une expérience médiocre (au mieux). Ou vous pourriez être obligé de vous écarter de la conception des frameworks pour accomplir certaines fonctionnalités spécifiques.

— Berin Loritsch
source

Ensuite, vous devez négocier avec le client. Expliquez ce que vous pouvez et ne pouvez pas faire avec les contraintes qu’ils vous ont imposées. Proposez comment cela peut changer si vous choisissez le framework X. Ils peuvent ne pas vouloir changer et accepter de vivre avec une expérience dégradée. Ou bien ils peuvent décider que vous savez ce que vous faites et que vous avez confiance en vous. Cela dépend du client. Au bout du compte, vous gérez leurs attentes.

— Berin Loritsch

Il semble y avoir une certaine confusion entre les différents niveaux de conception: conception du système et conception détaillée. Pour moi, cette question concernait la conception détaillée (la méthode de mise en œuvre) plutôt que le système (interfaces, concurrence, volume de données, interface utilisateur, type d'utilisateur).

— Gusdor

Si la question tourne autour de la "conception technique", alors la langue et le système d'exploitation peuvent avoir des déductions dans la conception. Mais encore, la conception n'est pas la mise en œuvre. Si vous envisagez d'utiliser les fonctionnalités de Frameworks, il ne s'agit pas de conception, mais de mise en œuvre. Si vous basez vos décisions de conception sur les forces du cadre, préparez-vous à en subir les faiblesses. Et lorsque la faiblesse répond aux exigences, vous avez un énorme problème. Les plus grandes entreprises n'ont pas construit leurs propres cadres pour le plaisir.

— Laiv

@ Laiv Excellent commentaire! Vraiment, c'est "certains et certains". Un pistolet à clous et un pistolet à vis peuvent tous deux fixer des objets, l'un est plus réversible que l'autre et fonctionne également plus lentement et est plus complexe. Chaque choix que font les gens est inévitablement un compromis. Vous payez votre argent et vous prenez vos chances.

@ RobertPounder, C’est un outil qui doit déterminer la pertinence d’une solution lors de la conception du système. Je comprends comment les frameworks peuvent influencer le design, mais ils ne devraient pas le dicter.

— Berin Loritsch

Les frameworks influencent naturellement la conception de modules et de sous-systèmes spécifiques (tels qu'une interface graphique). Comme l’a dit l’autre réponse, il vous sera difficile de vous battre contre le ou les cadres choisis.

Plus généralement, évitez toutefois de laisser un seul cadre ou une seule technologie dicter ou «donner une vue d'ensemble» de votre architecture système globale. Cela n'encourage pas la plupart des frameworks d'application générale, donc si vous vous retrouvez à écrire tout votre système autour d'un framework, vous faites probablement quelque chose que les auteurs de ce framework n'avaient pas l'intention de faire.

Vous utiliserez probablement de nombreux cadres différents pour résoudre différents problèmes; Au fur et à mesure que votre système devient plus complexe, vous devez faire attention à ne pas construire The Big Ball Of Mud . Dans la mesure du possible, gardez votre système modulaire et faiblement couplé. Il serait peut-être préférable de garder certains frameworks derrière des abstractions en écrivant des wrappers et des adaptateurs qui "cachent" les flux de travail spécifiques au framework à l'écart d'autres composants. Les boîtes à outils d'interface graphique ont tendance à ne servir que la fonctionnalité d'interface graphique frontale, de sorte que ces modules d'interface graphique doivent être tenus à l'écart du reste du système.

Les frameworks d'usage général (tels que les frameworks d'interface utilisateur, les frameworks de couche de données, etc.) n'existent pas pour prescrire l'architecture complète de votre système - tout au plus, ils pourraient prescrire la conception d'un composant ou d'un module; Par exemple, certaines technologies d'interface graphique sont adaptées à des modèles particuliers de MV *.

L’architecture globale de votre système doit être principalement dictée par les besoins de votre entreprise . Vous pouvez vous retrouver fortement penché sur un outil particulier (par exemple, un middleware de messagerie ou un framework ORM) afin de tout relier, mais si vous avez encapsulé le framework dans une abstraction telle qu'une classe de 'service', vous Vous êtes moins susceptible de vous retrouver contraint par ce cadre lorsque vous rencontrez ses limites.

Essayez de garder les éléments suivants à l’esprit pour votre conception grand format:

Vise à construire un logiciel modulaire
Considérer la séparation des préoccupations lors de l'écriture de chaque module et composant
Envisager une architecture à plusieurs niveaux pour séparer le système en couches
Ne construisez pas d' abstractions qui fuient
Les acronymes de cette question connexe : en quoi sont classés DRY, KISS, SOLID, etc.?

— Ben Cottrell
source

Parfois, il semble que certains auteurs de framework ne voient aucun inconvénient à ce que leurs utilisateurs écrivent du code d'application étroitement avec le framework.

— VENEZ DU

@COMEFROM - Les développeurs encouragent le couplage étroit de votre code à un framework, car ils supposent que vous avez choisi leur framework pour résoudre les mêmes problèmes pour lesquels ils l'avaient conçu.

— JeffO

Vous êtes allé un peu en dehors du sujet, en passant des principes de conception aux principes de codage, mais je comprends ce que vous dites: que se passe-t-il si l'exigence commerciale est qu'un certain cadre soit utilisé? (Pensez que la sous-traitance de la société et que les développeurs internes ne connaissent qu'une seule langue) Je pense que je devrais le préciser plus clairement dans le message d'origine.

— Robert Pounder

@RobertPounder Le point réel auquel je voulais en venir (peut-être pas très bien) est que les gens ont parfois tendance à utiliser des cadres particuliers comme "fondements" de l'ensemble de leur application, ce qui conduit inévitablement à la logique métier et à d'autres. code non lié étant fusionné de manière inappropriée à ce cadre - par exemple, la logique métier étant couplée à des contrôles d'interface utilisateur simplement parce qu'elle était rapide à l'époque. C'est très facile de faire ça, alors il faut se méfier de

— Ben Cottrell

Je ne suis pas d'accord avec @nocomprende ici; toutes les exigences futures ne sont pas prévisibles, mais parfois, les systèmes sont réécrits simplement parce que le logiciel précédent est trop difficile à étendre / maintenir .

— SeldomNeedy

Oui, vous devriez vous en tenir aussi étroitement que possible à ce que le cadre "vous dit" de faire.

La raison en est simplement que plus vous vous en tenez à la façon de "penser" des cadres, plus vous pourrez facilement parler à d'autres développeurs de vos problèmes / idées qui utilisent également ce cadre.

Vous augmentez l'interopérabilité et la facilité d'utilisation pour les autres personnes qui l'utilisent plus tard. Vous comprendrez et incorporerez mieux des tutoriels ou des solutions communes si vous vous en tenez à la philosophie sous-jacente de tout ce que vous utilisez.

La seule bonne raison pour laquelle je peux penser à la raison pour laquelle vous voulez "casser" le cadre est que vous avez absolument besoin de quelque chose qu'il ne peut pas fournir en raison de sa configuration / application "par défaut" des principes. Mais alors, ce ne serait peut-être pas le bon cadre pour commencer.

Fondamentalement, cela peut s’appliquer également à d’autres décisions. Vous devez utiliser la langue que vous utilisez aussi près qu'il est destiné à être utilisé, car il rend les choses plus facile si vous parlez la même langue que tout le monde.

— FP
source

Peut-être devriez-vous revoir votre réponse en raison des changements apportés à la question. Votre réponse ne répond pas à la question du PO.

— Laiv

@ Laiv Je ne vois pas en quoi cela ne répond pas à la question, bien que cela puisse ne pas correspondre à votre opinion sur le sujet, cela reste une réponse. Vous êtes le bienvenu pour écrire votre propre réponse pour montrer la nature conflictuelle du sujet en question.

— FP

Excusez-moi si je ne me suis pas bien expliqué. Je ne parle pas aussi bien l'anglais que je voudrais l'être. Je voulais juste dire que, OMI, la question et votre réponse parlent de choses différentes. Si vous pensez qu'ils ne le font pas, c'est bon. Je ne discuterai pas cela. C'est ça.

— Laiv

C'est absolument ça. Cela ressemble à la manière dont fonctionnent les langages spécifiques à un domaine et des idées similaires. Vos produits sont façonnés par l'outil (Framework) et non l'inverse. Le cadre "gagne". Si vous ne pouvez pas l'épouser, choisissez-en un autre. (Astuce: il n'y a pas de cadre idéal . Dites juste.)

Votre conception doit influer sur le cadre que vous choisissez (le cas échéant), et non l'inverse.

— RubberDuck