程序员如何改写工作流以适应长尾需求？

本文共计1157个文字，预计阅读时间需要5分钟。

每个程序员在接触工作流时，都会产生这样的疑问——既然一般方法可以实现，为何还要坚持使用工作流？我曾也困惑过，但现在理解得更清晰了。别急着深入探究。

每一个程序员，在接触到工作流的时候，都会有这么一个疑问——我用一般的方法可以实现，为什么还要用工作流？     我曾经也问过这个问题，不过现在稍微有点明白了。别着急要答案，      每一个程序员，在接触到工作流的时候，都会有这么一个疑问——我用一般的方法可以实现，为什么还要用工作流？       我曾经也问过这个问题，不过现在稍微有点明白了。别着急要答案，看过下面的例子，或许你也就明白一些了。     这是一个简单的业务——订货流程：

客户提交采购订单

业务员执行订单处理

如果缺货，转工厂生产       

仓库出货

物流发货

    如果不使用工作流技术，从头开始开发这个订购流程的业务逻辑，我们需要：

• 每个活动点都需要开发交互页面和后台处理程序
• 每个活动的流转都需要硬性判断下一步活动节点及其操作人
• 每次操作都需要维护业务数据和流程的相关数据

    最终结果就是这样：     这还不包括监视、控制、分析流程的部分。     但是，如果我们使用了工作流   这样看起来就简单多了。右侧的工作流管理系统，接管了所有订货业务在流程方面的定义和执行。这样做的好处很多：

• 使用专门的流程数据系统，维护所有涉及流程流转的数据。
• 提供“流程设计”工具，帮助用户定义订货流程的模型，而且一般都提供了可视化的界面。
• 所有的流程都依靠流程引擎来处理，避免了需求更改与硬编码之间矛盾的产生。