小胡站长 字节实习经验分享
在字节实习也一个月半了，收获还是蛮大的，相比以前自学，眼界开拓了很多，最主要的是我对学习一件新事物有了更好地理解。周五的时候突然有了灵感，就很神奇的想通了一些事，趁热总结分享一下子~ ，同时也是应 @Carl哥的邀请分享一些自己的总结。
另外，不知道大家对在字节的工作环境和资源有没有兴趣，有的话，我下回也分享一篇。
这篇文章的比较长，我先概述一下主题: （ps：①和②是相辅相成的）
① 时刻别忘记自己因为什么而出发，在每一个小的阶段这是十分重要的，因为我们是很容易陷入到一些细节里的，如果在细节里没有确认好自己的方向，是很容易迷失的，导致最后一天很忙，却没有收获到自己想要的，得不偿失！
② 如何快速理解一个全新的大的项目？
① 最主要的思想是：
每天留给自己一些安静思考的时间，来及时确保自己是否在正确的道路上行驶。
多问自己为什么做着这件事？及时调整计划走向。
这两点总结其实都是在强调多思考，我在最近几天回顾了我从高中到大三的学习历程，我发现我几乎都有在思考上偷懒的习惯，以前高中的时候我的借口是：“老师说了不会考的”，“这种题考得概率低，不做也没事”。我现在回忆起来，才发现那是我成绩当时一直不能提升到优秀的主要原因。我总是在大概率出的题上做重复性的操作，其实我并不是觉得他概率高才刷，更多地是我觉得顺手，反馈及时（所谓的舒适区）。但是我没有去思考其中的本质，没有去抽象总结出这类题的特征，更多地是靠的熟练度，还陷入每天十分忙碌的“努力”中，因此丧失了学习别的题的时间和精力，分数得不到提升。
现在的话，其实和当时也类似，虽然没有纸面上的考点，但是我在面对一个新的大项目的时候也一样在做很多无用（重复）的事，那么什么是无用（重复）的事呢？
我列举一些我遇到的我认为做过的无用的事。
下面我分享两个我的个人例子：
我现在在公司的工作是 搞懂小组自研的一套 RTC 协议，并对这个协议补充单元测试。
一些前置背景：
这套协议是音视频相关的，我音视频0基础，但我对音视频蛮感兴趣的；
这套协议写了4年了，经历过许多改写，并且文档不是很齐全，我找了很久才从同事那问到 类图 和 数据流图，并且不全；
这套协议是C++写的，我的C++基础是足够的，甚至在新特性上，我可能理解地更多（这不一定是好事，因为会让我想去优化细节，而脱离音视频主线），我也网络基础也是足够的；
我几乎没有写过单元测试，我 CMake 使用不熟悉，这套协议是跨平台的，我Android 和 WIndows 也不算很熟。
那么我是怎么面对这个需求的呢？
在接到这个需求一个星期后，我才跑通 Windows 的 demo。（文档真得不全，Windows环境很烦人）
学了一个星期 google test，输出文档与 demo
在写单元测试的时候，有一个变量不理解，然后我就去看整体架构，然后发现架构中的A不理解，我就去学A，然后A里面的 Ax 不理解，我就去学Ax，然后….. 一天，甚至几天就过去了。后来我才想起来，我只是想知道那个变量是从哪里来的。
那么我分析 A 的那一套流程有没有带来实际的价值呢？答案是没有：因为分析到最后我分析不出来，我最后卡主了，然后卡主了就在那研究，最后就只记得卡主的那个地方，已经完全偏离主线了。
- 中间也一直在学音视频，断断续续，其实我不知道该怎么学，一直没有主线，东跑一下，西跑一下，我一直没有找到我应该做什么。在这段时间中，我每天都挺忙，都在不停的学，但是没有多少思考这东西是不是我应该学的，或者是不是我想要的，其实我都没有搞清楚是不是？就一直搁那所谓的努力了，这看起来挺有成果，实际上：没有抓住主线的学习，最后只会收获一堆杂乱的知识，它们是无序的，难以相辅相成的，最后还是得重复学习这些知识。（如果这个过程还没有做过笔记的话，重复学习的代价会更大。）
更好的做法：
其实上面花费的时间在一个没有良好培养方案的小组来说，对于实习生应该是必然的。
但如果我当时能问一下 mentor （并多问问别的同事）这套协议到底是什么？需要什么知识？应该学什么？然后再梳理出主线。然后再顺着主线找学习方案，制定学习计划，如果可以的话，可以把这份计划给 mentor 或者 同事看看，确保一下自己的方向可行性和正确性，然后再开始努力。这个时候开始的学习就是有目标的，而不是学一个抽象的概念（音视频），这样学起来会更有动力，同时知识也是连贯的，可以相辅相成，进步很快。
我是大概3周后才知道这是 RTC 相关的知识，才找到主线，白白浪费了宝贵的学习音视频的时间。导致我多次重复学习音视频中大部分相同的内容，在这个新计划是是可以减少很多的。
那么在平常生活中应该如何做到确保方向正确呢？
我的方案是：（其实1，2 和 tdd 有些类似）
阶段性地询问自己，为什么现在在做这件事？做这件事的意义是什么？
根据上一步的结果进行计划的调整。
每天留给自己一些时间思考自己这一天做的怎么样，最好是用自己的话把那些做的事，学到的东西讲一遍（就像老师传授知识给学生一样，自己既是学生，也是老师。）
② 如何快速理解一个全新的大项目？
其实一开始我是比较自信的，因为我觉得我看过一些 Linux 源码，也能弄懂 muduo，我以为我那些经验能让我马上弄懂这个项目。但是我忽略了一点重点，我以前看 Linux、muduo 源码都是有很好的文档的，其实并不是我自己去分析代码，而是看了一遍别人的分析之后理解起来当然快，但是这次是没有这么全的文档的，也不会有人带着我分析。
那么这个情况我一开始是怎么做的呢？
我一直在找数据流图，一直在找类图，因为我坚信直接看代码我不可能看得懂。但是迫于无所事事的压力和自己小小的自信，我还是去看了一部分源码，果不其然没有什么收效。
找到数据流图 和 类图了，我就开始想设计思想了，我想自底向上分模块击破。但是为了搞懂思想我陷入了细节当中，面对一堆 magic number 、继承体系和异步，每一个细节都是难以攻破的。占用了很多时间，而且我没有梳理出有用的东西。
最后一个阶段，我开始想尝试通过调试 demo 来运行项目，但是写过多线程代码的同学是理解的，这种调试痛不欲生，4个线程，一堆 callback，经常不知道跑到哪里去了。
更好的方法是：
从最高的抽象层级开始挖掘项目本质，先从高的抽象层级击破它。举一个例子，一个 RTC 协议，那就先明白
RTC 是什么？
RTC 是实时音视频协议
什么是实时音视频协议？
就是延时 < 400ms 传输音视频包的协议。
到这我就明白了，它是一个应用层传输协议。
诶？ 这会不会 和 HTTP ，FTP 这些协议类似？
了解之后发现是类似的，那么也就是说 是封装了 TCP 或者 UDP 做传输咯。
- 用以前自己熟悉的项目区类比
分析到这，我就开始用分析 HTTP 和 FTP 去做相同的应用层功能分析，到此，我了解这个协议的功能。
然后我开始细化，我发现了很多回调和 select，我在哪里学过回调？Linux kernel 和 muduo ，我开始用分析 muduo 回调的方式来分析 这里面的回调，我发现都是 这种 buffer 的形式，很类似。我开始了解了这个项目的工作流程。
- 多问同事，特别是 owner 或者是正在维护的同事。
在上述分析过程中，并不是像写这么几行文字那么容易的，中间我去问了 4年前写这个项目的 owner，和他确定了项目思想，然后细节问题，我就问正在维护这个项目的人，这样才能理解地更快。
-
最后就是及时去学习 类似的、资源更多的项目，比如我这里是写 RTC，那么我就去学了 RTC 的祖宗：WebRTC，发现有很多类似点，也对理解会有帮助。
-
TODO ：分析出线程模型，接收和发送的流程。
小总结
在公司和学校的方式真得有所不同：
在公司要为业务（OKR）付出一些时间，最主要的是有了一些紧迫感，这些紧迫感无形地压迫了我思考的能力，让我思考的时间减少了，这样容易陷入盲目。
另外就是会比较累，想保持持续学习，需要更加坚定的意志力，和坚定的目标~
不过对于我来说，大公司的资源真得比我原来那个学校好太多太多了。（多到都可以新写一篇文章来说明了）
最后就是一句经典的话：学而不思则罔，思而不学则殆！
更多面试题库下载地址
