利用django打造本身的工做流平台(一):从EXCEL到流程化运做

　　因工做所需以及管理我的一些平常事项，本身基于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之间导入、导出等，以下图。还有的项目支持绘图，详见http://www.javashuo.com/article/p-oundwkry-nb.html。

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

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