记自己在用友的三个月实习经历 (1)
当初第一次收到面试通知，真的很紧张，进群之后就通知了明天下午进行所有人的视频面试，所以第二天从早上 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 培训，这个培训的目的只是教会我们使用用友公司的几个低代码开发工具，这个所谓的低代码工具，就是直接新建一个项目，然后一个完整的前后端公司财务系统就生成出来了，这个系统要是去做的话，大概也要花费几个月的时间，刚开始听到这觉得这个东西超牛逼，并且决定一定要学会怎么样，原理是怎样的
从那天起，培训室里就充斥着各种哀嚎，什么破解失效啊，生成报表失败，各种一堆看不懂的错误，我从一开始遇到问题的害怕，到暴躁，到最后的一笑而过，逐渐懂得了一个道理，逃跑虽然可耻，但却有用，只要我当作看不到，这个问题就没有出现过
对于当时的经历，我也知道了低代码的优点在于自动生成，缺点也在于自动生成，过度的封装所有东西，会让使用者根本不知道问题所在，培训完我就立刻把低代码的工具全部删掉了，还是那句话，逃跑虽然可耻，但却有用[旺柴]
培训完后就跟着导师去了客户那边驻场开发，然后一直到现在，办公的地点都在同一个地方
暑假期间，每天从嘉禾望岗挤着死亡三号线到客村地铁站，天天都能体会从地狱中（嘉禾望岗）回到天堂（珠江新城）的感觉
在那里我第一次接触大型公司项目，该项目就是一个电商系统，分了 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 语句还是产品经理教我写的??
最终还是由于自己的职业规划没有留在用友（当然有一方面的原因是因为用友给的真是太少了！！！）。
学到的最重要的东西还是对项目的整体把控、架构的理解，我个人觉得，这也是为什么一些程序员做了一辈子还是只能 CRUD 的其中一个原因，记得当初项目组来了一个后端正编，一开始让它来对接一下接口，渲染一下数据，后来他以没弄过，原来的公司都有专门的前端为借口不接这个需求，后面让导师让他去搭建技术中台，他以公司有专门的运维为借口又不接，最后就被炒了，估计他在上家公司呆不下去是因为有个专门的后端来代替他了。。。。。。
评论