Java 后台开发实习经历

不知不觉已经实习有一段时间了,主管让我自己先想想成长计划。索性就把这几天实习的经历整理记录下来。

2019.03.27(day1)

  1. 入职培训
  2. 申请各种公司账号
  3. 认识同事
  4. 配置IDEA环境
  5. 在禅道上拆解任务
  6. 学习状态机
  7. 学习观察者模式
  8. 学习UML
  9. 学习事件驱动

day1学习笔记

在禅道上拆解任务

在禅道上新建任务,估计任务完成的时长、优先级,完成之后做好记录。每天晨会要报告自己昨天做了什么,今天预计做什么。

状态机

在学校学了编译原理之后,觉得状态机原理跟自动机差不多啊,学起来也很快。看一两篇文章就弄懂了。基本就是,在当前状态下,满足一定条件或完成什么动作之后,就可以进入下一状态。

观察者模式

之前二面被面试官问到设计模式的时候,真的是一脸懵逼。于是回去后趁热打铁学了一下单例模式、工厂模式、适配器模式,不得不说这对我学习观察者模式帮助很大。看几篇博客之后就差不多理解了。
被观察者和观察者是一对多的关系。观察者会维持一个被观察者列表(一般用 list 实现),观察者把自己注册到该列表中。当被观察者状态发生改变之后,会主动通知列表中的观察者更改后的状态。

UML

就是制图语言,学起来挺快的,用几次就得心应手了。不过UML对于设计和看懂别人的设计帮助真的很大。

事件驱动

学习这个源于指引人给布置的一个小任务,实现事件驱动异步全量加载数据到缓存中。事件驱动?异步?全量?缓存?单看我都懂,不过揉在一起是个什么东西(?_?)。于是心虚地向指引人请教。指引人非常耐心地跟我讲了一下事件驱动,让我去看看安卓的EventBus

然后稍微懂了一下。主要就是维持一个事件队列(可以用阻塞队列实现,这样队列空的时候会自己阻塞),EventBus每消费一个事件,就会把这个事件告诉Controller,由它根据事件类型,发放给不同的模块完成事件。

“事件驱动异步全量加载数据到缓存中”状态图

事件驱动异步全量加载数据到缓存中,就是实现一个以事件驱动的方式,异步加载数据库的数据到缓存中(好像只是做了扩句。。。)
先设想了一下 cache 的状态:int、loading、running
状态转换过程:init状态下,接收到“初始化”事件,切换状态到loading。当数据加载完成后会发送“加载完成”事件到数据总线。在 loading 状态下接收到“加载完成”事件会切换到running 状态并启动定时器,定时发送 reload 事件。在 running 状态下收到 reload 事件会将状态切换到 loading。
在这里插入图片描述

2019.03.28(day2)

  1. 画 “事件驱动异步全量加载数据到缓存中”类图
  2. 画 “事件驱动异步全量加载数据到缓存中”时序图
  3. 编程实现 “事件驱动异步全量加载数据到缓存中”

day2笔记

在设计的时候走了不少的弯路,最后在指引人的耐心指导下,终于完成了。
附上寄几的 GitHub:https://github.com/Xyuping/Design-Pattern/tree/master/观察者模式/事件驱动异步全量加载数据到缓存中

2019.03.30(day3)

  1. 编程实现“事件驱动异步全量加载数据到缓存中”交给指引人审核
  2. 学习单元测试

day3笔记

上午先把代码给指引人看了,修改了一些小地方。
下午开始学习单元测试。稍微看了看白盒、黑盒测试。重点学习单元测试的 Junit。
附上寄几的 GitHub:https://github.com/Xyuping/Notes/blob/master/单元测试.md

2019.04.03(day4)

  1. 继续学习Junit
  2. 广告业务流学习
  3. ACM流程图

day4笔记

广告业务流

由于指引人清明要去旅游,赶紧揪住他问了下一个任务。然后他讲了一下公司的广告业务流程,主要的架构,各个架构之间的关系。(据说这个架构理论上可以应用于各种交易场景,不明觉厉)

ACM(Account Manager)

账号管理

管理账号的认证方式以及密码

认证管理

提供统一的账号认证。支持单点登录。

一开始连单点登录是什么都不知道的我,在小伙伴的帮助下,去了解了一下CAS,(在这里要感谢学校开了密码学的课,对于认证这些还是懂一些的)。总算能稍微看懂指引人还没完成的设计了。

2019.04.09(day5)

  1. 看ACM类图并修改

day5笔记

之前看时序图的时候有个小疑惑,在CAS的设计中,用户访问服务A的时候,如果没有认证,A直接重定向到CA。而指引人的设计,还多了一个W eb-1。当时不晓得为什么要这么做。后来问了他才知道是为了实现前后端的分离。

因为只做过 servlet+jsp 的项目,对于前后端分离并不了解。原来现在的页面主要是浏览器来渲染,后端只负责把数据给浏览器。所以Web-1只是一个静态页面(html、js…)Web-1Gateway才是后端来处理和返回数据。
(Mark 一下这里,以后还要深入了解一下)

2019.04.10(day6)

  1. 下载安装和配置 gradle
  2. 从 GitLab上克隆项目
  3. 下载etcd-v3.3.12-darwin-amd64
  4. 了解 oapi
  5. 了解Netty

day6笔记

今天主管指派了几个小bug让我改。于是暂时先放下ACM,开始正式深入了解公司的架构。
先是手忙脚乱地配了一波环境。
下载安装 gradle,然后使用 init 脚本让gralde在编译过程中使用私有的maven库 。
在 USER_HOME/.gradle/ directory下创建init.gradle

// init.gradle
 
allprojects {
 
  ext.RepoConfigurator = {
    maven {
      url 'http://xxxx/repository/maven-public/'
    }
    maven {
      url 'http://xxx/nexus/content/groups/public'
    }
  }
   
  buildscript.repositories RepoConfigurator
  repositories RepoConfigurator
}

配置完之后就在GitLab上面克隆项目了。
在IDEA打开项目的时候,发现,项目真的好大啊(@o@)。然后怀着敬畏的心开始追踪代码。
然后看到熟悉的EventBus、Controller,总算找到入手点,没那么慌了。不过还是看得很晕。一个下午只堪堪看懂了初始化阶段。(后来反思了一下,其实初始化在一开始可以直接把它当做黑盒,不必了解的太过深入)。
然后看到Netty 的时候觉得有点眼熟,就顺便去大概了解了一下NIO、Netty
ps:IDEA的快捷键真心好用啊。

2019.04.13(day7)

  1. opai 类图、时序图

day7笔记

今天还是在了解 oapi,不过要有输出。于是觉得画画类图时序图来帮助理解。一开始画类图和时序图的时候,由于画得太细了,导致效率很低,图也非常臃肿。后来在指引人给我大致讲了整个架构,指出重点之后,我再重新画了主要的类图和时序图。
不得不说看别人的代码确实能学到很多,也有很多收获。

  1. 如何把设计模式运用在实际开发中。
    单例模式:用了大量的单例模式,例如 EventBus、Controller、State 等等
    观察者模式:eventbus、controller 等等
    工厂模式:在日志那用到
    适配器模式
  2. 对象复用:减少创建对象的消耗
    在类中维持一个对象池(公共静态的队列),可以把用完的对象reset 之后放进池子里,等下次用的时候直接取出来用。(感觉有点像线程池)
  3. 用好public static final int xxx = 数字;
  4. 实现缓存机制。(把一些结果存到缓存里,查询的时候先看有没有命中缓存,这样可以减少查询数据库的操作。类似于cache 和内存。)
//pool
public class MessageQueue {
	private LinkedBlockingQueue<MessageItem> messageQueue = new LinkedBlockingQueue<>();
	private ConcurrentLinkedQueue<MessageItem> itemPool = new ConcurrentLinkedQueue<>();
	class MessageItem {
    int eventType;
    OAPIParam param;
  }
	public void putMessage(int eventType, OAPIParam param) {
    try {
      MessageItem item = retrieveItem();
      item.eventType = eventType;
      item.param = param;
      messageQueue.put(item);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
public void eventLoop() {
    while (true) {
        MessageItem item = messageQueue.take();
        transaction = Cat.newTransaction("event", EventType.getDescription(item.eventType));
        observer.handle(item.eventType, item.param);
        //put into idle list for reuse
        item.param = null;
        this.itemPool.add(item);
    }
  }
	private MessageItem retrieveItem() {
	    MessageItem item = itemPool.poll();
	    if (null == item) {
	      item = new MessageItem();
	    }
	    return item;
	  }
  }

2019.04.17(day8)

  1. 在oapi 中排查接口 bug
  2. 看DMS代码
  3. 了解Mevan

day8笔记

排查 bug

做测试的时候发现别人已经写好测试了QAQ,所以测试的时候主要就是写了个代码把Juint跑起来看看几个重要函数。

然后启动 etcd,再把别人已经写好的桩启起来,在DMS处debug,运行 oapi。另外装了个 postman 协助测试。
(此处要万分感谢指引人,没怎么看过 mockito 的我对着桩是一脸懵逼的)
经过排查之后发现 oapi 应该是没有问题的。(传到DMS的参数是正确的而且符合协议)
然后就要开始学习DMS了。同样把项目从GitLab上克隆下来。
在DMS目录下运行两个命令

git submodule init
git submodule update

(先 Mark 一下,要抽个时间好好学学 git 才行)
然后开始看代码(据说这个版本还是用状态机实现的旧版本,马上要被替换掉了。。。先用他来熟悉下大体框架emmm)

2019.04.18(day9)

  1. 学习mockito
  2. 学习DMS
  3. 尝试排查 bug

day9笔记

mockito

昨天做测试的时候比较吃力,主要还是对打桩、mockito 这些没什么概念。于是向先把 mockito学一下再开始。主要了解了一下基础的部分。
觉得下面这篇文章写得还不错:https://www.cnblogs.com/wangtj-19/p/5822369.html

DMS

向指引人请教了一些问题。觉得自己看代码看得太慢了,主要还是因为对整个流程的不熟悉,以及弄不清楚各个模块之间的数据边界,有时候容易过于深入,不能把某些部分抽象成黑盒。

排查 bug

本来想直接依葫芦画瓢,直接启别人的桩。不过指引人的建议是先追踪代码,看看哪里容易出现问题,单独排查。虽然有点懵,不过接下来要好好学学测试了。

终于打完了。。。以后再回来完善一下叭。。。
现在要去好好思考接下来的成长计划了。
每天都要加油鸭~

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页