rdm*_*ler 8 ide business-process-management
在实施业务流程时,您更喜欢(从开发人员的角度来看)？
业务流程管理系统(BPMS)或只是您喜欢的IDE,包含所需的工具和框架(例如报告工具)？
从您的角度来看,与使用个人工具和框架的IDE相比,BPMS的最大好处是什么？
好.也许我应该更具体一点......我了解了一个特定的BPMS,它可以通过配置规则轻松实现业务流程.但对于我作为开发人员来说,很难使用该系统.我想处理我可以重构的文本文件,我希望能够为我必须做的工作选择合适的技术或框架.而是系统强迫我配置.
有规则我可以使用java,但即使这样我也必须坚持使用系统编辑器而不使用intellisense等.
所以这引出了我自己的问题的答案 - 我想使用我习惯的工具,而不是必须学习如何使用BPMS(至少我知道的那个)因为它限制了我而不是帮助.我所知道的BPMS是一个很难逃脱的框架!在这个时候,我更喜欢像Grail这样的框架而不是我所知道的任何BPMS.
所以也许更具体的问题是:你是否有同样的感觉,或者是否有BPMS支持你成为一名开发人员并像开发人员一样思考,或者他们中的大多数会迫使你以不同的方式完成工作？
Kay*_* II 12
根据我的经验,BPMS系统提供的开发环境是三流的,非生产性的,并且实际上迫使您编写难以维护,设计不良的代码(由于它们的局限性).几乎所有我熟悉的BPMS系统提供的"功能"(UI,集成等)(该公司以其数据库命名的那个)都不值得我们支付的钱.
如果您被迫使用BPMS,作为开发人员,我的建议是在传统的开发环境中构建尽可能多的应用程序,例如Java或.Net,在BPMS环境本身尽可能少地构建,并集成他们俩.应该在BPMS中应该做的唯一事情是使业务流程工作的最小化.
我过去和BizPM一起工作,最近和JBPM合作过.由于以下原因,我的观点偏向于BPM:
陡峭的学习曲线:为了使流程有效,我必须了解系统和编辑器的工作原理.开发人员很难理解系统,更不用说业务用户了.拖放和可视化表示是一个很棒的演示工具.这无疑给管理者(最终为此付出代价)留下了深刻的印象,但开发人员的生产力却在下降.
非开发人员改变工作流程:我没有看到一个BPM解决方案完美无缺.虽然它看起来不像代码,但右键单击该框,您必须放置一些代码,否则它将不起作用.所以你肯定需要一个开发人员去做.最好的部分是它既不是开发人员友好的,也不是商业用户友好的,只是演示用户友好.
可测性和重构:测试驱动BPMS几乎是不可能的.你确实有广告的"单元测试框架",但大多数都是黑客并且很难使用.最近我尝试了JBPM一个; 我最终编写了大量的胶水代码和虚假的工作流程处理程序,以使其工作.对我而言,这笔交易的重点是重构.如果业务从根本上改变了对业务流程应该如何看待的想法,那么祝好运重新安排盒子,因为重新安排它们将无法工作,所有绑定到盒子的变量也需要重新安排.我更喜欢IDE和测试的强大功能来重构我的业务流程.
如果您的应用程序具有工作流程,那么您可以尝试工作流程库(具有或不具有持久状态).它仍将管理您的工作流程,而不会出现BPM带来的所有膨胀.如果业务用户需要了解代码,那么让业务部门准备好流程图并将其转换为良好的域驱动代码.使用黄瓜风格验收测试将开发人员和业务结合在一起.BPM只是试图做太多事情并最终做出所有这些事情的事情.
不知道究竟是什么问题,但BPM与普通编程的选择取决于要求."业务流程"在软件工程中是一个相对含糊的术语.
以下是评估您需求的一些标准:
根据这些问题的答案,您可能会发现您的流程更接近于简单的状态图表,其中包含可以按顺序执行的一些操作和决策,或者您可能意识到您需要更详细的内容,并且您不需要我不想自己重新实现这一切.
在普通编程和完整的BPM解决方案(例如包含BPEL,规则引擎等的Oracle BPM套件)之间,有一些中间解决方案,例如jBPM或Windows Workflow Foundation,可能还有很多其他解决方案.这些中间解决方案通常是很好的权衡.
BPMS——很多常见的业务案例、用例已经实现。所以你只需要知道如何使用它。对于常见的工作流程，您甚至不需要编写一行代码，尽管大多数情况下您必须编写一些脚本来覆盖尚未实现的内容。
简单的编程——只需使用 IDE 来破解代码即可。积极的一面：更多的控制。负面的？很多时间都花在重写样板代码上。你必须维护它们。
简而言之，我更喜欢业务流程管理系统。我推荐的一个是ProcessMaker。它具有直观的流程设计器，允许您通过拖放来设计工作流程。并且您始终可以编写触发器来扩展流程功能。它也是开源的。
| 归档时间： |
|
| 查看次数： |
2827 次 |
| 最近记录： |