鹅厂第七周实习总结（吐槽版）

说明

由于这周五部门团建，不怎么上班，所以这周只更新4天的内容。

周一 1.22

今天工作强度还是挺大的，导师生病了，我没怎么去问他问题。

早上发生了一件汗流浃背的事情，就是我之前修改的一小段代码导致发布包出现了bug，我注释掉了那行代码没有告诉原作者，我记得之前导师说这行代码可以提交了，我那样修改是因为特定机型的手机会有启动crash，但不管怎么说都是因为我忘记告诉原作者了才导致的问题，后来拉了个群，同事在群里艾特我，说我盖了这行代码导致了这个bug，而且是发布出去的包，不过不算特别严重。这个错误确实不应该犯的，可能也是因为之前bug实在是太多了，修改的文件也很多，不小心把那个文件也提交上去了。

中午同事在讨论年会礼物许愿的事情，我没收到邮件，应该是毕业生不能参加的活动吧。不过下午发了个公仔，企鹅公仔很大很可爱捏，超喜欢的。

下午则处理一个数据报表的问题，一直在debug，那个测试机太垃圾了，经常断连，这浪费了非常多的时间，明天我申请的四千多的测试机小米14就到了，终于不用用那台老古董测试机了。

数据报表不知道为什么前端页面一直没有数据，数据部门说看不到数据就是没上传成功，让我上传成功了再来找他，然后我就一直以为是我这边的问题，一直在看，可是整个逻辑其实非常复杂，我一直都只是处理上层的业务，底层代码没有接触过，很多实现我也不知道是什么逻辑，除了bug就被迫去看了源码，真的比想象中复杂很多，很多地方会对一个变量进行修改，然后会拿两个变量来做比较，也没注释说为什么要这样对比…. 这个需求最最难的地方就是在于导师没有说清楚整个需求的来龙去脉，以前的报表是怎么做的，现在和以前的区别是什么，是换了数据源还是换了实现方式，他跟我讲过几次，但是前几次讲的时候我没有结合代码去看，其实是很空泛的，现在我再去问他，好像他也不是很清楚，他就让我自己跟一下，唉，感觉下次一定要盘根问底，把细节都问清楚才好动手。

下午组长开了个小会，拉了我和导师，问我现在做的这个需求，他第一次看这个需求，但是感觉比我全力了解了三天还要懂这个需求是做什么。他很快抓住了重点，让我写一个文档，关于这个需求的需求周期是多久，涉及哪些数据报表、想要达到什么效果、后期维护成本之类的。

晚上回来继续看为什么数据没有上传成功，去问了这块代码的原作者，他说不应该呀，让我去网页上自测一下，我看到了旁边有个监控按钮，点开看了一下发现是有数据的，但是另一个报表没有数据，我跟数据部门同学反映，他查了一下发现确实是有日志的，那就是说这应该是数据部门的 bug 了…

挺崩溃的，到头来发现自己查了一天的 bug 原因不出在我这边，中午吃饭的时候另一个同事也提醒我，如果感觉自己这边没问题应该去找后台的同学看看数据到没到他那边，有可能只是前端没有展示。

好吧，还是应该听听建议的。其实我卡了这么久，很大一部分原因是我不太想跟数据部门（后台数据在他们那）的人沟通，因为他们也很明确告诉我，是我这边没上传成功，所以我就一直没去找他们核对一下，直到后面我找到了报表监控（另一处查询数据的地方）发现是有数据的证据的时候我才敢去找他们核对…

哎，不知道该说什么。

周二 1.23

他又问我毕设做什么，我说做app，他说是不是能拿实习的去当毕设，我说不能啊，他问为什么，评委也不知道这是不是你做的。说给我换个包名，做个定制包，就看不出来是企微了，难绷。

今天还在搞昨天那个需求，发现很大的难题还是因为没有和其他部门的同学沟通好，很多时候不知道该不该问他们，所以要先把自己的逻辑搞清楚才去问他们，不然如果是自己这边的原因，就浪费了别人的时间。而从结果来看，把自己的逻辑搞清楚是没多大必要的，因为之前的逻辑是不会出问题的。

最大的困难是这个东西没有一个很完善的开发文档，这东西都是其他同学跟数据那边的同学做好了，但是没有产生一个文档来记录这个东西怎么做，其他同学将来要维护的时候要怎么接手？还是只能把坑再踩一遍。

周三 1.24

工作之后发现很多事情都直接在群里沟通，很少会找人私聊，大家都倾向于有什么事情就直接拉群，有时候哪怕只是两个人之间的事情，也会让机器人发起一个群聊，因为很多事情都要留痕迹。

今天接触了一些底层代码，还做了校验相关的小需求，很多这种知识其实我之前根本就没用过，也记不住，都是现场去网上搜一下就会了…比如校验的那个需求，需要根据后台的校验规则，反向做一个匹配校验规则的校验码，这涉及一些位运算，之前我除了刷题都没怎么用过，可是问一下同事，他马上给我讲的一清二楚，再结合自己去网上搜一下就会了。之前我还很担心之后上班遇到不会的东西咋办，其实很多东西都能现学。

最近在忙的需求不用写什么代码了，跟设计有点像，就是用一个平台去配各种报表，有点像做PPT，要写一些 SQL 语句，还要结合那个平台的功能去做简单的开发，可是那个文档读起来非常繁琐，也不能一下子解决我的需求。最好的解决方法不是自己去读这些破文档和使用说明，而是直接去找这个平台的同学，提需求让他们帮我们做，或者让他们手把手教我怎么做…

周四 1.25

十点钟到家，在车上总是很头晕，因为现在跟刚开始不一样了，现在七点半开始干活，基本中间都没有休息，最多去一次厕所，其他时间就在干活，看着电脑，直到接近九点半才走会儿神。

今天一直在写 sql ，跟安卓开发都没什么关系，但上级给了这个任务就要去做啊。写了一些过程文档、规划文档，就兴致满满地去干了，途中遇到了贼多坑，贼痛苦，而且大部分的原因都不是在我这边，而是在和我合作的那边，非常痛苦，感觉花了很多时间但却没什么收获，也没什么产出，没有办法，这就是工作。

今天已经做这个需求第四天了，原计划四天就能做完，今天不得不跟组长说要延期了，不过这个也不是一个很急的需求，因为是内部需求，不是面向客户的。可能这个确实适合我来干吧，因为技术需求我根本也没能力做，只适合做这种杂活。

原本以为数据部门会帮我们分担一些需求，但是早上去跟他们沟通，他们让我们自己搞，也不愿意给权限我们单独建表。我说这样的话我还要花时间去学 SQL 还有那个数据报表的创建，这都要时间。他说SQL学起来很快的，半天就能掌握，数据报表其他部门的同学也是自己做的。

好吧，话都说到这份上了， 我还能咋办呢，只能硬着头皮学呗。到了晚上，我要写一行 SQL，要统计大版本号，要把版本号的后缀去掉，我想用SUBSTRING_INDEX()函数找到最后一个 ‘.’ 然后保留前边的部分，可是试了好久都不行，我就各种查，后面去问了数据部门才说他们的引擎是3.1的，这个函数是3.2的，所以不支持… 反正还有很多类似的坑，非常痛苦。

不过也是有一点收获的，至少是搞出来了一个报表，还有模有样的，不过有些细节还没处理好，真的是这些细节最花时间了，有时候一个晚上就在处理一个版本号的格式…

一开始说有3个报表，我心想这周应该也能完成。结果今天导师在我的文档上加了10多个报表，我人都傻了，这些都是工作量啊，还要保证数据成功上传到后台、然后还要花时间去配页面、写sql，而且这些sql语句只能拿到原报表，所有的数据处理都得我自己完成，每个报表都得重复和个过程。。。

更有甚者，后来他觉得光展示报表也没什么意义，还要在卡顿报表旁边展示堆栈信息…

我觉得是有道理的，光看报表确实是没什么意义，因为就算发现了卡顿但是不能知道原因干瞪眼可不行，所以还要加上堆栈信息，就这样需求多起来了。。。

需求真的是做不完的，每次我感觉这个需求快做完的时候，就会发现我只是完成很小的一个部分，因为后面可能别人又想到了跟这个需求相关的功能，可以放在一起做。

部门年终

说些轻松的，周四下午四点钟说开部门年终总结小会，我们都到了电脑，到了会议室发现有奶茶还有吃的，然后我又把电脑放回去了，接下来就是长达2个小时的会议。讲了部门的营收情况，这部分感觉太敏感了，我怕触碰高压线，就不说了。其中谈到了年终奖，大家确实最关心这个，在会议上肯定不会说年终奖发几个月，只是说了年终奖相较于去年是上涨还是下降。

我还发现一些很有趣的事情，比如年终奖真的不是固定的，每年都是有浮动的，浮动可能不大，但是差一两个月其实也差了不少钱。还有就是鹅厂的年终奖不只是看自己部门的，还要看整个bg的营收情况，所以自己的部门可能拉了，但是只要整体的营收上来了，也是能拿到不错的年终奖的。

还提到了很多新奇玩意，比如担任什么负责人，就有额外的年终奖，我这里刚好去上厕所了没听完全…

还有一些细节，我很想跟大家说，可是确实是太敏感了，只能说在会议上真的能听到很多平时不会听到的东西，比如上层对你们部门的看法、你们部门去年的整体营收情况等，平时这些都不会公开的，只有在这些关键节点才会讲。

这周好累，很烦，头很晕，压力也大起来了。