再谈工作流模式

(文章后半部份内容跑题了)

有些朋友对一个具体的业务流程使用何种工作流模式实现总是拿不定主意，
个人觉得设计工作流，其实没有什么应该的模式，
用状态机模式作主流程，管理业务状态，流模式作子流程，完成具体的业务操作是一个不错的方案。
有时业务流程不是一定要用工作流才能实现，有些系统因其类型、规模、应用、成本、时间、开发团队的技术结构等原因使其不适合用工作流平台实现。

以前做过一个业务流程，后来我管他叫接力棒模式，流程可以由任何人发起，下一节点的操作人由当前结点的操作人决定，流程只对当前结点操作人与发起人暴露，结点可由发起人与当前结点操作人随时结束。(业务需求有点类似于：发起人问小张，你对这事有什么看法，你要没什么看法你觉得谁还会有意见,叫他发表一下。一直将该询问指下去，直到某个被询问人没有要推荐的人或发起人觉满意时，流程就可以终止)

当时设计这个流程时，很头痛，这个需求与该原系统的授权模，其他的业务流程，以及所用的工作流平台都有点不对路，而且客户要得还很急，最后没用工作引擎实现，直接在页面中推，一个内容文本框，一个回复文本框，一个选择下一个接受询问者的列表框。有点象电子邮件转发的形式。我不想说这个没有技术含量，不符合设计模式的方案好不好。
不过，在一个已稳定运行并已结款的系统中，在不改变系统架构的情况下，用5个小时完成了一个重要客户的新增需求，我想对公司，对客户，对团队都是一件好事吧。

有时最好的技术不一定是项目最适合的，见过有的团队负责人，为了使用、跟随、学习一项新的技术，就在项目中及力主张使用新技术，甚至是团队或他个人都不熟悉的技术。我不想以小人之心猜想该负责人的真实想法，不过经常是该项目砸了，该负责人在项目开发中学会了该技术，找到了一家更有发展的新公司大展宏图去了，让公司(原来的)，让并肩作战的兄弟们(原来的)，陷入了一个泥潭。

我主张在项目中使用新的技术(私心成份也不少)，但是个人觉得将新技术应用到实际项目之前，还是应该进行一次评姑比效稳妥.......

今天酒喝得少了些，
又跑题了，
又开始胡说八道了，
又要被人骂了........................