La solution doit-elle être aussi générique que possible ou aussi spécifique que possible?
Disons que j'ai une entité qui a l'attribut "type". Il pourrait y avoir plus de 20 types possibles.
Maintenant, on me demande d'implémenter quelque chose qui permettrait de changer le type de A-> B, qui est le seul cas d'utilisation.
Dois-je donc implémenter quelque chose qui autorise des changements de type arbitraires tant qu'il s'agit de types valides? Ou devrais-je UNIQUEMENT l'autoriser à changer de A-> B selon l'exigence et rejeter tout autre changement de type tel que B-> A ou A-> C?
Je peux voir les avantages et les inconvénients des deux côtés, où une solution générique signifierait moins de travail au cas où une exigence similaire se présenterait à l'avenir, mais cela signifierait également plus de chances de se tromper (bien que nous contrôlions à 100% l'appelant à ce stade). point).
Une solution spécifique est moins sujette aux erreurs, mais nécessite plus de travail à l'avenir si une exigence similaire se présente.
Je n'arrête pas d'entendre qu'un bon développeur devrait essayer d'anticiper le changement et de concevoir le système de sorte qu'il soit facile à étendre à l'avenir, ce qui ressemble à une solution générique est la voie à suivre?
Modifier:
Ajout de plus de détails à mon exemple pas si spécifique: La solution "générique" dans ce cas nécessite moins de travail que la solution "spécifique", car la solution spécifique nécessite une validation sur l'ancien type ainsi que sur le nouveau type, tandis que la solution générique il suffit de valider le nouveau type.
Ma règle d'or:
- la première fois que vous rencontrez le problème, ne résolvez que le problème spécifique (c'est le principe YAGNI )
- la deuxième fois que vous rencontrez le même problème, pensez à généraliser le premier cas, si ce n'est pas beaucoup de travail
- une fois que vous avez trois cas spécifiques dans lesquels vous pouvez utiliser la version généralisée, alors vous devez commencer à vraiment planifier la version généralisée - à ce stade, vous devez comprendre le problème suffisamment bien pour pouvoir réellement le généraliser.
Bien sûr, il s'agit d'une ligne directrice et non d'une règle stricte: la vraie réponse est d'utiliser votre meilleur jugement, au cas par cas.
Une solution spécifique nécessite plus de travail à l'avenir si des exigences similaires sont nécessaires
J'ai entendu cet argument plusieurs dizaines de fois et, selon mon expérience, il s'avère régulièrement être une erreur. Si vous généralisez maintenant ou plus tard, lorsque la deuxième exigence similaire se posera, le travail sera presque le même au total. Il est donc absolument inutile d'investir des efforts supplémentaires dans la généralisation, alors que vous ne savez pas que cet effort sera rentable.
(Évidemment, cela ne s'applique pas lorsqu'une solution plus générale est moins compliquée et nécessite moins d'efforts qu'une solution spécifique, mais d'après mon expérience, ce sont de rares cas. Un tel type de scénario a été modifié par la suite dans la question, et ce n'est pas le une de mes réponses concerne).
Lorsque le "deuxième cas similaire" apparaît, il est temps de commencer à penser à généraliser. Il sera alors beaucoup plus facile de généraliser correctement , car cette deuxième exigence vous donne un scénario où vous pouvez valider si vous avez fait les bonnes choses génériques. Lorsque vous essayez de généraliser un seul cas, vous photographiez dans le noir. Il y a de fortes chances que vous généralisiez de façon excessive certaines choses qui n'ont pas besoin d'être généralisées et que vous en manquiez d'autres. Et quand un deuxième cas survient et que vous réalisez que vous avez généralisé les mauvaises choses, alors vous avez beaucoup plus de travail à faire pour résoudre ce problème.
Je recommande donc de retarder toute tentation de faire les choses "au cas où". Cette approche ne mènera à plus de travail et d'efforts de maintenance que si vous avez manqué l'occasion de généraliser trois, quatre fois ou plus et que vous avez ensuite une pile de code similaire (donc en double) à maintenir.
TL; DR: cela dépend de ce que vous essayez de résoudre.
J'ai eu une conversation similaire avec mes Gramps à ce sujet, alors que nous parlions de la façon dont Func et Action en C # sont géniaux. My Gramps est un très vieux programmateur de minuterie, qui utilise les codes source depuis que le logiciel a été exécuté sur des ordinateurs qui occupaient une pièce entière.
Il a changé de technologie plusieurs fois dans sa vie. Il a écrit du code en C, COBOL, Pascal, BASIC, Fortran, Smalltalk, Java et a finalement commencé C # comme passe-temps. J'ai appris à programmer avec lui, assis sur ses genoux pendant que j'étais mais un devling, découpant mes premières lignes de code sur l'éditeur bleu du SideKick d'IBM. À l'âge de 20 ans, j'avais déjà passé plus de temps à coder qu'à jouer dehors.
Ce sont un peu mes souvenirs, alors excusez-moi si je ne suis pas exactement pratique en les racontant. J'aime un peu ces moments.
Voilà ce qu'il m'a dit:
"Devrions-nous opter pour la généralisation d'un problème, ou le résoudre dans la portée spécifique, demandez-vous? Eh bien, c'est une ... question."
Gramps a pris une pause pour y réfléchir pendant un bref instant, tout en fixant la position de ses lunettes sur son visage. Il jouait un match-3 sur son ordinateur, tout en écoutant un LP de Deep Purple sur son ancien système de son.
"Eh bien, cela dépendrait du problème que vous essayez de résoudre", m'a-t-il dit. "Il est tentant de croire qu'il existe une solution unique et sainte pour tous les choix de conception, mais il n'y en a pas. L'architecture logicielle est comme du fromage, vous voyez."
"... Du fromage, Gramps?"
"Peu importe ce que vous pensez de votre préféré, il y aura toujours quelqu'un qui pense qu'il sent mauvais".
J'ai cligné des yeux dans la confusion pendant un moment, mais avant de pouvoir dire quoi que ce soit, Gramps a continué.
"Lorsque vous construisez une voiture, comment choisissez-vous le matériau d'une pièce?"
"Je ... Je suppose que cela dépend des coûts impliqués et de ce que la pièce devrait faire, je suppose."
"Cela dépend du problème que la pièce tente de résoudre. Vous ne fabriquerez pas un pneu en acier ou un pare-brise en cuir. Vous choisissez le matériau qui résout le mieux le problème que vous avez à portée de main. Maintenant, qu'est-ce qu'un solution générique? Ou spécifique? A quel problème, à quel cas d'utilisation? Faut-il opter pour une approche fonctionnelle complète, pour donner un maximum de flexibilité à un code qui ne sera utilisé qu'une seule fois? Faut-il écrire un code très spécialisé et fragile à une partie de votre système qui verra beaucoup, beaucoup d'utilisations et peut-être beaucoup de changements? Des choix de conception comme ceux-ci sont comme les matériaux que vous choisissez pour une pièce dans une voiture ou la forme de la brique Lego que vous choisissez pour construire une petite maison . Quelle brique Lego est la meilleure? "
Le programmeur âgé a recherché un petit modèle de train Lego qu'il a sur sa table avant de continuer.
"Vous ne pouvez répondre à cela que si vous savez pour quoi vous avez besoin de cette brique. Comment diable vous saurez si la solution spécifique est meilleure que le générique un, ou vice versa, si vous ne savez même pas quel problème vous essayez de résoudre? Vous ne pouvez pas voir au-delà d'un choix que vous ne comprenez pas. "
"..Avez-vous juste cité La matrice? "
"Quoi?"
"Rien, continue."
"Eh bien, supposons que vous essayez de créer quelque chose pour le système national de facturation. Vous savez à quoi ressemblent cette API infernale et son fichier XML de trente mille lignes. À quoi ressemblerait une solution" générique "pour créer ce fichier comme? Le fichier est plein de paramètres facultatifs, plein de cas que seules des branches d'activité très spécifiques doivent utiliser. Dans la plupart des cas, vous pouvez les ignorer en toute sécurité. Vous n'avez pas besoin de créer un système de facturation générique si la seule chose que vous " Je ne vendrai jamais que des chaussures. Créez simplement un système de vente de chaussures et faites-en le meilleur système de facturation de vente de chaussures. Maintenant, si vous deviez créer un système de facturation pour tout type de client, sur une application plus large - à revendre en tant que système de vente générique indépendant, par exemple - maintenant il est intéressant de mettre en œuvre les options qui ne sont utilisées que pour le gaz, la nourriture ou l'alcool. Maintenant ce sont des cas d'utilisation possibles. juste quelques cas hypothétiques Ne pas utiliser, et vous ne voulez pas imp lement Ne pas utiliser cas. Ne pas utiliser est le petit frère de Pas besoin. "
Gramps remit le train lego à sa place et retourna à son match-3.
"Donc, pour pouvoir choisir un générique ou une solution spécifique pour un problème donné, vous devez d'abord comprendre ce qu'est ce problème. Sinon, vous devinez, et deviner est le travail des gestionnaires, pas des programmeurs. Comme presque tout en informatique, ça dépend. "
Alors voilà. "Ça dépend". C'est probablement l'expression à deux mots la plus puissante lorsque l'on pense à la conception de logiciels.
Principalement, vous devez essayer d'anticiper s'il est probable qu'un tel changement se produira - pas seulement une possibilité éloignée quelque part en aval.
Sinon, il est généralement préférable d'opter pour la solution simple maintenant et de l'étendre plus tard. Il est tout à fait possible que vous ayez une image beaucoup plus claire de ce qui est alors nécessaire.
Si vous travaillez dans un domaine qui est nouveau pour vous, alors la règle de trois que Daniel Pryden a certainement mentionné devrait être appliquée. Après tout, comment êtes-vous censé construire des abstractions utiles si vous êtes novice dans ce domaine? Les gens sont souvent sûrs d'eux-mêmes dans leur capacité à capturer des abstractions, bien que ce soit rarement le cas. D'après mon expérience, l'abstraction prématurée n'est pas moins un mal que la duplication de code. Les abstractions erronées sont vraiment pénibles à comprendre. Parfois encore plus pénible à refactoriser.
Il y a un livre adressant mon point sur un développeur dans une zone inconnue. Il se compose de domaines spécifiques avec des abstractions utiles extraites.
Compte tenu de la nature du corps de votre question, en supposant que je l'ai bien compris, je considère cela comme une question de conception des fonctionnalités du système central plus qu'une question de solutions génériques par rapport à des solutions spécifiques.
Et en ce qui concerne les fonctionnalités et capacités du système central, les plus fiables sont celles qui ne sont pas là. Il vaut la peine d'errer du côté du minimalisme, d'autant plus qu'il est généralement plus facile d'ajouter des fonctionnalités de manière centralisée, longtemps souhaité, que de supprimer des fonctionnalités problématiques, longtemps indésirables, avec de nombreuses dépendances car cela a rendu le travail avec le système beaucoup plus difficile. que nécessaire tout en soulevant des questions de conception sans fin avec chaque nouvelle fonctionnalité.
En fait, en l'absence d'une forte anticipation quant à savoir si cela sera nécessaire fréquemment à l'avenir, je chercherais à éviter de considérer cela comme un remplacement de type de A à B si possible, et plutôt à le chercher simplement comme un moyen de transformer l'état de A. Par exemple, définissez certains champs dans A pour le rendre morph et apparaître comme B pour l'utilisateur sans réellement changer en un `` type '' de chose différent - vous pourriez potentiellement faire A stocker B en privé en utilisant des fonctions de composition et d'appel dans B lorsque l'état de A est défini pour indiquer qu'il doit imiter B pour simplifier la mise en œuvre si possible. Cela devrait être une solution très simple et peu invasive.
Donc, de toute façon, faisant écho à beaucoup d'autres, je suggérerais d'errer du côté d'éviter les solutions génériques dans ce cas, mais plus encore parce que je suppose que cela tient compte de l'ajout d'une capacité très audacieuse au système central, et là je suggérer de pécher par excès de côté, surtout pour l'instant.
Il est difficile de donner une réponse générique à ce problème spécifique ;-)
Plus il est générique, plus vous gagnerez de temps pour les modifications futures. Par exemple, pour cette raison, de nombreux programmes de jeu utilisent le modèle de composant d'entité au lieu de construire un système de type très élaboré mais rigide des personnages et des objets du jeu.
D'un autre côté, faire quelque chose de générique nécessite un investissement initial en temps et en efforts dans la conception, ce qui est beaucoup plus élevé que pour quelque chose de très spécifique. Cela comporte le risque de sur-ingénierie, et même de se perdre dans les futures exigences potentielles.
Cela vaut toujours la peine de voir s'il existe une généralisation naturelle qui vous permettra de faire une percée. Cependant, en fin de compte, ce sera une question d'équilibre entre l'effort que vous pouvez dépenser maintenant et l'effort dont vous pourriez avoir besoin à l'avenir.
Hybride. Il n'est pas nécessaire que ce soit une question ou /. Vous pouvez concevoir l'API pour les conversions de type général tout en implémentant uniquement la conversion spécifique dont vous avez besoin en ce moment. (Assurez-vous simplement que si quelqu'un appelle votre API générale avec une conversion non prise en charge, elle échoue avec un état d'erreur "non pris en charge".)
Essai. Pour la conversion A-> B, je vais devoir écrire un (ou un petit nombre) de tests. Pour une conversion générique x-> y, je devrai peut-être écrire toute une matrice de tests. C'est beaucoup plus de travail, même si toutes les conversions partagent une seule implémentation générique.
Si, en revanche, il s'avère être un moyen générique de tester toutes les conversions possibles, alors il n'y a pas beaucoup plus de travail et je pourrais être enclin à aller plus tôt vers une solution générique.
Couplage. Un convertisseur de A à B peut nécessairement avoir besoin de connaître les détails d'implémentation des A et des B (couplage étroit). Si les A et les B évoluent toujours, cela signifie que je devrais peut-être continuer à revoir le convertisseur (et ses tests), qui craint, mais au moins il est limité aux A et aux B.
Si j'étais allé avec une solution générique qui a besoin d'accéder aux détails de tous les types, alors même que les C et D évoluent, je devrai peut-être continuer à peaufiner le convertisseur générique (et un tas de tests), ce qui peut me ralentir - même si personne n'a encore besoin de se convertir en C ou en D.
Si les conversions génériques et spécifiques peuvent être implémentées d'une manière qui n'est que vaguement couplée aux détails des types, alors je ne m'en inquiéterais pas. Si l'un de ceux-ci peut être fait de manière à couplage lâche mais que l'autre nécessite un couplage serré, alors c'est un argument solide pour l'approche à couplage lâche dès la sortie de la porte.
La solution doit-elle être aussi générique que possible ou aussi spécifique que possible?
Ce n'est pas une question recevable.
Le mieux que l'on puisse raisonnablement obtenir est quelques heuristiques pour décider du degré de généralité ou de spécificité d'une solution donnée. En travaillant sur quelque chose comme le processus ci-dessous, généralement l'approximation de premier ordre est correcte (ou assez bonne). Dans le cas contraire, la raison est probablement trop spécifique au domaine pour être couverte en détail ici.
Approximation de premier ordre: la règle habituelle de trois de YAGNI telle que décrite par Daniel Pryden, Doc Brown, et al .
Il s'agit d'une heuristique généralement utile, car c'est probablement la meilleure chose que vous puissiez faire ne dépend pas du domaine et d'autres variables.
Donc, la présomption initiale est: nous faisons la chose la plus spécifique.
Approximation de second ordre: d'après votre connaissance approfondie du domaine de la solution, vous dites
La solution "générique" dans ce cas nécessite moins de travail que la solution "spécifique"
donc nous pourrions réinterpréter YAGNI comme recommandant d'éviter le travail inutile , plutôt que d'éviter une généralité inutile. Donc, nous pourrions modifier notre présomption initiale et faire à la place la chose la plus simple .
Cependant, si votre connaissance du domaine de la solution indique que la solution la plus simple est susceptible d'ouvrir de nombreux bogues, ou d'être difficile à tester correctement, ou causer tout autre problème, alors être plus facile à coder n'est pas nécessairement une bonne raison de changer notre choix d'origine.
Approximation de troisième ordre: votre domaine problématique connaissances suggère-t-elle que la solution la plus simple est réellement correcte, ou autorisez-vous beaucoup de transitions que vous savez être dénuées de sens ou erronées?
Si la solution simple mais générique semble problématique, ou si vous n'êtes pas confiant dans votre capacité à juger ces risques, faire le travail supplémentaire et rester avec votre supposition initiale est probablement mieux.
Approximation du quatrième ordre: votre connaissance du comportement du client, ou comment cette fonctionnalité est-elle liée aux autres, ou les priorités de gestion de projet, ou ... toute autre considération non strictement technique modifie-t-elle votre décision de travail actuelle?
Ce n'est pas une question facile à répondre avec une réponse simple. De nombreuses réponses ont donné une heuristique construite autour d'une règle de 3, ou quelque chose de similaire. Il est difficile de dépasser ces règles générales.
Pour vraiment vraiment répondre à votre question, vous devez considérer que votre travail est le plus susceptible de ne pas implémenter quelque chose qui change A-> B. Si vous êtes un entrepreneur, c'est peut-être l'exigence, mais si vous êtes un employé, vous avez été embauché pour effectuer de nombreuses tâches plus petites pour l'entreprise. Changer A-> B n'est qu'une de ces tâches. Votre entreprise va se soucier de la façon dont les modifications futures peuvent également être apportées, même si cela n'est pas indiqué dans la demande. Pour trouver "TheBestImplementation (tm)", vous devez regarder l'image plus grande de ce qu'on vous demande vraiment de faire, puis l'utiliser pour interpréter la petite demande qui vous a été donnée de changer A-> B.
Si vous êtes un programmeur d'entrée de bas niveau fraîchement sorti de l'université, il est souvent conseillé de faire exactement ce qu'on vous a dit de faire. Si vous avez été embauché en tant qu'architecte logiciel avec 15 ans d'expérience, il est généralement conseillé de penser aux choses dans leur ensemble. Chaque travail réel va se situer quelque part entre "faire exactement ce qu'est la tâche étroite" et "penser à la situation dans son ensemble". Vous vous sentirez où votre travail s'inscrit dans ce spectre si vous parlez suffisamment aux gens et faites assez de travail pour eux.
Je peux donner quelques exemples concrets où votre question a une réponse définitive basée sur le contexte. Considérez le cas où vous écrivez des logiciels critiques pour la sécurité. Cela signifie que vous avez mis en place une équipe de test pour vous assurer que le produit fonctionne comme promis. Certaines de ces équipes de test doivent tester chaque chemin possible à travers le code. Si vous leur parlez, vous constaterez peut-être que si vous généralisez le comportement, vous ajouterez 30 000 $ à leurs coûts de test, car ils devront tester tous ces chemins supplémentaires. Dans ce cas, ne pas ajouter des fonctionnalités généralisées, même si vous devez dupliquer le travail 7 ou 8 fois à cause de cela. Économisez de l'argent et faites exactement ce que la demande a indiqué.
D'un autre côté, considérez que vous créez une API pour permettre aux clients d'accéder aux données dans un programme de base de données créé par votre entreprise. Un client demande à autoriser les modifications A-> B. Les API ont généralement un aspect de menottes dorées: une fois que vous ajoutez des fonctionnalités à une API, vous n'êtes généralement pas censé supprimer cette fonctionnalité (jusqu'au prochain numéro de version principale). Beaucoup de vos clients ne sont peut-être pas prêts à payer le coût de la mise à niveau vers la prochaine version majeure, vous pouvez donc être bloqué avec la solution que vous choisissez pendant longtemps. Dans ce cas, je fortement recommande de créer la solution générique dès le départ. Vous ne voulez vraiment pas développer une mauvaise API pleine de comportements ponctuels.
Pour moi, une ligne directrice que j'ai établie il y a quelque temps est la suivante: "Pour les exigences hypothétiques, n'écrivez que du code hypothétique." C'est-à-dire - si vous prévoyez des exigences supplémentaires, vous devriez réfléchir un peu à la façon de les implémenter et structurer votre code actuel afin qu'il ne bloque pas de cette façon.
Mais n'écrivez pas de code réel pour ceux-ci maintenant - réfléchissez un peu à ce que vous feriez. Sinon, vous compliquerez généralement les choses inutilement et vous serez probablement ennuyé plus tard lorsque des exigences réelles différentes de celles que vous attendiez.
Quatre votre exemple: si vous avez toutes les utilisations de la méthode convert sous votre contrôle, vous pouvez simplement l'appeler convertAToB pour l'instant et planifier d'utiliser une refactorisation "rename method" dans le IDE à renommer si vous avez besoin de fonctionnalités plus générales plus tard. Cependant, si la méthode de conversion fait partie d'une API publique, cela pourrait être très différent: être aussi spécifique bloquerait la généralisation plus tard, car il est difficile de renommer les choses dans ce cas.
Hmm ... pas beaucoup de contexte pour trouver une réponse ... faisant écho aux réponses précédentes, "ça dépend".
Dans un sens, vous devez vous rabattre sur votre expérience. Si ce n'est pas le vôtre, alors quelqu'un de plus senior dans le domaine. Vous pouvez chipoter sur ce que disent les critères d'acceptation. Si c'est quelque chose du genre "l'utilisateur devrait pouvoir changer le type de" A "en" B "" contre "l'utilisateur devrait pouvoir changer le type de sa valeur actuelle à n'importe quelle autre valeur autorisée".
Les critères d'acceptation sont souvent sujets à interprétation, mais un bon personnel d'AQ peut rédiger des critères appropriés à la tâche à accomplir, minimisant ainsi l'interprétation requise.
Existe-t-il des restrictions de domaine qui ne permettent pas de passer de "A" à "C" ou toute autre option, mais uniquement de "A" à "B"? Ou s'agit-il simplement d'une exigence étroitement spécifiée qui n'est pas "avant-gardiste"?
Si le cas général était plus difficile, j'irais demander avant de commencer le travail, mais dans votre cas, si je pouvais "prédire" que d'autres demandes de changement de "type" viendraient à l'avenir, je serais tenté de: a) écrire quelque chose de réutilisable pour le cas général, et b) envelopper dans un conditionnel qui n'autorise que A -> B pour l'instant.
Assez facile à vérifier pour le cas actuel dans les tests automatisés, et assez facile à ouvrir à d'autres options plus tard si/quand différents cas d'utilisation se présentent.
Je continue d'entendre qu'un bon développeur devrait essayer d'anticiper le changement et de concevoir le système de sorte qu'il soit facile à étendre à l'avenir,
En principe, oui. Mais cela ne pas conduit nécessairement à des solutions génériques.
Il y a deux types de sujets dans le développement de logiciels, en ce qui me concerne, où vous devez anticiper les changements futurs:
- Les bibliothèques destinées à être utilisées par des tiers, et
- architecture logicielle globale.
Le premier cas est résolu en surveillant votre cohésion/couplage, l'injection de dépendance ou autre. Le deuxième cas se situe à un niveau plus abstrait, par exemple en choisissant une architecture orientée services au lieu d'un gros bloc de code monolothique pour une grande application.
Dans votre cas, vous demandez une solution spécifique à un problème spécifique, qui n'a aucun impact prévisible sur l'avenir. Dans ce cas, YAGNI et DRY sont de bonnes devises pour lesquelles tirer:
- YAGNI (vous n'en aurez pas besoin) vous dit d'implémenter les choses de base absolument minimales dont vous avez besoin et que vous utilisez en ce moment. Cela signifie implémenter le minimum qui fait passer votre suite de tests actuelle du rouge au vert, si vous devez utiliser le développement de style TDD/BDD/FDD. Pas une seule ligne de plus.
- SEC (ne vous répétez pas) signifie que si vous rencontrez à nouveau un problème similaire, alors vous examinez attentivement si vous avez besoin d'une solution générique.
Combiné avec d'autres pratiques modernes (comme une bonne couverture de test pour pouvoir refactoriser en toute sécurité), cela signifie que vous vous retrouvez avec un code rapide, maigre et moyen qui grandit au besoin.
qui ressemble à une solution générique est la voie à suivre?
Non, il semble que vous devriez avoir des environnements de programmation, des langages et des outils qui rendent la refactorisation facile et amusante lorsque vous en avez besoin. Les solutions génériques ne fournissent pas cela; ils découplent l'application du domaine réel.
Jetez un œil aux frameworks ORM ou MVC modernes, par exemple Ruby on Rails; au niveau de l'application, tout se concentre sur le travail non générique. Le Rails = les bibliothèques elles-mêmes sont évidemment presque 100% génériques, mais le code de domaine (sur lequel porte votre question) devrait faire des manigances minimales à cet égard.
Une autre façon de penser le problème est de considérer ce qui a du sens.
Par exemple, il y avait une application que je développais qui comportait des sections qui faisaient presque la même chose mais avec des règles d'autorisation incohérentes. Comme il n'y avait aucune raison de les garder différentes, quand j'ai refactorisé cette section, je leur ai fait faire toutes les autorisations de la même manière. Cela a rendu le code global plus petit, plus simple et l'interface était plus cohérente.
Lorsque la direction a décidé d'autoriser d'autres personnes à accéder à une fonctionnalité, nous avons pu le faire en changeant simplement un indicateur.
De toute évidence, il est logique de faire la conversion de type spécifique. Est-il également judicieux d'effectuer des conversions de type supplémentaires?
Gardez à l'esprit que si la solution générale est plus rapide à implémenter, le cas spécifique est également facile, vérifiez simplement qu'il s'agit du seul type de conversion que vous autorisez.
Si l'application est dans un domaine hautement réglementé (une application médicale ou financière), essayez d'impliquer plus de personnes dans votre conception.