0 你的问题，我知道！
本文深入T型图“竖线”的立足之本：专业技术 + 技术赋能业务能力。研发在学习投入精力最多，也误区最多。
某粉丝感发展遇到瓶颈，项目都会做，但觉无提升，想跳槽。于是，梳理过往经历。
他觉得业务小，阻其技术发展。但细问，这系统用户量百万级，一点不小，只是淡季、旺季明显。旺季时常卡死、提交延迟。
你这核心系统主程，咋看待这问题，啥优化思路？他皱眉说不出。我看他还做过重构
Q：系统为啥重构？
A：原框架太老，现在大家都用新框架。而重构的收益，说不透……
这是典型只看到技术能力最表层技能，觉得会编程，做需求开发上线就够。但研发硬技能不止于此。
1 专业技术能力
如用冰山模型形容，更多藏在冰山下“看不见能力”。如Javaer日常Java编程，会用编程工具如IDEA，还会Linux命令，知道后端必备MySQL、Redis、MQ的API咋调，还能遵循编码规范和稳定性要求……看得见能力。
但更多看不见能力藏在山下。很多 JVM 原理，数据库原理等很多知识和能力需具备。
若研发仅注意力放在冰山上，大概率会：
- 很快沉溺瓶颈。觉得每天就CURD，没成长。若研发完全不懂设计原理，不懂咋写好代码，其环境也无好设计和CR机制，长久以往，系统成“垃圾山”，技术债越垒越高，完全无法维护。《代码整洁之道》说“不管你多敬业加班，面对烂系统，仍寸步难行，因你大多精力不在开发需求，而是应对混乱”。
- 变成定制螺丝钉。若你在大厂，会发现大部分底层服务如Redis、MQ有专人维护，他们还在上面定制开发。如把它们全当黑盒，出问题就找接口人，也非不可。但硬伤是协作成本高，而且你真变“螺丝钉”，“定制的螺丝钉”，只能在特定体系下生存，换个系统可能就“拧不上”
个人职业发展角度，若研发专业技术能力仅专注“山上”，就真是个“搬砖”。越在冰山之上的能力越简单、门槛低，越底层能力，鲁棒性越强：
- 曾经团队技术栈更换，从PHP全部重构为Java。之前PHP技术栈不错的，几月语言熟悉，在 Java技术栈仍不错。作为后端开发，难在网络通讯、存储、MQ、系统设计、故障排查等更底层经验积累。语言学不难，智商正常2周入门，后续只是需熟悉
- 前端常抱怨前端技术更新迭代太快，学不过来。而从业15年前端大佬指出前端工作本质：前端交付用户使用体验，而使用体验核心在交互。前端要多花时间了解交互及背后渲染，理解底层CPU、GPU渲染原理，弄清标准化端容器（如浏览器）工作原理。
因此，为让技术成长之道更长，让“兼容性”更高，能解决更复杂问题，适配更多样环境，要更关注冰山下技术，“往下沉”。
下沉方向
Javaer往3方向，可大提升技术深度。
语言深钻
底层及高级玩法。
能日常基础需求开发后，再深入掌握更高级使用。如了解JVM原理，知道Java系统调优方法，让服务更轻盈。
99%程序员一辈子没机会写JVM代码，但研发仍需了解技术底层实现原理，因为这是你解决难题、为企业创造价值前提。也是延长职业赛道的唯一有效途径；更是面试必问！
周边服务
与你日常工作息息相关的底层服务原理。
如：
- MySQL了解透彻数据库引擎、事务、索引等底层原理
- MQ清楚底层实现，了解常用MQ，技术选型时知啥场景选啥
熟悉这些最基础内容，是为日常工作出现问题、故障时可高效应对，更重要的是你的工作域变大，不再一群黑盒。
系统设计
常见设计原理、应用、经典场景的设计。
研发专业能力的成长：刚开始仅开发小功能，到维护模块，再到子系统，甚至一个业务域系统。系统设计能力就关键了。需将相应设计原理，具体应用方法，还有经典场景设计思路都搞透。
如了解高可用系统架构设计原理和实践，你就对公司这样那样“稳定性红线要求”更深理解，甚至主动思考自己做的模块强依赖、弱依赖啥服务？如需降级，咋设计？
当你了解语言底层、底层服务原理及系统设计，你就把自己“技术世界”撑大，也给自己发展打下更坚实基础。若很有技术热情，愿研究新技术，地盘稳定后，学习速度也会加快。
2 技术赋能业务能力
专业技术往下渗透，了解底层原理相当于研发工作的“微观环境”撑大，进一步，就要去理解技术周围系统。技术作为工具要回到真实场景衡量价值。
2.1 技术和业务啥关系？
技术技能好比一个锤或锯，业务好比要做一张桌。做张桌很多工序，需设计，需锯木，需锤钉，需打磨，需抛光，可能还需营销推广……
若看不到桌全貌，就难知啥时需用锤，要锤几次，咋锤才更精准。即业务研发价值绝不仅代码写多好、无Bug、接口TPS多厉害，还看到底用技术解决多少业务问题，带来多少业务增量，给客户创造啥价值。完全不了解业务时，空谈技术就耍流氓，空中楼阁不长久。
很多研发把自己发展只定义在专业技术能力，这是惯性。职场初期，工作要求被定义很清晰，这是公司高层和各级管理者定义。如电商商家端团队要找个Javaer，那电商系统划分，如用户、交易、商家端等框架划分，还有整系统具体要承接功能、解决问题，甚至解决问题方式及对这岗位考核，都是提前定义好，只是需人“填坑”。
我们要做的，就是从“坑”走出。到一定年龄，给企业的价值更多是在一些不确定、不清晰事，去定义啥是有价值，从而定义自己的工作。就像刚开始有锯、有锤，那做桌时咋用这些工具？
就是“咋用”，去定义这些事，是更大价值所在。研发想发挥更大价值，追求自身长远发展，除技术本身技能，须懂技术赋能业务。
2.2 咋技术赋能业务？
① 了解业务
要理解商业价值，如清楚当前业务重要指标，要达成需解决啥问题，啥可技术手段解决？如企业用OKR做技术管理，那就是业务重要的O。
② 定义问题
当你找到要解决的问题，就要把这业务问题转为技术问题。
③ 解决问题
研发最擅长，技术手段解决问题。
④ 数据回证
提前做好数据埋点，通过数据统计论证最开始设想，检验是否真正解决问题？啥收益？
2.3 实战
他客户端研发，所在部门负责外卖物流配送系统，即管理和调度外卖配送员。随外卖发达，公司越重视骑手安全，今年业务有考核指标关于骑手配送过程事故率。如配送1万个订单，出现交通事故率控制多少。你会咋做？
① 了解业务
想想骑手配送事故，和啥相关？
可能跟对骑手考核相关，如：
- 要求30min送达，不过这是业务运营规则，跟市场环境相关，技术干预少
- 可能和调度系统相关，如给骑手派太多单或不顺路，导致骑手赶时间，不得不超速，甚至闯红灯，造成交通事故。这是调度算法团队解决议题，客户端研发参与感少
没法了？但他线下调研骑手配送。发现很多骑手送餐过程，一只扶把手，一只刷手机，因为可能来新订单，而骑手要抢单。这过程增加事故发生率。可用技术解决？可！用语音交互，这就是技术助业务提升点。
② 定义问题
将业务问题转化为技术问题。刚才就是语音交互系统问题。但回到业务场景，不够精准：
- 骑手配送在户外，快速移动、无稳定电源，耗电量是问题
- 配送过程环境声音嘈杂，有的地方可能网络环境还差
所以，问题进步精准定义为需低功耗，弱网、噪音环境可用语音交互系统。
精准定义问题后，技术手段解决问题的第三步就不难。
最后，第四步数据回证。可能AB测试，对比上线前后期骑手事故率的变化，用数据证明收益。
这就是技术赋能业务的完整闭环。
3 总结
本文讨论研发硬技能。专业技术能力，不仅得编程，排查问题，更需深钻，知其然，知其所以然，不断打磨技术。还不够，还得把技术放现实去用，历练不同场合“炫技”能力，即用技术赋能业务。
职业发展角度，专业技术能力、技术赋能业务能力是研发岗的根本，是更好发展的基础。抛开这些，技术能力还帮历练好的抽象能力和务实精神。
互联网是把现实搬到线上，那这“搬”就是靠研发把现实抽象成线上的数据结构、对象、模块和系统来实现。系统设计、编码过程，就是历练从现实的“现象”抽丝剥茧，提炼本质的能力。
代码界不容虚头巴脑，手抖写错字符，就能让庞大系统轰然倒塌。要求极度精准工作磨炼下，大多研发就很务实，能静下和深扎，能啃硬骨头。这种抽象复杂事物本质的能力以及极其务实的精神，都是职业发展能航行更远的燃料。
4 FAQ
Q：研发咋在专和通之间保持合理平衡？
A：无比例，个人经验根据自己工作阶段、当下工作需要和兴趣综合判断。
如工作前几年，定以专为主，至少一个技术栈做到熟悉，解决工作中大部分问题，当你在一个领域深钻后，深度会帮助更好做广度。
而当你工作五六年，很多基本面技术已掌握，可适当拓展广度。同时结合当前工作需要，这里面最基础逻辑是技术所有的东西光学很难掌握，要有好的历练场所。如根据工作的需要，针对性拓展广度和精钻深度，又能回到工作中运用是最好的闭环。
最后是兴趣，如对某方向感兴趣，也会帮助你在广度或深度拓展。 所以无绝对比例，或者这个平衡，是根据你工作的阶段、工作场景的需要和你自己的兴趣来动态调整的。
本文由博客一文多发平台 OpenWrite 发布！
