Un système peut-il être 100% piloté par les données?
Mon nouveau patron travaille sur ce projet depuis de nombreuses années. Je ne suis ici que depuis quelques semaines, mais je ne suis pas sûr que ce soit possible. Il aimerait concevoir un système "100% piloté par les données".
Donc, si nous mettons suffisamment de données, nous pouvons définir et générer n'importe quelle application. J'ai réussi à lui faire au moins concéder des choses comme les utilisateurs, ou les applications devraient avoir des valeurs prédéfinies, mais il aime le concept de la structure du système, l'interface utilisateur et la logique tous stockés sous forme de données.
Il y a quelques démos de choses simples et il a fondamentalement redécouvert quelques idées simples de programmation orientée objet et vos systèmes de modèles de base, mais je pense que dans l'ensemble, cet objectif pourrait être impossible.
Je ne sais pas comment définir la logique à l'aide de données sans que le système ne devienne si complexe que vous effectuez de toute façon une programmation réelle.
Je pense qu'en théorie ce n'est pas parce que la chose qui interprète les données doit finir par devenir complète pour décrire l'application, vous venez donc de déplacer le problème d'un niveau plus haut sans aucun avantage net.
Une telle application 100% pilotée par les données est-elle possible?
Votre patron devrait lire cette pièce: Bad Carma: le projet "Vision", un récit édifiant sur l'effet de plate-forme intérieure ou l'effet du deuxième système.
Abstrait
Ceux d'entre nous qui travaillent dans les technologies de l'information (TI) ont tous été sur un projet où quelque chose d'important n'est tout simplement pas correct. Nous le savons, presque tout le monde le sait, mais personne n'est tout à fait capable de mettre le doigt sur le problème de manière convaincante.
Cette histoire concerne un tel projet informatique, l'échec le plus spectaculaire que j'aie jamais connu. Cela a entraîné le licenciement complet d'un service informatique de taille moyenne, et a finalement conduit à la destruction d'une entreprise en pleine croissance dans une industrie en pleine croissance. La société, que nous appellerons "Upstart", était une entreprise de télévision par abonnement prospère et rentable.
Le projet a eu lieu au début des années 1990 et il s'agissait d'une application de saisie de commande et de service client sur mesure, ressemblant étroitement à ce que l'on appelle maintenant la gestion de la relation client ou CRM. La fonctionnalité de base du système comprenait:
- Entrée de commande et inventaire
- Service client, helpdesk
- Grand livre, comptes débiteurs, facturation et comptes créditeurs
L'application s'appelait "Vision" et le nom était à la fois sa promesse officiellement déclarée pour Upstart ainsi qu'un clin d'œil auto-agrandissant à son architecte. L'application était innovante, en ce sens qu'elle était conçue pour être suffisamment flexible pour s'adapter à tout changement futur de l'entreprise. Non seulement tout changement futur prévisible dans l'entreprise, mais absolument tout changement dans l'entreprise, sous quelque forme que ce soit. C'était une affirmation tout à fait remarquable, mais Vision devait être la dernière application jamais construite. Il a atteint cette totale flexibilité en étant entièrement piloté par les données, fournissant une abstraction illimitée et en utilisant des techniques de programmation orientées objet qui étaient à la pointe de la technologie à l'époque.
Comme de nombreux projets de ce type qui visaient à créer une application critique, l'effort de développement s'est étalé sur deux ans, soit environ un an de plus que prévu initialement. Mais c'était acceptable, car c'était l'application qui durerait pour toujours, s'adaptant à toutes les exigences futures, offrant un retour sur investissement (ROI) illimité. Lorsque l'application a finalement été "mise en service", presque tout le monde dans l'entreprise y avait tellement investi que le sort de l'entreprise dépendait de son succès.
Cependant, en cas de dysfonctionnement total du projet, les applications essentielles au fonctionnement des activités principales des sociétés multinationales ne peuvent pas se permettre le luxe du type d'extinction rapide démontré par des milliers de sociétés "dot-com" à l'ère de la bulle Internet. Moins d'un mois après la mise en service de Vision, il était évident pour tous, sauf pour ceux qui étaient le plus lourdement investis dans sa construction, que c'était un échec.
Voir également
La réponse est oui, il est possible de créer un système entièrement piloté par les données et oui, c'est généralement une très mauvaise idée.
Un programme entièrement piloté par les données est un programme dans lequel toute la logique et la configuration sont gérées par des valeurs stockées de telle manière que dans un autre contexte, elles seraient considérées comme des données. De nombreux produits 4GL fabriqués dans les années 1980 offraient la capacité de générer des rapports, des formulaires, des tableaux et une logique à l'aide d'éléments de données entrés dans une multiplicité de formulaires, stockés dans des tableaux et accessibles via des rapports. J'avais l'habitude de faire référence à des systèmes tels que "Paint by numbers" mais je vois qu'il est maintenant connu sous le nom d'effet "système interne". Réputation.
Les gens qui créent ces systèmes essaient (qu'ils le sachent ou non) de créer un nouveau langage de programmation. Puisqu'ils n'ont pas les compétences, ils le font mal. Du point de vue de la JVM/CLR, un programme Java/C # compilé est simplement des données. Dans ce cas, cela a été bien fait. Dans les deux cas, les programmeurs sont nécessaires pour utiliser le langage, quel qu'il soit.
Il y a une façon spécifique de faire fonctionner ça, à ma connaissance. Vous construisez le squelette de chacun des composants dont vous avez besoin: formulaire, rapport, tableau, etc. Vous fournissez un mécanisme pour configurer différentes parties de ces composants en définissant des éléments de données. Pour un ensemble choisi de fonctionnalités, vous prenez les décisions et les gelez dans le système, et vous refusez spécifiquement la possibilité de configurer ces fonctionnalités.
Vous implémentez également un langage capable de coder des opérations logiques. Ma recommandation est d'utiliser un langage existant tel que lua ou peut-être Python. Vous intégrez des morceaux de ce code là où des opérations logiques sont nécessaires.
En faisant cela, vous réduisez considérablement la quantité d'écriture requise pour implémenter chaque formulaire, rapport, tableau, etc. Le système semble être axé sur les données, mais seulement jusqu'à un certain point.
À ce stade, vous venez de mettre en œuvre un nouveau 4GL. Si vous réussissez, faites-le moi savoir. La plupart des gens échouent lamentablement. Je serai le premier à vous féliciter pour votre réussite.
Je pense que vous avez fondamentalement raison. Un runtime de langage est déjà un système entièrement flexible piloté par les données. Il prend un morceau de données (le programme) et l'utilise pour déterminer comment il doit agir sur d'autres données. Il pourrait même avoir un schéma multi-utilisateurs pour stocker le code pour la réutilisation par d'autres programmes (allant d'un chemin d'inclusion à une bonne gestion de l'installation).
Un "langage de script", en gros, est un runtime de langage où cette entrée de code est lisible par l'homme. Un compilateur place une étape supplémentaire entre l'utilisateur et le runtime. Langages "blagues" comme Malbolge et APL n'a pas besoin d'être lisible par l'homme sous quelque forme que ce soit. Mais c'est la même chose à un seul niveau, et de toute façon lisible par l'homme ne signifie pas que tous les utilisateurs potentiels ont les compétences pour le lire ou l'écrire, ou peuvent s'attendre à les développer.
Il y a bonnes raisons pourquoi vous n'exposez pas normalement un runtime de langue directement aux utilisateurs finaux. Le principal étant que la suppression de la flexibilité augmente la commodité.
Si je veux taper un SO post, je veux juste le taper. Je suis parfaitement capable d'écrire un programme C++ pour le produire, mais je n'utiliserais pas un navigateur Web qui exposerait un éditeur de programme C++ au lieu d'une zone de texte standard. Les personnes qui ne connaissent pas C++ non seulement n'utiliseraient pas le navigateur, mais non.
Si je veux configurer certains paramètres métier, je ne veux pas nécessairement le faire en utilisant un langage de spécification complet de Turing, et même si je l'ai fait cela ne se distingue probablement pas de "coder en dur" ceux mêmes paramètres métier dans tout autre langage de programmation. Vous devez toujours vous demander si ce que vous écrivez signifie ce que vous voulez que cela signifie. Vous devez toujours tester que les modifications sont correctes. Autrement dit, vous avez toujours besoin de compétences en programmation pour toutes les tâches qui ne sont pas triviales et non prévues par quelqu'un qui fait possède des compétences en programmation qui ont préparé un sous-système spécialisé ("application") que vous devez configurer ( "utilisation").
Donc, si vous êtes sur le point de vous lancer dans un système 100% data-driven, qui peut faire n'importe quoi avec les bonnes données, vous avez deux questions à vous poser:
- Sommes-nous en train d'inventer des langages de programmation, ou devrions-nous l'être?
- Notre nouveau langage de programmation sera-t-il meilleur (pour nos besoins) que ceux que nous avons déjà et allons-nous le soutenir et le développer selon ses besoins?
Parfois, les réponses sont oui et vous écrivez une langue spécifique au domaine. Ou même un véritable langage de programmation à usage général si vous êtes Sun/Microsoft/Stroustrup/van Rossum/beaucoup d'autres. Parfois, les réponses sont non et vous avez l'effet de "plate-forme intérieure" - après beaucoup d'efforts et d'essais et d'erreurs, vous vous retrouvez avec quelque chose. Si vous avez de la chance, il n'est que légèrement inférieur au langage de programmation dans lequel vous l'avez écrit et n'est pas plus facile à utiliser.
Certaines langues sont plus difficiles ou plus faciles à utiliser que d'autres, en particulier si elles sont spécialisées dans un but comme R, certains utilisateurs les trouveront beaucoup plus faciles. Ce que vous ne ferez probablement pas, c'est de simplifier fondamentalement la programmation d'applications générales. À tout moment, il y a probablement plusieurs personnes/organisations dans le monde qui ont le potentiel de le faire, mais votre patron/entreprise doit honnêtement considérer si cela inclut lui/vous.
Il existe une astuce souvent utilisée pour les jeux, qui consiste à exposer les liaisons Lua au moteur de jeu. Cela permet aux concepteurs de programmer dans un langage relativement facile, mais d'engager quand même un "vrai" programmeur lorsque cela est nécessaire pour les performances ou pour accéder à des fonctionnalités particulières du moteur ou de la plate-forme. Les scripts Lua résultants sont des "données" en ce qui concerne le moteur. Ils n'ont pas tous besoin d'inclure une grande partie de ce que vous appelleriez de la "logique" par opposition aux données de configuration, et souvent ils définissent à peu près tout l'intrigue et l'environnement, mais pas le gameplay entier. Ce n'est pas 100% basé sur les données et ce n'est certainement pas 100% sans erreur, mais c'est un compromis pratique intéressant.
J'ai travaillé dans une entreprise où c'était l'objectif. Des extraits de code SQL ont été stockés dans des tables de base de données, lus au moment de l'exécution et exécutés. Les performances étaient horribles, comme vous pouvez l'imaginer, et les bugs étaient fréquents. Il était également impossible de déboguer, sans trace de pile ou quoi que ce soit d'autre qui facilite la vie.
La "programmation axée sur les données" résulte d'un manque fondamental de compréhension de ce que nous faisons, en tant que programmeurs; toutes les données qui sont capables de faire en sorte qu'un algorithme se produise est en fait de la "programmation", même si vous avez en quelque sorte réussi à mêler (mangle?) les deux idées dans l'interface utilisateur. Maintenant, cela ne signifie pas que vous ne pouvez pas combiner les deux idées dans l'autre sens, de sorte que tout le code soit des données; c'est la prémisse derrière LISP, qui est rendue possible par son homoiconicité et exploitée par son système macro. Oui, ces concepts semblent similaires, mais leurs implications et leurs applications sont très différentes dans la pratique.
En outre, cela peut être éditorialiste, mais les endroits que j'ai rencontrés qui souhaitent une programmation "entièrement basée sur les données" n'apprécient vraiment pas leurs programmeurs. Ils considèrent le code comme un centre de coûts, quelque chose à externaliser ou à ignorer.
Vous voulez dire que votre patron veut que vous écriviez ceci:
[
{
"statement": "Assignment ",
"variable": "App",
"value": {
"type": "Function",
"arguments": [],
"function-body": [
{}
]
}
},
{
"statement": "Assignment",
"variable": "App.prototype.action",
"value": {
"type": "Function",
"arguments": [
"data"
],
"function-body": [
{
"statement": "Call",
"function-name": "console.log",
"arguments": [
"data"
]
}
]
}
}
]
Pour générer ceci:
var App = function () {};
App.prototype.action = function ( data ) {
console.log( data );
}
Le premier est [~ # ~] json [~ # ~] et le second est JavaScript .
Clearification
Je pense qu'en théorie ce n'est pas parce que la chose qui interprète les données finit par devoir devenir complète pour décrire l'application, vous venez donc de déplacer le problème d'un niveau plus haut sans aucun avantage net.
Une telle application 100% pilotée par les données est-elle possible?
C'est là que je viens de commencer. Avec ma réponse, j'essaie d'être d'accord avec le message d'origine: C'est possible, mais vous avez raison, cela ne fera que déplacer le problème d'un niveau plus haut sans aucun avantage [évident].
Vous pourriez affirmer de manière convaincante, je pense, que toute application de navigateur Web pourrait être considérée1.
Bien sûr, cela ne rend pas la création d'applications plus simple ou plus facile sur le Web, en fait, cela les rend beaucoup plus difficiles.
Dites à votre patron qu'il réinvente le navigateur Web, et il devra éventuellement réinventer JavaScript pour construire quelque chose de relativement complexe.
1 Eh bien, si vous ignorez les plugins, JavaScript et HTML5 .