利用django打造自己的工作流平台:从EXCEL到流程化运作

Posted 2020-11-25 leituhaomo

　　因工作所需以及管理个人一些日常事项，自己基于django（一个基于python的web框架，详细介绍可查阅相关资料）开发了一个简易的工作流平台[平台地址]。本文首先简要介绍工作流平台的设计思想及其在项目开发中的应用案例，代码层面的细节介绍后续有时间继续补充。

　　1.工作流平台在日常工作中的设计思想： 

　　如果你是一名软件研发类工作的从业者（开发、测试等），设想一下早期在没有问题单系统的时候是怎样处理软件问题的：使用一份excel表格记录问题，如图1所示：用户A在系统日常使用或者测试过程中遇到问题，需要将问题的关键信息（概要，详细描述，环境配置，触发步骤等）整理到EXCEL表格中。再通过电子邮件把表格发送给开发人员B。B可能同时有几个问题要处理，在接收到的问题中添加一些列用于记录问题状态信息（当前状态；解决时间；问题处理人等）。

 图1.问题记录表格示例 

　　用excel记录和传递问题信息的弊端：
　　1.处理闭环的不确定性：发送给开发人员B的问题邮件可能被淹没在他的大量邮件中，无法确保问题一定被解决；
　　2.效率问题：通过邮件流转问题处理信息效率太低。尤其人员较多时，人手一份EXCEL的副本，进行信息同步带来很高的沟通成本。

　　为了解决上述两个问题，诞生了专用于问题处理的问题单系统，其实质是web化的excel：图1中的每一行对应为一个问题单，每一列对应问题单的一个字段。其中有两个字段较为特殊："问题处理人"和 "当前状态"，WEB后端利用"问题处理人"字段与当前登录用户X进行匹配，把过滤出相匹配的问题并显示在界面上，就是需要用户X处理的问题。另外WEB后端预设有问题处理流程，根据"当前状态"字段决定接下来的处理：比如问题处于"待处理"状态，则下一步可以通过编辑问题单处理问题；如果问题单处于"已解决"状态，则表示该问题已完成处理归档，不能再进行处理了。

　　问题单系统优势在于通过固化字段、流程以及某些流转条件（比如设计xx字段为必填项），首先保证了问题处理的闭环，同时最大程度减少了问题流转到下个环节信息不足的情况；解决了多个环节间信息流通，多人协作的效率问题。

　　其不足在于字段和处理流程固化导致功能单一，只能用于问题处理跟踪，扩展性差。再审视一下问题单系统的实质：问题单系统实际是将一份EXCEL WEB化并使用固定的流程进行处理。我们把问题单系统视为一种特例，特例一般化（将多份EXCEL WEB化，每份EXCEL使用其给定的流程进行处理）就可以打造可定制字段、流程的工作流平台，用于部门团队的事务管理和知识积累。

　　工作流平台的架构非常简单，采用自底向上的设计，步骤如下：

　　1.为一种事务（问题处理、请假审批等）定制字段和流程；

　　2.把一种事务的字段和流程封装成一个项目。

　　3.把多个项目封装成项目群。

　　工作流平台的基本架构如图2所示：　　

图2：工作流平台的基本架构

　　理解了上述架构，不难看出工作流平台的核心就是两张表：数据表和状态转换表。数据表决定显示哪些内容，数据表字段决定如何显示(比如从数据表过滤出“当前处理人字段”等于当前登录用户名的数据显示在界面)。转换表决定每个问题的处理流程，每个项目都有一组State1xStim1>State2格式的描述，表示State1状态下收到Stim1激励跳转到State2状态，这组转换描述确定了项目的处理流程。State1xStim1>State2格式的描述的具体实现形式可以自由定义，下图是一个示例：

 

图3：状态转换描述表 

图4：状态转换描述表对应的流程图

　　图3是状态转换描述的一种实现示例，其对应的流程图如图4所示。图3中‘source‘表示源状态；‘trigger‘表示触发事件,对应界面上的按钮; ‘dest‘表示目标状态;‘trans_condition‘表示完成状态转换需要满足的条件;‘trans_action‘表示状态转换时需要执行的操作。状态转换描述表由状态机引擎解析，这样每个项目只要定义自己的状态转换描述表就可以确定项目对应的事务处理流程。

　　平台采用三级的页面结构，按层级关系分为项目群首页、单个项目主页和具体问题单页面。

　　首页列出了每个项目的项目名称，该项目下分配给当前账号的待处理问题个数等 信息，此外还可以管理项目，创建项目下的问题，以及注册为特定项目的用户等，如图5所示。

 图5.项目群首页

　　项目群主页上点击项目名称可以进入具体的项目主页；项目主页中列出了分配给当前用户的待处理条目，以及当前用户的监视条目，如图6所示。所谓监视条目就是 其他人在处理，但是当前用户比较关心的问题；比如某重大问题由人员 A 处理并使用该系统进行跟踪，并将最新的处理进展更新到系统中的问题单里，A 的直接主管可以监视该问题单以及时了解问题的最新进展，避免了各种汇报带来的整理材料和沟通成本； 若某重大问题的关键阶段已处理完成，只有一些琐碎的收尾工作，则主管可以随时取消监视问题，交由 A 处理即可。项目首页的右半部分画出了当前项目的处理流程，该流程图根据项目的状态转换表自动生成。

 图6.具体的项目主页

　　项目主页点击问题概要可进入具体问题单页面，其左半部分是问题单字段信息，上方有监视问题和取消监视两个按钮用于监 视和取消监视该问题（监视功能介绍见上文）；右半部分是问题单的管理信息，包括创建时间、创建人、当前处理人、当前状态等，如图7所示。问题单当前状态下所能执行的操作由项目流程定义，比如在” 维护人员处理” 状态下所能执行的操作是” 更新进展” 和” 提交审核”，前者只更新字段信息，后者将问题处理结果提交给维护代表审核，分别对应问题单界面下方的两个按钮。

图7.具体问题单页面

　　2.工作流平台在日常工作中的应用示例：

　　团队项目开发过程中涉及下列事务：

1. 测试问题跟踪
2. 代码检视记录；
3. 版本发布记录;
4. 各种汇报材料管理
5. 调试设备信息、编码注意事项等杂事记录

　　上述事务中有些需要归档记录以便随时查阅，比如版本发布记录、编码规范、代码检视记录以及调试设备信息、相关人员联系方式之类杂项记录等；有些只需要完成处理即可，比如分解的子功能点开发、测试过程中遇到的一般问题等。这些事务如果没有统一的平台进行管理，多名开发之间的协作，开发、测试、项目管理等不同角色之间的沟通，上下级间的汇报等都会带来很高的沟通成本。

　　为此在工作流平台中创建了三个项目：

1. 任务跟踪：用于跟踪从需求分解出的子功能点开发、测试过程中遇到的一般问题等，处理完后即可关闭，不再显示在界面上。
2. 开发记录：用于记录调试设备信息、相关人员联系方式之类杂项记录等，不要关闭，一直显示在界面上用于相关人员查阅。
3. 代码走查：用于归档代码走查记录。

　　这三个新增项目的三级页面结构见图8-14。

图8.项目群首页最后添加三个项目

图9.任务跟踪项目主页

 图10.任务跟踪项目的具体问题 

 图11.开发记录项目主页  

  图12.开发记录项目中的具体问题 

图13.代码走查项目主页

图14.代码走查项目中的具体问题

　　此外，平台中每个项目都支持权限管理，平台中数据与EXCEL之间导入、导出等，如下图。还有的项目支持绘图，详见https://www.cnblogs.com/leituhaomo/p/11784600.html。

 图15.代码走查项目导出到表格的问题

　　除用于项目管理外，工作流平台还可以拓展其他方面的应用，如问政反馈、扫码点餐、请假审批、物流信息跟踪等。