技术篇

进入公司后，导师交代了使用ShardingSphere进行数据分片和数据迁移，并产出相关的技术文档的任务。关于这个技术，感兴趣的同学可以看我的博客或者百度。在学习ShardingSphere的过程中，收获了很多，具体收获有如下几点：

1. 对技术要求的严格把控

在公司中引入一门新的技术栈，要么是作为实验性的试点，要么是最终一定要应用到线上的生产中。对于前者实验性的试点，公司目前正在测试的是前端的跨平台技术。后者则是目前自己做的数据分片和数据迁移。技术一旦要应用到生产环境中，就需要考虑到性能、高可用、扩展性、维护成本以及与公司现有技术栈的契合程度。这些问题没有考虑清楚，盲目引进新的技术，一定是要付出成本的。比如：公司现在的技术栈是Go，而ShardingSphere是Java生态的，公司不可能为了进入ShardingSphere而大规模引入Java的组件，比如集群节点间的协调服务ZooKeepere，而是尽可能地用公司现有的技术栈去进行等价地代替，选用Etcd。这也是为什么有些公司会对一些开源项目进行改造，使之更加契合公司的实际场景。比如：得物根据自身的需要，将ShardingSphere改造成彩虹桥，扩展原有组件的能力。要学会用别人的代码和改造别人的代码，解决自己的问题。

2.解决问题C之前，需要解决问题A、B

在公司需要写日报，总结今日，计划明日。工作第一天熟悉了一下Mac，看了ShardingSphere的官方文档，就计划着明天要将Sharding运行起来，并进行一些实操。结果第二天在自己的服务器上运行Sharding的时候，因为内存不足运行不起来。跟导师要了公司的服务器，结果导师给了个Kuboard平台的账号（K8S的可视界面），让我在Kuboard上面运行部署。之后自己就需要Kuboard基本操作，了解了K8S的一些基本概念，花费了两天。后面还有为了支持Sharding连接数据库，编写Dockerfile文件，将jar包加入到自己制作的镜像中，将制作镜像上传到DockerHub，在从DockerHub中拉取到公司的集群中，等到真正运行连接起来，就已经是4天后了。对于一个新手，刚刚进入一个新领域，未知太多，难以准确地进行计划，常常是我们解决了一个问题，后面又有一大堆问题，像冰糖葫芦一样，等着你吃。没办法，慢慢吃吧，又酸又甜。

认知篇

1.要学会及时求助，向导师、同龄人、陌生人，向能够帮助你的人

大家都知道这个道理，我也知道，但是当你真正需要向他人求助的时候，却有时会显得犹豫，尤其是在一些特定的场景下。比如向你的同龄人就自己最近遭遇的问题寻求帮助、四顾无人，让一个不太相熟的人帮你写材料等等。一个人之所以对求助感到为难有以下几点原因：（欢迎补充，这也可以算做是我的求助，帮助我完善这个观点）

一、好胜心作祟，总是想要在所有方面都胜过其他人。所以，把向他人寻求帮助视作展示自己的脆弱，所以开不了这个嘴。

二、对自己不自信，对自己未来的预期没有掌控感。总是感觉像其他人求助了，就好像欠了人情一样，自己承担不起，还不起。

三、没有真正解决过超出自己能力的困难。解决一个真正的大问题，是需要借助各方力量的，这些力量来自政府、商业伙伴、家人等等。没有这样的经历，一个人对于求助的认知就难免停留在自己的经验主义上，顾影自怜了。

四、把求助和自己能力不行的概念搞混了。每个人向上成长都会遇到问题，新手有新手的问题，高手有高手的问题，解决这些问题或多或少都需要其他人的帮助，所以，并不是你能力不行。

当然，求助的方式也有很多不同，比如：向他人请教自己的计划是否可行（因）、让他人帮助自己收拾烂摊子（果）。

汉典示意|普遍的行为

2.我们需要管理的不是时间和任务，而是自己和目标

由于公司11点上班，20点下班，这就导致我上午8点到10半之间是有一大段空白时间的。这段时间是比较宝贵的，不能浪费。所以比较自然地给自己制定了一些任务，但总是有些拖拉，要么睡过头，要么不是很想要做这些任务。后来仔细想了想，这段时间起床，坐在桌子前不是关键，关键的是这段时间也想要做什么？想要利用这段时间和精力换到一个什么样的结果？以及你是否有动力做？离开了小组的环境，会面临之前忽视的一些挑战，你成长的原动力是什么？你认知到的你和当下真实表现的你是否一致？