记自己在用友的三个月实习经历

大二下学期的求职
用友的面试通知
报道与NCC培训
驻场开发
- 第一个接口
- 前端需求
- 数据库版本工具开发
回顾与展望

博主只是一个双非且非科班的一个小Java后端开发，这篇文章总结一下自己在用友的三个月实习经历（用友广东分公司）

大二下学期的求职

本着给自己找一段实习经历填充一下自己的简历，大二下学期刚开始的时候就在边做项目边复习了，那时候在做工作室的一个社交活动类的小程序，并且在主要复习着MySQL与Redis两个数据库和一些Java基础，那段时间的复习是通过看书来复习的，并且我也开始写博客记录一下自己的读书笔记

Java
- Java核心技术卷
MySQl
- 《MySQL技术内幕》
- 《Innodb技术内幕》
Redis
- 《Redis设计与实现》

从四月份开始准备简历，六月份开始投递简历，在BOSS直聘上沟通、投递过71家公司，但仅仅有10家给了笔试或者面试的机会，其余60家要么就石沉大海、要么就只考虑应届生、还有的要长期实习半年以上的（我当时只想要段经历来填充简历，并不打算长期实习）

用友的面试通知

最后得到了用友HR的面试通知

当初第一次收到面试通知，真的很紧张，进群之后就通知了明天下午进行所有人的视频面试，所以第二天从早上7点到下午的5点都在看自己近段时间写的博客日记，Redis数据结构的源码、Innodb引擎的底层、Java各种容器和锁，甚至忘记了自己下午还有一节微机实验课（幸好好舍友帮我签到了）

当开始第一个人面试的时候，我才知道每个人大概只有15分钟左右，而我是倒数第二个，看着前面那些甚至10分钟都不到的人出来，感觉越来越紧张，后面等我出来的时候我人都有点傻了，问的东西真的基础的不能基础了，整体的流程如下

自我介绍
你项目使用Redis做了什么（存储点赞了，定时任务刷新进库存，实现模块之间的通信，框架模块使用Shiro进行登录验证，存储信息进Redis，然后在接口模块取出信息封装在JWT里面）
技术问题
- 双等号与equal的区别（双等号对于基本数据类型比较值，对于引用类型比较对象地址，即判断是不是同一个对象，equal方法是Object的方法，每个类都继承了Object，所以都拥有equal方法，如果不进行重写，本质上与双等于号没有区别，重写的话想怎样比较就比较）
- StringBuffer与StringBuilder的区别（从源码上讲解，从AbstractStringBuilder开始分析起，引出本质上只有方法上加了Synchronic的区别）
- SpringBoot使用什么注解来接受前端参数。。。。（@RequestBody，@RequestParam，@PathVariable）
后面面试官问我SpringMVC的问题，我及时打断还没有对SpringMVC进行源码学习
最后问了点职业规划
反问：实习生有没有Coding的机会，面试整体表现如何，哪些不足之处，都是一些客套的问题

整个流程下来后，我都不知道我前面复习那么多的源码是为了什么。。。。。。

最后，也拿到了用友的实习offer

报道与NCC培训

第一天的报道，签了合同之后就只是简单参观了一下公司

不知道是倒霉还是幸运，这段时间进来的实习生都要参加NCC培训，这个培训的目的只是教会我们使用用友公司的几个低代码开发工具，这个所谓的低代码工具，就是直接新建一个项目，然后一个完整的前后端公司财务系统就生成出来了，这个系统要是去做的话，大概也要花费几个月的时间，刚开始听到这觉得这个东西超牛逼，并且决定一定要学会怎么样，原理是怎样的

从那天起，培训室里就充斥着各种哀嚎，什么破解失效啊，生成报表失败，各种一堆看不懂的错误，我从一开始遇到问题的害怕，到暴躁，到最后的一笑而过，逐渐懂得了一个道理，逃跑虽然可耻，但却有用，只要我当作看不到，这个问题就没有出现过

对于当时的经历，我也知道了低代码的优点在于自动生成，缺点也在于自动生成，过度的封装所有东西，会让使用者根本不知道问题所在，培训完我就立刻把低代码的工具全部删掉了，还是那句话，逃跑虽然可耻，但却有用[旺柴]

驻场开发

培训完后就跟着导师去了客户那边驻场开发，然后一直到现在，办公的地点都在同一个地方

暑假期间，每天从嘉禾望岗挤着死亡三号线到客村地铁站，天天都能体会从地狱中（嘉禾望岗）回到天堂（珠江新城）的感觉

在那里我第一次接触大型公司项目，该项目就是一个电商系统，分了15个模块，并且分了三套环境（测试、预热、正式），而我们的工作就是对这个项目进行二开

第一天就是在搭建环境，那时候我还不知道为什么导师要给我maven仓库依赖，maven仓库依赖直接下载不就好了吗？这个问题也导致了我一天都搭建不起来项目的原因，最后被导师反问为什么不用给我的仓库，看到里面的一些客开依赖，我当场裂开。。。。。。

接下来的工作就是越改越多的BUG，天天都在解决问题清单上的各种问题，什么二级价差报错、工程门户报错、单据模板报错

第一个接口

大概一个星期后，导师给我分配了第一个开发需求，开发一个跨模块调用的接口，功能是判断用户权限的

当时第一次感受了SpringCloud微服务的通信功能，并且也写下了自己的第一份开发文档（后面来的实习生基本都是看我的文档开发的，然后出现一些我都没看过的BUG，2333333），后面也出了几份的开发文档记录，搭建Redis监控、补丁的规范、数据库版本工具（后面自己开发的一个工具）的使用等。。

并且出了自己的第一份补丁（项目采用打补丁的方式来添加功能），并且成功与前端对接

前端需求

当时前端的负责人仅仅只有一个，而且还是实习生，后面我就被导师去安排弄前端的需求了，当时花了两天的时间学习了一下React基础，然后就开始倒弄前端了，好在页面是有的复制重用的，不用去切图话页面，只要进行数据渲染就可以了，一开始听到导师跟我说这个的时候，我也信以为真，事实证明，导师也没有骗我，的确有页面可以重用，的确只要进行数据渲染就可以了，但却没跟我说那个页面有4000多行代码，里面还引用了各种组件，加起来大概1W多行，看的我头皮发麻，并且一开始弄根本不知道前端怎么发请求的、怎么将数据存储进props那里去取的，那时候天天都与前端的实习生（他也没学过React）一直在边学边做

慢慢地，弄懂了React的生命周期、React使用promise去发请求，组件的props与model关系，弄懂了这些之后，页面也渲染了大部分了，并且由于model的问题，导致数据放的很乱，当初就应该直接新建一个model然后将所有数据都放进去的，不过最后还是把需求做了出来，并且已经上线运行了

弄完这个需求之后，来到用友就不分什么前后端了，大家统一叫开发，也是从这里开始，我感觉慢慢开始掌控整个项目了，经过了整个需求的开发，前端的请求，后端处理参数，规则调度链的启动，慢慢知道了整个项目的底层如何运转的，我这里指的不是使用的框架与技术，而是项目的整体架构，框架与技术说白了只是一个工具，项目的整体架构才是核心所在，懂得框架与技术的不一定可以架构出项目；但懂得架构项目的人，一定认识实现这个架构所用的框架与技术

也是从这里，我知道了去认识一个项目，重要的是掌控他，看清它的架构，而不是因为自己的岗位是一个后端开发而只去管理后端的东西，对前端或者服务器上的事情而毫不关心，用着有专门的前端、专门的运维去管的借口来逃避开发与不想去解决问题

数据库版本工具开发

完成了那个项目之后，导师就分配了一个项目让我单独进行后端开发，前端由那个会前端的实习生开发，后来那个实习生走了，前端就也交给我开发了，然后就过着早上上班写了5个接口，中午休息完后自己对接自己写的接口的生活。。。。。

先说明一下这个工具的用途，这个工具是针对数据库的补丁的，比如项目添加新的需求需要去扩展已有的表，或者修改数据库的什么数据，是使用PHP形式打上去的，不方便管理，所以客户那边就提出了开发一个数据库版本工具，使用这个工具来进行数据库脚本的执行，并且记录脚本的报错情况

我三个月的实现，大概在这里花了一个大半月，从整体的架构，到实现，到版本1的出现，到版本1的推翻，到再重新架构，到版本2的出现，再到版本2的推翻，最终出来了版本3，整整花了差不多两个月

版本1：全局只有一个数据源，使用单例模式实现，谁连接了就可以使用，限定死了只能连接一个环境的数据库，保证了执行脚本的有序、安全，用Redis做了个简单的消息队列，本来的做法是开启后台线程去给其他环境同步更新脚本的，但发现这样做可能会导致产生的线程过多（虽然实际情况肯定不会是很多），所以使用了一个简单的消息队列，同步上传的工作都只交给了一个线程去做（这里其实我考虑并不妥当，因为如果上传脚本不频繁，一直维护这个线程可能会比上传的时候开启线程要更加消耗性能），最终被导师推翻，因为只有一个数据源，不能操作无关的数据库

版本2：不再只有一个数据源，解除了单例模式，参考Redisson设置了一把锁，一把简单的锁，对数据源进行上锁，并且是使用SessionID去标识获取锁，谁获取了锁，谁就可以对这个数据源进行操控，并且简单设置了一个锁续命的机制，跟JWT过期续命机制差不多，当过期时间仅剩5分钟，并且还在操作，就延长到10分钟，并且前端使用了钩子函数，当刷新了页面之后，并且关闭浏览器之后，，最终被项目经理推翻，因为三个环境的脚本是记录在一个与业务环境无关的数据库中，那么如果产生了测试、预热或者生产数据库覆盖是无法进行追踪的，也就是说，你使用了这个环境执行了脚本并且记录了下来，后来偷偷摸摸地把数据库整个覆盖了，我这里显示的记录还是已执行

版本3：在版本2的基础上，取消了将指向脚本、上传脚本的记录保存在指定的数据库（但保存了数据源表，即数据源表还在原来与业务无关的数据库，因为里面是保存的是数据源的信息），而是改成了当新建数据源的时候就给当前的数据源创建一张表，该数据源的所有脚本执行都记录在新创建的表中，那么当这个数据源覆盖的时候也会把那张表覆盖了，这样就能追踪到数据源自身发生了覆盖处理，并且覆盖了之后，脚本执行记录也跟着覆盖了过来，并且保留了正确的脚本执行情况，但这样做就会出现很多繁琐的操作，比如你对脚本进行查询、处理的那些接口，都要首先去判断当前数据库有没有那张表（可以使用拦截器进行改良，即关于脚本操作的接口，都首先要判断数据源的表是否被数据库覆盖冲掉了），而且比较难的一些点就是怎么用原生的hibernate了，比如动态查询。。。。。。。。

第一次一个人架构整个项目，体验了与导师、产品经理的idea碰撞，所幸遇到了一个好的产品经理，需求的提出都是基于自己看到过的，自己分析过能否实现的，仍然记得我写的一个接口的SQL语句还是产品经理教我写的