摘要：天真的幻想站不住脚以技术安身立命自从就读软件工程以来就曾是我一直追求的目标我相信这也是很多软件人的目标只是参加业务开发后的种种让我觉得这个信条在大部分业务开发中都只是一个天真的幻想打造技术专家不仅缺乏养成的环境也缺乏使用的机会拿自己来说我所
天真的幻想站不住脚
"以技术安身立命",自从就读软件工程以来,就曾是我一直追求的目标,我相信这也是很多软件人的目标;只是参加业务开发后的种种让我觉得这个信条在(大部分)业务开发中,都只是一个天真的幻想,打造"技术专家"不仅缺乏养成的环境,也缺乏使用的机会.
拿自己来说,我所在的是一个市场上强敌环伺/处于发展初期/直接面向消费者的业务,近一年的开发工作主要可以归纳为:
技术上:
熟悉公司的开发框架: 如RPC/微服务/Hive/CI/报表/监控等
开发健壮的业务代码: 加了try-catch/logger/null检测等的多层if-else代码
监控并排除线上问题: 临时hotfix/入口出口log/刷表/扩容等
学习和各工种配合的流程: 和产品/QA/前端RD/后端RD开需求讨论会/开Case审核会/设计方案评审会/进度和风险同步会/质量检测和总结等
业务上:
熟悉业务流程并不断加深理解: 通过持续的story推进/项目/突发的线上bug/数据需求等
总体上:
硬实力提高有限(也就是之前认为的"以技术为主的核心竞争力"),提高的部分主要是代码质量/责任意识/工具与框架使用熟练度,对于计算机/编程语言/算法/网络等重要而基础的领域的理解都没有进步
软实力提高,主要途径是融入现有技术团队和跨团队合作,提高的是流程落实/沟通能力/文档能力/风险控制能力
我真实的感受是作为底层的开发工程师,业务上并不需要多高的硬实力,基本的计算机课程完全能够满足开发业务和处理业务异常的需要,也就是熟练地使用公司提供的工具写出没有bug的满足产品需求的if-else型代码.而一些领域性较强的如数据库原理/操作系统/编译原理/算法导论等知识上层的业务不关心,更不会去使用.
这引起了一个矛盾,"以技术为主的核心竞争力"要求在技术上挖一口深井,针对某个细分的技术领域能够从原理/技术/工程一条龙的研究透,形成一定的技术壁垒,而业务RD的日常则停留在工程应用的最顶层,没有具体的细分领域可言,今天开发JavaWeb,明天开发搜索,后天说不定开发推荐系统了.而且业务RD在每天都被无止境的业务story/机动需求/各种会议填满的情况下很难有机会积累更多的有效时间把细分领域吃透,大部分对细分领域的理解停留在如何搭建环境/使用什么开源库/开源库有哪些坑等.
因此总的来说,业务RD较难拥有自己的技术深井,这对于一些有着"以技术安身立命"信条的人是难以接受的.
解决的办法其实很简单也很痛苦,如果你不打算或者不能换岗的话,那就放弃在细分领域深挖技术吧~
相较于技术上的硬实力，业务RD提升工程能力和个人软实力的机会则有很多:比如线上真实场景,多工种配合完成任务等.这也与互联网公司中业已升级的业务RD脱离或半脱离一线开发工作的现状相符.
升级者们不再需要实际进行业务编码,转而从事更高价值的工作:如管理业务RD/讨论大需求/设计总体架构/协调资源/规范流程等偏M侧的任务.
提高软实力可以对标Manager的行为,可以因地制宜的做几件事:
提高管理能力: 在简单的技术/有限的资源上权衡并尽可能满足产品的要求
提高工程能力: 凭借经验识别出产品/RD可能的风险;采取技术方法/开发规范增加业务系统的稳定性,减少质量缺陷
提高表达/沟通能力: 无论是和产品/RD还是Leader沟通,做到清晰/简洁/有逻辑的表达
提高业务能力: 对业务有自己的观点,参与把握业务的发展方向,有针对性的做好技术上的准备
在现实中生活 人力市场会萎缩吗？公司中同是计算机专业的一线开发人员,除了业务RD,还有中间件RD(提供技术基础工程服务如大数据/数据库/RPC/容器/CI等)和运维同学.总的来说业务RD需要的知识面最广,但知识深度最浅;而中间件RD和运维都只局限于自己的技术领域,相对知识深度更深.
然而不管是哪种RD,我觉的未来都会面临的趋势是:
业务RD的人数会随着业务的发展而不断变化.因为目前编码还是一项不能自动化的工作,一个人的代码产出很容易达到上限,交付时间不变的情况下业务扩容相应的业务RD也必须扩容,但是随着技术的发展业务RD的位置同时会不断被边缘化,对技术要求也会逐渐降低,不需要业务RD对技术的理解有多深刻,总体来说会用框架/会查bug/懂团队合作就行.
中间件RD的人数会越来越少,但对技术专家的需求会逐步提高.因为随着开源的发展和技术的进步,当初需要自己开发的中间件目前开源社区中已经有成熟的框架,因此对底层RD的需求会逐步下降,但如果业务发展到了一个较高的层次而现有的框架已经无法满足时,比方说中间件部门有更广阔的目标,要将中间件服务虚拟化/云化提供给市场上的外部客户,这时候中间件业务就需要技术专家因地制宜来打造自己的框架了.运维也是同理,自动化程度的提高会逐步淘汰低价值的一线运维.
回忆19-20世纪期间工业从家庭小作坊到工厂到联合体的历史,业务RD也会一步一步从一种知识密集型工作走向劳动密集型工作.
如何应对危机感？虽然story各不相同,但光就技术和流程而言是高度重复的,每一次开发都会重复几个常见的步骤,比如:
讨论需求
拆分story
和QA讨论Case
和相关RD定义开发方案
开发(开发DAO层/开发Service层/开发Web层)
和相关RD联调跑Case,修复Bug
测试通过上线
总结
经过一段时间的反复之后开发时甚至都不需要动脑,类似于大脑可以自动处理怎么骑车/怎么系鞋带一样,"无他,唯手熟尔".
但是必须指出:长期的重复非常可怕,会让人陷入泥泞的惰性和舒适区无法自拔.因此工作三年实际上却只有一年工作经验的案例在职场上屡见不鲜.
为了避免这种情况,有必要在工作中挖掘可以提高效率的措施,节约出必要的时间为在舒适区外生存做准备.比如在反复的开发中考虑提高效率,如:
缩短拆分task时间: 多进程同步进行
缩短开发时间: 缩短需求理解时间,多用类库少造轮子
缩短自测/返工时间: 提高代码质量
缩短联调时间: 拆分大联调为小联调,充分利用人力
梦醒了生活不仅仅是工作,更不仅仅是眼前的这份工作,面朝未来,利用好时间这个最宝贵的资源,努力提升时间的厚度,丰富时间的色彩.
互联网正在快速发展,站在当前的位置很难看到远方是什么样子,也许我们只能怀着对未来的恐惧去"拥抱变化",在炮火密布的战场上冲锋固然可怕,但也只有咬牙向前一条路可走.
愿与屏幕前的你共勉
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/67278.html
摘要：导读本文介绍了基于技术的企业级应用容器平台，从云的定义云服务分类，到用友云基础平台平台总体架构架构预览部署架构平台核心价值和核心竞争力，阐述基础平台成为广大传统企业数字化转型的一把尖刀。 导读：本文介绍了基于Docker技术的企业级应用容器平台，从云的定义、云服务分类，到用友云PaaS基础平台、平台总体架构、架构预览、部署架构、平台核心价值和核心竞争力，阐述PaaS基础平台成为广大...
摘要：小蚂蚁说在金融级互联网产品持续交付方面，蚂蚁金服积累了丰富的经验和最佳工程实践。金融互联网产品最核心的两个关键词，第一个就是金融。 小蚂蚁说：在金融级互联网产品持续交付方面，蚂蚁金服积累了丰富的经验和最佳工程实践。在2018年ATEC技术探索大会上，蚂蚁金服解决方案架构师吕中邦（凤启）从行业背景出发，分析了金融级互联网产品持续交付的核心挑战，从更快更早地交付价值和守住技术风险底线保障交...
摘要：华为副董事长轮值董事长徐直军发表了题为加速智能，共创未来的演讲，他呼吁中国政府和企业抓住人工智能带来变道的战略机遇，构建面向未来的竞争力。 智能网联、于斯为盛，2019互联网岳麓峰会于4月1日在湖南长沙开幕。华为副董事长、轮值董事长徐直军发表了题为《加速智能，共创未来》的演讲，他呼吁中国政府和企业抓住人工智能带来变道的战略机遇，构建面向未来的竞争力。华为轮值董事长徐直军：加速智能，共创...
摘要：到今年月，华为轮值董事长徐直军于软博会上的演讲中指出要努力把华为云打造成软件企业开发和运营的平台。这条线贯穿华为云方针的始终。不碰数据，做伙伴的云平台，目前华为云进展如何在月日日的大会上，华为云向伙伴交出了他们的答卷。谋定而后动，不打无准备之仗向来都是华为的风格。从2017年3月成立云BU，正式宣布进入公有云市场，到2018年7月进入Forrester发布的《中国企业公有云平台》领导者象限，...
阅读 829·2021-11-22 15:33
阅读 3129·2021-11-08 13:20
阅读 1007·2021-09-22 10:55
阅读 1929·2019-08-29 11:08
阅读 623·2019-08-26 12:24
阅读 2916·2019-08-23 17:15
阅读 2050·2019-08-23 16:12
阅读 1766·2019-08-23 16:09
