1、努力提高技术，争取早日实现跳槽自由

2、

3、

弧度的概念是怎么来的：

度的概念才是人为直观区分的，它和一年有365天相关

而弧度才是圆本身的一种度量，它是由圆周率这个概念引申出来的

弧度能带来什么方便呢，最主要的是它是一个数字，可以进入数系计算

4、

编写漂亮的代码。丑陋的代码会隐藏问题，让想要帮助你的人无从下手。

当我们想通过阅读代码的方式来了解一个新的项目时，一般都是采取广度优先的策略，自上而下的阅读代码，先了解整体结构，然后再深入感兴趣的细节。

如果没有对实现细节进行良好的抽象（并凝练出一个名副其实的函数），那么阅读者就容易迷失在细节的汪洋里

有表达力的代码是无需注释的：注释的适当作用在于弥补我们用代码表达意图时遇到的失败，这听起来让人沮丧，但事实确实如此。

我们常说，好的代码需要有可读性、可维护性、可扩展性，好的代码、架构需要不停的重构、迭代，但自动化测试是保证这一切的基础，没有高覆盖率的、自动化的单元测试、回归测试，谁都不敢去修改代码，只能任其腐烂。

5、

6、

IaaS是基础设施即服务，只给客户提供服务器资源，其他的工作客户自己完成，可以理解成一台没有安装操作系统的电脑。通过虚拟化技术，可以让客户想要多少电脑就有多少电脑。

PaaS是平台即服务，给客户提供服务器的基础上把平台搭建好，让客户有个编程环境，可以可以把自己的程序部署上去，可以理解成一台安装了操作系统和数据库的电脑。

SaaS是软件即服务，给客户提供现成的在线软件。相当于一台已经安装了客户要使用的软件的电脑。

能够真正提供稳定IaaS的企业非常少，而且未来会越来越少，马太效应明显。提供IaaS的企业往往也提供PaaS。

从市场规模上看， SaaS﹥IaaS﹥PaaS

云游戏实现的原理是什么呢？

一句话：用宽带（网络）代实体线缆。

平时大家的游戏是存在电脑主机里，主机用线缆和屏幕相连，你才能看到游戏界面。

现在，你的主机变成了某个遥远的数据中心虚拟出的主机里，这台虚拟主机性能极其强劲，而且想要多强就有多强，然后通过宽带（网络）代替线缆把这台云主机和你的屏幕相连接。

只要网速够快，延迟够低，你就愉快地玩耍吧。

5G刚好就能够让网速够快、延迟够低。

7、

你要判断你领导的核心需求是什么（如果判断不出来，就找你的领导去沟通交流，但凡一个正常的领导都会告诉你的）。

你努力的事情能不能满足你的领导的核心需求，为领导创造价值。

如果都不能，就不要抱怨自己干活多，任务重而不受重视了。就多想想这些工作能不能给自己带来提升。

如果也不能，证明你的工作没有任何价值，可有可无，趁早离职才好

8、

链接：https://www.zhihu.com/question/23774081/answer/1191077182

为什么需要数据产品

If you can’t measure it, you can’t improve it（如果你无法衡量，你就无法增长）. 数据驱动增长。

03 如何设计数据产品?

对于产品设计来讲，一些固定的步骤必不可少。厘清这些内容后，大到系统级的产品规划，小到功能级的产品设计，概念上都会清晰很多，我们将它抽象成了五个步骤：

面向什么用户和场景

不同用户有不同的价值。这个方法主要面向第一类即企业内部产品。这里并不主张职位歧视，只是从数据能产生的价值来看，高层的一个正确的决断可以节省下面无数的成本

不同层级用户关心的粒度不一样，永远要提供下一个颗粒度的分析以及可细化到最细粒度的入口。数据分析本质上就是不断细分和追查变化

要了解自己的用户，必须和他们保持长期有效的沟通。如 GrowingIO 的 PM，每周都会有和销售和客户沟通的习惯，而且每位 PM 入职后，必须兼职一段时间的客服

解决什么问题/带来什么价值

首先判断核心需求是什么，可用 Demand/Want/Need 方法分析。用户来找你要可乐 (Demand)，如果你没有可乐就无法满足用户。但其实他只是要解渴 (Want)，需要的只是一杯喝的东西就够了 (Need)。

其次判断需求的价值，可用 PST 方法分析。P：x 轴，用户的痛苦有多大；Y 轴，有多少用户有这种痛苦；z 轴：用户愿意为这付出多少多少成本。相乘得出的结果才是这个需求的价值。

问题的分析思路是什么

需要用到什么样的指标

数据的完备性提前明确所有需要的数据是否已经准备完全。数据就像水面上的冰山，展示出来的只是很小的一部分，它的采集，清洗和聚合才是水面下 98% 的部分。

所以如果需要的数据没有采集或没有经过清洗的话，会让整个工期增加了极大的不稳定因素。

这些指标该怎么组合展现

9、虽然下图不一定是真实的，但是却是符合人的直观认知的