Si t'as pas développé ta "machine à état" avant 50ans, c'est que t'as raté ta vie de dev ;-)
Sans blagues, je connaissais le concept, mais comme beaucoup de dev, ça ne me parlait pas beaucoup.
Sous l'impulsion d'un projet PRO, qui consiste à virer JBPM d'un projet (*). Je me suis beaucoup pencher dessus, et j'ai trouvé le concept plus qu'intéressant, au point de m'opposer à sa suppression ;-).
Pour garder le concept de "machine à état" dans le projet, j'ai tenté de re-développer la "mienne" … Conceptualisé en python, et recodé en java : elle fonctionne parfaitement, en se basant sur des descriptifs de nodes en YAML (plus lisible que du xml).
J'ai fait un convertisseur de "process def jbpm" en yaml. Et sans beaucoup de changements, ça fonctionne "out of the box" (sans toucher au fonctionnel). ça fait une 100aine de lignes de codes, et ça marche.
Mais ça m'a surtout permis de rentrer dans le fonctionnement d'une machine à état.
Les avantages sont énormes:
- dans notre cas : on reprends la main sur la machine, et on l'adapte à nos besoins sans soucis.
- On peut générer des beaux graphiques, pour les décideurs pressés (via yapgvb/graphviz). Ce qui permet également de bien comprendre les enchainements, le fonctionnel.
- on peut changer de "moteur" (ce n'est que des conversions de process, et des adaptations de code … on ne change pas le "fonctionnel") : en gros, ça permet d'abstraire le fonctionnel du technique.
Bref, je suis devenu un fervent défenseur des "machines à état". Et merci pour ce post, qui m'amène encore un peu plus loin dans leurs compréhensions. (ça donnerait presque envi de re-tenter QT (on est vendredi, hein ?))
(*) : brique proprio, et probs d'empreintes mémoires en jvm.
# excellent post
Posté par manatlan (site web personnel) . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 10.
Si t'as pas développé ta "machine à état" avant 50ans, c'est que t'as raté ta vie de dev ;-)
Sans blagues, je connaissais le concept, mais comme beaucoup de dev, ça ne me parlait pas beaucoup.
Sous l'impulsion d'un projet PRO, qui consiste à virer JBPM d'un projet (*). Je me suis beaucoup pencher dessus, et j'ai trouvé le concept plus qu'intéressant, au point de m'opposer à sa suppression ;-).
Pour garder le concept de "machine à état" dans le projet, j'ai tenté de re-développer la "mienne" … Conceptualisé en python, et recodé en java : elle fonctionne parfaitement, en se basant sur des descriptifs de nodes en YAML (plus lisible que du xml).
J'ai fait un convertisseur de "process def jbpm" en yaml. Et sans beaucoup de changements, ça fonctionne "out of the box" (sans toucher au fonctionnel). ça fait une 100aine de lignes de codes, et ça marche.
Mais ça m'a surtout permis de rentrer dans le fonctionnement d'une machine à état.
Les avantages sont énormes:
- dans notre cas : on reprends la main sur la machine, et on l'adapte à nos besoins sans soucis.
- On peut générer des beaux graphiques, pour les décideurs pressés (via yapgvb/graphviz). Ce qui permet également de bien comprendre les enchainements, le fonctionnel.
- on peut changer de "moteur" (ce n'est que des conversions de process, et des adaptations de code … on ne change pas le "fonctionnel") : en gros, ça permet d'abstraire le fonctionnel du technique.
Bref, je suis devenu un fervent défenseur des "machines à état". Et merci pour ce post, qui m'amène encore un peu plus loin dans leurs compréhensions. (ça donnerait presque envi de re-tenter QT (on est vendredi, hein ?))
(*) : brique proprio, et probs d'empreintes mémoires en jvm.