不是学框架是看穿它20 年政务开发里长出来的一种认知写给那个拿到新框架先翻源码再写代码的自己。文章目录不是学框架是看穿它20 年政务开发里长出来的一种认知从一个习惯说起一、看穿本质框架在替你做什么例子Activiti 的用户表为什么能换成视图例子事务管理的空壳化二、找到缝隙在别人的框架里找到自己的路例子任意流转例子分支条件自动注入三、不碰源码弯曲但不破坏四、这种认知从哪来五、这不是技术能力是一种思维习惯写在最后从一个习惯说起我拿到一个新框架第一件事不是看官方文档的 Quick Start而是翻源码。不是因为我热爱读源码。是因为我需要知道一件事它到底在干什么。Activiti 说自己是一个工作流引擎。但翻开源码它的本质就是解析一张 XML 图把节点和连线变成内存里的 Java 对象然后沿着对象引用往下走。所谓的流程流转就是把当前节点的指针挪到下一个节点。知道这件事之后很多原本不可能的操作就变成可能了。我不是在夸自己。这是一个花了 20 年才养成的习惯——不是能力是习惯。下面我用自己干过的几件事把这种认知拆开来讲。一、看穿本质框架在替你做什么大部分人用框架的方式是照着文档配置跑通了就不管了。出了问题再去搜。但如果你知道框架在替你做什么出了问题你就不需要搜——你自己就能推出来。例子Activiti 的用户表为什么能换成视图Activiti 有三张用户表ACT_ID_USER、ACT_ID_GROUP、ACT_ID_MEMBERSHIP。官方文档教你往里插数据或者实现 IdentityService 接口。我翻了源码发现 Activiti 查用户就是写标准 SQLSELECT * FROM ACT_ID_USER WHERE ID_ ?。没有特殊存储过程没有二进制序列化没有缓存穿透机制。就是一条 SQL。既然是 SQL表和视图有什么区别对查询来说没有区别。于是我 drop 掉三张表建了三个同名视图直接映射到业务系统的用户表。零同步、零 Java 代码、零接口实现。这个方案不是拍脑袋想出来的。是看穿了Activiti 查用户就是一条 SQL这个本质之后自然推导出来的。例子事务管理的空壳化Activiti 自己管数据库连接MyBatis 也自己管连接。业务表和流程表不在同一个事务里流程提交了但业务回滚了数据就脏了。官方方案是用 Spring 统一管理。但我的项目没有 Spring是自研框架。我翻了 Activiti 的源码发现它的事务管理就是三个方法commit()、rollback()、close()。于是我继承了JdbcTransaction把这三个方法全部架空——commit 不提交rollback 不回滚close 不关闭。Activiti 以为自己管着事务实际上连接和生命周期全在我的框架手里。这不是 hack是理解了事务的本质就是这三个操作之后做出的最简方案。二、找到缝隙在别人的框架里找到自己的路看穿本质之后下一步是找到框架的边界在哪里——哪些是它必须控制的哪些是它以为自己控制了但其实可以绕过的。例子任意流转Activiti 原生只能按 BPMN 定义的路径走。但政务场景是科长要直接跳到处长、退回到科员、转办到其他科室。BPMN 画不出这种路径。我啃了两个月源码。最后发现流程图在运行时就是内存里的ActivityImpl对象节点之间的连线就是对象之间的引用。所谓的走下一条线就是把当前指针从 A 节点挪到 B 节点。那我是不是可以直接改这个引用试了一下可以。改完跳转完成再改回去。不影响流程定义不影响其他实例。核心方法turnTransition()就是这么来的。Activiti 控制的是流程定义的路径。但它管不了运行时内存里对象的引用。这个缝隙就是突破口。例子分支条件自动注入业务人员画流程图经常忘记给分支连线加条件。开发时才发现缺条件回头改 BPMN 不现实。但 BPMN 就是一个 XML 文件。XML 可以解析。解析之后sequenceFlow节点就是一行一行可读的结构。我的方案流程部署之前扫描所有sequenceFlow找到同一个源节点有多条连线的情况自动注入${nextid连线id}条件。业务人员只管画图条件框架自动补。他们甚至不知道有条件表达式这个东西。缝隙在于Activiti 要求条件在部署时存在但没说条件必须是人工写的。机器写的也行。三、不碰源码弯曲但不破坏这两个原则是我给自己定的底线不碰别人的源码——不改 Activiti 的 jar 包不 fork 分支。升级的时候不会被自己的改动拖住。弯曲但不破坏——可以绕过框架的限制但不能让框架崩溃。跳转完了要把连线改回去空壳事务要保证连接生命周期正确。这两个原则看起来矛盾——你要绕过框架又不破坏它不矛盾。因为你看穿了框架在做什么你就知道哪些地方能动、哪些不能动。ActivityImpl的连线引用能动因为跳转完改回去其他实例完全不受影响。JdbcTransaction的三个方法能动因为真正的 commit/rollback 由上层统一管理器控制连接不会被泄漏。用户表能换成视图因为 Activiti 只做 SELECT不做 INSERT。每一步都是在知道框架到底在干什么的前提下在安全范围内找到最短路径。四、这种认知从哪来说了这么多这种认知不是天生的也不是看书看来的。是 20 年踩坑踩出来的。几个关键经历VC PB 时代PowerBuilder 的 DataWindow 把数据库查询、展示、编辑、保存全做到一个控件里。我后来用 Java 写框架时脑子里一直有这个模型——能不能把重复的事情做到一个地方自研框架 Browise十几年的框架从 XML 配置进化到注解驱动从事务散落各处到统一管理。每一版改进都是因为碰到一个痛点想清楚了本质然后找到最简方案。政务审批的特殊性政务场景的需求永远比框架设计者想的多。科长要跳签、处长要退回、会签部门随时变、业务人员不会写条件表达式。这些需求逼着你不能只当框架的使用者必须理解框架的内部结构。这些经历教会我一件事框架是人写的人写的就有边界。边界不是墙是缝隙。找到缝隙你就有了自由度。五、这不是技术能力是一种思维习惯很多人觉得能改 Activiti 源码、能绕过框架限制是因为技术强。不是。是因为我在面对任何一个新系统时都会问自己三个问题它在干什么——不是它声称自己在干什么是它实际上在干什么。它的边界在哪——哪些是它必须控制的哪些它以为控制了但其实没有。最短的路径是什么——不是最优雅的不是最规范的是在安全范围内最快的。这三个问题不需要技术天赋。需要的是不甘心只当使用者的心态——拿到一个工具总想拆开看看里面是什么。这种心态不是学来的。是被真实的业务需求逼出来的——当科长说我要直接跳到处长你搜遍了官方文档发现做不到你不拆源码还能怎么办写在最后这篇文章不是教你绕过框架。是告诉你你不需要被框架牵着走。框架的设计者不可能预见你所有的需求。当需求超出了框架的能力你有两条路一是换框架二是看穿框架找到缝隙。第一条路成本高而且下一个框架也会有边界。第二条路需要认知但认知是可以训练的——每次拿到新东西别急着用先想清楚它到底是什么。政务信息系统 20 年框架换了四五个语言换了三四种。但每一种新东西到手我的处理方式都一样先看穿再使用。这不是能力问题是习惯问题。而这个习惯什么时候开始养都不晚。
