进了架构平台部，终于成了大佬
The following article is from 程序员榕树 Author 不落叶的榕树
“在架构平台部，做基础组件研发。”
“哇，大佬！
其实大佬两个字，我真是受不起的。
虽然从业了几年，但对这个行业的认知还是冰山一角， 离真正的行业大佬的差距那不是一丁点儿。
在业界，隐约有一点点鄙视链，做操作系统的鄙视做中间件，基础组件的。 做中间件的鄙视做业务的。
我之前做过业务研发，现在从事基础组件研发，今天想唠唠我对这两个岗位的看法。
工作内容&工作难度
关于业务研发岗
我在实习期做业务研发的时候，的确只是需要写一些基础功能，改改前端的页面，做一些很基础的增删改查的工作。
但是随着工作经验的累加，就需要去承担更复杂的工作。
1. 业务知识
在一些专业性比较强的行业，比如银行，物流行业，你除了要会技术，还要学习该行业的各种专业术语，业务知识。
2. 抽象设计
而和产品同学的沟通，其实也很需要功力的。大部分产品同学是不会技术的，他只能跟你讲他想要什么功能。初级的开发人员，可能就是把产品需求翻译成代码就完事了。但实际上只是这么做是不太够的。
简单举个例子，比如如果没有跟产品同学确认好这个需求哪些是可能会变化，哪些是不会变化的，那么你就无法针对性的去做抽象设计。
产品同学跟你说需要开发一个接入支付宝的支付流程，你说简单，一顿操作迅速就搞定了，结果过几天，又跟你说要和微信支付合作，如果之前的设计没有预留好这个扩展，那就是要去改造原有的支付流程，这样的改动可能就对原有已经接入支付宝的流程造成风险。
这也是常说的对扩展开放，对修改关闭的设计原则。因此也是需要熟练掌握各种设计原则，熟悉一些常用的设计模式，针对各种业务场景去做抽象设计。
3. 掌握各种组件的使用场景
在充分理解了产品的需求，以及了解清楚未来可能会变化的需求点。你还要结合业务场景预估需求的流量，从而能够去做好稳定性的建设。
比如秒杀活动的场景，你还要考虑结合消息队列去设计，比如对查询效率要求高的，你可能要结合缓存去设计，或者还可能要做数据库读写分离。
再比如写入数据库的数据并发太多，你还可能要做分库分表的设计，做分库分表的设计之前，还要考虑未来可能不一定是按照分库分表的分键字段去查数据。
这又涉及到数据异构的问题。对大数据搜索查询要求高的，你可能还要结合Elasticsearch去设计等等。甚至必要的时候，你还要考虑一些安全性的问题。
关于基础组件研发岗
在架构平台部门工作，我负责过监控系统的研发，职责就是做能及时并精确发现问题的监控。
我们做了全链路监控，日志监控，以及度量指标收集这些常规的监控，也开发了告警系统去做故障预警。
之后我又负责了基础组件，包括服务化框架、注册中心、配置中心，以及一些基础组件客户端（kafka,memory cache,redis,mysql ）等，职责就是做好公司整个基础架构的高可用。
日常主要是结合公司的业务使用场景，做前期一些技术选型，以及后续改造和维护，很多时候需要自己去阅读开源代码。
比如之前引入了skywalking 做监控，需要改造源代码，针对公司内部的一些客户端组件添加埋点，添加一些新的度量指标的收集。再比如微服务框架引入注册中心nacos，也对请求nacos做了本AZ优先，跨AZ备份的源代码改造。
偶尔遇到一些线上问题，涉及到这些开源代码的bug，也需要硬啃开源代码，掘地三尺，找出问题。
如果没有合适的开源组件，就要自己去做研发，比如我最近就是针对公司现有的延迟队列中间件，在研发适配的延迟队列的客户端，主要是提供基于注解的使用方式，便于业务开发同学更好的去接入使用。
做基础组件研发也有一些比较难的课题的，比如引入新的技术框架或者技术组件，如何去推动业务无感升级就是一个难题。
另外随着不断演进，如何更精准的帮助业务服务做故障根因，如何帮助业务服务做到故障自愈，如何提前预估流量上升，做整条业务线服务的自动扩缩容等，都是比较复杂的问题。
工作氛围
回想起之前做业务研发的时候，我最深刻的记忆就是各种开会。
一般是一两周一个迭代，每个迭代前开需求研讨会，然后每天也都会开早会，沟通工作进度。
每个月开总结会，反思过去一个月的问题，总结接下来要怎么做才更好。
生命不止，会议不停。
而我现在做基础组件研发，项目周期会比较长，我们就是每周开个会沟通一下进度和问题，其余时间就是做好自己的事情就可以。
做业务研发会比较频繁的和测试同学还有产品同学去配合，项目内部女生会多一些，平时也会感觉大家交流的比较多，很多人可能会比较喜欢这种氛围，觉得男女搭配，干活不累。
而我现在做基础组件研发，绝大多数都是男生，如果不是工作遇到问题啥，一般比较少交流，大家就都是埋头做自己的事情。
比较直观的一个对比，就是目前坐我左手边的就是一个业务项目组，经常听到他们男生女生讨论问题传来欢声笑语。
在我合作过的一些同事里，有的人比较喜欢多开会多交流，觉得一直埋头苦干，很沉闷，有的人比较喜欢安安静静搞技术，不希望被频繁的打扰。因此萝卜青菜，各有所爱，选择自己喜欢的就好。
就业机会&职业规划
业务研发岗相比基础研发岗，其实市场上的就业机会更多一些。这个打开招聘软件就看的出来了。
至于职业前景，业务研发一般就是几个方向：
对业务比较熟悉的，不想做开发了，就可能转产品岗
想走管理路线的，就是: 业务研发->晋升开发经理岗位->技术总监
技术走到底了，就是：业务研发->架构师 ->技术专家
而基础研发岗一般就是往架构师方向走，之后成为技术专家。
不过很多时候并不是绝对的，有些时候也都是有交叉的，比如我现在虽然做基础组件研发，也还有在独立负责维护一个业务项目。一定程度上也还算是半个业务研发。而一些业务研发同学也会做技术选型和基础框架封装的工作。
我为什么会做基础组件研发？
其实没有什么很高大尚的原因，就是做了两三年业务研发，想换换口味，玩一点不一样的，就去尝试面试基础研发的岗位，这一做就做到现在了。
目前还是比较喜欢现在这种基础组件研发的岗位。经常能去看看业界一些新的技术框架，做一些技术选型，也能去阅读一些比较优秀的源代码，经常看到一些优秀的代码，觉得作者设计得真是妙啊。
平时也做一些框架的封装，给各个业务开发团队去使用，还是有不少成就感的。
最重要的是，部门内部有比较多的技术专家，大佬们都比较谦逊且无私，跟他们去请教问题，也都很受益。这也是我写公号号的一部分原因，除了可以做自己的技术总结，另一方面平时跟大佬们的沟通，也可以总结整理输出他们的一些技术想法。就好像《论语》也是孔子的弟子和再传弟子整理的一样。
一些小建议
做业务研发需要花比较多时间花做业务梳理，这应该也是很多业务研发同学感到矛盾和焦虑的点，平时工作为了把项目做好，大多时间都是在兢兢业业的梳理业务需求，对一些新技术和开源组件的底层技术比较少关注。
结果想跳槽时人家面试官一上来就各种底层技术的问你，感觉工作经验还没派上用场，面试官已经让你出门右拐，回去等通知了，而这通知遥遥无期。
那这种情况应该怎么办?
我的想法是，还是要让自己去做有积累的事情。
除了跳槽尽量跳跟自己之前做的业务相似的岗位这种基本原则之外，最好平时工作中养成写文章做总结的习惯。比如排查一个有技术含量的bug可以总结记录下。
做了一个比较好的设计方案，也可以总结下，顺便分析分析自己用到了哪些设计原则；
平时遇到技术盲区，也可以把对应的技术知识再系统学习总结下，写文章总结的时候你会发现自己可能对这个问题理解的还是不够，这样就会再去学习解惑，让输出带动输入。
这样时间长了，你会发现自己持续在积累，不仅能把自己的工作做的更好，即便有想跳槽的时候，因为你都有在总结，表达起来也会更流畅，甚至可以把你的总结博客发给面试官看看，我相信这是会加分的。
此外，最好给自己制定一些学习的计划，其实人都有偶尔想躺平的想法，也有偶尔情绪小丧的时候，这都很正常，因此做一些计划，比较能推动一下自己，flag总要先立一下，如果你完成了flag，那恭喜你，你很优秀！
如果因为偶尔躺平了，flag没完成，也不要焦虑不安苛责自己，调整自己的心理状态，跟自己和解也很重要。不过我相信跟你之前没做学习计划相比，你也走出去一大步了。收拾收拾心情，继续立下一个flag。你会发现，每阶段的小小成长，其实也是能带来很多幸福感的。
- END -
文章精选1、羊了个羊，但是低配版2、CPU 和 CPU Core 有啥区别？多核 CPU？多个 CPU？3、2019年诺奖得主大翻车！被曝54篇论文涉嫌造假，刚撤回4篇PNAS4、网友大赞国家电网：停电烧坏的电脑被它免费修好了5、那个写出最烂代码的程序员，不但进了Google，还财务自由了！6、高能警告！这些极品网站有一手7、这个新规，将延长手机寿命 5 年！
8、我为什么放弃 C++，选择 C 语言编写个人项目？
8、我为什么放弃 C++，选择 C 语言编写个人项目？