从三月初至今，许多公司开启了实习生招聘工作，但是不少第一次实习的同学有着各种各样的疑问，
同学甲：“目前在小厂实习，工作内容只有CRUD怎么办？要跑路吗？”
同学乙：“目前在小厂实习，工作内容非常繁杂琐碎，觉得没有含金量怎么办？”
同学丙：“目前在大厂实习，工作内容只有CRUD怎么办？”
同学丁：“目前在大厂实习，实习期间做的内容太难了，感觉自己能力跟不上怎么办？”
其实上面的几个问题非常具有代表性，不过在回答这些问题之前，老白需要说明一下，大厂和非大厂的实习同学遇到这种问题的解决办法是不一样的，主要原因还是大厂的技术积累比较深厚（包括技术文档、同事水平等），所以后面会围绕是不是大厂实习进行具体的情况分析~
接下来老白针对这几个问题的共性，和大家分享一些个人的看法和建议，为了防止太抽象，主要都是基于理论+举例子，本篇内容非常值得即将实习或正在实习中的同学三连~（在看+点赞+收藏）
问题一：实习期间做的内容太简单，只有增删改查（CRUD）怎么办？
这个问题首先要按照时间点来说，如果是实习入职第一个月，无论是不是大厂，实习生熟悉了解项目的应该都是从简单的模块做起，比如某个模块的查询接口等等，但如果实习两三个月都一直是重复的CRUD的工作，这时候就需要注意了。
对于大厂同学来说：
如果做了一个月CRUD后还没有做其他的内容，第二个月开始应该有意识的主动询问导师或主管是否有复杂一些的业务或者技术的需求；
如果仍然只能分配到一些比较简单的需求，那么就启动我们的大厂最终方案：
1.看懂同事做的就是自己做的！2.看公司的技术文档（如中间件设计、**问题的解决方案）
听起来很简单，但是这也需要很多技巧，里面的细节很多！下面详细分析一下，都是干货~
1.看懂同事做的就是自己做的
看同事代码，始终牢记一点，这是基于怎样的业务场景去解决怎样的问题？为了解决这个问题用了什么技术？之前是否做过优化？有没有设计模式的良好实践？
然后去看需求的评审文档，看看有没有系统的架构设计、概要设计、详细设计等等，对着业务场景去思考如果自己来写这个需求要如何做？然后再去看同事如何设计方案的。
接下来是非常重点的内容！要将自己想象成面试官，问自己几个问题：这个需求的技术难点是什么？解决***问题，你为什么要这样做？还有优化的方案吗？要知道，即使是同事写的代码，也不一定是最优的方案，这些问题都要学会去思考！
说起来还是比较抽象，举两个简单的例子：
例①：假设同事的功能涉及到多张数据库表的插入操作，比如数据表A的status字段，从状态1变为状态2，然后需要我们同步去更新数据表B的type字段，从true变为false，这时就会涉及到事务的内容。
以Spring的事务为例，那么面试官可能就会问数据库事务和Spring事务的八股文，再深入点就会问事务加在什么位置对性能更好，使用@Transactional注解？使用事务模板？类上？方法上？
例②：假设同事的功能涉及到上下游的交互，即同事负责上游的A业务，A业务会通过消息队列去通知B业务进行某些操作，这种时候很明显就涉及到消息队列的内容，比如如何保证消息可靠？如何保证A业务请求B业务时候的幂等性？如果发生消息堆积你会怎么做？
2.看公司的技术文档
技术文档通常分了两种，一种是框架/中间件的设计文档，一种是部门或小组的技术文档，设计文档也可以结合市面上的开源的框架/中间件的博客文章一起看。
这里老白主要讲讲后者，首先大家一定要了解上下游和系统全链路这个概念，我们看看简单的定义：
假设我们的小组负责A业务，另一个小组负责B业务，还有小组负责C业务，可能就会存在A是B的上游，B是C的上游，即B业务很多编码是为A业务服务的，C业务则是为B服务。这种时候站在面试官的角度，就会考察候选人是否对自己实习的内容有一个整体的宏观理解，即全链路的考察。
模拟几个面试问题，比如：
-
A业务是如何去调用B业务的内容的，RPC还是HTTP？
-
你是否了解B业务是怎么做的呢？如果让你来设计B的那个功能模块，你会怎么做？
如果我们事先对全链路研究过，回答出不错的方案，相信一定能给面试官一个不错的印象！
即使我们不负责B和C业务，没有写过或看过里面的代码，但是同一个部门的不同组，都会有技术设计文档，这就为我们去了解系统全链路提供很大的便利，里面的技术内容和设计就不只是简单的CRUD了，如果感兴趣自然可以深入了解，提高自己的技术理解。
这里还可以扩展到很经典的八股文：用户（客户端）发起请求，你们的浏览器（公司的系统服务端）是如何处理的？假如我们对系统的全链路不熟悉，这里显然无法结合八股回答好这个问题。
大厂技术文档建议观看学习并写进简历的内容：
-
小组线上bug的问题与排查思路
-
sql优化或其他性能优化相关的处理
-
项目架构的设计或重构方案
对于非大厂同学来说：
上面大厂同学的很多内容其实也适用于非大厂的同学，如果技术文档不错，就参考上面大厂实习的方式。
当然如果公司的技术文档不好，框架用的也是开源框架，而不像大厂自研框架，遇到这种情况咱们也别怕，我们同样启动我们的非大厂最终方案：
1.看懂同事做的就是自己做的！2.尽量吃透项目 3.利用空余时间看开源框架的技术设计
下面详细分析一下，都是干货~
1.看懂同事做的就是自己做的
参考大厂的最终方案~
2.尽量吃透项目
如果公司项目比较小型，那就把公司整个项目的运行流程了解清楚，包括业务需求等等；如果公司项目也比较大，那么我们也需要了解清楚上下游和全链路（参考大厂的最终方案~）
3.利用空余时间看开源框架的技术设计
如果公司技术文档很少很乱，那么这个时候最好的方式就是查看开源的技术文档，通常网上会有很多博客解析。
举个例子：如果公司采用RocketMQ，那么我们就需要去了解项目哪部分用到了它，首先去了解清楚RocketMQ的用法，其次再去了解对应的设计原理。很多时候大厂的自研框架其实都是基于开源的框架做一层封装或解决某些不好用的bug，所以会存在很大的相通性，因此学习开源框架的设计可以等价于在大厂看自研框架的设计。
综上，无论大中小厂，实习前期（第一个月）只做CRUD是为了快速熟悉系统和业务，而后若是仍然只有CRUD，那么我们需要主动出击破局，遇事不决就看中间件/框架设计原理和源码，并且要学会从面试官的角度去思考模块的改进和优化方案，小到sql优化，大到系统技术选型优化、代码逻辑优化、设计模式优化等等
问题二：实习期间做的内容太难怎么办？
这个问题通常会导致实习的同学觉得自己能力不足，比如有些大厂同学会觉得自己“德不配位”，有些非大厂同学会觉得自己“学艺不精”，但老白要说的是，这很正常，谁不是从小白慢慢成长为老白的呢？
如果实习期间做的内容难，当然这个难不是某个sql写不出来觉得难，而是相对客观的难，比如业务逻辑复杂、代码要处理的内容很多、接口性能太慢需要换方案优化，如果是这些问题，最好的方法就是多问！问GPT！问谷歌！问同事！
不过要注意的是，在问同事之前，自己一定要实现调研过方案，比如我看到网上这个问题的解决思路有ABC三种，但是对公司的业务还是有些差别无法使用，这时候再去请教同事，讲清楚自己的思路和问题，这才是正确的询问方式。
实习期间遇到有挑战性的问题，比只做CRUD的含金量可要高多了，坚定好自己的信心攻克下难点，把经验总结一下，写到简历里面不又是一处亮点吗？毕竟面试高频的问题：你项目觉得你实习项目遇到最难的点是什么？
如果问了这个问题，想必这时候你面试的内心一定是：
问题三：实习期间做的内容太杂怎么办？
问题四：实习公司分配的工作内容太杂/太简单，要跑路吗？
由于前面篇幅已经比较长了，后面的两个问题内容也不少，所以暂时留到下一篇更新，欢迎追更~
老白在大厂实习期间也遇到了各种各样的问题，现在回头来看也都能找到合适的解决方法，希望本篇内容能给已经实习或将要实习的同学一些帮助~
--------------------------------------------------------------------------------------------------------------------------------
更多精彩内容请关注公众号：绝命Coding
