“There are only two hard things in Computer Science: cache invalidation and naming things”?
-- Phil Karlton
这篇文章本来想写在内网里的，怕自己之后看不到，就写在这里了。
CS 有两个难题，一个是缓存失效，一个是命名。确实如此，除了写代码时候的命名变量，似乎其他时候取名字也是个很难的事情，比如现在，我还没有想到用什么文字来做这篇小短文的标题。 (2021年5月27日)
就叫江湖再见吧，有缘希望真的可以再见。（2021年5月27日夜）
不想说时间过得很快，显得很俗套。就像昨天晚饭后遛弯时候和大家说：“别看飞机飞得慢，它速度挺快的。”一样，不是因为这句话是个惯用套路，而是因为它是大家都知晓的事实。飞机确实飞得快，时间也确实跑得快。
这是我的第一份实习，也很开心，第一份实习是在滴滴，在我们小组。这绝对不是因为这篇文章会分享给大家才这么写噢。这么说主要是因为这么两点吧，一个是技术方面，另外一个是团队氛围。
（技术、氛围、思考、致谢 四个部分）
技术方面
讲道理，自己简历上写了几个项目，但都是用的 SpringBoot 单体架构，倒是先前也有课程的作业让做过 SpringCloud 架构的作业，不过说实话，也都是走马观花，把先前的项目拆了拆，分成俩模块整在一起，运行起来也就算是结束了，说到底和考前突击差不多?，回头看看真的不算是个 “Cloud”。这次也算是自己第一次真正的去开（参）发（与）一个SpringCloud项目了，而 Feign 这个东西，也是自己第一次用它。
Redis 缓存这个，自己先前也看过一些文章，偏理论的一些东西，像缓存击穿之类的，大都是面向面试的hhh，ElasticSearch 也学过一丢丢，但这俩在项目里到底是没用过。要是问我问题，我可能能像赵括一样侃上两句，问的深了点，偏实际一些，我就蔫了估计。所以来了之后，就先看这些东西在项目里是怎么用的，分布式锁实际项目咋实现的，比之前有点进步，但是还是有很大的进步空间（还是很菜），昨天宇哥让我把两个队列迁移重排的时候，对redis实际的几个方法还不是很了解，这东西真得用才能只知道怎么用。
说了框架再说说编程习惯吧。到现在记得最清的俩事儿一个就是“get到底”，一个就是“CV出的BUG”，哎，也是“有幸”造了个生产BUG。。。
接手的第一个需求是对接外卖侧的需求，让获取一个列表。当时我拿到后，前postman测了下接口，看了看它的返回结构。然后就开始在代码里 get().get().get()，不能说质量差吧，简直是惨不忍睹...
当时给鹏哥和俊哥看了之后，说：“你咋能一直get呢？他要是没了呢？”“这不是上游的结构吗，咋会没呢？”“别太相信他们，得多做检验，你这个他要是有一个断了，是不是就崩了？” 一想，诶 还真是，毕竟都是人写的嘛。从那之后，我对其他接口基本上就失去了信任，不管你是啥，先来判个空再说。健壮性高于一切。
线上bug那个，是新增了一条业务线，然后我们需要适配下，最初我只考虑了双方数据都符合规范的情况，然后写了之后想想，不够健壮啊。就又对于上游符合我不符合，上游不符合我符合等总共四个情况作了判断和逻辑处理。为了避免敲重复的代码，我CV了判断条件和返回里的填充值。写完之后，我感觉这挺棒，这次考虑的全。而问题就出在了“CV”这里，“CV”之后没有修改... 周五时候发现了这个问题，当时心想，上游不上我们这没有影响，等到周二再上修复吧。但不曾想，周一时候上游上线了... 因为缺乏沟通，所有命中错误分支点都没法创建工单。 当时看到这个问题的时候，我慌了，这得影响多少工单啊，想想上线修复，要一两个小时影响时间有点久，所以就提了工单改动了数据库，之后让代码命中其他没有问题的分支，让问题暂时得到了解决。
之后瑞哥统计不稳定性时长的时候，问我多长时间，我看了下工单提出到我们修改完毕，是16分钟，然后说16分钟。这个已经占了很长稳定性时长了，有点内疚，但压力还不是很大。到后来，瑞哥又问这个是怎么造成的，上游上线是什么时候？
我问了问，一算时间跨度，卧槽，100 多分钟，直接把一年的稳定性时长干完了... 我也不知道当时我脸上有没有表现出来什么情绪，但当时脑袋是懵逼的... 冷静了会我去问鹏哥，刚开始没说时间时候，鹏哥说多久啊，很轻松的表情和语气，我让他看了下我的电脑屏，然后我看到了微妙的川剧变脸?（我鹏哥也是四川人嘛），随后我俩去找了宇哥... 晚上我问了下松哥，松哥说：“没事儿，有公式不会全算进去的，别太担心。”当时感觉如释重负。最后按权重算了下，耗了90s好像，真的凶险。
又学了一个道理：轻易不要去CV，或者说永远不要去CV
除了这些还了解了公司正规的一些流程、规范等等。
团队氛围
周四我来的，然后一天半后，合租室友带回来一个次接触的朋友，我直接被隔离了... 想想自己能在当时0感染的海淀密切接触个次接触也是中彩了? 后来和宇哥、松哥反馈了下情况，帮忙开了下vpn，开始了半个月的远程办公主要就是看些文档熟悉项目，当时的感觉就是：互联网公司这个办公就是很灵活。
然后刚到公司上班时候，有点拘谨，怕自己哪里做的不恰当啥的，也看一些博客啊某乎上的一些帖子都说什么不要把同事当成朋友啥的，也没怎么放开自我，慢慢的熟悉了之后，感觉团队里的小伙伴就真的是朋友啊，什么帖子啥的，竟瞎扯淡。
宇哥是小组长，也确实可以看出来绝对配得上小组长，考虑事情很全面，碰到问题也很冷静，出bug那次宇哥当时直接说：先算下占比，有权重的不用着急。
还给我“小鹿茶” /开心开心
刚见到鹏哥时候，给我的印象偏书生气一些，觉得稍稍有那么点严肃和宇哥的感觉有那么点像；所以前期时候，项目有什么问题，我就老早俊哥问，他笑眯眯的，像尊佛。等到后来相处的久了，发现鹏哥其实并不是看起来那个样子，遛弯时候时不时的就会蹦出一些段子，当真是人不可貌相啊。
俊哥和鹏哥技术能力挺强的都比我们(我、文证)高出几个level，有次聊一个专栏时候，俊哥说那个讲的有点浅，没什么实际应用。“怪不得人能做面试官，我们刚看，人家都看完了！” 俊哥给我的感觉挺和蔼可亲的，因为他一直都在笑，去别的小组“找事儿”的时候也笑，大家可以注意下，只要他没盯着电脑屏，他准在笑。遛弯溜得多了慢慢的我感觉也被同化了，有时候看个看个代码的注释也能盯着电脑屏笑。
文证和陈哥俩人来的稍稍晚一点，鉴于文证零零的，我就不喊哥了啊。
文证可以看出来对技术很有追求，写代码和平时看的一些文章可以看出来，给我的感觉就是能拍倒前浪的后浪那种；讲真和你参加一届招聘，压力很大啊！如果不得不卷的话，文证你卷的慢点。另外你想做的那事儿，最好别做，要是真想做，喊上我，咱拉俊哥的证书来挂个名。
陈哥的话来了就接手了项目的改造，说话也蛮有趣的，这两天的经典语录就是“1分钟1千米，你也才60码啊”。入职后陈哥在定目标的时候参考了一位前辈的，定了个要完成1个内推，现在每天都在为之努力，其实就这个态度推不推成应该都没那么重要了?。另外就是陈哥对于电瓶车也很有独特的喜好或者说商业头脑，回头理清楚之后，找个你钟意的合伙人，超过窃格瓦拉·周我觉得不是什么问题。
思考
-
耗时的地方是在开发吗？
之前自己认为开发者的时间分配中，开发时长应该占到总时长的 70% - 80% ，但是在实际工作中发现，正经的敲代码的时间实际并没有这么高的占比。
-
对于功能性需求：实际耗时的主要是沟通交流，这个环节包含和PM的，以及和其他部门或者模块之间的交流。其次是对于所要进行开发的功能的思考，之后才是投入的开发。
-
非功能性需求：非功能性需求，主要是指BUG 修复之类的。此类耗时的点在于问题的排查和溯源，如果碰上一个精巧的bug，可能需要投入更久的时间，而最后动手修复的时间相比于排查时长则是更短
-
-
拿到需求时候应该考虑哪些因素？
这个问题主要是平时同几个前辈的沟通中得到的解。
刚入职时候，或者说刚拿到第一个需求时候，我的处理通常都是：这个需求是哪个模块的 -> 对应到代码的哪块 -> 编写代码 -> debug
在经手过几个小需求，同前辈的沟通中以及解决自己造出的bug之后，我对这个问题的看法稍稍有了改观（也不十分全面，大家可以指正）：-
评估影响面
也就是先看当前需求会影响到哪些模块，进而延伸到之前的模块会不会被需求波及到。
example: 之前的 dlp 等级信息，这个方法在更改后所接受的参数也会发生变化，因此我们要先去看这个方法所被引用到的模块，以及更改后其他模块的检索方式需不需要动态的更改，诸如此类的信息。
另外一个坏的例子就是：业务线和商家店铺列表这个，当时商家列表和工具同时上了线，未等待前端同步上线，之后又提前上了一条巴西的业务线进行测试，此时一切都可以正常的运转，因为前端未上线所以商家列表接口并未使用；但当前端上线商家列表时候，在测试环节发现了错误：无法拉取到订单信息了，这便是上边提到的“业务类型key冲突”的背景。这个产生的原因便是在加测试业务线时候，未考虑全面他的影响面，以及会波及到哪个功能，好在是在测试环节发现了问题并得到了解决。
-
确定自身角色
需要和PM进行沟通，不清楚地点要问清楚，搞清楚自己的接口在当前流程中承担的角色，要提供的数据，这些是为了确定我们所要实现的功能。
-
代码的设计
这个用“设计”这个词可能有点大，其实主要想要说的是要考虑到 健壮性。一个系统的健壮性是大于其他任何特性的。那怎么去实现健壮性呢？我觉得主要是要去思考输入输出的处理、边界值/情况的思考以及对于数据源的校验等。我刚开始第一个需求的时候，对于上游提供的数据是很信任的，具体体现就是
.get("data").get("list")这种，之后在review代码时候俊哥指出了这个问题。 -
代码编写
-
debug与上线
-
致谢
后端小分队
首先要感谢的肯定是方舟小组啦！从自己进入小组后熟悉项目，到接触基础的关单，到做一些小需求，再到负责满意度模块都离不开大家的帮助。
感谢鹏哥在自己熟悉项目、处理需求上的帮助；自己有些浮躁，刚开始来时候看了些项目后就想着可以串讲了，但实际上还有很多没有看到，鹏哥拖了拖也给自己讲了很多系统的知识点；在之后处理需求时候也帮忙梳理逻辑，?。
感谢俊哥在日常对自己代码的指点以及问题的答疑；自己有时候看整不动代码时候就会去找俊哥帮忙，俊哥都会很热心的帮忙解决，也会给自己写的代码提一些建议，感谢。
感谢宇哥在生活中对自己的照顾培养安排，自己入职后接手的任务都是一步步的提升的，整个过程很平缓，没有说忽然很大的压力那种，能力也慢慢的提升了许多。另外就是把满意度模块给自己负责，真的感到了很大的信任，这个模块也帮自己在模块和系统认知上有一定的提升，而不是看问题只看到方法级别。
在满意度模块push上的配合，满意度模块push偶尔会抽点小风，感谢在遇到问题时候韧哥帮忙追查解决。
在自己问一般去哪打羽毛球后，利家老师和蕴熙前辈都告诉我去哪玩，可惜最后也没和两位一起打一次，有点遗憾；感谢两位前辈！
前端小分队
感谢菁汐姐、申哥两位前辈在处理外卖侧需求以及在满意度模块的配合；外卖需求是我接手的第一个需求，当时还碰上外卖侧PM不断增加prd内容的情况?，菁汐姐犹如战神：“prd上原来没有的不做”，才让需求没有延期的很晚。
满意度模块的问卷配置以及工作台改版的部分内容都是和申哥配合的，感谢申哥在这两个模块的配合和支持！
测试&PM
讲真，有一段时间我看到测试同学都稍稍有点害怕，尤其是有一次征哥抱着电脑喊着“有bug有bug”走到小组里之后。
感谢晓娟姐和锋哥在满意度模块的配合，自己在做满意度时候，几个问题和需求都是晓娟姐配合测试的，也使得它们最后得以顺利交付。感谢征哥在其他需求方面以及近期满意度模块的配合，最近满意度涉及到的国家有点多，征哥辛苦！！
