阿里妹导读
作者总结了在阿里的三年时间中所收获的宝贵经验和成长感悟。
二零二一年的七月九号，我以校招生的身份入职了阿里，开启了一段十分有意思、有意义的阿里旅程。
这三年，我从企业金融技术部，到ICBU技术部，中间还借调到1688技术部一段时间。整个滨江园区的业务我好像都经历了一遍。
在这三年里，换过N个小组。中间经历过很多好的坏的、各种闹心奇葩的坑爹事。但是幸好周围的各位大佬对我不厌其烦帮助、孜孜不倦地教诲，让我感受到了阿里人温暖，在这里收获了友情，成长和感动。
在阿里有句俗语，三年成人，在这个时间点，我小小地做个总结，欢迎拍砖～
搞业务与做技术
“面试造火箭，入职拧螺丝”。
在越来越卷的当下，面试的难度越来越高，HR先筛选一下简历，非985的不要，没项目的不要。面试阶段，大部分阿里的面试官一上来先来几道八股文练练手，再结合简历项目看看实力，最后问几道高并发完美收场。面试官的这套组合拳打完后，面试者真的会以为将来工作的场景会和这些高并发高可用休戚相关，拳打千万并发、脚踢亿级流量，一想到亿级用户将通过在下手中的代码完成一次次交易与支付，激动之情就难以言表，喜不自胜。
但是入职之后却发现，面试时候信手拈来的各种高性能、高可用、高性能的奇技淫巧暂时没有用武之地， 取而代之的是被PD各种虐，CURD就是干，每天在N年前古人写下的深山中猜测各种古老的业务细节。
很多人入职都会进入业务团队，他们就会后发现，自己日常接触的代码，或许因为业务迭代的压力，或许困于前任设计的缺陷，几乎没有任何“技术”的设计可言，一言不合加机器、升配置，是最常见、也可能是唯一的处理所谓高并发的手段。
至于高可用，中间件平台已经够完善了，根本不可能出现之前面试所说的极端问题——即使出现，也不在业务场景的考虑范围内，因为数据流量太小，离线核对订正往往是最常见的解决方案。
所以，入职业务技术团队后，相信大部分校招同学，在开发一段时间业务需求之后，轻则怀疑公司，生出“阿里就这？”的感叹，然后麻木地被业务需求往前赶；重则道心破碎，开始怀疑自己的当初的梦想，最后要么被干要么跑路换行。
我刚入职后就属于前者，看着周围一些同学CURD一把梭，不禁陷入了迷茫，开始怀疑自己在学校钻研了三年技术的意义。我常常想，难道我每天CURD就能解决问题了吗？
纯粹的CRUD当然是解决不了问题的。随着工作的深入，我发现事情远没有我想象的那么简单。虽然是增删改查，但是在写增删改查的前提一定是对业务有相当程度的了解和熟悉。只有通过技术完成对真实业务的抽象和建模，才能写出来高扩展性的代码。而随着承接越来越多和越来越大的需求，我们所了解的业务知识也会慢慢变成自己的壁垒。在这个过程中，我们也会写出越来越健壮、可读性越来越高、扩展性越来越强的代码，我们掌握了对应业务知识，以及当前业务需要的性能和稳定性指标，都会成为我们宝贵的职业财富。
业务技术团队和纯技术团队最大的不同是解决不一样的问题。业务团队负责解决真实世界的业务问题，纯技术团队则负责解决技术问题。某种程度上来说，科班出身的计算机同学更容易受到geek风的影响，认为毕业将来一定会做很多技术相关的工作，再加上面试过程中各种硬核问题，拉高了面试者的工作预期，才会导致大家投入工作后产生很大的割裂感。
在业务团队，对于技术人来说，很大的忌讳就是硬秀肌肉，大家都想尝试新的技术，更高难度的技术挑战。但是，既然低并发能够解决业务问题，为什么还要处理高并发的各种问题自讨苦吃呢？尤其是在现在经营责任制的环境下，技术要做的就是服务业务，最小代价的解决业务的问题。
其实处处留心皆学问，虽然很多硬核技术在日常的业务场景中用不到，但如果实在喜欢钻研技术，进入阿里后，还是有很多机会学习的。抽时间看中间件的源码、应用中间件的设计模式、解决日常遇到的各种诡异问题（maven排包、类加载）、线上问题的响应与处理，等等。只要抽出身来，即使在业务团队拧螺丝，但只要多花点时间准备，为业务造火箭的机会可能就会到来。
草船借箭的勇气
写这篇文章的时候，通过GPT搜索了下，程序员中的I人会占到60%甚至更高，这种性格固然会使得大家在开发的时候更专注，但是往往也会导致开发同学在与人的沟通上不那么积极。
很多人刚入职的时候，无论是学习业务，还是开发需求，在遇到问题的时候，都不好意思问师兄。甚至有些同学在师兄问项目进度的时候，支支吾吾地说快完成了，结果等到联调的时候才发现，自己写的代码和业务预期的代码，还是有相当大的出入的。
所以，对于校招生来说，为了保证自己进步的速度，在合适的时机，多向周围的师兄、老板、业务方咨询问题，是一件非常有必要的事情。但是，大家往往缺少问问题的勇气，结合我自己和身边的例子，大概统计了下，一般有以下原因：
-
和被咨询的人没打过交道不熟悉，不知道怎么开口； -
担心问题太简单，害怕被咨询的人嘲笑或者看低自己； -
大家都很忙，害怕影响到被咨询人的工作
之前另外印象很深刻的一个例子，几年前，隔壁组一个刚入职的校招生在工位熬夜搞到11点，刚好我也在处理些事情，看他一直没走，就上前搭了几句话，得知他正在处理一个非常经典的Spring启动的问题。所以我就顺手帮他解决了。后来才知道，这个问题他已经看了快3个小时了。如果他能找机会向其他同学寻求帮助，那天晚上11点他就可以直接在床上原神启动了。
不只是问别人，阿里有太多的技术资产了。遇到问题，搜索语雀、ata往往就有50%的概率解决问题。学会使用工具，也是成长的一部分。
不像古代男耕女织、几乎一个家庭就能完成从生产到消费的全链路，现在的社会是以分工合作为基础的，所以我们必不可免的要和其他人打交道。甚至很多时候，我们自己的工作需要主动或者被动的依赖别人的帮助才能完成。
新同学刚进入工作的时候，一定要多向师兄和同事借力。在新手保护期的阶段，大家会更容忍你有更多的“不知道”，所以，一定要在最懵懂的时候，尽可能的获取更多的知识。
项目遇到卡点的时候，一定要多向老板借力。业务方工期紧？合作方不配合？这些涉及到更高层级沟通的地方，一定要向老板汇报，让老板站在更高的视角帮我们推动项目的执行。不过，在找老板之前，不能只把问题抛给老板，还有给出一定的解决方案和预期时间，这样在后续争取资源或者撕逼扯淡的时候，老板才会不至于那么被动。
作为业务开发，业务的知识也是开发必须要掌握的基础之一。在遇到业务问题的时候，要多向业务借力。想业务咨询问题背景、可能的方案以及原因。多与业务沟通，不仅能掌握更多的业务知识，从功利的角度讲，也算是和业务方刷刷脸。大家更熟悉了，后续合作需求的gap也会越来越小，工作起来也会越来越顺心。
草船借箭，不仅需要勇气，更需要智慧。聊之前准备好草船，也要注意时间和场合。完事之后表达感激也是必不可少的。至于是一句thanks，还是一杯咖啡，抑或是一顿饭，这个见仁见智吧～～～
预期与项目管理
无论是写代码，还是PM技术项目，核心都是保障事情按时交付。在这个过程中，一定有自己不了解的地方，所以如何平衡好未知的坑和确定的交付时间，是我入职之后做技术PM最痛苦的点之一。
如果遇到一个自己有超过30%都不熟悉的项目，建议此时一定要给自己多留一点buffer。这样做的原因有两点，一方面是面对未知的坑，运气好一点可以直接跳过去；运气差的话，直接陷进去一周都出不来。无论项目大小，作为项目负责人，我们不能让项目的交付时间跟随运气的好坏而波动。这样不仅会使得自己陷入被动，项目的对外放声，前线运营也会受到影响。
给自己留buffer，不仅仅是帮助自己有更多时间踩坑，也是给自己留更多地和业务方聊排期的空间。如果一上来和业务聊了一个很紧张，加班后勉强才能做完的时间，后面这个项目大概率是要延期的。这么一搞，自己在合作方中的印象分就会很低。鲁迅大爷说过：“中国人的性情总是喜欢调和，折中的。譬如你说，这屋子太暗，须在这里开一个天窗，大家一定不允许的，但如果你主张拆掉屋顶，他们就回来调和，愿意开窗了。”所以，刚开始估一个留buffer的排期，后面到底是拆屋顶还是开天窗，就有很大的活动空间了。
但是有的时候，项目的排期并不是我们这些小P能够决定的。930、330前要上线的项目一大堆，各个项目问就是P0、第N增长曲线，必须要做。没有留buffer的空间，这个时候该怎么办？
过去的经验告诉我，在不断发现风险，解决风险的项目过程中，遇到难以解决的风险一定同步老板。及时让老板了解项目的进度，适时地管理项目参与方对项目的预期。这样才不至于在项目的各个里程碑中给各位大佬一个惊喜的SURPRISE。
独乐乐不如众乐乐
在阿里这三年，发现了太多大牛前辈，他们中的大部分人在我阿里的历程中都给予过非常重要的帮助。当我不解问及他们为何要在工作如此繁忙的时候还会抽出时间来给我答疑，他们的答案出奇的相似：
“因为当时淋过雨，才知道做这些无聊的事情有多痛苦”
“这些概念性的东西，知道后会少走很多弯路，没必要让你们把时间浪费在这些没有价值的事情上”
我听了之后甚是感动，在我看来，这是阿里师兄文化最好的体现。从实习到校招，我的每一任师兄和每一任老板，都在尽力帮我landing，教我了解技术原理、告诉我如何学习和成长、如何管理项目、如何控制风险，感谢这三年与他们相处的每一个瞬间，与他们相处的日子是我这辈子最宝贵的财富（之一，哈哈哈哈）。
所以如果有时间，不妨多去帮助那些新来的朋友们，在他们成长起来之前，少一点PUA，多给予力所能及的帮助。这样自己开心，大家也高兴，无形之中团队的氛围就会慢慢变好，阿里的文化也会一点点的传承下去。
其实帮助他们成长，对我们自己来说，又何尝不是一种成长？
万物是否皆可卷
我是2020年入职阿里实习，以本科生身份校招转正的漏网之鱼。互联网公司在20、21、22这三年校招扩招的校招生非常多，站在现在的角度，以当下的招聘标准，作为一个普通本科生，我是无论如何也不会被招进来的。现在部门的校招生研究生起步、985打底，卷学历，作为开发，我已经输在了起跑线上。
如果不能卷学历，那还能卷什么？卷加班时长？卷代码量？还是卷aone的工时？
我觉得这些都是一些过程指标，卷这些东西除了能够安慰和缓解下上次管理者的焦虑之外，是很难明显地解决其他问题的，对于自身的成长和提升更是没有一点帮助。
互联网头部大厂作为人才的蓄水池，周围随处可见的都是优秀的人才，技术能力高，业务sense强，甚至每个人都有一套为人处事的方式方法。作为刚进入职场的菜鸟小白，我们应该努力卷我们自身的技能，向周围的大佬看齐，提升技术，学习业务，然后再将学习到的东西进行实践，从模仿到超越，实现学习、理解、实践、提升的闭环。
在具备基础的技术和业务能力之后，作为业务开发，不要只盯着自己技术域的一亩三分地，而是慢慢地开始去卷业务，了解自己开发业务的背景、发展和规划，学着站在全局的地方去考虑问题。阿里对新人还是有容错的，校招生快速试错，然后不断成长，等待机会，承担更大的责任。
不妨慢一点，给自己一点时间，找到一两个自己在工作中和生活中真正想做的事情，然后坚持做下去。不要去卷各种无谓的指标，校招生，从卷自己开始。
踩坑了，然后呢
作为新人，在刚入职的时候，一定有很多不懂的地方，甚至有些同学之前没有使用过部门常用的开发语言，这都是很正常的事情。在刚来的一年时间里，大家总是会踩各种各样的坑，印象中，我踩了很多坑：
-
dts任务批量调用导致下游报警
-
奥创发布上线不生效
-
某些租户缺少配置导致NPE，等等
有些还导致了P5故障，在复盘的过程中，老板和师兄们帮我总结经验，让我收获了很多。很多人把这些当做工作履历的黑点不想面对，但是对于校招生来说，正相反，只要问题不大，都是改错的大好时机。俗话说，好记性不如烂笔头，像高中写错题笔记一样，将之前踩过的坑记录下来。一定会有一天，在第二次遇到类似的问题后，脑海中突然闪过第一次踩坑的场景，然后把记录的问题翻开，成功跳过这个坑，继续前行。
大家对校招生的容错度是很高的，新同学一定要利用这个时间区间来试错和学习。记得我刚实习的时候，师兄给我review代码提了一些建议但是当时我没有放在心上，并没有改正，师兄很严厉的指出了我在回复comments过程中的问题，耐心教育我，“有人帮你CR指出错误，一定要有回应、讨论或者改正，这体现了对reviewer的重视。如果不回复的话，以后找相同人CR就很难获得高质量的comments”。这个建议我一直很受用，后续正式入职后，在师兄组织大面积CR的时候，在得到一些高质量的CR时候，我就会立刻提patch修复，其实，修复的越早，上线的风险也就越低。
同时，踩坑之后，不仅要记得防止自己踩坑，如果能形成公开文档或者知识库，防止别人踩坑，或者是顺手把坑修复掉，这就更加功德无量了。（当然，如何让别人知道你把坑修复掉，这是一门艺术 //v//）
听得懂、讲明白
作为程序员，虽然在日常的开发中与机器打交道的比较多，但是在项目管理的过程中，与人的沟通也是必不可免的。信息墒在传递的过程中一定是有损失的。所以，在交流的过程中，我们要通过各种方式来尽可能地保证信息的正确和完整传递。
沟通是一个需要长期锻炼的技巧，有两个比较重要的点，一个是耐心，一个是细心。在听的时候，能够给伙伴足够多自我表达的空间，正常情况下，不要着急去否定和打断对方，正如你讲话时也不希望别人打断一样。此时我们需要做的就是细心去听，然后分条分点地把对方要表达的观点记录下来并消化。同时，在回答别人问题之前，可以用几句话把对方刚才的语言复述下来，尽量降低两个人沟通之间的GAP。
同样的，在表达自己观点的时候，尽量也分条分点，像写作文一样，用总分总的方式，开篇和结尾表达问题关键点，中间分条分点论述。除此之外，一定要注意交代好上下文和背景。否则，很容易造成接受者的信息紊乱，形成驴头不对马嘴的尴尬场景。尤其是咨询问题的时候，如果直接问某一个具体的细节点，可能对方很难一下子get到意思，如果背景交代清楚，沟通起来就可能顺畅许多。
但是，一切的技巧终归是点缀，自己的影响力足够高，很多事情就迎刃而解了。
拥抱变化
拥抱变化作为新六脉，每一位同学都不陌生。在公司，拥抱变化不仅体现在口号上，更是在行动上表现的淋漓尽至。
作为校招生，刚开始对变化这两个词其实感知是不深刻的。第一次感知到变化的时候，是我入职5个月后整个组被通知换到了另一个BU，因为只是换了组织关系，周围合作的同学和老板没有变化，所以对于这次的变化只是有一个感性的认识。第二次感知到变化的时候，是22年从实习就开始带我的老板毕业之后，整个团队都陷入了一场漩涡之中，那次我就陷入了思考。第三次感知到变化，则是我自己的选择，选择了换个环境继续工作。
在这几次变化中，我有几点感触：
