天博程序员做技术开发（如中间件、数据库）还是业务开发？

　　天博平时也跟一些研发朋友说过自己目前工作岗位，一些开发朋友听说我在架构平台部做基础组件研发的工作就改口开始叫我大佬。其实大佬两个字，我真是受不起的。虽然从业了几年，但一直觉得自己对这个行业的认知只是冰山一角， 离真正的行业大佬的差距那不是一丁点儿。

　　在业界，隐约有一点点鄙视链，觉得做基础组件更加底层，技术更深入，就更牛。但其实并不是这样。我觉得业务研发工程师和基础组件研发工程师就是工作岗位不同而已，要做得好，都有各自岗位的难题要去解决的。

　　因为之前做过业务研发工程师，现在在从事基础组件研发工程师的工作，今天想唠唠我对这两个岗位的看法。

　　之前做业务研发工程师的时候，的确有时候只是需要写一些基础功能，改改前端的页面，做一些很基础的增删改查的工作。但其实这些都是我在实习期的工作范畴。随着工作经验的累加，就需要去承担更复杂的工作。

　　在一些专业性比较强的行业，比如银行，物流行业，你除了要会技术，还要学习该行业的各种专业术语，业务知识。

　　而和产品同学的沟通，其实也很需要功力的。大部分产品同学是不会技术的，他只能跟你讲他想要什么功能。初级的开发人员，可能就是把产品需求翻译成代码就完事了。但实际上只是这么做是不太够的。

　　简单举个例子，比如如果没有跟产品同学确认好这个需求哪些是可能会变化，哪些是不会变化的，那么你就无法针对性的去做抽象设计。产品同学跟你说需要开发一个接入支付宝的支付流程，你说简单，一顿操作迅速就搞定了，结果过几天，又跟你说要和微信支付合作，如果之前的设计没有预留好这个扩展，那就是要去改造原有的支付流程，这样的改动可能就对原有已经接入支付宝的流程造成风险。这也是常说的对扩展开放，对修改关闭的设计原则。因此也是需要熟练掌握各种设计原则，熟记一些常用的设计模式，针对各种业务场景去做抽象设计。

　　在充分理解了产品的需求，以及了解清楚未来可能会变化的需求点。你还要结合业务场景预估需求的流量，从而能够去做好稳定性的建设。比如秒杀活动的场景，你还要考虑结合消息队列去设计，比如对查询效率要求高的，你可能要结合缓存去设计，或者还可能要做数据库读写分离天博。再比如写入数据库的数据并发太多，你还可能要做分库分表的设计，做分库分表的设计前你还要考虑未来可能不一定是按照分库分表的分键字段去查数据，又涉及到数据异构的问题。对大数据搜索查询要求高的，你可能还要结合Elasticsearch去设计等等。甚至必要的时候，你还要考虑一些安全性的问题。

　　说了这么多的，就是想说做业务研发，不仅要学习行业知识，还要做业务的抽象设计，并且还要充分掌握各种组件的使用场景，想要做到恰如其分的设计和开发也是件不太容易的事情。

　　在架构平台部门工作，我负责过监控系统的研发，职责就是做能及时并精确发现问题的监控。我们做了全链路监控，日志监控，以及度量指标收集这些常规的监控，也开发了告警系统去做故障预警。

　　之后我又负责了基础组件，包括服务化框架，注册中心，配置中心，以及一些基础组件客户端（memory cache,redis,mysql ）等，职责就是做好公司整个基础架构的高可用。

　　日常主要是结合公司的业务使用场景，做前期一些技术选型，以及后续改造和维护，很多时候需要自己去阅读开源代码，比如之前引入了skywalking 做监控，需要改造源代码，针对公司内部的一些客户端组件添加埋点，添加一些新的度量指标的收集。再比如微服务框架引入注册中心nacos，也对请求nacos做了本AZ优先，跨AZ备份的源代码改造。偶尔遇到一些线上问题，涉及到这些开源代码的bug，也需要硬啃开源代码，掘地三尺，找出问题。有时候也会有没选到合适的开源组件的时候，就要自己去做研发，比如我最近就是针对公司现有的延迟队列中间件，在研发适配的延迟队列的客户端，主要是提供基于注解的使用方式，便于业务开发同学更好的去接入使用。

　　做基础组件研发也有一些比较难的课题的，比如引入新的技术框架或者技术组件，如何去推动业务无感升级就是一个难题。

　　另外随着不断演进，如何更精准的帮助业务服务做故障根因分析，如何帮助业务服务做到故障自愈，如何提前预估流量上升，做整条业务线服务的自动扩缩容等，都是比较复杂的问题。

　　回想起之前做业务研发的时候，我最深刻的记忆就是各种开会。一般是一两周一个迭代，每个迭代前开需求研讨会，然后每天也都会开早会，沟通工作进度，每个月开总结会，反思过去一个月的问题，总结接下来要怎么做才更好。总之就是，生命不止，会议不停。而我现在做基础组件研发，项目周期会比较长，我们就是每周开个会沟通一下进度和问题，其余时间就是做好自己的事情就可以天博。

　　做业务研发会比较频繁的和测试同学还有产品同学去配合，项目内部女生会多一些，平时也会感觉大家交流的比较多，很多人可能会比较喜欢这种氛围，觉得男女搭配，干活不累。而我现在做基础组件研发，绝大多数都是男生，如果不是工作遇到问题啥，一般比较少交流，大家就都是埋头做自己的事情。比较直观的一个对比，就是目前坐我左手边的就是一个业务项目组，经常听到他们男生女生讨论问题传来欢声笑语。

　　在我合作过的一些同事里，有的人比较喜欢多开会多交流，觉得一直埋头苦干，很沉闷，有的人比较喜欢安安静静搞技术，不希望被频繁的打扰。因此萝卜青菜，各有所爱，选择自己喜欢的就好。

　　业务研发岗相比基础研发岗，其实市场上的就业机会会更多一些。这个打开招聘软件就看的出来了。

　　想走管理路线的，就是:业务研发-晋升开发经理岗位-技术总监

　　不过很多时候并不是绝对的，有些时候也都是有交叉的，比如我现在虽然做基础组件研发，也还有在独立负责维护一个业务项目。一定程度上也还算是半个业务研发。而一些业务研发同学也会做技术选型和基础框架封装的工作。

　　其实没有什么很高大尚的原因，就是做了两三年业务研发，想换换口味，玩一点不一样的，就去尝试面试基础研发的岗位，因为有针对该岗位要求做一些面试准备，所以没有什么曲折的故事，就比较顺利的通过并入职了，这一做就做到现在了。

　　目前还是比较喜欢现在这种基础组件研发的岗位。经常能去看看业界一些新的技术框架，做一些技术选型，也能去阅读一些比较优秀的源代码，经常看到一些优秀的代码，觉得作者设计得真是妙啊。

　　最重要的是，部门内部有比较多的技术专家，大佬们都比较谦逊且无私，跟他们去请教问题，也都很受益。这也是我写公号号的一部分原因，除了可以做自己的技术总结，另一方面平时跟大佬们的沟通，也可以整理输出他们的一些技术想法。就好像《论语》也是孔子的弟子和再传弟子整理的一样。

　　这边还想说说做业务研发比较多时间花在业务梳理上的问题。这应该也是很多业务研发同学感到矛盾和焦虑的点，平时工作为了把项目做好，大多时间都是在兢兢业业的梳理业务需求，对一些新技术和开源组件的底层技术比较少关注。结果想跳槽时人家面试官一上来就各种底层技术的问你，感觉工作经验还没派上用场，面试官已经让你出门左拐，回去等通知了，而这通知遥遥无期。

　　除了跳槽尽量跳跟自己之前做的业务相似的岗位这种基本原则之外，最好平时工作中养成写文章做总结的习惯。比如排查一个有技术含量的bug可以总结记录下；做了一个比较好的设计方案，也可以总结下，顺便分析分析自己用到了哪些设计原则；平时遇到技术盲区，也可以把对应的技术知识再系统学习总结下。写文章总结的时候你会发现自己可能对这个问题理解的还是不够，这样就会再去学习解惑，让输出带动输入。这样时间长了，你会发现自己持续在积累，不仅能把自己的工作做的更好，即便有想跳槽的时候，因为你都有在总结，表达起来也会更流畅，甚至可以把你的总结博客发给面试官看看，我相信这是会加分的。

　　此外，最好给自己制定一些学习的计划，其实人都有偶尔想躺平的想法，也有偶尔情绪小丧的时候，这都很正常，因此做一些计划，比较能推动一下自己，flag总要先立一下，如果你完成了flag，那恭喜你，你很优秀！如果因为偶尔躺平了，flag没完成，也不要焦虑不安苛责自己，调整自己的心理状态，跟自己和解也很重要。不过我相信跟你之前没做学习计划相比，你也走出去一大步了。收拾收拾心情，继续立下一个flag。你会发现，每阶段的小小成长，其实也是能带来很多幸福感的。最后，欢迎关注地球号： 程序员榕树