【胡言乱语】开发工程师如何在互联网公司的业务流水线上打造核心竞争力？

天真的幻想站不住脚

"以技术安身立命",自从就读软件工程以来,就曾是我一直追求的目标,我相信这也是很多软件人的目标;只是参加业务开发后的种种让我觉得这个信条在(大部分)业务开发中,都只是一个天真的幻想,打造"技术专家"不仅缺乏养成的环境,也缺乏使用的机会.

拿自己来说,我所在的是一个市场上强敌环伺/处于发展初期/直接面向消费者的业务,近一年的开发工作主要可以归纳为:

1. 技术上:

   1. 熟悉公司的开发框架: 如RPC/微服务/Hive/CI/报表/监控等
   2. 开发健壮的业务代码: 加了try-catch/logger/null检测等的多层if-else代码
   3. 监控并排除线上问题: 临时hotfix/入口出口log/刷表/扩容等
   4. 学习和各工种配合的流程: 和产品/QA/前端RD/后端RD开需求讨论会/开Case审核会/设计方案评审会/进度和风险同步会/质量检测和总结等

2. 业务上:

   1. 熟悉业务流程并不断加深理解: 通过持续的story推进/项目/突发的线上bug/数据需求等

3. 总体上:

   1. 硬实力提高有限(也就是之前认为的"以技术为主的核心竞争力"),提高的部分主要是代码质量/责任意识/工具与框架使用熟练度,对于计算机/编程语言/算法/网络等重要而基础的领域的理解都没有进步
   2. 软实力提高,主要途径是融入现有技术团队和跨团队合作,提高的是流程落实/沟通能力/文档能力/风险控制能力

我真实的感受是作为底层的开发工程师,业务上并不需要多高的硬实力,基本的计算机课程完全能够满足开发业务和处理业务异常的需要,也就是熟练地使用公司提供的工具写出没有bug的满足产品需求的if-else型代码.而一些领域性较强的如数据库原理/操作系统/编译原理/算法导论等知识上层的业务不关心,更不会去使用.

这引起了一个矛盾,"以技术为主的核心竞争力"要求在技术上挖一口深井,针对某个细分的技术领域能够从原理/技术/工程一条龙的研究透,形成一定的技术壁垒,而业务RD的日常则停留在工程应用的最顶层,没有具体的细分领域可言,今天开发JavaWeb,明天开发搜索,后天说不定开发推荐系统了.而且业务RD在每天都被无止境的业务story/机动需求/各种会议填满的情况下很难有机会积累更多的有效时间把细分领域吃透,大部分对细分领域的理解停留在如何搭建环境/使用什么开源库/开源库有哪些坑等.

因此总的来说,业务RD较难拥有自己的技术深井,这对于一些有着"以技术安身立命"信条的人是难以接受的.

解决的办法其实很简单也很痛苦,如果你不打算或者不能换岗的话,那就放弃在细分领域深挖技术吧~

相较于技术上的硬实力，业务RD提升工程能力和个人软实力的机会则有很多:比如线上真实场景,多工种配合完成任务等.这也与互联网公司中业已升级的业务RD脱离或半脱离一线开发工作的现状相符.

升级者们不再需要实际进行业务编码,转而从事更高价值的工作:如管理业务RD/讨论大需求/设计总体架构/协调资源/规范流程等偏M侧的任务.

提高软实力可以对标Manager的行为,可以因地制宜的做几件事:

1. 提高管理能力: 在简单的技术/有限的资源上权衡并尽可能满足产品的要求
2. 提高工程能力: 凭借经验识别出产品/RD可能的风险;采取技术方法/开发规范增加业务系统的稳定性,减少质量缺陷
3. 提高表达/沟通能力: 无论是和产品/RD还是Leader沟通,做到清晰/简洁/有逻辑的表达
4. 提高业务能力: 对业务有自己的观点,参与把握业务的发展方向,有针对性的做好技术上的准备

在现实中生活

人力市场会萎缩吗？

公司中同是计算机专业的一线开发人员,除了业务RD,还有中间件RD(提供技术基础工程服务如大数据/数据库/RPC/容器/CI等)和运维同学.总的来说业务RD需要的知识面最广,但知识深度最浅;而中间件RD和运维都只局限于自己的技术领域,相对知识深度更深.
然而不管是哪种RD,我觉的未来都会面临的趋势是:

1. 业务RD的人数会随着业务的发展而不断变化.因为目前编码还是一项不能自动化的工作,一个人的代码产出很容易达到上限,交付时间不变的情况下业务扩容相应的业务RD也必须扩容,但是随着技术的发展业务RD的位置同时会不断被边缘化,对技术要求也会逐渐降低,不需要业务RD对技术的理解有多深刻,总体来说会用框架/会查bug/懂团队合作就行.
2. 中间件RD的人数会越来越少,但对技术专家的需求会逐步提高.因为随着开源的发展和技术的进步,当初需要自己开发的中间件目前开源社区中已经有成熟的框架,因此对底层RD的需求会逐步下降,但如果业务发展到了一个较高的层次而现有的框架已经无法满足时,比方说中间件部门有更广阔的目标,要将中间件服务虚拟化/云化提供给市场上的外部客户,这时候中间件业务就需要技术专家因地制宜来打造自己的框架了.运维也是同理,自动化程度的提高会逐步淘汰低价值的一线运维.

回忆19-20世纪期间工业从家庭小作坊到工厂到联合体的历史,业务RD也会一步一步从一种知识密集型工作走向劳动密集型工作.

如何应对危机感？

虽然story各不相同,但光就技术和流程而言是高度重复的,每一次开发都会重复几个常见的步骤,比如:

• 讨论需求
• 拆分story
• 和QA讨论Case
• 和相关RD定义开发方案
• 开发(开发DAO层/开发Service层/开发Web层)
• 和相关RD联调跑Case,修复Bug
• 测试通过上线
• 总结

经过一段时间的反复之后开发时甚至都不需要动脑,类似于大脑可以自动处理怎么骑车/怎么系鞋带一样,"无他,唯手熟尔".

但是必须指出:长期的重复非常可怕,会让人陷入泥泞的惰性和舒适区无法自拔.因此工作三年实际上却只有一年工作经验的案例在职场上屡见不鲜.

为了避免这种情况,有必要在工作中挖掘可以提高效率的措施,节约出必要的时间为在舒适区外生存做准备.比如在反复的开发中考虑提高效率,如:

• 缩短拆分task时间: 多进程同步进行
• 缩短开发时间: 缩短需求理解时间,多用类库少造轮子
• 缩短自测/返工时间: 提高代码质量
• 缩短联调时间: 拆分大联调为小联调,充分利用人力

梦醒了

生活不仅仅是工作,更不仅仅是眼前的这份工作,面朝未来,利用好时间这个最宝贵的资源,努力提升时间的厚度,丰富时间的色彩.

互联网正在快速发展,站在当前的位置很难看到远方是什么样子,也许我们只能怀着对未来的恐惧去"拥抱变化",在炮火密布的战场上冲锋固然可怕,但也只有咬牙向前一条路可走.

愿与屏幕前的你共勉