已经来公司实习一个多月了，趁着最近要准备闪光课题（准备一个类似于转正答辩那样形式的分享会，会有同学和导师在下面围观）
来总结一下我一个多月来在公司收获到的东西和心路历程。
刚来的时候我觉得数据科学应用中心应该很高大上，因为我对数据科学知之甚少，所以为它蒙上了一层神秘感。在后来的实习中逐渐深入一点点地揭开了数据中台的面纱。
入职的后的两周内，基本上就是在熟悉项目，导师给了我数据工作台和调度运维中心的代码权限，根据熟悉项目的步骤，第一步不是上来直接看代码，而是去了解项目是干什么的，数据工作台是一个给数据开发人员和数据分析人员这种专业人士使用的项目，比一般toC的项目理解起来更加有难度，我看了好几遍内部的使用说明，还有业界标杆阿里云dataworks的介绍，然后又对着接口文档把项目里的大部分接口过了一遍，终于了解了数据中台的一些工作流程，了解了数据集成是干嘛的，数据研发任务又是干嘛的......
在把业务流程熟悉的差不多之后，我开始跟导师索要一些开发的小任务，想在开发中进一步的深入学习项目。
一开始的话就是一些搬运和梳理改造的任务，印象比较深刻的就是运维中心保存调度任务的接口，这个接口的话可以说是整个调度运维中心的核心接口之一，搞明白了这个接口，也就明白了配置调度任务的逻辑。而整个运维中心就是为调度任务服务的，这是一个比较复杂的接口，因为保存调度任务需要很多参数配置的合法性校验，比如有没有父任务，任务类型和调度时间间隔是否符合逻辑，有父任务的话父任务合不合法等等很多校验，原先的接口看起来很混乱，我猜测也是因为这个接口可能是经过多个人多次修补之后变成这样，比如说把一些与数据库没有交互的校验放在了一些与数据库有复杂交互的校验的后面，这样无疑是在一些场景下给数据库增加了不必要的开销，但我觉得最大的问题还是这个接口的可读性已经变的很差，整体看起来逻辑很零散，所以我按照自己容易理解的方式调整了一些顺序，我把它分成了三块逻辑，第一块是对入参的合法性校验，如果入参不符合规则，则尽早抛出错误信息给用户。第二块是对父任务的校验，因为父任务的合法性校验涉及到数据库的交互，所以我把它放在第二步，父任务中的校验中也有顺序，先去校验父任务是不是自己，再校验父任务是否存在或者失效，再去校验任务有没有发生闭环现象，然后再根据任务类型校验父任务的任务类型和时间规则是否和子任务相匹配。第三块逻辑是把修改或者插入任务，附带地会修改或者插入任务关系表和告警配置表。这样改写之后，我觉得逻辑就变的清晰很多，因为接口逻辑比较复杂，所以我改这个接口必须很小心翼翼，改写它加上调试测试就花了几天时间，并且中间也顺便发现了一个小bug并且给sql做了防注入处理。
在搬运加工了几个接口之后，我终于开始了我的第一个需求，就是给数据质量平台的规则界面前端可以显示子规则的强弱，并且，还要可以按照子规则的强弱进行条件筛选，这个需求就在原来的查询任务规则的接口上改就可以了，一个规则可以对应好几个子规则，子规则的信息在另外一张表里面用一个规则id和规则进行关联。直接做一个连表查询是一种工作量比较小的方法，但是这个连表查询也并不简单，当没有规则强弱条件查询时，就直接把子规则并到一排上再和原来的表左连接，当有规则条件查询的时候，要先进行一个自连接选出所有目标规则id，再去内连接，显示出这些目标规则的所有需要信息。第一次写这么复杂的sql，不过还好是磕磕绊绊最终写出来了。
其实在公司里，领导也还是会关心实习生的，比如领导觉得我这几周干的东西都比较琐碎，并且看到我在公司编写代码的时间并不多，这样的话一来不利于我之后的转正答辩，二来到了公司实习自己也得要学到一点东西，于是就开始给我一些参与感比较强的工作，比如我之前的文章中提到了权限控制，这个接口应该也是很重要的一个接口，所有的菜单和按钮都会受到这个接口返回的接口去做权限控制，所以这个接口设计的好不好很重要，如果设计的不好，所有按钮点下来都卡卡的非常影响整个平台的用户体验，刚写出来的时候性能并不好，接口响应时间太长，以至于根本没法用，刚进去直接首页菜单都加载不出来，不过好在之后不断地对接口的优化，并且进行缓存化改造，到后面性能已经可以接受了。之后还让我自己设计了一个切面，用来记录用户的操作记录，并且也可以直接当日志用，后面又给它增加了requestId，方便查询整个调用链路。
在实习过程中，导师和同事们也给了我非常多的编码建议，比如说使用设计模式，项目中我就发现了大量地使用了策略模式可以适配多套环境。最近项目组里一直在忙项目的外部科技输出，所以现在还没有一些成体系的模块去给我做，等这个项目结束了之后，领导说应该要进行进一步地微服务拆分，我比较期待之后能够在我们项目组学到更多东西。
