从3月27号入职到8月10号离职总共实习了137天，这是我的第一次实习，刚入职的时候想着自己要把每天做的事情记录下来，但慢慢发现很多时候一天做的事情其实很少，有些时候可能产品评了新的需求、和前端对了接口、和组内人员沟通好了彼此设计的交叉部分、和测试评了测试文档，但是很多时候也可能就改了一下bug，详细设计做了一半、环境出现了问题排查问题，修复，部署，很多时候一天甚至完不成一件完整的事情，后来我决定在一个需求结束的时候来一个总结，但最终我没能坚持下来，现在整个实习结束了总该对这一段时间做一下总结。
实习收获
在公司开发和以前在学校里开发个人项目的区别是很大的，我最开始的时候的时候很不适应效率很低，但随着慢慢从0到1开发完一个接口，后来慢慢适应了这种团队开发的模式，我感觉自己的技术得到不小的提升。
- 对业务的层次划分更加清晰。 以前个人项目使用的是mvc架构，自己只需要按照固定的模版controler、service、mapper去写就行了，对层级具体的作用并没有理解，从头到尾一个对象就搞定，完全不需要考虑各层次的职责，也不需要定义vo、dto、modal、do这些具体层次的对象。公司采用的是DDD架构，将一个接口的链路分成了starter、web、biz、core、common等多个层次，每个层次职责清晰，通过这种方式可以降低各层次之间的耦合，使得代码能得到更好的复用，但是这就需要你对整个接口链路的层次有一定的理解了，最基础的，你在使用vo、dto、modal、do这些具体层次的对象对象的时候你需要清楚每个层次能够使用到哪些对象，更深入一点的就是你在定义各层次的接口的时候，你应该明确你这个接口的职责是什么，要让接口的职责更清晰，不要把其他层次负责的事情给做了，这样接口更好复用，可读性也更强。
- 开发规范得到提高。 开发规范不仅仅是代码规范，还包括了MR规范(git)、日志规范、maven配置文件的规范。刚入职的时候给了两个星期的时间天天看文档，其中很大部分的时间就是在学习规范。为什么需要规范呢？第一、在团队协作开发的过程中大家遵守同样的规范能使别人更好读懂你的代码，提高开发效率，第二、遵守规范的代码能避免很多莫名其妙难以排查的问题，比如不要使用魔法值，他能提高可读性，另外如果在发起请求的时候你通过map传参，你的变量名使用魔法值的时候某个字母打错了导致最终接受到不到，我相信这个问题被找出来肯定要耗费不少时间。在这段实习的时间中我的开发规范得到了很大的提升，可以说以前几乎毫无规范可言。
- 线上排查问题的能力提高。 在我实习期间在一个国企的项目里面添加一个入口去调用我们公司的服务，那是我见过最臃肿的项目，里面有好几十个模块，但是80%都是废弃不可用的代码，各种依赖包也早就找不到了，所以在本地不可能跑起来他们的项目，每次写完代码检查没出错之后需要直接部署到服务器上去跑自测，如果出现了问题也只能线上排查，虽然可以使用线上debug来测试，但是这需要对方运维配合，经常找不到他，所以我大部分时间都是通过日志的方式的方式去排查问题，在代码里尽可能的去把日子打得更加详细，最后通过判断代码执行到哪了，请求是什么，响应是什么，各种环境参数是什么...这段经历很心酸，但是线上排查问题的能力也实打实的得到了提升
- 沟通能力得到提升。第一、沟通能力是你能表达清楚你的东西，对于产品、前端、测试、以及组内共同开发的同学等不同的人群表达清楚你的东西，他们所站在的维度不同，你可能表达的方式可能也不太一样。另外沟通能力是你能积极的去沟通进度，确认需求以及和团队内部积极同步问题等，千万不要只按照自己的理解和看法去完成任务，不然你做出来的东西可能前端会不满意让你改，产品会不满意让你改，最后大家都合作不愉快，也千万不要遇到问题卡在那里也不说，非要执着于靠自己把这个问题解决，及时沟通问题，如果别人能帮你拿你更高效，如果因为解决问题耽误了进度也提前说，大家的时间都要协调，不要到了联调时间了你才和前端说你接口没做完，到了测试时间了你才和测试说你功能没实现，到了上线时间了你和你领导说需要delay，这些都是很严重的问题，如果你能提前说大家可以调整计划总比到了计划时间啥也做不了强
总的来说实习的收获还是很大的，从一个毫无章法的计算机学生向专业开发者走进了一步。
实习感受
- 通勤距离一定不能太长。实习期间我住在学校，距离公司30公里，每天上下班都要坐一个半小时的地铁，刚开始的时候充满新鲜感，我每天到公司的时间还能比绝大部分人都要早，后来渐渐的越来越起不来，基本上都是掐点到了，整个上下班的时间的时间太长，刚开始的时候还觉得自己每天在地铁上能看看博客什么的，但是发现每天下班的时候身体有些疲惫，在地铁那种环境下也不太能静下心来学习，另外零散的看一些博客脑子里留不下东西，所以我之后的工作一定不会选择住在通勤超过30分钟的地方了。
- 一定要确认好任务范围。我就踩了一个大坑，领导让我去做基于角色的权限管理这个新需求，这是我第一个负责的需求，也有点紧张没有细问，然后周三下午评完了需求，领导让我下周一就提测，我当时都懵了脑子里就一堆问号？？？我设计开发联调就两天时间？算上周末也才4天，我详细设计完成后和领导说了时间不够，他说那给我延迟一天，周二提测，我当时虽然觉得时间不够，但是这又是我第一个需求我怀疑是不是他们的时间就是这么紧张，不敢多问，最后我周末两天都加班，紧赶慢赶在周三完成了，已经延迟了一天，而且时间太紧张导致我的代码质量也不高，然后领导review了我的代码之后特别生气，让我改，改动很大，几乎把我的代码给废弃掉了，原来是他们原本是有给予角色权限管理的部分内容的，但是角色和权限那些全是从数据库手动加入的，我只需要添加新增修改就行了，还有就是把他们原有的体系看看和新需求有没有什么出入的地方我去修改一下，结果我自己从头到尾做了一套，从web接到到数据库的表全部做了一套，领导让我改的时候我很难过，也很生气，但是后来想想要是早一点把这个任务具体的内容给明确了可能我也不会那么累，做出的结果也更让人满意。
- 多向同事学习。我实习的时候有一些学历不太行，但是技术深度很不错的同事，他们工作多年对于很多框架的思想，源码，对于很多业务的考虑的点更加全面，在工作之余多向他们请教也能提升你的理解与见识，但是你需要首先把你想问的问题表述清楚。
业务总结
基于角色的访问控制（RBAC）
用户-角色-资源项
权限:角色-资源项的关系
需求：
- 用户CURD
- 角色CURD和当前用户的角色
- 资源列表和当前角色的权限
- 每次用户访问接口需要判断用户是否有权限，需要支持状态实时更新（禁用、权限修改）
鉴权思路：
- 在项目启动时读取数据库加载资源列表url(/admin/** , /user/**)
- 在请求到来时将请求path与资源的url匹配，得到needAuthority（如果匹配不上则直接返回没权限(白名单方式)，直接放行（黑名单方式））
- token解析拿到username，通过username获取用户当前的权限（因为需要权限实时更新，直接保存在token中）
- 将用户拥有的权限与需要的权限匹配，只要用户有needAuthority权限中的任意一个则可以放行
门店管理
需求：
B端：
- 门店的增删改查
- 门店关联若干个资源列表、若干个营销素材、详细位置(省市区、详细地址、经纬度)
- 门店手动可以手动关联若干个地铁站、公交站
C端：
- 通过用户的坐标获取最近的站点
- 通过关键字搜索站点
- 获取站点关联的若干个门店
- 门店详情
实现思路：
对于门店关联了多个其他属性
关联关系表：处理所有的关联关系（sourceType，sourceId，TargetType，TargetId）
- 每一个关联属性定一个filter，比如营销素材的filter负责处理营销素材的增删改查
- 定义一个上下文对象使用责任链模式，遍历所有的filter，通过反射判断当前被处理的对象是否有当前filter能够处理的属性，如果有则处理，没有则调用nextFilter
- 对于某些接口可能不需要把关联的属性都查出来，提供needProperites属性，在查询的时候如果当前filter不是needProperites中需要的filter则直接调用在一个filter
多态序列化问题
见我之前的文章：多态序列化问题
性能优化：
接口性能优化思路
- 加了redis缓存，缓存关系+缓存活动单元，我负责缓存关系
- 加了索引，提高缓存未命中时的性能
- 批量查询接口通过批量命令的方式查询redis，增加数据库批量接口，减少网络io，磁盘io的时间
- 接口增加needProperties，只查询需要查询的部分数据，减少网络传输时间
