大二结束的那个暑假我没去投互联网公司的实习而是一头扎进本地一家做企业信息化的公司跟着一个五人的小团队做用友ERP的二次开发。身边同学听我说ERP二开第一反应基本都是那是干啥的说实话进组之前我自己也只有一个模糊印象——大概就是给一套很庞大的企业管理软件打补丁、加功能。两个月下来我才慢慢意识到这活儿的技术密度和踩坑密度跟写一个普通的增删改查后台完全是两码事你要面对的是十几年的历史代码、客户现场跑着的真实数据、以及一套升级一次就能把你写的东西全部冲掉的产品版本节奏。这篇就当作我的暑假实习小结把用友ERP系统二次开发里我真正摸过的东西、踩过的坑、想通的道理尽量讲清楚也给后面想走这条路的同学留个参考。1. 进组第一周先搞明白二次开发改的是哪一层进组第一天组长没让我写代码而是丢给我一份产品线清单让我自己查资料把这些名字的定位理清楚。我当时挺不服气觉得这有什么难的。结果一查才发现用友的产品线确实杂U8、U8、T、U9、U9C、NC、NCC、BIP光看名字很难分辨谁是谁的下一代、谁又是完全独立的另一条线。这个认知如果一开始不建立起来后面连我到底在给哪个产品做开发都说不清更别提查文档了。按我后来理解的大致脉络U8和U8主要面向中小型制造、商贸企业是比较典型的C/S加Web混合架构服务端跑在Windows上数据库一般是SQL Server客户端要装一个厚厚的客户端程序U9和U9C面向中大型企业架构上更偏SOA服务端以.NET为主U9C是向云化方向走的那一版NC和NCC面向大型集团技术栈换成了Java系再往上的BIP是用友这几年主推的商业创新平台走的是云原生、低代码那一路。这几条线各有一套二次开发体系API不通用扩展方式也不一样千万不能拿U8的经验去套U9。理解了产品线还得理解二次开发这四个字在ERP语境下到底覆盖了哪些层面。我当时把它拆成了四层来看这个拆法对我帮助很大数据层直接动数据库写SQL脚本、存储过程、视图、触发器甚至建中间表。见效最快风险也最大。逻辑层通过插件、工作流、业务规则来改业务流程比如审批通过后自动生成某张单据。界面层改单据模板、自定义表单、自定义报表让界面上的字段和布局贴合客户的实际业务。集成层通过OpenAPI、中间表、消息机制把ERP和外部系统比如MES、PDM、WMS对起来。这四层不是随便选的而是有一个从轻到重的排序。我在实习期做的活基本都在这四层里来回横跳下面会一一道来。1.1 标准功能能解决的尽量不要写代码这条是我整个暑假听得最多、也是体会最深的一句话。刚进组的时候我看到需求就想着怎么用代码实现结果被组长按着头改了好几次。后来他给我讲了一个很实在的道理客户提的需求先问三遍标准产品能不能配置出来。比如客户说我们的采购订单要增加一个项目号字段这根本不用改代码用自定义项就能加客户说我们的请购单要走三级审批这是工作流配置的活儿客户说我想看按部门、按月份的采购汇总表优先考虑自定义报表或者BI工具而不是自己去写一个查询页面。只有当标准配置确实绕不过去的时候才轮到写代码。为什么这么强调因为二开代码在产品升级时是最脆弱的一环。你用标准配置做出来的东西升级时大概率能平滑过渡你写死在代码里的逻辑升级一次可能就要重新适配一遍。我实习期间就遇到过组里维护的一个老项目因为客户要升级U8版本之前写的一堆触发器全都要重新验证光回归测试就做了两个星期。1.2 新手最容易踩的第一个坑上来就改数据库我自己踩过这个坑。当时有个小需求——某张单据的某个字段要按客户规则重新计算。我图省事直接写了个触发器挂在表上测试环境里跑得好好的交上去也被夸了一句效率高。结果上了客户现场问题来了触发器在批量导入数据的时候把性能拖垮了而且逻辑写死在数据库层业务人员完全看不到、也维护不了后面换个规则又得改一次。后来我才明白数据层的改动应该尽量作为最后手段。能用插件在业务层拦住的逻辑就别下沉到数据库能用视图解决的统计就别写触发器。数据库层的代码隐蔽、难维护、升级时最容易被冲掉而且一旦出问题排查链路特别长——你得先怀疑业务代码再怀疑接口最后才怀疑到数据库头上中间能烧掉你一整天。2. 搭环境这一关比想象中难啃一百倍在互联网公司实习的同学环境搭建可能就是clone一个仓库、装个依赖、跑个dev server十分钟搞定。在ERP这边光把开发环境搭起来我花了整整三天而且中间反复重装了两次。这一关不写出来真的对不起我掉的头发。2.1 老系统的依赖链条牵一发动全身以U8为例一个能跑起来的开发环境大概需要这些东西操作系统我们用的是Windows Server 2016也见过客户用Windows 7和Windows 10的、IIS、对应版本的.NET Framework、SQL Server版本还得和产品版本匹配、以及一些说不清道不明的运行库和组件。理论上照着安装文档一步步来就行实际上每一步都可能卡你。最经典的一个坑是安装过程中提示某个IE Web Control组件装不上尤其是在Windows 7这类系统上。我第一次遇到的时候完全懵以为是安装包坏了。后来查资料加上组长指点才知道这是老产品对旧组件的依赖问题处理思路大致是确认安装程序是以管理员权限运行的如果组件包没有自动释放可以尝试手动解压安装包里的组件目录再单独注册有时候还需要先把系统的IIS相关兼容组件勾选上让它满足老组件的运行前提。这些问题在网上能搜到不少同行的处理记录但每台机器的具体情况不一样照抄不一定管用关键是理解它是依赖没满足而不是安装包有问题。提示ERP开发环境的版本匹配是第一原则。产品的补丁号、数据库的版本、.NET的版本三者之间是绑定的随便升其中一个都可能让整套环境起不来。装之前一定要拿准客户现场的版本清单别自己凭感觉装最新的。2.2 U9/U9C里那两种让人头大的扩展字段如果说U8的环境是老那U9和U9C给我的感觉就是绕。进组第二周我接触到了U9C里的扩展字段当时被公共扩展字段和实体扩展字段这两个概念绕得晕头转向后来才算理清楚。简单说实体扩展字段是挂在某个具体业务实体比如销售订单、采购订单上的只有这个实体能用字段的含义也偏向这个实体的业务属性公共扩展字段则更通用可以在多个实体之间共享适合放一些跨业务的通用属性。选择哪种取决于这个字段到底是某个单据专属还是一类业务通用。我个人的经验是宁可先按实体扩展字段来设计。因为公共扩展字段一旦被多个实体引用后面想改类型、改含义牵涉面会大很多而实体扩展字段的影响范围可控。当然如果业务上确实明确是跨实体的通用属性那就老老实实用公共扩展字段别硬塞。这个判断在项目初期就要定下来后期改动成本极高。3. 实习期间真正动手做的几类活前面讲了认知和环境这部分讲我实际干的活。整个暑假我参与的三个项目活儿基本都落在界面改造业务逻辑嵌入系统对接这三类里下面挑有代表性的说。3.1 单据模板改造看起来最没技术含量其实最磨人我接手的第一个任务是改一张采购相关单据的模板。说白了就是在界面上加几个自定义项、调整字段顺序、设置某些字段的必填和只读规则。听起来特别简单但我改了整整两天。磨人的地方在于细节。第一字段的显示名称和数据库里的字段名往往不是一回事你得先搞清楚这个自定义项对应到哪张表的哪一列否则后面做报表、做接口时会全部对不上。第二字段的可见性、必填性、编辑性是可以按角色、按流程节点变化的客户嘴上说这个字段要显示实际业务里可能只在审批环节需要看。第三模板改完后要关联到对应的人员和角色不然业务人员根本看不到你改的东西。这类界面级的改造最大的价值在于让业务人员能自己看懂、自己维护。我把这次的经验总结成一句话界面层能解决的需求尽量留在界面层别往代码里塞。因为业务规则会变而业务人员改一个模板比找你改代码快得多。3.2 业务逻辑的嵌入插件是主力但要知道它挂在哪逻辑层是我做得最多的一类活。典型场景比如某张单据保存时要按规则校验单据审核通过后要自动生成另一张单据某个关键字段变更时要触发消息通知。这些逻辑标准功能里如果没有现成的就要靠插件或者工作流来做。以U8的二次开发为例产品提供了配套的开发工具和接口你可以在单据保存、审核、删除这些关键节点上挂自己的逻辑。我用得最多的是保存前校验和审核后处理这两类。这里有个教训校验逻辑尽量往保存前放早一点拦住错误数据比事后修数据省事太多。我们有个项目因为校验放在了审核后导致一批错误单据已经进了系统最后只能写脚本一条条清理费了老劲。写插件还有两个要注意的地方。一是异常处理插件里抛出来的异常如果没处理好用户看到的就是一句莫名其妙的报错甚至可能让整个单据保存失败。我的做法是尽量把用户能看懂的提示信息包装一层别把原始堆栈直接甩给业务人员。二是性能插件在单据保存时会同步执行如果里面做了复杂查询甚至调外部接口用户点一下保存可能要等好几秒。复杂耗时的逻辑能异步就异步能放后台就放后台。3.3 OpenAPI对接把ERP和外部系统连起来第三个项目涉及对接是用友产品的OpenAPI把ERP和外部系统连起来。这块是我实习期觉得最有意思的部分也是最能体现ERP二次开发不只是改改单据的地方。对接的常见方案有三种我们当时对比过方案大致做法优点缺点直接调用OpenAPI外部系统通过HTTP接口读写ERP数据实时性好接口文档相对规范依赖网络和接口稳定性对方系统要改造中间表双方约定一张数据库表各写各的解耦、实现简单、老系统友好实时性差需要定时任务字段含义要严格约定消息机制通过消息中间件异步传递削峰、解耦、适合大批量架构复杂排查问题链路长我们最后选的是以OpenAPI为主、中间表兜底的混合方案。原因很实际客户现场有一批老设备它们的系统根本没法改造去调接口只能通过数据库层交换数据而新的业务系统走OpenAPI实时性有保障。这个选择让我第一次体会到技术方案往往不是选最好的而是选能在客户现有条件下跑通的。对接里最耗时间的其实是字段映射。ERP里叫存货编码对方系统里可能叫物料号ERP里的日期是带时分秒的对方可能只要日期金额的精度、数量的单位、状态的枚举值每一项都要对齐。我们当时是拉了一张Excel把两边的字段一一列出来谁的、什么类型、怎么转换、由谁负责全部写清楚再动手。这张表后来成了排查问题的第一手资料非常值。4. 一次真实的排错数据对不上的那三天讲一个我印象最深的排错经历因为那三天让我对ERP二开的坑有了全新的认知。4.1 现象同一天的库存两边差了几十件项目上线测试阶段客户反馈说ERP系统里某个仓库的库存和他们对账系统里的数量对不上差了大概几十件而且是今天对不上、明天又对上了、后天又对不上这种飘忽的状态。这种间歇性问题最要命因为你在现场盯着的时候它偏偏不复现。我第一反应是怀疑接口传值传错了于是把对接日志翻了个底朝天结果每条记录看起来都正常。接着我怀疑是不是有人手工改了数据查了操作日志没有。然后我又怀疑是并发写入导致的覆盖但业务量并不大按理说不至于。4.2 定位问题出在事务边界和缓存真正找到根因是靠缩小范围这个笨办法。我把出问题的单据逐条拉出来发现它们都有一个共同点都是通过接口批量写入的而且写入的时间点集中在某个定时任务执行之后。顺着这条线我们发现接口在处理批量数据时把多条记录放在了一个事务里提交而下游对账系统是逐条读取的中间存在一个短暂的时间窗口——在这个窗口里数据只写进去了一部分对账系统读到的是半成品状态。另外还有一个隐藏的推手产品侧的缓存。ERP里有些数据会被缓存在内存里提高性能接口写入后如果缓存没有及时失效后续读到的可能是旧值。这两个因素叠在一起就造成了数据飘的现象。4.3 修复与验证把问题锁死在最小范围修复的思路并不复杂一是调整接口的处理粒度把批量提交拆成更小的批次缩短那个半成品窗口二是在数据写入后显式触发缓存刷新确保读到的都是最新值。改完之后我们没有马上收工而是做了一轮针对性的回归——用同样的批量数据反复跑盯着对账结果看了大半天确认稳定了才交。这次排错给我最大的启发是ERP系统里的问题很少是单一原因造成的。事务、缓存、并发、定时任务这些因素经常是叠加在一起才暴露出来。新手容易犯的错是找到一个可能的原因就急着改而我们组长的方法是先把所有可疑因素列出来再一个个排除虽然慢但不会误伤。注意排查这类问题时千万不要在客户的生产环境上直接改数据做实验。我们的做法是先在生产环境只读地收集信息把复现条件摸清楚再到测试环境上重现和验证。生产环境的一行数据背后可能牵着好几张单据和一堆报表。5. 一个暑假换来的几条经验两个月说长不长但对我这个还没正式工作过的学生来说密度是真的高。除了技术上的长进有些东西是在学校完全学不到的。5.1 技术之外沟通和文档占了至少一半我原本以为实习就是埋头写代码结果发现我在沟通和文档上花的时间一点不比写代码少。客户提的需求经常是模糊的你得反复确认你写的东西要交给别人维护文档就不能只写给自己看。我印象很深的是组长要求我每改一个东西都要在项目文档里记清楚改了什么、为什么改、影响哪些功能、怎么验证。一开始我觉得麻烦后来自己维护别人的代码时才明白这些记录有多值钱。5.2 给想入行ERP二次开发的同学几点实在建议如果你也在考虑这条路线我按自己的体会给几条实在的先把产品线的定位搞清楚别上来就学具体API。知道U8、U9、NC、BIP各是什么定位比背几个接口名有用得多。数据库功底要扎实尤其是SQL。ERP二开里大量的时间是在和表、视图、存储过程打交道SQL写不好会很痛苦。学会判断该不该改代码。这是区分新手和老手的关键能力标准功能能配出来的坚决别写代码。重视版本和环境的匹配。这个问题会贯穿你的整个职业生涯装环境前先要版本清单别凭感觉。养成写文档和记日志的习惯。ERP项目周期长、参与人多你的记录就是团队的资产也是你自己的护身符。我个人最大的感受是ERP二次开发这条路看起来不如互联网那么性感但它特别锻炼人对复杂系统的理解能力。你要同时考虑数据结构、业务流程、客户习惯、升级兼容这种全局视角是在别的地方很难练出来的。如果非要说这个暑假我赚到了什么大概是这么一件事我终于明白写代码只是解决问题的手段之一而真正难的是搞清楚问题到底出在哪一层、该用哪种最轻的方式去解决它。这个认知我觉得比学会任何一个API都值钱。要是你也在纠结暑假实习该往哪个方向走又恰好对企业的真实业务运转感兴趣不妨考虑一下ERP二次开发这条线——它可能不会让你一夜之间变成技术明星但会让你对软件怎么真正在企业里跑起来这件事有远比同龄人扎实的理解。