听说在 xxx landing 是地狱难度？
本篇文章主要是为了：
-
从外部刚进大厂的同学；
-
在大厂内部主动转岗的同学；
-
在大厂跟随组织异动，变更部门的同学。
如果你属于其中之一，那你有福（fǔ） 了，即将迎来个人能力的飞快提升！当然，也会附赠一些小小的历练。 [手动狗头]
一、写在前面
在某大厂待了几个年头了，辗转也拥抱了几次变化，做过许多不同的业务，去了几个不同的部门，landing过几次。 在网上看到大家讨论“在xxx landing 是地狱难度” ，我想说，确实。可是日子还是要过：“还能离咋地？”总结起来还是有一些方法的。正好最近又又又又又在经历一次新的 Landing，就一起总结下，与君共勉～
Ps: 希望这篇文章你能看到，但是别有机会用到，至少别用到太多次 -_-!!
二、Landing 的难点是什么？
-
业务上：业务太复杂，历史太悠久
没有一个业务是简单的，除非它上周刚上第一期。
业务的复杂度主要体现在以下三个方面：
-
功能多
大家都希望自己的产品好用，更希望自己的业务做大，可以覆盖更多的用户。那么功能一定是越加越多的，很少听说砍功能的情况（在这点上真的很佩服张小龙式产品经理的魄力，删繁就简）。所以时间不用长，半年一过，你就发现一个马桶产品也会加人脸识别+个性化音乐推荐。
-
功能之间的配合多
如果仅是功能间大家各玩各的， 互不干涉还好。但是更难的是，恨不得每个功能间都会有“梦幻联动”。这就导致，做了挺久以后你才惊奇地发现：what？这个玩意还会被这个场景用到。
当然，这是我们鼓励的“合理利用资源，互相借力”。但是多了以后，对于一线干活同学的压力就会指数级陡增，你改一个功能点时，很怕考虑不全，会不会不小心影响到了另一个模块的功能，然后背个事故，凉凉。
-
特化逻辑多
虽然大家都在吐槽，认为特化逻辑不好，但是根据我的经验，没有一个业务是没有 if else 的特化逻辑的。这个是和“快速迭代”相伴相生的。当研发排期一压再压，在面临内部、外部、他人、自我多重压力下，选择写一个“小小的”if else 往往是最省事也是对个人 ROI 最高（至少短期）的做法。但是你一个我一个，随着不断迭代，长期以后项目 be like this:
-
技术上：每个部门的技术栈都有差异
头部大厂的所有业务发展都非常迅速，不同的业务在发展过程中，通常都以快速迭代、满足业务需求为第一优先级。那么这就会造成技术上很多的个异性，具体的个异性通常表现在三个方面：
-
技术基建差异
在一个部门用顺手的技术基建组件，不会轻易换：比如有的部门很喜欢用 Mysql，有的部门就不喜欢用 Mysql，会优先使用Redis(或 Redis 的变种) 等这种Key-Value的存储，还有的喜欢用 mongoDB；（这些和业务属性有关，也和做这个业务的早期的人的偏好有关）。
-
工具差异
开发过程中使用到的各种工具、平台都是伴随业务发展应运而生的，所以各不相同是比较大概率的事件。所以我们总需要去学一下新工具、新平台怎么使用（嗯，大多数都做不太到产品体验极佳、开箱即用，毕竟是给自己人用的，凑付能用就行，甚至文档也不会长期维护，用法需要口口相传）。别说刚来的同学了，在同一个公司待很多年的同学，来到一个新部门的时候，也会经常感叹：我去，你们这又是什么“轮子”？
-
代码风格差异
显/隐式传参、写/不写注释、拆/不拆功能函数这些就不谈了，一句话 dddd：虽然都是 go 代码，但是你能一眼看出来哪段代码是写Java出身的同学写的，哪段是写 C 出身的同学写的。
-
人际上：互相不了解，信任关系薄弱
初来乍到，大家过往的成长经历、项目经验、处事方式都不一样，在短时间内可能大家互相都会有一些点，超出对方的预期（可能好可能坏），这时候可能会产生一些误会等额外成本，加大做事情的难度。
-
心态上：自我怀疑
之前感觉自己都挺优秀的，怎么来了新团队怎么感觉自己这么笨呢，这也不会那也不会。别人说的话也会理解错，承接个需求也这么难，竭尽全力了都会有考虑不周全的点。是不是我能力不行啊？
三、如何快速 Landing?
好了，抽象部分结束，接下来我要开始装逼了（不是）。说了这么多，并不是说公司不好，在哪家互联网大厂都是这样。也不是说这些问题大到解决不了，只是说需要时间，需要精力。那么如何缩减我们landing 的时间与精力呢？让我们逐一击破！！！
-
业务上：先把自己当成用户去体验
Dogfooding & 先完成再完美
神龟虽寿犹有竟时，功能再多也是给用户用的！不了解这个业务，那还是用的少。
- 如果你负责的业务是电商购物软件，那你就去拿它搜一搜你最近想要的东西，真的去下一单，货不好的话体验一下售后流程；
- 如果你负责的业务是办公软件，那你就找一个真实的办公场景，拿它去帮你实现一些办公功能，看看是不是真的能解决你处理问题的工作流全流程；
- 如果你负责的业务是抖音短视频推荐，那你就猛猛刷就完事了......
有的小机灵鬼可能会问：
- 我负责的业务只是全流程中很小的一个模块，体验全流程有什么用？
- 我负责的业务了解难点在于有很多的边缘场景，只体验核心流程也不够啊？
- 我负责的业务目标用户不是我，我也不知道他们平时怎么用，我自己体验有用吗？
我想说这都是很好的问题，不过饭要一口一口吃，山要一步一步爬。在 landing 的时候，我们能做的，也最需要做的就是快速建立一个 overview。
-
你先要知道这个产品是干啥的，它主要的功能是什么，然后你可能就知道了你的那一个“小破模块”在它的功能里哪里起了帮助；
-
你先要熟练掌握核心流程，建立了相关的知识框架，再去扩展边缘场景的时候就不会是一堆散点式的知识压的你喘不过气。也不会像狗熊掰棒子一样，知道这个忘了那个；
-
业务目标用户不是你，也得假装是你。尽你所能地去多了解用户的使用场景，代入用户视角，这样可能有一天你会发现原来这个功能是干这个用的（也可能发现这功能纯自嗨， 根本没用！）
-
技术上：从大到小，以出为入
坦诚清晰地说，我作为服务端工程师，只懂这一套，所以就直接陈述我的方法，其他的工种应该也可以借鉴，如果有特殊的点，欢迎评论区补充，帮助其他同学一起早日脱坑。
-
从架构到细节
了解一个业务，如果我们直接去看具体的功能代码，很容易陷入到细节的魔鬼里。看一个函数的代码，脑子里有一百个问号，解都解不完，不如放弃。那么这里其实思路还是先建立认知框架，再补充血肉。给一个最最最最简的步骤集，这几步做完你就敢说“对这个业务有一定程度的了解”了：
-
画出架构图
这个非常关键，注意是你自己得能画的出来，而不是看其他人画的。如果你能真正知道这个系统有几层，每层的作用是什么，每层由什么组成，他们是如何交互合作的，那就成功一半了。
-
画核心链路流程图
选这个系统里最重要的几个链路的流程，把他们的运作流程搞明白。这里可以不用看那么的细，细到每行代码都了然于胸，但是要能说出大致分了几步，每步做了什么事情，这一步里又分了几种情况，搞完这个恭喜你进度条解锁70% 了。
-
梳理系统监控报警
一个系统的监控报警是它对外界窗口承诺的最低底线，它监控和报警的通常都是这个系统里最重要的部分。当你掌握了这部分，那你至少后面在动这个系统时知道是不是惹大祸了，如果惹大祸了，那及时回滚，还有的救。做完这部分此时进度条 80% 。
-
做一个小需求
好了，如果你不亲手做一个需求，你将永远无法上手，在做一个需求之后，你将会了解开发环境、开发流程、需求迭代流程等等。做完以后，你会发现好像也挺简单的，轻舟已过万重山～ 此时进度条 90%
什么？都做完了为啥不是100%？
嗯...因为行百里者半九十，其实此时你距离一个称职的 owner还有至少一半的距离，只有到你真的什么问题都可以独立处理好之后 ，才完成真正的 landing。
-
用输出的方式去进行更好地输入
通常的情况下，在 landing 阶段我们都会被扔来/或自己找来大量的文档，此时会进行大量地阅读。但是阅读完以后，好像懂了，又好像没懂。看的时候全懂，合上文档全废。（何况文档本身的内容在当下都不一定是对的）。那么这个时候有一种很好的方式来帮你建立正确的认知，那就是你给别人讲！
What? 我是个新人，我还给别人讲？这世界上有人比我更不懂吗？
哈哈哈哈哈，要的就是反差！（bushi），给别人讲有几大好处：
- 强迫你去了解更多信息（否则你就会丢大人）；
- 因为你需要给别人讲，所以你需要建立知识逻辑，这过程中会push你思考这个系统的各个方面，引起你问更多的问题（只看别人的文档你很可能完全想不到这些问题）；
- 一些信息的时效性已过，而你现在去找一个对这个系统最熟悉的老哥来确认，才能知道到底哪些是现在的现状；（这些东西早晚都要知道，与其事来了再问不如一次性问完）
好了，当你讲完，大家都说没戳没戳的时候，你对这个系统的技术了解已经达到准出水平，可以去仗剑闯天涯了～
-
人际上：做好每件小事，乐于沟通
大家来自天南海北，萍水相逢，互相不了解，都是很正常的事情，所有的人都是一样的，没有人可以在短时间内熟的像穿一条裤子似的。但是信任关系这个事情重要，也没有那么重要，终归还是工作伙伴关系，大家是来一起做事的。我们只需要做好两件事即可：
- 把每一件小事都竭尽自己所能的做到位，尽量地让别人可以“懒”一点；
- 有问题就多沟通，就事论事友善地说出来，人心都是肉长的，即使短期有一些误会，路遥知马力，日久见人心。
我们自己能做的只有这么多，其他的控制不了，也无需控制。
-
心态上：take it easy
用一个英语作文常用句式，last but not least。心态处理我们放最后，但是这个是最最最重要的。如果在心态或者情绪上消耗了太多的精力，那会导致你做事情时事倍功半。请你记住两个法则就好：
-
循序渐进，一步一步慢慢来，没事的；
-
大家都一样。
四、最后
咱们把这些方方面面一分析以后，是不是感觉也还好？也就这么点事，小小 Landing，一咬牙一跺脚，也就扛过来了，扛多了，也就不是事了。
（真扛不过来，也没啥～ 海阔天空，还有下次机会😊）
一些碎碎念
其实关于Landing这事说大不大，说小也不小。 Landing 本质上是一个跨领域学习的过程。关于跨领域学习也有很多比较系统或权威的方法，我比较喜欢的一种说法是冯唐的方案：想要快速了解一个行业，进而成为专家，要做到四步。
第一步，先知道这个行业的一百个关键词；
第二步，找三五位行业专家，坐下来和每位专家谈一天；
第三步，就是读书，找到这个行业三到五本专著，认认真真地读完；
第四步，在项目中学。然后不断重复这四步
我是冯唐粉丝，上面我给出的技术 landing “四步法”就是借鉴了冯唐说法的灵魂。
之前写多了所谓“干货满满”的技术文章，干货太多太“噎”了，这次整体还是希望文章写的轻松幽默一些。同时这次讨论的主题其实也比较沉重（当你感觉 landing 很难时，压力绝对很大），所以也希望尽可能地给大家传递一些轻松，游戏人生～
